Ntpd on local network - Preventing clock drift causing high offsets

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?

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.

Your lack of a relation between your NTP server's clock time and the real-world UTC time could be the root of your problem. If your NTP server does not have multiple real-world sources (regardless of whether they're out on the Internet or a GPS, PPS, or atomic source on your local network), then it will be unable to determine the frequency error of its own clock, and thus won't be able to discipline its clock effectively.

You can work out if this theory is correct by turning on stats logging on both server and client, like this:

statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

Then post your stats files and your configs to a pastebin or similar site and we can analyse them in light of the behaviour you're seeing.

After trying a few different options on ntpd still having a too big delay, I switched to chrony. My NTP server remained unchanged. Using chrony gave me a latency of <1ms all the time. I increased the polling time as recommended by chrony having following config file

### chrony.conf

# Add server
server 192.168.0.11 iburst minpoll -6 maxpoll -6 filter 15 xleave
hwtimestamp eth0 minpoll -6

# Logging
logdir /var/log/chrony
log measurements statistics tracking 

makestep 0.1 3
driftfile /etc/chrony.drift

And started the deamon with ./chronyd -f /etc/chrony.conf