[ntp:questions] 500ppm - is it too small?

David Woolley david at ex.djwhome.demon.invalid
Fri Nov 13 22:06:33 UTC 2009

Unruh wrote:

> 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
> 500ppm.AFAIK)

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 mailing list