[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