29

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.)

19

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 timedatectlif you use timesyncd, I know of no utility that can read both.

  • How is it possible then that on one system ntpd's sync is failing while on the other it's successful (both running systemd-timesyncd in parallel). I am quite certain that this doesn't relate to a firewall problem as I've checked the corresponding settings. Right now I am left with two results and I am tempted to trust the successful one however I have doubts as both clients implement the same NTP protocol but one is failing. Actually I would expect both of them to work. – a_guest Aug 25 '16 at 11:34
  • 1
    ntpd and timesyncd use different settings. Did you set the same timeserver for both? – maxf Aug 26 '16 at 9:32
  • can you use timesyncd to sync time with a GPS like with ntp? – bakalolo Apr 12 at 0:03
12

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.