Chapter 16. Configuring NTP Using the chrony Suite

Accurate time keeping is important for a number of reasons in IT. In networking for example, accurate time stamps in packets and logs are required. In Linux systems, the NTP protocol is implemented by a daemon running in user space.
The user space daemon updates the system clock running in the kernel. The system clock can keep time by using various clock sources. Usually, the Time Stamp Counter (TSC) is used. The TSC is a CPU register which counts the number of cycles since it was last reset. It is very fast, has a high resolution, and there are no interruptions.
There is a choice between the daemons ntpd and chronyd, available from the repositories in the ntp and chrony packages respectively.
This chapter describes the use of the chrony suite.

16.1. Introduction to the chrony Suite

Chrony is an implementation of the Network Time Protocol (NTP). You can use Chrony:
  • to synchronize the system clock with NTP servers,
  • to synchronize the system clock with a reference clock, for example a GPS receiver,
  • to synchronize the system clock with a manual time input,
  • as an NTPv4(RFC 5905) server or peer to provide a time service to other computers in the network.
Chrony performs well in a wide range of conditions, including intermittent network connections, heavily congested networks, changing temperatures (ordinary computer clocks are sensitive to temperature), and systems that do not run continuously, or run on a virtual machine.
Typical accuracy between two machines synchronized over the Internet is within a few milliseconds, and for machines on a LAN within tens of microseconds. Hardware timestamping or a hardware reference clock may improve accuracy between two machines synchronized to a sub-microsecond level.
Chrony consists of chronyd, a daemon that runs in user space, and chronyc, a command line program which can be used to monitor the performance of chronyd and to change various operating parameters when it is running.

16.1.1. Differences Between ntpd and chronyd

Things chronyd can do better than ntpd:
  • chronyd can work well in an environment where access to the time reference is intermittent, whereas ntpd needs regular polling of time reference to work well.
  • chronyd can perform well even when the network is congested for longer periods of time.
  • chronyd can usually synchronize the clock faster and with better accuracy.
  • chronyd quickly adapts to sudden changes in the rate of the clock, for example, due to changes in the temperature of the crystal oscillator, whereas ntpd may need a long time to settle down again.
  • In the default configuration, chronyd never steps the time after the clock has been synchronized at system start, in order not to upset other running programs. ntpd can be configured to never step the time too, but it has to use a different means of adjusting the clock, which has some disadvantages including negative effect on accuracy of the clock.
  • chronyd can adjust the rate of the clock on a Linux system in a larger range, which allows it to operate even on machines with a broken or unstable clock. For example, on some virtual machines.
  • chronyd is smaller, it uses less memory and it wakes up the CPU only when necessary, which is better for power saving.
Things chronyd can do that ntpd cannot do:
  • chronyd provides support for isolated networks where the only method of time correction is manual entry. For example, by the administrator looking at a clock. chronyd can examine the errors corrected at different updates to estimate the rate at which the computer gains or loses time, and use this estimate to adjust the computer clock subsequently.
  • chronyd provides support to work out the rate of gain or loss of the real-time clock, for example the clock that maintains the time when the computer is turned off. It can use this data when the system boots to set the system time using an adapted value of time taken from the real-time clock. These real-time clock facilities are currently only available on Linux systems.
  • chronyd supports hardware timestamping on Linux, which allows extremely accurate synchronization on local networks.
Things ntpd can do that chronyd cannot do:
  • ntpd supports all operating modes from NTP version 4 (RFC 5905), including broadcast, multicast and manycast clients and servers. Note that the broadcast and multicast modes are, even with authentication, inherently less accurate and less secure than the ordinary server and client mode, and should generally be avoided.
  • ntpd supports the Autokey protocol (RFC 5906) to authenticate servers with public-key cryptography. Note that the protocol has proven to be insecure and will be probably replaced with an implementation of the Network Time Security (NTS) specification.
  • ntpd includes drivers for many reference clocks, whereas chronyd relies on other programs, for example gpsd, to access the data from the reference clocks using shared memory (SHM) or Unix domain socket (SOCK).

16.1.2. Choosing Between NTP Daemons

Chrony should be preferred for all systems except for the systems that are managed or monitored by tools that do not support chrony, or the systems that have a hardware reference clock which cannot be used with chrony.

Note

Systems which are required to perform authentication of packets with the Autokey protocol, can only be used with ntpd, because chronyd does not support this protocol. The Autokey protocol has serious security issues, and thus using this protocol should be avoided. Instead of Autokey, use authentication with symmetric keys, which is supported by both chronyd and ntpd. Chrony supports stronger hash functions like SHA256 and SHA512, while ntpd can use only MD5 and SHA1.