Ntpd on local network – Preventing clock drift causing high offsets

clock-synchronizationntpntpdtime-synchronization

I have a local network with a microcontroller ARM as the NTP server and I have a desktop computer running with ubuntu 16.04 LTS as a NTP client.

Once I start ntpd -g -c /etc/ntp.conf with the following ntp config file

server 192.168.0.11 minpoll 4 maxpoll 4

The very first offset after ntpd sets the time shows a very good result, i.e. something below 1ms.
I get the offset values by ntpq -p.

However, the offset slowly rises up to 55ms after approx. 1000 seconds. This high offset is unacceptable for my application. But after the offset reaches 55 ms, ntpd seems to set the time again and the offset becomes sufficiently small and stable (< 1ms). It seems that ntpd let the clocks drift for a while and after a (too) long period of time, the deamon takes countermeasures to the clock drift between NTP client and NTP server.

Using ntpd -g -c /etc/ntp.conf -f /etc/ntp.drift where ntp.drift was generated by ntpd, the offset will stay below 1ms the whole time, i.e. no linear rise of the offset caused by clock drift; the desired behavior.

Now to my problem: In my application, we can not let ntpd run for a while to calculate the clock drift after a long period of time, the synchronization has to take place after a few seconds after booting the NTP client and the offset has to stay stable.

How can I get a stable and small offset with ntpd without knowing exactly the clock drifts?

Best Answer

A driftfile records the frequency of the local clock, and is a good thing to have to accurately discipline it. Ubuntu /etc/ntp.conf has a driftfile by default.

Appending iburst to the server line sends a few packets rapidly on initial sync. Recommended, particularly if you do not want to wait several minutes for the first few packets.

Init scripts can delay starting the application until NTP is synced. Do this with a dependency on the ntp-wait systemd unit. Or the ntpwait script directly.

Your report of an offset growing and then correcting itself sounds like ntpd crossing its step threshold, then setting the time rather than slewing it.

Related Topic