The graph is not load but processor time. Here is a snapshot of the Performance Monitor, sampling at one second intervals, for dodicat's program. Since the max load is without the limits then it can be regarded as unusual and was not sustained for very long. The ± 1.22 may be regarded as an indication of the volatility. Over a session of 120 seconds we have a current load of 3.13%, a max load of 5.66% and can say, with 95% confidence, that the load is between 2.12% and 4.56%. I have coded the above and get this with one of dodicat's master pieces. So, we need to wait for 30 seconds before accepting the confidence interval. I have opted for the normal distribution and am now sampling, and displaying, at one second. I do not want to bore you but for 30 or less samples we should use the t-distribution and for greater than 30 samples we should use the normal distribution for our % confidence calculations. Looking at the time graphs of the Performance Monitor it seems to me that we should use balanced intervals or, in other words, two sided confidence limits. Here we would have not just an average but an interval encompassing that average where we can say, something like, "We are 95% confident that the CPU load is in the interval 18 - 22." With a balanced interval I would prefer to use 20 ± 2. There is a statistical method worth looking at and that is confidence intervals. The slower the sampling rate the more important the Max Load metric becomes. However, a slow sample rate is not a smoothing mechanism. Contrary to my initial approach of faster sampling, I was thinking about digital sound sampling for audio CDs, the slower the sampling the lesser the volatility. The 'average of 8' tweak needs a fast polling, so I now questioned the fast polling. To my mind there is no case to not use the synchronizing tweak. In my case I questioned the early 'average of 8' tweak, preceding the later synchronizing tweak. This happens with tax law where a consolidating tax act is introduced after several 'tweaking budgets'. Microsoft do this with consolidating updates. Some early tweaks could be dispensed with by virtue of later tweaks. When we have a tweaking regime it is sometimes worthwhile to halt the proceedings and ask if it is necessary to keep all the tweaks made to date. If we poll at the system interrupt then when we subtract two readings we 'eliminate' the interrupts resolution so it doesn't matter if the resolution is 1ms or 16ms or anything in between. My next tweak was to synchronise the polling. The Performance Monitor also has a display delay corresponding to the refresh rate. On the face of it then it looks like none of them are employing conditioning, but I am. If we 'dial in' the slowest refresh rate with any of the above there is a corresponding delay before the first readings are displayed. Since we are examining CPU Load, % CPU usage, then, clearly, we need at least two readings. Your suggestion of having large intervals got me to wonder what the above would look like when using large intervals. Mine are not: The polling rate is 8Hz and the display rate is 2Hz. A polling rate and a display rate may not be the same. What none of them are clear about is the polling rate employed. Task Manager, Process Explorer and Process Hacker all have the option to choose different refresh rates, up to 10s with the latter two. My logic was to try and smooth out some of the volatility. The oldest reading of eight is dropped, a new reading taken and the average of 8 is calculated. I am doing that with the average session load. You could implement a moving average or two. I mention this because we would not see this behaviour when the average session load was only being reported at the end of monitoring. If your app then bursts into activity again the current load will reflect that and the average session load will start to rise. The average session load will now start to fall.
If, for some reason, your app enters a quiet period then the current load may show as zero for that time. Of course, if we vary the load during a session that will be reflected in the current load, the average session load will be just that and be influenced by all the loads since the session started.Īdded: If you have an app which is active throughout its session, such as a graphics app, then whilst the current load may be going up an down the average session load should enter a steady state. I tried a variety of loads and it is now 'bang in line' with what Process Explorer and Process Hacker seem to be showing. For some reason the average session load was showing as an over estimate so I have brought it in line with the 'averaging of 8' that the current load is subject to.
0 kommentar(er)
