[ntp:questions] Speed of ntp convergence

Richard B. Gilbert rgilbert88 at comcast.net
Sun Nov 2 23:46:02 UTC 2008

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>> Unruh wrote:
>>> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>>>> Unruh wrote:
>>>>> "David J Taylor" <david-taylor at blueyonder.neither-this-part.nor-this-bit.co.uk> writes:
>>>>>> Hal Murray wrote:
>>>>>>>>> Try switching it off, changing the value int he drift file by say
>>>>>>>>> 50PPM and
>>>>>>>>> then switching it on again, and see how long it takes to recover
>>>>>>>>> from that.
>>>>>>>> Why would I do that?  The drift values rarely change by more than
>>>>>>>> five, certainly not by 50.  If you are seeing a change of 50, then
>>>>>>>> perhaps that it part of your problem?
>>>>>>> A big step like that makes it easy to see how the system responds.
>>>>>>> At least if it's a linear system. :)
>>>>>> Yes, I appreciate that, Hal, but it doesn't emulate the situation here 
>>>>>> very well, which I understood to be slow convergence after a routine 
>>>>>> start.  It sounds as if the OP may have an incorrect drift file - it's 
>>>>>> worth checking that it /is/ being updated.
>>>>> The drift file read 10. The actual drift was 250 (determined after the
>>>>> system had settled down). The drift file never changed even after a day of
>>>>> running. ntp does not seem to be rewriting the drift file. Now that is a
>>>>> problem (although with the  apparent Linux bug in the timing routines where is
>>>>> miscalibrates the clock on bootup, the drift is NOT stable over reboots
>>>>> anyway, so the existence of a drift file is irrelevant. ) However, the question is
>>>>> about the bahaviour of ntp. ntp should NOT be taking 10 hours to get over a
>>>>> wrong value in the drift file. 
>>>> That's easy to fix!  If the drift file is not correct, remove it before 
>>>> starting ntpd.
>>> Of course. However, I have no idea it is incorrect until after ntp has
>>> started up and shown me it was incorrect. 
>>>> How do you tell if it's incorrect?  Since ntpd is supposed to 
>>>> update/rewrite the drift file every sixty minutes, a drift file more 
>>>> than sixty minutes old is suspect!
>>> I think my problem was that the permissions on /etc/ntp/drift were
>>> incorrect ( owned by root rather than by ntp). But that makes no
>>> difference to how ntp behaves. ntp should do the "right thing" even if the
>>> drift file is wrong. It should take a bit longer, but not 10 hours longer. 
>>> And with the current apparent bug in Linux wehre the system time is
>>> miscalibrated, it would seem that the drift file on Linux is ALWAYS wrong.
>> Do not blame ntpd for the consequences of your errors!  If ntpd is 
>> configured correctly and operated correctly, it behaves quite well.
> ???? I was not blaming ntp for my error. I was blaming ntp for its reaction
> to "my error" . And note a bad drift file is now the standard for
> Linux. For example between two reboots, my drift rate went from 180PPM to
> 250PPM. No drift file would have fixed that. 
> NTP handles drift errors badly. But that is not the question I asked.
>  So far NOONE has answered the
> question-- why if my poll internal is 16 sec is the time scale for the
> error correction 1 hour?

How big is the error?  Why is your poll interval 16 seconds?  (If you 
are using a refclock, I withdraw the question!)  Are you setting the 
correct time at startup with ntpd -g or ntpdate or sntp?

If the drift file is known to be incorrect it's best practice to remove 
or delete it (depending on which operation your O/S supports) in which 
case nptd makes no assumptions about the drift and attempts to measure 
it.  A drift file that was last modified more than 60 minutes ago should 
be assumed to be incorrect.


One very good way to avoid startup problems is leave it running, which I do!

More information about the questions mailing list