[ntp:questions] Speed of ntp convergence
Richard B. Gilbert
rgilbert88 at comcast.net
Sun Nov 2 20:42:50 UTC 2008
> "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.
And if you can write an ntpd equivalent that works better, I'm sure that
most of us would be interested and, perhaps, even grateful!
More information about the questions