ntpd vs. systemd-timesyncd - How to achieve reliable NTP syncing?

Question

When I query the status of the NTP daemon with ntpdc -c sysinfo I get the following output:

system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      12.77106 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Thu, Feb  7 2036  7:28:16.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

This indicates that the NTP sync failed. However the system time is accurate within 1 second precision. When I ran my system without network connection for the same period as I did now the system time would deviate ~10s.

This behavior suggests that the system has another way of syncing the time. I realized that there is also systemd-timesyncd.service (with configuration file at /etc/systemd/timesyncd.conf) and timedatectl status gives me the correct time:

      Local time: Thu 2016-08-25 10:55:23 CEST
  Universal time: Thu 2016-08-25 08:55:23 UTC
        RTC time: Thu 2016-08-25 08:55:22
       Time zone: Europe/Berlin (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2016-03-27 01:59:59 CET
                  Sun 2016-03-27 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2016-10-30 02:59:59 CEST
                  Sun 2016-10-30 02:00:00 CET

So my question is what is the difference between the two mechanisms? Is one of them deprecated? Can they be used in parallel? Which one should I trust when I want to query the NTP sync status?

(Note that I have a different system (in a different network) for which both methods indicate success and yield the correct time.)

Answer 1

systemd-timesyncd is basically a small client-only NTP implementation more or less bundled with newer systemd releases. It's more lightweight than a full ntpd but only supports time sync - i.e. it can't act as an NTP server for other machines. It's intended to replace ntpd for clients.

You should not use both in parallel, as in theory they could pick different timeservers that have a slight delay between them, leading to your system clock being periodically "jumpy".

To get the status, you unfortunately need to use ntpdc if you use ntpd and timedatectl if you use timesyncd, I know of no utility that can read both.

Answer 2

systemd-timesyncd does no clock discipline: the clock is not trained or compensated, and internal clock drift over time is not reduced. It has rudimentary logic to adjust poll interval but without disciplining the host will end up with uneven time forever as systemd-timesyncd pushes or pulls at whatever interval it thinks the near-term drift requires. It also can't assess the quality of the remote time source. You're unlikely to get accuracy much greater than 100ms. This is sufficient for simple end user devices like laptops, but it could definitely cause problems for distributed systems that want greater time precision.