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

Ulrich Windl Ulrich.Windl at RZ.Uni-Regensburg.DE
Thu Aug 13 08:53:27 UTC 2009


"David J Taylor"
<david-taylor at blueyonder.not-this-part.nor-this.co.uk.invalid> writes:

> I've recent been suggesting the Windows port of NTP as a program suitable for
> an application where the timekeeping needed to be within a second or two.
> Yes, NTP is overkill, but it has the advantages of multiple servers, best
> server selection, adaptive poll rate, and memory of the clock drift etc.
> However, on quite a few installations - at a guess between 1% and 5% - NTP has
> failed because the click frequency error appears to be too great for NTP to
> correct.

I still say NTP is no technology to fix bad hardware or clocks. Those
Windows people all seem not to care much about time, while the NTFS
filesystem stores timestamps in nanoseconds AFAIK.

>
> Is there any feeling for changing the 500ppm limit, perhaps to 1000ppm or even
> as much as 5000ppm (to pull a figure out of the hat)?  Or is 500ppm generally
> believed to be the worst error which should be compensated?

When increasing the PPM range, you must also decrease the polling
interval. Do we really want that? I'd say no.
(Interestingly Windows "genuine" NTP client adjusts the clock once per
week by default. Why not use that service?)

>
> One possibility is that some of the problem PCs are portables, with some sort
> of power-saving or even hibernation scheme.  I don't have direct visibility of
> the type of PC.

Well if someone runs ntpd on a machine and does a suspend to disk (or to
RAM), and then after a few hours resumes execution, ntpd will be really
confused about the time it missed. I think those machines should not run
NTP. Maybe the solution Microsoft provides fits the needs of those.

Regards,
Ulrich




More information about the questions mailing list