Show Table of Contents
Chapter 17. 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.
17.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
NTPservers, - 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.
17.1.1. Differences Between ntpd and chronyd
Things
chronyd can do better than ntpd:
chronydcan work well in an environment where access to the time reference is intermittent, whereasntpdneeds regular polling of time reference to work well.chronydcan perform well even when the network is congested for longer periods of time.chronydcan usually synchronize the clock faster and with better accuracy.chronydquickly adapts to sudden changes in the rate of the clock, for example, due to changes in the temperature of the crystal oscillator, whereasntpdmay need a long time to settle down again.- In the default configuration,
chronydnever steps the time after the clock has been synchronized at system start, in order not to upset other running programs.ntpdcan 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. chronydcan 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.chronydis 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:
chronydprovides support for isolated networks where the only method of time correction is manual entry. For example, by the administrator looking at a clock.chronydcan 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.chronydprovides 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.chronydsupports hardware timestamping on Linux, which allows extremely accurate synchronization on local networks.
Things
ntpd can do that chronyd cannot do:
ntpdsupports all operating modes fromNTPversion 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.ntpdsupports 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.ntpdincludes drivers for many reference clocks, whereaschronydrelies on other programs, for example gpsd, to access the data from the reference clocks using shared memory (SHM) or Unix domain socket (SOCK).
17.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.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.