Starting with Ubuntu Bionic, the choice for fast and accurate time synchronization is chrony. For the features available with chrony and how chrony compares to other time synchronization implementations check out the comparison page on the chrony site.
This post will demonstrate how to get started, a few helpful commands for end-users, and a couple features of chrony.
The package consists of two commands:
chronyc the client and
chronyd the daemon. If chrony is not already installed it is a simple apt install away:
To verify that chrony is successfully installed and to see the number of servers and peers that are connected run the
Configuration settings for chrony are kept in
/etc/chrony/chrony.conf. For details on all the numerous possible arguments see the configuration file page on the chrony site.
By default, the Ubuntu package will come with the configuration file pointing at
ntp.ubuntu.com and the
ubuntu.pool.ntp.org as NTP pools to provide 6 dual-stack NTP sources and 2 additional IPv4-only sources.
The only other item to note is the default configuration is the makestep argument, which will step up the system clock if the adjustment is larger than 1 second, but only for the first three clock updates. All other adjustments will use clock skewing to gradually correct the time by speeding up or slowing down the clock.
Below are a few chronyc subcommands to aid in gathering the status of chrony. A user can run these commands with chronyc or use chronyc to pull up a chrony specific command prompt and run them there.
To see what server chrony is tracking with and performance metrics from that server execute the
For additional details on each field view the tracking documentation
sources command shows a list of servers available to the system, status, and offsets from the local clock and the source. Using the
-v flag provides the meanings of each column. Users should pay attention for servers with a state of ‘?’, ‘x’, or ‘~’.
For additional details on each field view the sources documentation
sourcestats command is used to show additional statistics for each server including the number of samples from each server and estimated offset from a source. Using the
-v flag to get more details on each column is helpful initially.
For additional details on each field view the sourcestats documentation
ntpdata command by provides details on a specified address or for every server the system is currently using if no address is specified. The data includes information about the source and statistics from the last valid measurement. Unlike the other commands this one does require elevated privileges.
For additional details on each field view the ntpdata documentation.
When having multiple systems on a network it is advisable to setup a single system to act as the server for all other local systems. This is similar to how cloud providers will run their own NTP pools for instances inside their own data centers. As stated on the chrony site, the benefits of this model include reduced load on external connections, reduced load on the remote NTP servers, and keeps local systems in sync with each other should the external connection or servers go down.
To enable a local server in the configuration file, specify the network and subnet to allow connections from. When developing the access list, access can be tested on the server by using the
accheck <address> command. For example, the below lines would allow connections from 192.168.2.0/24 and all of the 10.0.0.0/8 subnet:
allow 192.168.2 allow 10.0.0.0/8
Assuming the system is reachable on port 123 for incoming connections and the service is restarted the server is ready.
To setup the clients, update the chrony configuration to point at the new system and restart chrony. For example, my server is at 192.168.2.12 I can update the configuration file to use it to synchronize by adding:
A user can then verify the connection to the specified server with the
cronyc activity command and the status of the connection using the
cronyc tracking command.
On the server, verify the list of clients using the
To enable even more accurate time synchronization consider using hardware timestamping if hardware supports it. This features provides incoming and outgoing packets with precise timestamps using the network controller. If this feature is enabled, it is best to enable it on both the host and client.
To determine hardware support of timestamping view ethtool output and first look for ALL of the following capabilities:
And then confirm that the NIC has at least one of the following capabilities:
For more details on these capabilities see the kernel timestamping documentation. Below is an example of a NIC that has all the necessary capabilities for both send and receive:
Enable Hardware Timestamping
To enable hardware timestamping in the configuration add the
hwtimestamp option and either specify a single interface or use the wildcard character (*) to enable hardware timestamping on all interfaces that support it:
hwtimestamp enp0s25 hwtimestamp *
Once the service is restarted a user can verify if hardware timestamping is used by a particular interface through messages in syslog:
Apr 5 21:09:31 nexus chronyd: Enabled HW timestamping on enp0s25
To verify that the connection to a server is using hardware timestamping view the output of the
It is worth consulting the chrony guide on improving accuracy as depending on the environment additional tuning to server or pool parameters may result in gains in performance.
As an example, when connecting to a local system the guide suggested changing the polling interval and to use the interleave mode for additional performance gains:
server 192.168.2.12 minpoll 2 maxpoll 2 xleave
To secure chornyc commands and NTP packets a user can enable authentication.
Keys are stored in the
/etc/chrony/chrony.keys file (as setup by chrony.conf) and the file can take keys in a large variety of hash functions.
The built in keygen command is useful to generate random keys. It takes the following optional arguments:
- The key ID (default: 1)
- The type of has function to use (default: SHA1 or MD5 if SHA1 is not available)
- The number of bits to use between 80 and 4096 (default: 160)
Here are a few examples:
First, the key files of the server and the client need the same key ID entry that will be used, otherwise no relationship between the computers will be possible. Both the client and server service need to be restarted to pick up the keys once there.
For example, if the client and server key files had the following entry:
27 SHA1 HEX:57545218761536EE5FCBCEF67D9F720DE462FB4B
On the client, in order to tell Chrony to use key #27 for a particular server add the key option to the corresponding server entry:
add server 192.168.1.12 key 27
Restart the service and see if the server now shows as authenticated:
To determine the synchronizing status, check the values from the tracking command. If the values are all zeros and the reference time is wrong, then the system is not synchronizing correctly. For example if a user sees the following then no valid NTP data was received:
By default logs for chrony go to syslog, therefore start by searching through
/var/log/syslog for details on the chrony service.
If additional logging is required to aid in debugging or tracking the performance of the NTP service, it is possible by commenting out or adding the line below to the chrony configuration file. In doing so enables additional data and statistics to be collected on an on-going basis:
# Uncomment the following line to turn additional logging on log measurements statistics tracking # or for even more logs add additional items log measurements statistics tracking rtc refclocks tempcomp
These logs will appear under the default directory of