This web page provides the details for the data that gives the "peter35" (the Linux Reported Load Averages accuracy improvement patch (Commit-ID: Pending)) line of this graph (although the process was the same for the other line):
The experiment was done on a Ubuntu server 12.04 running a kernel with the proposed patch back edited and referred to as "peter35".
This experiment was done with one process and low frequency, low load conditions.
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 script that executed the main program was manually edited from an older auto-generated one, therefore the source program is not listed, as it is obsolete.
The script, as a text file, that was used to run the main program under the desired conditions.
The raw data as a text file.
The oversampled data as a text file. (warning: large file ~ 1 megabytes)) This data contains a reported load average sample every 5 seconds, i.e. it contains every reported load average sample. This data is sometimes used to correct bad data or outlyer samples. Herein, it was also used for the below graphs.
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 (sometimes a cron job or something runs and might bias a single sample).
The oversampled data was plotted and observed for anomalies:
There appears to be a beat frequency somewhere around 23 to 26 hertz. This is a highly aliased sampling system, only taking a load sample every 5 seconds, so beat frequencies are to be expected. However, a more detailed experiment was run to acquire more detailed data in the frequency range.
The desire is to prove if this is truely a beat frequency or some race condition, or timing window, or something else, perhaps related to the 10 tick grace period (250 Hz / 10 = 25 Hz).
Baiscally the same experiment was run, but with the frequency sweep from 21 to 26 hertz at 0.1 hz steps. The actual load was increased from 0.20 to 0.35.
The oversampled data was plotted and observed for anomalies:
Why do we not see the larger low "beat frequency" amplitude modulations as were observed in the previous test above? The whole purpose of this test was to attempt to zero in better on the exact beat frequency. Note that due to the filtering on the reported load averages, the closer the beat frequency get to 0, the larger the amplitude of the oscillations.
The change in load also has a slight effect on the actual sleep frequency, just enough reduce the beat amplitude.
By tweeking the 0.35 load parameters, to better match the frquency of the 0.20 case, larger magnitude oscillations were obtained(supports the beat frequency argument).
By switching to Peter Zijlstra's conusume.c program (uses system calls for the time base (waiter.c does not, on purpose) the beat frequency was able to be tuned to 0.
On s15.smythies.com the command "../c/consume 40.0 24.98" (40% load at 24.98 Hetrz sleep frequency (the syntax has been changed from Peter's original code) gave reported load averages of 1, with no beat freqeuncy.
I should be able to do this at any many exact spots, for example around 5 Hz. The command "../c/consume 40.0 4.996" gave a reported load averages of 1.
Conclusion: Residual amplitude modulation is a result of signal aliasing, which can be expected from a masively undersampled system. While it showed in a test environment it is less likely to show in a real environment, with truely asynchronoous events.