[ntp:questions] 500ppm - is it too small?
david at ex.djwhome.demon.invalid
Fri Nov 13 22:06:33 UTC 2009
> adjtime does not change the rate at all except to eliminate the input offset. Ie,
> you cannot use it to slow down or speed up the clock in a predictable manner. You
Nonetheless, this is how ntpd worked before the introduction of the
kernel time discipline, on operating systems that never had it, and when
people use -x, or otherwise try to stop ntpd stepping.
> give it an offset and it slows down or speeds up the clock to eliminate that
> offset ( something like the adjtimex -s option. And that does not limit itself to
The typical implementation of tickadj was to add an excess +/-5 counts
to the time every tick. That means with the then typical 100Hz clock,
the software clock ran at -500ppm, 0ppm or +500ppm relative to its
nominal frequency. That set an absolute limit of +/- 500ppm on the slew
rate. The ntpd v3 user space discipline applied a partial time
correction every four seconds, so the clock frequency was effectively a
square wave and the phase error a sawtooth. I haven't looked at the
ntpd v4 user space discipline, but I think it applies correction every
I think some OSes used only +/- 1 count, so were limited to +/- 100ppm.
Others could use less than 5 counts on the last step of a correction.
More information about the questions