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

phil pharwood at bellsouth.net
Fri Aug 14 13:41:07 UTC 2009


"Unruh" <unruh-spam at physics.ubc.ca> wrote in message 
news:o48hm.41192$PH1.17076 at edtnps82...
> "David J Taylor" 
> <david-taylor at blueyonder.not-this-part.nor-this.co.uk.invalid> writes:
>
>>"nemo_outis" <abc at xyz.com> wrote in message []
>>> I fail to see the value or relevance of "500ppm satisfies 98% of
>>> computer
>>> clocks" if some other number, perhaps 5000 ppm, could satisfy yet even
>>> more
>>> than 98% of computer clocks with no downside - as indeed seems to be the
>>> case!  Chrony, whatever its other merits and demerits, is an "existence
>>> proof" for this proposition.
>>>
>>> Regards,
>
>>Oh, simply that have knowledge of how many computers were excluded at a
>>particular value of maximum drift might allow the NTP designer to make a
>>better judgement of just where to set that arbitrary 500ppm number.  For
>>example, if 100ppm excluded 50% it would obviously be a poor choice, and
>>it 500ppm includes 99.999% of computers it could be an excellent choice.
>>As it is, in a community of end users perhaps one or two out of about a
>>hundred have reported problems with NTP as supplied, and it seems a shame
>>to exclude them if a small relaxation in the tolerance might allow them to
>>run NTP rather than them having the view "NTP doesn't work".
>
>>No chance of the limit being a command-line parameter, I suppose?
>
> So I have 9 clocks.
> The rates are
> -190, 19 , -106, -67,-200 -219, -115 -140 221
>
> On reboot, the latter changed from 221 to 215 (Which took ntp about 6
> hours to recover from)
>
> The clock scaling in linux seems to suffered a real problem in the past
> year or two, so that the rate from one reboot to the next can change by
> 50PPM, which then takes ntp a long time to recover from.
>
> two years ago those same clocks, running earlier kernels, had rates of
> 5 -17 45 27 23 100 101 -10 8 -39 39 25.
>
> It will not take much more degredation for the clocks to surpass the
> 500PPM limit. And this is not due to any change in the hardware. It
> seems to be kernel software and the scaling calibration being performed
> at bootup.
>

Sometimes "complex" problems can have simple solutions.
I had the same issue a couple years ago with multiple computers. I bought a 
box of button batteries and changed every one I could find. My hardware 
clocks improved at least on the order that you say yours degraded, perhaps 
more.





More information about the questions mailing list