Chrony is a versatile implementation of the Network Time Protocol (NTP). It can synchronise the system clock with NTP servers, reference clocks (e.g. GPS receiver), and manual input using wristwatch and keyboard. It can also operate as an NTPv4 (RFC 5905) server and peer to provide a time service to other computers in the network.

It is designed to perform 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 continuosly, or run on a virtual machine.

Typical accuracy between two machines synchronised over the Internet is within a few milliseconds; on a LAN, accuracy is typically in tens of microseconds. With hardware timestamping, or a hardware reference clock, sub-microsecond accuracy may be possible.

Two programs are included in chrony, chronyd is a daemon that can be started at boot time and chronyc is a command-line interface program which can be used to monitor chronyd’s performance and to change various operating parameters whilst it is running.

Supported systems
The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris. Closely related systems may work too. Any other system will likely require a porting exercise.

Mailing lists
There are three mailing lists relating to chrony:

• Chrony-announce is a low-volume list, intended for announcements about new versions and other important news. All messages sent to the chrony-announce list are sent also to the chrony-users and chrony-dev lists.
• Chrony-users is for general user discussions, questions, reporting bugs and so on.
• Chrony-dev is for discussion about development, testing, new features, submitting patches.

Comparison of NTP implementations

chrony vs ntp

Things chrony can do better than ntp:

• chrony can perform usefully in an environment where access to the time reference is intermittent. ntp needs regular polling of the reference to work well.
• chrony can usually synchronise the clock faster and with better time accuracy.
• chrony quickly adapts to sudden changes in the rate of the clock (e.g. due to changes in the temperature of the crystal oscillator). ntp may need a long time to settle down again.
• chrony can perform well even when the network is congested for longer periods of time.
• chrony in the default configuration never steps the time to not upset other running programs. ntp can be configured to never step the time too, but in that case it has to use a different means of adjusting the clock (daemon loop instead of kernel discipline), which may have a negative effect on accuracy of the clock.
• chrony can adjust the rate of the clock in a larger range, which allows it to operate even on machines with broken or unstable clock (e.g. in some virtual machines).
• chrony is smaller, it uses less memory and it wakes up the CPU only when necessary, which is better for power saving.

Things chrony can do that ntp can’t:

• chrony supports hardware timestamping on Linux, which allows extremely accurate synchronisation on local networks.
• chrony provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock). chrony can look at the errors corrected at different updates to work out the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.
• chrony provides support to work out the gain or loss rate of the real-time clock, i.e. 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 from a corrected version of the real-time clock. These real-time clock facilities are only available on Linux, so far.

Things ntp can do that chrony can’t:

• ntp supports all operating modes from RFC 5905, including broadcast, multicast, and manycast server/client. However, the broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode, and should generally be avoided.
• ntp supports the Autokey protocol (RFC 5906) to authenticate servers with public-key cryptography. Note that the protocol has been shown to be insecure and it will be probably replaced with an implementation of the Network Time Security (NTS) specification.
• ntp has been ported to more operating systems.
• ntp includes a large number of drivers for various hardware reference clocks. chrony requires other programs (e.g. gpsd or ntp-refclock) to provide reference time via the SHM or SOCK interface.

Specifications

Industry :

Information technology