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

system peer:
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      12.77106 s
reference ID:         []
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.)


2 Answers 2


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.

  • 1
    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
    Commented Aug 25, 2016 at 11:34
  • 1
    ntpd and timesyncd use different settings. Did you set the same timeserver for both?
    – maxf
    Commented Aug 26, 2016 at 9:32
  • 8
    Systemd-timesyncd is an SNTP client which is less accurate than NTP. Readers should not be misled into thinking systemd-timesyncd is a light weight NTP client. Commented Nov 24, 2019 at 23:04
  • 3
    I don't know what the answer implies by lightweight. I've seen no evidence that systemd-timesyncd is more lightweight than ntpd. CPU stats are the same; systemd-timesyncd allocates the same amount of physical memory, it is a bit hungrier for shared memory and a lot hungrier for virtual memory though the latter is not that important. From what angle should I be looking to see it as more lightweight? Commented Oct 19, 2020 at 15:41
  • 1
    I'd say systemd-timesyncd is more crippled than lightweight in that it implements very little of what a full-strength, competent time service client like ntpd or chrony does. It is thus far less effective, regardless of your concept of "weight".
    – Metaxis
    Commented May 8, 2021 at 21:07

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.

  • 4
    And systemd-timesyncd seems to do the corrections with time steps and not by skewing time.
    – simohe
    Commented Apr 27, 2020 at 8:06
  • 5
    This is the reason I alwasy install a proper ntp server/client. Yet another NIH thing from systemd group.
    – Anders
    Commented Feb 24, 2022 at 5:05
  • 2
    Is there really no compensation of internal clock drift with systemd-timesyncd / timedatectl? Current versions report via timedatectl timesync-status a frequency. That implies a correction.
    – Hannes
    Commented Mar 17, 2022 at 12:15
  • @Hannes I took a quick look at current docs and I'm not seeing it. It still says it implements only SNTP and as expected from that I see no evidence of a drift file, which would be required to reapply the clock discipline learned over restarts/reboots. This is important as a good drift value can take on the order of a day to arrive at.
    – Metaxis
    Commented Jun 29 at 17:40

You must log in to answer this question.

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