[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