[ntp:questions] Speed of ntp convergence
unruh-spam at physics.ubc.ca
Sun Nov 2 22:31:57 UTC 2008
"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>> "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?
>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!
already written, IF you do not want refclocks and you are running Linux. It
is called chrony.
More information about the questions