chrony vs. systemd-timesyncd – What are the differences and use cases as NTP clients?

Question

Somehow but not quite building upon the older question "ntpd vs. systemd-timesyncd - How to achieve reliable NTP syncing?", I'd like to ask about the differences between chrony and systemd-timesyncd in terms of an NTP client.

I know that systemd-timesyncd is a more or less minimal ntp client implementation whereas chrony is a full fledged NTP daemon solution that happens to include an NTP client.

The ubuntu Bionic Beaver release notes state the following:

For simple time sync needs the base system already comes with systemd-timesyncd. Chrony is only needed to act as a time server or if you want the advertised more accurate and efficient syncing.

I like the idea of using a minimal preinstalled tool to do the job and I am pretty sure systemd-timesyncd will do the job for my use cases, still I am curious:

• What are the real world differences between the two in terms of accuracy?
• What are the differences in efficiency?
• What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?

Solution 1

The announcement of systemd-timesyncd in the systemd NEWS file does a good job of explaining the differences of this tool in comparison with Chrony and tools like it. (emphasis mine):

A new "systemd-timesyncd" daemon has been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations. [...]

This setup is a common use case for most hosts in a server fleet. They will usually get synchronized from local NTP servers, which themselves get synchronized from multiple sources, possibly including hardware. systemd-timesyncd tries to provide an easy-to-use solution for that common use case.

---

Trying to address your specific questions:

What are the real world differences between the two in terms of accuracy?

I believe you can get higher accuracy by getting synchronization data from multiple sources, which is specifically not a supported use case for systemd-timesyncd. But when you're using it to get synchronization data from central NTP servers connected to your reliable internal network, using multiple sources isn't really that relevant and you get good accuracy from a single source.

If you're synchronizing your server from a trusted server in a local network and in the same datacenter, the difference in accuracy between NTP and SNTP will be virtually non-existent. NTP can take RTT into account and do timesmearing, but that's not that beneficial when your RTT is really small, which is the case of a fast local network and a nearby machine. You also don't need multiple sources if you can trust the one you're using.

What are the differences in efficiency?

Getting synchronization from a single source is much simpler than getting it from multiple sources, since you don't have to make decisions about which sources are better than others and possibly combine information from multiple sources. The algorithms are much simpler and will require less CPU load for the simple case.

What are a "non simple" time sync needs aka the use-cases for chrony as NTP client?

That's addressed in the quote above, but in any case these are use cases for Chrony that are not covered by systemd-timesyncd:

• running NTP server (so that other hosts can use this host as a source for synchrnoization);
• getting NTP synchronization information from multiple sources (which is important for hosts getting that information from public servers on the Internet); and
• getting synchronization information from the local clock, which usually involves specialized hardware such as GPS devices which can get accurate time information from satellites.

These use cases require Chrony or ntpd or similar.

Solution 2

As the other answer correctly states, chrony implements NTP and systemd-timesyncd SNTP.

From the point of view of a time service client:

SNTP is a much more simple protocol to implement;
NTP allows for step-by-step increments/corrections on time. One major advantage of NTP is that it also takes on account the RTT of the answer to get a more exact time.

From https://www.meinbergglobal.com/english/faq/faq_37.htm

While a full featured NTP server or client reaches a very high level of accuracy and avoids abrupt time steps as much as possible by using different mathematical and statistical methods and smooth clock speed adjustments, SNTP can only be recommended for simple applications, where the requirements for accuracy and reliability are not too demanding. By disregarding drift values and using simplified ways of system clock adjustment methods (often simple time stepping), SNTP achieves only a low quality time synchronisation when compared with a full NTP implementation.

SNTP adopts a much simpler approach. Many of the complexities of the NTP algorithm are removed. Rather than skewing time, many SNTP clients step time. This is fine for many applications where a simple time-stamp is required. Additionally, SNTP lacks the ability to monitor and filter multiple NTP servers. Often a simple round-robin approach is used, where if one server fails, the next one in a list is used

From https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP is far more accurate and precise than SNTP, and this makes it the de facto winner in most enterprise applications. On the other hand, the simplicity of SNTP makes it more appropriate for things like IP cameras, DVRs and some network switches. These types of hardware lack the processing resources to handle more complex protocols, but as connected devices become increasingly powerful, that may change.

One major weak point of SNTP is that you can't make it more accurate by retrieving time from multiple sources like Network Time Protocol does by default.

One other major point I can see SNTP implementations giving more problems than NTP is in virtualisation, when you have both the hypervisor and NTP daemon trying to change the VM time. Especially with them not agreeing on time with some misconfiguration causes them to be both active, it might cause big problems. (Whilst competent system administrators will only keep active one method for synchronisation with time, it can happen they are both active by a configuration error).

P.S. systemd-timesyncd should not be an advised alternative when not using systemd.

Solution 3

chrony is not a fork form ntpd but it is implemented from scratch. It implements both client and server modes of full NTPv4 protocol (RFC5905). On enterprise grade users, we are seeing a trend switching from traditional ntpd to chrony like Red Hat (RHEL 7 onwards) and SuSE (from SLES 15).

systemd-timesyncd only implement SNTP protocol (RFC4330) client mode. Hence complex use cases are not covered by systemd-timesyncd. For example, SNTP cannot make it more accurate by retrieving time from multiple sources like NTP does by default. As a result systemd-timesyncd cannot provide as high precision time as chrony.

Comments

[JdeBP]

It's not wholly obvious. In theory one could run the systemd-timesyncd program under another service manager. I have provided a service bundle for running it under the nosh toolkit's service-manager since 2018. What you have missed is that the systemd people (per Debian bug #812522) encourage VirtualBox guest services and others to explicitly conflict with the systemd-timesyncd service in order to prevent its use in virtual machines.

[Rui F Ribeiro]

@JdeBP Interesting remark.I use using Debian without systemd....Nevertheless, vmtools timesync can and will be disabled, and should be disabled in servers doing NTP services (for instance the NTP servers VMs), and some sysadmins keep synchronised by vmtools, others follow VmWare papers of disabling vmtools timesync (which should only be used when you know what you are doing) . That bug is not linear to be solved, and it will be an extra point of configuration easily missed by people following VmWare recommendations of not using vmtools timesync.

[Rui F Ribeiro]

(edit my answer on light of your remark, had one mistake on that text about managing vmtools vs (S)NTP, and make it more explicit)

[wedi]

Thanks a lot for your elaborate answer and thumbs up for specifically addressing my questions. To elaborate on that: – – 1. What is the order of magnitude of the accuracy delta. Knowing this would definitely add some substance to decision making. Are we talking about 10^-9 or 10^-1 seconds? – – 2. Your answer regarding efficiency made me even more courious: Does - blasphemously speaking - some averaging of a few numbers add so much to the CPU load that you need to mention it in Ubuntu release notes?

[wedi]

Thanks a lot for your elaborate answer, especially for including the differences between NTP and SNTP! Regarding time synching on virtual machines: doesn't the hypervisor compensate for multiple parties synchronising the time? I can imagine that more often than not the admin of the VM and the admin of the underlying host machine do not talk to eachother as in a customer - big service provider - relationship.

[Rui F Ribeiro]

@wedi In the case of VmWare timesync with the hypervisor can be disabled both at Vcenter, VM image configuration or at the Linux side. see related unix.stackexchange.com/questions/492487/… I always do vmware-toolbox-cmd timesync disable in my NTP servers, whether or not the VmWare guys have disabled timesync for those VMs. (I also usually prefer using chrony as a NTP client)

[TooTea]

@wedi: The accuracy of timesyncd will depend mainly on the server and the network. With just a single server, there's no way to tell if the server is returning bogus data, so you just have to fully trust it. (The maximum error from this is unbounded). The maximum accuracy you can achieve will be determined by the network jitter between you and the server (could be a couple milliseconds or more).

[wedi]

Thanks, @TooTea! Ok. I see. So the increased accuracy comes from using more than one source and any special magic chrony is doing with one single source can be neglected. My understanding: – – 1. Using the single timeserver metadata.google.internal on a GCE instance => no measurable difference in accuracy (let's exclude timesmearing et.al.) – – 2. Using three time servers with great reputation on a vm at some settled hosting company => you see a difference but not "much" (whatever this might be) – – 3. Using pool.ntp.org on a raspi connected via some ISP => you are as happy as larry can get.

[filbranden]

I'd say correct on all three @wedi. In particular (1), if you're using a timeserver on the same "local network" as your machine and essentially in the same datacenter (very low rtt and very low jitter) the benefits of NTP and timesmearing vs SNTP, regarding accuracy, will be very low. So there's little reason to run NTP (and not SNTP) in those use cases!

[filbranden]

@wedi Updated the answer to explicitly mention using a trusted server on a local network.

[wedi]

I am glad you pointed out the possible time sync race! Good to keep this in mind!

[wedi]

Mmmh. I haven't noticed anyone purporting chrony is a fork and I mentioned in my question that chrony implements server and client whereas systemd-timesyncd is client only. Thanks for mentioning the relevant RFCs.

[simohe]

Also for me the biggest diffreence when using as a client is that systemd-timesync does time steps (and not skew time).

[Rui F Ribeiro]

@wedi Give it an upvote, it is a good answer. We have been also seeing a trend in using chrony.