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

Unruh unruh-spam at physics.ubc.ca
Fri Nov 13 23:41:33 UTC 2009


David Woolley <david at ex.djwhome.demon.invalid> writes:

>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 

Well, when it is quantized like that, yes. but a better way of phrasing
it is to say what you did


>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 
>second.

Yes, it does.
 now understand why the signal I was getting from one of my servers was
a nice triangle wave. I was wondering wht they were doing to so mess up
their timekeeping.


>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