[ntp:questions] NTP not syncing

unruh unruh at invalid.ca
Thu Dec 5 01:41:19 UTC 2013

On 2013-12-05, mike cook <michael.cook at sfr.fr> wrote:
> Le 4 d?c. 2013 ? 22:41, antonio.marcheselli at gmail.com a ?crit :
>>>> I kept monitoring the drift file, but it was stable.
>>> Were you monitoring the modification times as well as the contents? As the logs were not being updated, maybe they were not being changed either?
>> Hi,
>> I'm not sure what you mean.
>> I was monitoring the status of the ntp using ntpd and the "o" option to see the offset and the status of the sources.
>> I was also reading the ntp.drift file to check the drift value.
>   Unfortunately there is no history for the drift file contents and the times between updates seems irregular. looking around my systems I see
> OSX           >1hr
> FreeBSD   >5hr
> FreeBSD   >2hr40
> FreeBSD   >15m
> linux   	   >1hr:50      
> Windows 7 > 2h

Once it has settled down ntp polls the server every 20 min (approx). But
it then sends that poll through a clock filter algorithm which throws
away roughly 7/8 of the results. (it keeps only that poll item whose
delay is smaller than any of the other delays of the last 8 polls),
which brings you up to roughly 2.5hr. between updates. 

>  I haven't looked at the source, but it may mean  that ntpd updates the file only when there is a change in frequency, say due to temperature variations, but this is not systematic as if you check the frequency with ntpq -rv, you get data that can differ from the value in the file . There must be some time factor as well.

ntpd changes the offset ONLY by changing the frequency. Thus if there is
a non-zero offset, the frequency is changed ( and the offset is "never"
zero). Ie, anytime a new poll result makes it through the filter, it
changes the frequency. 

> example:
> mike at raspberrypi ~ $ sudo ls -l /var/lib/ntp/ntp.drift
> -rw-r--r-- 1 root root 8 Dec  5 00:51 /var/lib/ntp/ntp.drift

AIUI, it does not write out the drift file every time it changes the
The drift file is there to give an approximate value for the drift of
the system for next bootup. Since the new drift will certainly be
different from the present drift (temperature, recalibration of the
system clock, wear on the crystal, ....) it is pointless to have the
file follow the current drift to closely.

> mike at raspberrypi ~ $ sudo cat /var/lib/ntp/ntp.drift
> -36.656
> mike at raspberrypi ~ $ ntpq -c rv
> associd=0 status=061d leap_none, sync_ntp, 1 event, kern,
> version="ntpd 4.2.7p319 at 1.2483 Tue May 28 11:26:22 UTC 2013 (2)",
> processor="armv6l", system="Linux/3.2.27-pps", leap=00, stratum=2,
> precision=-19, rootdelay=12.702, rootdisp=15.447, refid=,
> reftime=d64a40a8.49108193  Thu, Dec  5 2013  1:00:40.285,
> clock=d64a41e9.897ae5b9  Thu, Dec  5 2013  1:06:01.537, peer=45162, tc=6,
> mintc=3, offset=-0.172132, frequency=-36.748, sys_jitter=0.069766,
> clk_jitter=0.000, clk_wander=0.549
>  If you don't check the file modification times with ls or whatever as well as the contents you may not know whether it is being updated or not.

More information about the questions mailing list