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

Unruh unruh-spam at physics.ubc.ca
Thu Aug 13 21:51:20 UTC 2009


"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>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???


I do. And I have found that with the modern linux the clock rate changes
randomly from boot to boot, changes by of the order of 50PPM a random
walk that way will soon produce drift rates which violate the 500PPM
rule ( and some of my systems have 250 PPM drift rates).

The OP was however asking about ntp on windows. chrony does not work on
windows (the original writer never having had much interest in porting
it, nor has anyone else-- people familir with it use Linux)
The question is NOT whether or not chrony is better than ntp, but that
chrony has demonstrated that allowing larger drift rate corrections than
500PPM leads to no severe problems.

I will admit that once one gets to corrections of 100000PPM (10%) one
starts to get problems even defining what the rate of the clock is. For
example, there is not way of correcting a stopped clock. That is a
limitation of ALL systems. Similarly there is no way of correcting a
clock whose rate changes rapidly and randomly.

The OP asked why ntp could not relax its limits since those limits are
problematic for him. The response he is getting is "We don't care if it
is problematic for you, it is not problematic for me". All I am saying
is that there is no rational reason for the current limits.




More information about the questions mailing list