Ryfujk

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?

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. Specially with them not agreeing on time with some misconfiguration, it will cause big problems. (Whilst competent system administrators will try to disable the former, it can happen they are both active).

P.S. Obviously systemd-timesyncd is not an alternative when not using systemd.

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.

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.