chrony vs. systemd-timesyncd – What are the differences and use cases as NTP clients?
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.
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.
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.