Product SiteDocumentation Site

Chapter 3. Configuring NTP Using the chrony Suite

3.1. Introduction to the chrony Suite
3.1.1. Differences Between ntpd and chronyd
3.1.2. Choosing Between NTP Daemons
3.2. Understanding chrony and Its Configuration
3.2.1. Understanding chronyd
3.2.2. Understanding chronyc
3.2.3. Understanding the chrony Configuration Commands
3.2.4. Security with chronyc
3.3. Using chrony
3.3.1. Checking if chrony is Installed
3.3.2. Installing chrony
3.3.3. Checking the Status of chronyd
3.3.4. Starting chronyd
3.3.5. Stopping chronyd
3.3.6. Checking if chrony is Synchronized
3.3.7. Manualy Adjusting the System Clock
3.4. Setting Up chrony for Different Environments
3.4.1. Setting Up chrony for a System Which is Infrequently Connected
3.4.2. Setting Up chrony for a System in an Isolated Network
3.5. Using chronyc
3.5.1. Using chronyc to Control cronyd
3.5.2. Using chronyc for Remote Administration
3.6. Additional Resources
3.6.1. Installed Documentation
3.6.2. Useful Websites
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 interrupts.
There is a choice between the daemons ntpd and chronyd, which are available from the repos in the ntp and chrony packages respectively. This section describes the use of the chrony suite of utilities to update the daemon on systems that do not fit into the conventional permanently networked, always on, dedicated server category.

3.1. Introduction to the chrony Suite

Chrony consists of chronyd, a daemon that runs in user space, and chronyc, a command line program for making adjustments to chronyd. Systems which are not permanently connected, or not permanently powered up, take a relatively long time to adjust their system clocks using the NTP time protocol. This is because many small corrections are made based on observations of the clocks drift and offset. Temperature changes, which may be significant when powering up a system, affect the stability of hardware clocks. Although adjustments begin within a few milliseconds of booting a system, acceptable accuracy may take anything from ten seconds from a warm restart to a number of hours depending on your requirements, operating environment and hardware. chrony is a different implementation of the NTP protocol than ntpd, it can adjust the system clock more rapidly.

3.1.1. Differences Between ntpd and chronyd

One of the main differences between ntpd and chronyd is in the algorithms used to control the computer's clock. Things chronyd can do better than ntpd are:
  • chronyd can work well when external time references are only intermittently accessible 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 synchronise 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.
  • chronyd in the default configuration never steps the time, 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.
  • 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.
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 look at the errors corrected at different updates to estimate the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.
  • chronyd provides support to work out the rate of gain or loss of the real-time clock, the hardware 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 adjusted value of the time taken from the real-time clock. This is, at time of writing, only available in Linux.
Things ntpd can do that chronyd cannot do:
  • ntpd fully supports NTP version 4 (RFC5905), including broadcast, multicast, manycast clients and servers, and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (RFC5906). chronyd uses NTP version 3 (RFC1305), which is compatible with version 4.
  • ntpd includes drivers for many reference clocks whereas chronyd relies on other programs, for example gpsd, to access the data from the reference clocks.

3.1.2. Choosing Between NTP Daemons

  • Chrony should be considered for all systems which are frequently suspended or otherwise intermittently disconnected and reconnected to a network. Mobile and virtual systems for example.
  • The NTP daemon (ntpd) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast IP, or to perform authentication of packets with the Autokey protocol, should consider using ntpd. Chrony only supports symmetric key authentication, such as the use of MD5, SHA1, and SHA256 hash functions, whereas ntpd supports the Autokey authentication protocol which can make use of the PKI system. Autokey is described in RFC5906.