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

Richard B. Gilbert rgilbert88 at comcast.net
Thu Aug 13 19:21:10 UTC 2009


Unruh wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
> 
>> Unruh wrote:
>>> Ulrich Windl <Ulrich.Windl at RZ.Uni-Regensburg.DE> writes:
>>>
>>>> "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.
>>> The whole purpose of ntp is to fix bad hardware or clocks. Not everyone
>>> can afford a Hydrogen Maser temperature controlled clock on their
>>> system, and ntp is for taking temeprature uncontrolled quartz oscilators
>>> and delivering sub millisecond time accuracy. That is its whole purpose.
>>> You seem to say that if it is "bad enough" you do not consider it worth
>>> fixing, when even Mills agrees that that 500PPM was a totally arbitrary
>>> figure. On Linux one can control the clock rate to about 1% *10000PPM"
>>> but ntp insists on 500PPM for no other reason than tradition.
>>>
>>>
>>>>> 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.
>>> Why must you decrease the polling interval? ntp determines that this
>>> clock runs at 3500PPM out. So it adjusts the clock tick rate to that and
>>> it stays at that. 
>>>
>>>> (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.
>>> Agreed with this. If the clock rate changes by some large amount on
>>> short time scales that is problematic. But the fact that the clock runs
>>> consistantly 3000PPM too fast need not be problematic at all. (Note that
>>> chrony, which runs only on Linux, has no trouble with 3000PPM)
>>>
>>>
> 
>> When you consider that the majority of computer clocks are within +/- 
>> 50PPM it doesn't seem wrong to consider a clock out by more than 500 PPM 
>> to be badly broken.  You are, of course, at liberty to set the limit to 
>> some arbitrarily large value.  It won't, of course, be supported.
> 
>> Some of us might be interested in your results if you do change the 
>> limit to +/- 1000 or +/- 10,000.
> 
>> The 500 PPM limit may be completely arbitrary but I suspect that it 
>> includes a vast majority of computer clocks.
> 
> Interesting how completely arbitrary traditions then get staunchly
> defended as somehow "natural" and unchangeable. True of ntp and of
> politics and of the role of women in society etc. Interesting
> psychology.
> 
> Note that chrony has no such limits, and it works well-- about three
> times better than ntp in time accuracy, about 100 times better in speed
> of convergence. Ie, the test has been done, the results are in, but the
> impact is zero.  Note that this limit hardly jibes with ntp's using
> infinite rate adjustments ( it steps the time sometimes) which means it
> does 500PPM except when it is infinite. How that is better than allowing
> say 10000PPM (the tick adjust limit of the Linux adjtime routine) 
> I have no idea.
> 

500 PPM works for most of us.

Suppose you change 500 PPM to 5,000 PPM or 10,000 PPM and show that NTP 
works better with that value!

Six computers is a very small sample but all of mine that are powered on 
  are well within +/- 500 PPM.  That's three Sun SPARC, one DEC Alpha, 
and two X86 PCs.

BTW, is there some reason why you don't use chrony???




More information about the questions mailing list