[ntp:questions] NTP not syncing
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
>> *22.214.171.124 .TS-3. 1 u 31 64 377 14.237 -1.681 0.=
>> 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
>> We don't get back to the normal stable state until around 2hrs after
> 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".
More information about the questions