An introduction to the Network Time Protocol

Does anybody really know what time it is? Does anybody really care?

— Chicago, 1969

Perhaps that rock group didn’t care what time it was but our computers and devices really need to know the exact time.

There are many reasons our devices and computers need precise time. For example, in banking, stock markets, and other financial businesses, transactions must be maintained in the proper order, and exact time sequences are critical for that. Our phones, tablets, cars, GPS systems, and computers all require precise time and date settings. I want the clock on my computer desktop to be correct, so I can count on my calendar application to pop up reminders at the correct time. The correct time also ensures cron jobs and systemd timers trigger when they’re supposed to.

NTP is the Network Time Protocol that is used by computers world-wide to synchronize their times with internet standard reference clocks via a hierarchy of NTP servers.

The NTP Server Hierarchy

The NTP server hierarchy is built in layers called strata. Each stratum is a layer of NTP servers. The primary servers are at stratum 1 and they are connected directly to various national time services at stratum 0 via satellite, radio, or even modems over phone lines in some cases. Those time services at stratum 0 may be an atomic clock, a radio receiver that is tuned to the signals broadcast by an atomic clock, or a GPS receiver using the highly accurate clock signals broadcast by GPS satellites.

To prevent time requests from time servers lower in the hierarchy, that is with a higher stratum number, from overwhelming the primary reference servers, there are several thousand public NTP stratum 2 servers that are open and available for all to use. Many users and organizations, myself included, with large numbers of their own hosts that need an NTP server, set up their own time servers so that only one local host actually accesses the stratum 2 time servers. The remaining hosts in our networks are all configured to use the local time server which, in my case, is a stratum 3 server.

NTP implementation options

The original NTP implementation is ntpd, the NTP daemon, and it has been joined by two newer ones, chronyd and systemd-timesyncd. All three keep the local host’s time synchronized with an NTP time server.

Chrony is an NTP implementation containing two programs: the chronyd daemon and a command-line interface called chronyc. Chrony has some features that make it the best choice for many environments, chiefly:

• Chrony can synchronize to the time server much faster than the old ntpd service. This is good for laptops or desktops that do not run constantly.
• It can compensate for fluctuating clock frequencies, such as when a host hibernates or enters sleep mode, or when the clock speed varies due to frequency stepping that slows clock speeds when loads are low.
• It handles intermittent network connections and bandwidth saturation.
• It adjusts for network delays and latency.
• After the initial time sync, Chrony never stops the clock. This ensures stable and consistent time intervals for many system services and applications.
• Chrony can work even without a network connection. In this case, the local host or server can be updated manually using the date command.
• Chrony can act as an NTP server.

The systemd-timesyncd service is not as robust as chronyd, but it is sufficient for most purposes. It can perform large time jumps if the RTC is far out of sync, and it can adjust the system time gradually to stay in sync with the NTP server if the local system time drifts a bit. It’s interface is good but more complex than Chrony. The systemd-timesync service cannot be used as a time server, which I find to be it’s major deficiency.

Just to be clear, NTP is a protocol that is implemented on a Linux host using either Chrony or the systemd-timesyncd service.

Conclusion

Modern Linux distributions have moved from NTP to Chrony as their default timekeeping implementation. They also install systemd-timesyncd but most distributions continue to use Chrony. I find that Chrony works well, provides a better interface than the old NTP service, presents much more information, and increases control, which are all advantages for the SysAdmin. It has the best interface and can be used as a server with little effort. It’s my choice for managing NTP on my systems.

systemd-timesyncd also provides a good interface with all the information a SysAdmin needs to manage NTP. It’s not as easy to work with as Chrony and can’t be used as an NTP server. It makes no sense to use systemd-timesyncd on all my systems except for the server, on which I would use Chrony. So I see no real reason to use it.