8

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?

Improve this question
3
  • 3
    Why is the 20 minute synchronization unacceptable? Have you tried a different NTP client?
    – Michael Hampton
    Oct 19, 2018 at 23:12
  • As my NTP client logs/processes sensordata connected to it, I can not wait 20 min to have good timestamps unfortunalety. I have not tried a different NTP client yet.
    – Daniel R.
    Oct 19, 2018 at 23:19
  • I am not sure if I was clear enough, the clocktime of my NTP server has no relation to the real-world UTC time as it is not required. The initial offset between an NTP client and the NTP server can be arbitrary, e.g. a few milliseconds or even months. As ntpd -g sets the clock of NTP client initially very precisely, it would be even enough for me to set the clock in each poll interval, but I am not sure if ntpd allows me to do so.
    – Daniel R.
    Oct 20, 2018 at 13:06

3 Answers 3

Reset to default
9

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.

Improve this answer
3
  • Adding iburst (and even burst) for your local server should help quite a bit.
    – Paul Gear
    Oct 24, 2018 at 3:59
  • Yes, in the first minutes, ntpd does not seem to set nor slew the clock, except the initial set caused by the -g command. Adding iburst helps a lot for the initial sync. I tried adding -x in order to have slew corrections in the beginning, but i resulted to keep having a delay of about 15ms.
    – Daniel R.
    Oct 24, 2018 at 18:09
  • You will need to collect data (see Paul's answer) to determine how fast your requirements can be met from a cold boot, unknown drift, and slew only. I suspect this will be many seconds.
    – John Mahowald
    Oct 24, 2018 at 20:57
5

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.

Improve this answer
1
  • Unfortunalety, I do not have access to real-world UTC time in my setup, only the clock of my local NTP-Server. I think logging the stats is a good idea for a constant setup. This is what I did partly. Knowing the clock drift in PPM, I can provide a drift file and ntpd works like charm. However, ntp-clients may change so frequency error is unknown.
    – Daniel R.
    Oct 24, 2018 at 19:55
3

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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .