fasttime gain and loop delay adjustment

All tests on this page so far conducted on Athlon64 2.2 GHz, Linux 2.6 under very light workload.

100 2-hour tests were run for varying PLL gain. Until now the gain has been fixed at 0.1; now it is tested for all values 0.01, 0.02, 0.03, ... to 1.0. The tests were run at the same time, but the starting times were staggered to alleviate contention between the processes. I will not show all the results here, just some representative ones.

Each graph shows the offset as measured by the daemon thread (the thread doing the calibration adjustment). Shown first are runs for gain = 0.01 to 0.05:

0.01	0.02	0.03	0.04	0.05

Things to note:

• The spike at approximately 2300 seconds is present in all runs, indicating it was jitter in the system or TSC clocks, and not a fault in the algorithm. More clock filtering should be applied to get rid of these (I have seen some sort of spike in most test runs to date).
• At these very low gains the derived clock is quite stable and quick to recovers to within a 5us error in 200 seconds. The higher gain runs recover faster.
• All these runs converge to within 5us almost instantaneously, and afterwards remain within 1us offset, discounting the spike.

Increasing the gain increases oscillation after the spike. Shown below are runs for gain = 0.05, 0.1, 0.15, 0.2, 0.25:

0.05	0.10	0.15	0.20	0.25

Increasing the gain further completely destabalises the clock. Shown below are the runs for gain = 0.3, 0.4, 0.5, 0.6 and 0.7:

0.30	0.40	0.50	0.60	0.70

Longer loop delay

The tests above begin with a loop delay of 1 second, which is permitted to increase in increments of 1 second when the clock is sufficiently stable. Shown below are the loop delays for runs with gain = 0.1, 0.2, 0.3 and 0.4:

0.10	0.20	0.30	0.40

As hoped, the loop delay steadily increases except after the spike, which reduces it for some time, and in the cases where the clock stabilised, increases again.

The set of 100 tests were run again, this time with an initial loop delay of 15 seconds, increasing by 5 seconds when stable enough (and decreasing when stability is lost). Offsets for gain = 0.01, 0.02, ... 0.05:

0.01	0.02	0.03	0.04	0.05

There is no spike in this data; perhaps due to the increased loop delay (or possibly by chance). As expected, the derived clock takes some time to stabilise around 0us (up to 1000 seconds). Increasing the gain improves this:

0.05	0.10	0.15	0.20	0.25

As with the 1 second loop delay, increasing the gain too much destabilises the clock:

0.70

Loop delays are shown below:

0.10	0.20	0.30	0.40

It is encouraging to see the loop delay exceed 200 seconds without affecting the stability of the clock.

Next steps

• It appears the aim will be to increase the gain large enough to quickly converge the clock without oscillation. Larger loop delays appear to allow for larger gains, but this will need to be checked.
• Try to allow the loop delay to increase faster; changing the way the increment/decrement decision is made might be the best way, in addition to increasing the increment and starting value.
• Add filtering to the clock input to eliminate small spikes (there is currently a very coarse filter to catch errors greater than 20ms).
• Check these changes on other machines, undoubtedly each will have its own "sweet spot" for the gain; a compromise will probably need to be found.