[ntp:questions] NTP not syncing

unruh unruh at invalid.ca
Sat Dec 7 06:32:03 UTC 2013

On 2013-12-07, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
> On 12/07/2013 01:17 AM, unruh wrote:
>> On 2013-12-06, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>>> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
>>>> mike cook writes:
>>>>>> If you know the drift file is unreliable, you should delete it.  ntpd
>>>>>> will then perform a frequency calibration before entering the main
>>>>>> loop. ...
>>>>> This is what has been recommended for ages but it doesn't completely
>>>>> fix the issue. It still takes a long time to settle. Here are the
>>>>> results of a test I did using the same system and ntp config as in my
>>>>> previous reply wit h the unrepresentative drift file data.
>>>> An "unrepresentative drift file" is not a "deleted drift file".
>>> I filed a bug to address this. If the drift file is obviously nuts,
>>> ignore it for speed-up and just work as it was not there, that is, do
>>> normal frequency lock-in.
>> How does it know that the drift file is obviously nuts? 
>> If it knew that it could fix it. It does not know that. ntpd ONLY knows
>> the current offset. Now on bootup if there is not drift file, then it
>> tries to remember the past few offsets and use those to estimate a
>> drift, but if there is a drift file, it trusts the value in that drift
>> file. If you are always going to do a drift estimate for the first few
>> polls anyway, why have a drift file at all?
> Well, we can discuss which is the best way to detect it, but when you
> fail to lock and is forced to re-set the time, then you surely know you
> didn't where were you expected to be.

??? There could be all kinds of reasons for that. 

> The drift-file-accelerated lock-in isn't robust. Current behavior of
> response isn't very useful for most people experiencing it.

While I do not particularly want to defend the ntpd philosophy, if you
buy that then it does help. Except for those broken Linux kernels which
did a really bad job of calibrating their clocks (apparently because
that takes time during bootup).
Remember that IF you have a good drift file, (ie one that corresponds
with the computer drift) then it does speed up convergence. And people
keep complaining that ntpd is slow to converge. The boot estimate of
drift is a real kludge stuck in there because so many complained that
ntpd was so slow to converge. It completely breaks the ntpd philosophy,
but only does so on bootup so that is OK:-).

As I said, get chrony if you want much faster convergence, if you want
better control of the time offset from UTC, and if yourun Linux or BSD.

More information about the questions mailing list