[ntp:questions] Speed of ntp convergence

Richard B. Gilbert rgilbert88 at comcast.net
Mon Nov 3 13:47:53 UTC 2008


Unruh wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
> 
>> 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 
> 
> It IS a refclock-- GPS PPS via refclock_shm.
> 
>> are using a refclock, I withdraw the question!)  Are you setting the 
>> correct time at startup with ntpd -g or ntpdate or sntp?
> 
> ntpd -g I am using the shm driver. ntp first uses other servers to set the
> time, and then starts the shm pps. The drift is way off, it seems because
> of the bug in the linux time driver ( the drift rate changes by 50PPM after
> a reboot). 
> 
> 
>> 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.
> 
> I should NOT have to check up on the drift file to see if it is correct.
> That is the computer's job. ntp should NOT take 10 hours to correct a wrong
> drift file. With a 16 sec poll, ntp should NOT have a 1 hour time constant.

Your opinion!  The designers/developers evidently disagree.




More information about the questions mailing list