[ntp:questions] NTP not syncing
stenn at ntp.org
Fri Dec 6 09:53:55 UTC 2013
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".
> 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
> Fri Dec 6 00:30:49 CET 2013
> *188.8.131.52 .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?
More information about the questions