[ntp:questions] NTP not syncing
magnus at rubidium.dyndns.org
Sat Dec 7 03:54:01 UTC 2013
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.
The drift-file-accelerated lock-in isn't robust. Current behavior of
response isn't very useful for most people experiencing it.
More information about the questions