[ntp:questions] NTP not syncing
mike cook
michael.cook at sfr.fr
Fri Dec 6 10:05:27 UTC 2013
Le 6 déc. 2013 à 10:53, Harlan Stenn a écrit :
> 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".
All I'm saying here is that the same config was used.
>
>> So under 5 minutes after the start we have a first estimation of the
>> drift. It is not that bad, being only 10ppm from normal.
>>
>> The drift file is not updated until an hour after startup, as
>> before. This is a shame as this better approximation would help if
>> there was a restart during this time.
>
> So you are trying to shave the sync time down from 5 minutes for the
> case where somebody reboots the box within an hour of having rebooted
> the box?
I am not trying to do anything. Just pointing out what I think is non optimal behavior.
>
>> Fri Dec 6 00:30:49 CET 2013
>> *145.238.203.14 .TS-3. 1 u 31 64 377 14.237 -1.681 0.=
>> 254
>> mintc=3D3, offset=3D-1.681362, frequency=3D-33.536, sys_jitter=3D0.253768,
>> -rw-r--r-- 1 root root 8 Dec 6 00:30 /var/lib/ntp/ntp.drift
>> -33.536
>>
>> We don't get back to the normal stable state until around 2hrs after
>> restart.
>
> and by then the drift file will have been written twice, the first time
> getting you to within 10ppm and the second time that gets you better
> than that, right?
>
> So this discussion is really about convergence, and apparently in the
> situation where folks do things to specifically mess things up just to
> see how long it takes to fix them?
Just highlighting 2 corner cases relevant to the OP. In their case, IIRC they had issues with cpu stepping which left crappy drift file data hanging around. They were not "messing things up".
>
> H
More information about the questions
mailing list