[ntp:questions] Can a clock drift be too big for ntpd?

Maarten Wiltink maarten at kittensandcats.net
Sat Oct 20 15:24:41 UTC 2007


"Jos van de Ven" <jos at notavailable.nl> wrote in message
news:53889$471a0733$5351af52$24300 at cache100.multikabel.net...
[...]
> My relative frequency is stable at about -148 ppm, so my system clock
> runs too fast due to 1000 Hz setting as I understand.

It would run fast if not corrected, but I would hesitate to ascribe it
to the kernel's HZ setting.


> I read that -148 ppm is not a good clock; should be no more than
> absolute 50 ppm.

Why not? It's well within the limit of what NTP can correct for.


> Is it the kernel that's making my clock bad or just also bad hardware
> or a combination of both?

You don't know. I don't, either.


> What if I do a tickadj, so the frequency is stable at about 0 ppm,
> do I have a better clock then? I don't think so, but other people
> querying my server, may think it is very reliable.

It could correct for a wider range of transients. If -150 PPM is your
starting point, an extra disturbance of +350 PPM pushes you over the
limit. If you pre-correct, it could deal with disturbances up to
+500 PPM. On the other hand (side), though, you could stand a -650 PPM
disturbance in the first, and 'only' -500 PPM in the second case.

However, even 350 PPM is absurd. If you saw variations like that, I'd
recommend not leaving your computer out in the desert at night.

And those other people should *never* see your uncorrected frequency
offset. Even loading this value from the drift file would correct
for it.

Groetjes,
Maarten Wiltink





More information about the questions mailing list