This web page provides the details for the data that gives this graph:
The experiment was done on a Ubuntu server 12.04 running a kernel with the "peter35"proposed patch back edited (Commit ID: 5167e8d5417bf5c322a703d2927daec727ea40dd).
With older kernels prior to commit c308b56b5398779cd3da0f62ab26b0453494c3d4, every data point in the above graph would be at a reported load average of 0.0
With newer kernel, prior to this patch, high reported load averages can occur at light loads with high context switch frequencies and low reported load averages can occur at high loads and extremely high context switch frequencies.
Idle enter / exit frequencies were selected to always add up to 180 hertz and also to avoid going below 25 hertz and avoid known alias frequencies.
This gave: 6 processes at 30 hz; 5 processes at 36 hz; 4 processes at 45 hz; 3 processes at 60 hz; 2 processes at 90 hz; and 1 process at 180 hz.
To avoid discontinuities in the reported load averages, and to maintain predictable execution loop times in the main program, the cpu frequency governors were set to powersave mode.
The main program, as a text file.
The program, as a text file, that generates the script for execution conditions of the main program.
The resulting script, as a text file, edited for one hour (4 time constants of the 15 minute load average) of extra settling time between number of processes changes.
The raw data as a text file.
The experiment was run in two parts:
The oversampled data for part 1 as a text file. (warning: large file ~ 1.5 megabytes)) Sometimes used to correct bad data or outlyer samples.
The oversampled data for part 2 as a text file. (warning: large file ~ 1.8 megabytes))
The main program parameters were selected to print an update every 10 seconds and to run for 30 minutes.
Obviously, the server can not be used for anything else during the execution of this test, or the reported load averages might be biased. See the background (idle) results which verifies that the background can be ignored.
For the 5 and 6 processes cases, the reported load averages are in error at higher loads, even more in error than the previous solution. Why?
This appears to be the area where the use of the CPU's begins to rotate around somewhat. At lower loads, the use of CPU's doesn't chnage very "often".
The 15 minutes oversampled reported load average data was plotted:
Actually, all of the 1, 5, and 15 minute Reported load averages were plotted.
The above plots don't reveal much, except perhaps some aliased frequencies (where the peak to peak amplitude of the 1 minute average is larger).
Is there more deviation in Reported Load Averages at a different frequency? The following graph takes the 5 processes cases, 0.7 load per process (the worst deviation in the above graph, at 36 hertz per process) and sweeps the frequency in that area:
Samples were taken and added for a Kernel 3.5 RC2 for comparison.
The maximum deviation is -17% at about 37.5 Hz (approx, as the predicting program deviates some from reality at higher loads).
A broader range of frequencies was examined, not revealing anything new:
