Chapter 18. 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
chronyd, available from the repositories in the ntp and chrony packages respectively.
This chapter describes the use of the chrony suite.
18.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
- to synchronize the system clock with a reference clock, for example a GPS receiver,
- to synchronize the system clock with a manual time input,
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.
18.1.1. Differences Between ntpd and chronyd
chronyd can do better than
chronydcan work well in an environment where access to the time reference is intermittent, whereas
ntpdneeds 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, whereas
ntpdmay 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.
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.
ntpd can do that
chronyd cannot do:
ntpdsupports all operating modes from
NTPversion 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, whereas
chronydrelies on other programs, for example gpsd, to access the data from the reference clocks using shared memory (SHM) or Unix domain socket (SOCK).
18.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.
Systems which are required to perform authentication of packets with the
Autokey protocol, can only be used with
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
ntpd. Chrony supports stronger hash functions like SHA256 and SHA512, while
ntpd can use only MD5 and SHA1.
18.2. Understanding chrony and Its Configuration
18.2.1. Understanding chronyd and chronyc
The chrony daemon,
chronyd, can be monitored and controlled by the command line utility chronyc. This utility provides a command prompt, which allows entering a number of commands to query the current state of
chronyd and make changes to its configuration. By default,
chronyd accepts only commands from a local instance of chronyc, but it can be configured to accept monitoring commands also from remote hosts. The remote access should be restricted.
18.2.2. Understanding the chrony Configuration Commands
The default configuration file for
-f option can be used to specify an alternate configuration file path. See the
chronyd man page for further options. For a complete list of the directives that can be used see http://chrony.tuxfamily.org/manual.html#Configuration-file.
Below is a selection of
chronyd configuration options:
- Comments should be preceded by #, %, ; or !
Optionally specify a host, subnet, or network from which to allow
NTPconnections to a machine acting as
NTPserver. The default is not to allow connections.
Example 18.1. Granting access with the
Use this this command to grant access to an IPv4:
Use this this command to grant access to an IPv6:
The UDP port number 123 needs to be open in the firewall in order to allow the client access:
~]# firewall-cmd --zone=public --add-port=123/udp
If you want to open port 123 permanently, use the
~]# firewall-cmd --permanent --zone=public --add-port=123/udp
This is similar to the
allowdirective (see section
allow), except that it allows control access (rather than
NTPclient access) to a particular subnet or host. (By "control access" is meant that chronyc can be run on those hosts and successfully connect to
chronydon this computer.) The syntax is identical. There is also a
cmddeny alldirective with similar behavior to the
Path to the directory to save the measurement history across restarts of
chronyd(assuming no changes are made to the system clock behavior whilst it is not running). If this capability is to be used (via the
dumponexitcommand in the configuration file, or the
dumpcommand in chronyc), the
dumpdircommand should be used to define the directory where the measurement histories are saved.
If this command is present, it indicates that
chronydshould save the measurement history for each of its time sources recorded whenever the program exits. (See the
hwtimestampdirective enables hardware timestamping for extremely accurate synchronization. For more details, see
localkeyword is used to allow
chronydto appear synchronized to real time from the viewpoint of clients polling it, even if it has no current synchronization source. This option is normally used on the "master" computer in an isolated network, where several computers are required to synchronize to one another, and the "master" is kept in line with real time by manual input.
An example of the command is:
local stratum 10
A large value of 10 indicates that the clock is so many hops away from a reference clock that its time is unreliable. If the computer ever has access to another computer which is ultimately synchronized to a reference clock, it will almost certainly be at a stratum less than 10. Therefore, the choice of a high value like 10 for the
localcommand prevents the machine’s own time from ever being confused with real time, were it ever to leak out to clients that have visibility of real servers.
logcommand indicates that certain information is to be logged. It accepts the following options:
This option logs the raw
NTPmeasurements and related information to a file called
This option logs information about the regression processing to a file called
This option logs changes to the estimate of the system’s gain or loss rate, and any slews made, to a file called
- This option logs information about the system’s real-time clock.
This option logs the raw and filtered reference clock measurements to a file called
This option logs the temperature measurements and system rate compensations to a file called
The log files are written to the directory specified by the
An example of the command is:
log measurements statistics tracking
This directive allows the directory where log files are written to be specified.
An example of the use of this directive is:
chronydwill cause the system to gradually correct any time offset, by slowing down or speeding up the clock as required. In certain situations, the system clock may be so far adrift that this slewing process would take a very long time to correct the system clock. This directive forces
chronydto step system clock if the adjustment is larger than a threshold value, but only if there were no more clock updates since
chronydwas started than a specified limit (a negative value can be used to disable the limit). This is particularly useful when using reference clock, because the
initstepslewdirective only works with
An example of the use of this directive is:
makestep 1000 10
This would step the system clock if the adjustment is larger than 1000 seconds, but only in the first ten clock updates.
This directive sets the maximum allowed offset corrected on a clock update. The check is performed only after the specified number of updates to allow a large initial adjustment of the system clock. When an offset larger than the specified maximum occurs, it will be ignored for the specified number of times and then
chronydwill give up and exit (a negative value can be used to never exit). In both cases a message is sent to syslog.
An example of the use of this directive is:
maxchange 1000 1 2
After the first clock update,
chronydwill check the offset on every clock update, it will ignore two adjustments larger than 1000 seconds and exit on another one.
chronyd's tasks is to work out how fast or slow the computer’s clock runs relative to its reference sources. In addition, it computes an estimate of the error bounds around the estimated value.
If the range of error is too large, it indicates that the measurements have not settled down yet, and that the estimated gain or loss rate is not very reliable.
maxupdateskewparameter is the threshold for determining whether an estimate is too unreliable to be used. By default, the threshold is 1000 ppm.
The format of the syntax is:
Typical values for skew-in-ppm might be 100 for a dial-up connection to servers over a telephone line, and 5 or 10 for a computer on a LAN.
It should be noted that this is not the only means of protection against using unreliable estimates. At all times,
chronydkeeps track of both the estimated gain or loss rate, and the error bound on the estimate. When a new estimate is generated following another measurement from one of the sources, a weighted combination algorithm is used to update the master estimate. So if
chronydhas an existing highly-reliable master estimate and a new estimate is generated which has large error bounds, the existing master estimate will dominate in the new master estimate.
minsourcesdirective sets the minimum number of sources that need to be considered as selectable in the source selection algorithm before the local clock is updated.
The format of the syntax is:
By default, number-of-sources is 1. Setting minsources to a larger number can be used to improve the reliability, because multiple sources will need to correspond with each other.
- This directive, which takes no arguments, specifies that client accesses are not to be logged. Normally they are logged, allowing statistics to be reported using the clients command in chronyc.
chronydselects synchronization source from available sources, it will prefer the one with minimum synchronization distance. However, to avoid frequent reselecting when there are sources with similar distance, a fixed distance is added to the distance for sources that are currently not selected. This can be set with the
reselectdistoption. By default, the distance is 100 microseconds.
The format of the syntax is:
stratumweightdirective sets how much distance should be added per stratum to the synchronization distance when
chronydselects the synchronization source from available sources.
The format of the syntax is:
By default, dist-in-seconds is 1 millisecond. This means that sources with lower stratum are usually preferred to sources with higher stratum even when their distance is significantly worse. Setting
stratumweightto 0 makes
chronydignore stratum when selecting the source.
rtcfiledirective defines the name of the file in which
chronydcan save parameters associated with tracking the accuracy of the system’s real-time clock (RTC).
The format of the syntax is:
chronydsaves information in this file when it exits and when the
writertccommand is issued in chronyc. The information saved is the RTC’s error at some epoch, that epoch (in seconds since January 1 1970), and the rate at which the RTC gains or loses time. Not all real-time clocks are supported as their code is system-specific. Note that if this directive is used then the real-time clock should not be manually adjusted as this would interfere with chrony's need to measure the rate at which the real-time clock drifts if it was adjusted at random intervals.
rtcsyncdirective is present in the
/etc/chrony.conffile by default. This will inform the kernel the system clock is kept synchronized and the kernel will update the real-time clock every 11 minutes.
18.2.3. Security with chronyc
Chronyc can access
chronyd in two ways:
- Internet Protocol (IPv4 or IPv6,
Unix domain socket, which is accessible locally by the
rootor chrony user.
By default, chronyc connects to the Unix domain socket. The default path is
/var/run/chrony/chronyd.sock. If this connection fails, which can happen for example when chronyc is running under a non-root user, chronyc tries to connect to 127.0.0.1 and then ::1.
Only the following monitoring commands, which do not affect the behavior of
chronyd, are allowed from the network:
- manual list
The set of hosts from which
chronyd accepts these commands can be configured with the
cmdallow directive in the configuration file of
chronyd, or the
cmdallow command in chronyc. By default, the commands are accepted only from localhost (127.0.0.1 or ::1).
All other commands are allowed only through the Unix domain socket. When sent over the network,
chronyd responds with a
Not authorised error, even if it is from localhost.
Accessing chronyd remotely with chronyc
Allow access from both IPv4 and IPv6 addresses by adding the following to the
Allow commands from the remote IP address, network, or subnet by using the
Add the following content to the
Open port 323 in the firewall to connect from a remote system.
~]# firewall-cmd --zone=public --add-port=323/udp
If you want to open port 323 permanently, use the
~]# firewall-cmd --permanent --zone=public --add-port=323/udp
Note that the
allow directive is for
NTP access whereas the
cmdallow directive is to enable receiving of remote commands. It is possible to make these changes temporarily using chronyc running locally. Edit the configuration file to make permanent changes.
18.3. Using chrony
18.3.1. Installing chrony
The chrony suite is installed by default on some versions of Red Hat Enterprise Linux 7. If required, to ensure that it is, run the following command as
~]# yum install chrony
The default location for the chrony daemon is
/usr/sbin/chronyd. The command line utility will be installed to
18.3.2. Checking the Status of chronyd
To check the status of
chronyd, issue the following command:
systemctl status chronydchronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Wed 2013-06-12 22:23:16 CEST; 11h ago
18.3.3. Starting chronyd
chronyd, issue the following command as
~]# systemctl start chronyd
chronyd starts automatically at system start, issue the following command as
~]# systemctl enable chronyd
18.3.4. Stopping chronyd
chronyd, issue the following command as
~]# systemctl stop chronyd
chronyd from starting automatically at system start, issue the following command as
~]# systemctl disable chronyd
18.3.5. Checking if chrony is Synchronized
To check if chrony is synchronized, make use of the
220.127.116.11. Checking chrony Tracking
To check chrony tracking, issue the following command:
chronyc trackingReference ID : CB00710F (foo.example.net) Stratum : 3 Ref time (UTC) : Fri Jan 27 09:49:17 2017 System time : 0.000006523 seconds slow of NTP time Last offset : -0.000006747 seconds RMS offset : 0.000035822 seconds Frequency : 3.225 ppm slow Residual freq : 0.000 ppm Skew : 0.129 ppm Root delay : 0.013639022 seconds Root dispersion : 0.001100737 seconds Update interval : 64.2 seconds Leap status : Normal
The fields are as follows:
- Reference ID
This is the reference ID and name (or
IPaddress) if available, of the server to which the computer is currently synchronized. Reference ID is a hexadecimal number to avoid confusion with IPv4 addresses.
- The stratum indicates how many hops away from a computer with an attached reference clock we are. Such a computer is a stratum-1 computer, so the computer in the example is two hops away (that is to say, a.b.c is a stratum-2 and is synchronized from a stratum-1).
- Ref time
- This is the time (UTC) at which the last measurement from the reference source was processed.
- System time
In normal operation,
chronydnever steps the system clock, because any jump in the timescale can have adverse consequences for certain application programs. Instead, any error in the system clock is corrected by slightly speeding up or slowing down the system clock until the error has been removed, and then returning to the system clock’s normal speed. A consequence of this is that there will be a period when the system clock (as read by other programs using the
gettimeofday()system call, or by the date command in the shell) will be different from
chronyd's estimate of the current true time (which it reports to
NTPclients when it is operating in server mode). The value reported on this line is the difference due to this effect.
- Last offset
- This is the estimated local offset on the last clock update.
- RMS offset
- This is a long-term average of the offset value.
The "frequency" is the rate by which the system’s clock would be wrong if
chronydwas not correcting it. It is expressed in ppm (parts per million). For example, a value of 1 ppm would mean that when the system’s clock thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.
- Residual freq
This shows the "residual frequency" for the currently selected reference source. This reflects any difference between what the measurements from the reference source indicate the frequency should be and the frequency currently being used.
The reason this is not always zero is that a smoothing procedure is applied to the frequency. Each time a measurement from the reference source is obtained and a new residual frequency computed, the estimated accuracy of this residual is compared with the estimated accuracy (see
skewnext) of the existing frequency value. A weighted average is computed for the new frequency, with weights depending on these accuracies. If the measurements from the reference source follow a consistent trend, the residual will be driven to zero over time.
- This is the estimated error bound on the frequency.
- Root delay
- This is the total of the network path delays to the stratum-1 computer from which the computer is ultimately synchronized. Root delay values are printed in nanosecond resolution. In certain extreme situations, this value can be negative. (This can arise in a symmetric peer arrangement where the computers’ frequencies are not tracking each other and the network delay is very short relative to the turn-around time at each computer.)
- Root dispersion
- This is the total dispersion accumulated through all the computers back to the stratum-1 computer from which the computer is ultimately synchronized. Dispersion is due to system clock resolution, statistical measurement variations etc. Root dispersion values are printed in nanosecond resolution.
- Leap status
- This is the leap status, which can be Normal, Insert second, Delete second or Not synchronized.
18.104.22.168. Checking chrony Sources
The sources command displays information about the current time sources that
chronyd is accessing.
The optional argument -v can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
~]$ chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* GPS0 0 4 377 11 -479ns[ -621ns] +/- 134ns ^? a.b.c 2 6 377 23 -923us[ -924us] +/- 43ms ^+ d.e.f 1 6 377 21 -2629us[-2619us] +/- 86ms
The columns are as follows:
This indicates the mode of the source.
^means a server,
=means a peer and
#indicates a locally connected reference clock.
This column indicates the state of the sources. "*" indicates the source to which
chronydis currently synchronized. "+" indicates acceptable sources which are combined with the selected source. "-" indicates acceptable sources which are excluded by the combining algorithm. "?" indicates sources to which connectivity has been lost or whose packets do not pass all tests. "x" indicates a clock which
chronydthinks is a falseticker (its time is inconsistent with a majority of other sources). "~" indicates a source whose time appears to have too much variability. The "?" condition is also shown at start-up, until at least 3 samples have been gathered from it.
- Name/IP address
This shows the name or the
IPaddress of the source, or reference ID for reference clock.
- This shows the stratum of the source, as reported in its most recently received sample. Stratum 1 indicates a computer with a locally attached reference clock. A computer that is synchronized to a stratum 1 computer is at stratum 2. A computer that is synchronized to a stratum 2 computer is at stratum 3, and so on.
This shows the rate at which the source is being polled, as a base-2 logarithm of the interval in seconds. Thus, a value of 6 would indicate that a measurement is being made every 64 seconds.
chronydautomatically varies the polling rate in response to prevailing conditions.
- This shows the source’s reach register printed as an octal number. The register has 8 bits and is updated on every received or missed packet from the source. A value of 377 indicates that a valid reply was received for all of the last eight transmissions.
This column shows how long ago the last sample was received from the source. This is normally in seconds. The letters
yindicate minutes, hours, days or years. A value of 10 years indicates there were no samples received from this source yet.
- Last sample
This column shows the offset between the local clock and the source at the last measurement. The number in the square brackets shows the actual measured offset. This may be suffixed by
ms(indicating milliseconds), or
s(indicating seconds). The number to the left of the square brackets shows the original measurement, adjusted to allow for any slews applied to the local clock since. The number following the
+/-indicator shows the margin of error in the measurement. Positive offsets indicate that the local clock is ahead of the source.
22.214.171.124. Checking chrony Source Statistics
sourcestats command displays information about the drift rate and offset estimation process for each of the sources currently being examined by
The optional argument
-v can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
chronyc sourcestats210 Number of sources = 1 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev =============================================================================== abc.def.ghi 11 5 46m -0.001 0.045 1us 25us
The columns are as follows:
- Name/IP address
This is the name or
IPaddress of the
NTPserver (or peer) or reference ID of the reference clock to which the rest of the line relates.
- This is the number of sample points currently being retained for the server. The drift rate and current offset are estimated by performing a linear regression through these points.
This is the number of runs of residuals having the same sign following the last regression. If this number starts to become too small relative to the number of samples, it indicates that a straight line is no longer a good fit to the data. If the number of runs is too low,
chronyddiscards older samples and re-runs the regression until the number of runs becomes acceptable.
- This is the interval between the oldest and newest samples. If no unit is shown the value is in seconds. In the example, the interval is 46 minutes.
- This is the estimated residual frequency for the server, in parts per million. In this case, the computer’s clock is estimated to be running 1 part in 109 slow relative to the server.
- Freq Skew
- This is the estimated error bounds on Freq (again in parts per million).
- This is the estimated offset of the source.
- Std Dev
- This is the estimated sample standard deviation.
18.3.6. Manually Adjusting the System Clock
To step the system clock immediately, bypassing any adjustments in progress by slewing, issue the following command as
~]# chronyc makestep
rtcfile directive is used, the real-time clock should not be manually adjusted. Random adjustments would interfere with chrony's need to measure the rate at which the real-time clock drifts.
18.4. Setting Up chrony for Different Environments
18.4.1. Setting Up chrony for a System in an Isolated Network
For a network that is never connected to the Internet, one computer is selected to be the master timeserver. The other computers are either direct clients of the master, or clients of clients. On the master, the drift file must be manually set with the average rate of drift of the system clock. If the master is rebooted, it will obtain the time from surrounding systems and calculate an average to set its system clock. Thereafter it resumes applying adjustments based on the drift file. The drift file will be updated automatically when the
settime command is used.
On the system selected to be the master, using a text editor running as
root, edit the
/etc/chrony.conf as follows:
driftfile /var/lib/chrony/drift commandkey 1 keyfile /etc/chrony.keys initstepslew 10 client1 client3 client6 local stratum 8 manual allow 192.0.2.0
192.0.2.0 is the network or subnet address from which the clients are allowed to connect.
On the systems selected to be direct clients of the master, using a text editor running as
root, edit the
/etc/chrony.conf as follows:
server master driftfile /var/lib/chrony/drift logdir /var/log/chrony log measurements statistics tracking keyfile /etc/chrony.keys commandkey 24 local stratum 10 initstepslew 20 master allow 192.0.2.123
192.0.2.123 is the address of the master, and
master is the host name of the master. Clients with this configuration will resynchronize the master if it restarts.
On the client systems which are not to be direct clients of the master, the
/etc/chrony.conf file should be the same except that the
allow directives should be omitted.
In an Isolated Network, you can also use the
local directive that enables a local reference mode, which allows
chronyd operating as an NTP server to appear synchronized to real time, even when it was never synchronized or the last update of the clock happened a long time ago.
To allow multiple servers in the network to use the same local configuration and to be synchronized to one another, without confusing clients that poll more than one server, use the
orphan option of the
local directive which enables the orphan mode. Each server needs to be configured to poll all other servers with
local. This ensures that only the server with the smallest reference ID has the local reference active and other servers are synchronized to it. When the server fails, another one will take over.
18.5. Using chronyc
18.5.1. Using chronyc to Control chronyd
To make changes to the local instance of
chronyd using the command line utility chronyc in interactive mode, enter the following command as
chronyc must run as
root if some of the restricted commands are to be used.
The chronyc command prompt will be displayed as follows:
You can type
help to list all of the commands.
The utility can also be invoked in non-interactive command mode if called together with a command as follows:
Changes made using chronyc are not permanent, they will be lost after a
chronyd restart. For permanent changes, modify
18.6. Chrony with HW timestamping
18.6.1. Understanding Hardware Timestamping
Hardware timestamping is a feature supported in some Network Interface Controller (NICs) which provides accurate timestamping of incoming and outgoing packets.
NTP timestamps are usually created by the kernel and chronyd with the use of the system clock. However, when HW timestamping is enabled, the NIC uses its own clock to generate the timestamps when packets are entering or leaving the link layer or the physical layer. When used with
NTP, hardware timestamping can significantly improve the accuracy of synchronization. For best accuracy, both
NTP servers and
NTP clients need to use hardware timestamping. Under ideal conditions, a sub-microsecond accuracy may be possible.
Another protocol for time synchronization that uses hardware timestamping is
PTP. For further information about
PTP, see Chapter 20, Configuring PTP Using ptp4l. Unlike
PTP relies on assistance in network switches and routers. If you want to reach the best accuracy of synchronization, use
PTP on networks that have switches and routers with
PTP support, and prefer
NTP on networks that do not have such switches and routers.
18.6.2. Verifying Support for Hardware Timestamping
To verify that hardware timestamping with
NTP is supported by an interface, use the
ethtool -T command. An interface can be used for hardware timestamping with
ethtool lists the
SOF_TIMESTAMPING_TX_SOFTWARE capabilities and also the
HWTSTAMP_FILTER_ALL filter mode.
Example 18.2. Verifying Support for Hardware Timestamping on a Specific Interface
~]# ethtool -T eth0
Timestamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
18.6.3. Enabling Hardware Timestamping
To enable hardware timestamping, use the
hwtimestamp directive in the
/etc/chrony.conf file. The directive can either specify a single interface, or a wildcard character () can be used to enable hardware timestamping on all interfaces that support it. Use the wildcard specification in case that no other application, like [application]*ptp4l from the linuxptp package, is using hardware timestamping on an interface. Multiple
hwtimestamp directives are allowed in the chrony configuration file.
Example 18.3. Enabling Hardware Timestamping by Using the hwtimestamp Directive
hwtimestamp eth0 hwtimestamp eth1 hwtimestamp *
18.6.4. Configuring Client Polling Interval
The default range of a polling interval (64-1024 seconds) is recommended for servers on the Internet. For local servers and hardware timestamping, a shorter polling interval needs to be configured in order to minimize offset of the system clock.
The following directive in
/etc/chrony.conf specifies a local
NTP server using one second polling interval:
server ntp.local minpoll 0 maxpoll 0
18.6.5. Enabling Interleaved Mode
NTP servers that are not hardware
NTP appliances, but rather general purpose computers running a software
NTP implementation, like chrony, will get a hardware transmit timestamp only after sending a packet. This behavior prevents the server from saving the timestamp in the packet to which it corresponds. In order to enable
NTP clients receiving transmit timestamps that were generated after the transmission, configure the clients to use the
NTP interleaved mode by adding the
xleave option to the server directive in
server ntp.local minpoll 0 maxpoll 0 xleave
18.6.6. Configuring Server for Large Number of Clients
The default server configuration allows a few thousands of clients at most to use the interleaved mode concurrently. To configure the server for a larger number of clients, increase the
clientloglimit directive in
/etc/chrony.conf. This directive specifies the maximum size of memory allocated for logging of clients' access on the server:
18.6.7. Verifying Hardware Timestamping
To verify that the interface has successfully enabled hardware timestamping, check the system log. The log should contain a message from chronyd for each interface with successfully enabled hardware timestamping.
Example 18.4. Log Messages for Interfaces with Enabled Hardware Timestamping
chronyd: Enabled HW timestamping on eth0 chronyd: Enabled HW timestamping on eth1
When chronyd is configured as an
NTP client or peer, you can have the transmit and receive timestamping modes and the interleaved mode reported for each
NTP source by the
chronyc ntpdata command:
Example 18.5. Reporting the Transmit, Receive Timestamping and Interleaved Mode for Each NTP Source
~]# chronyc ntpdata
Remote address : 203.0.113.15 (CB00710F) Remote port : 123 Local address : 203.0.113.74 (CB00714A) Leap status : Normal Version : 4 Mode : Server Stratum : 1 Poll interval : 0 (1 seconds) Precision : -24 (0.000000060 seconds) Root delay : 0.000015 seconds Root dispersion : 0.000015 seconds Reference ID : 47505300 (GPS) Reference time : Wed May 03 13:47:45 2017 Offset : -0.000000134 seconds Peer delay : 0.000005396 seconds Peer dispersion : 0.000002329 seconds Response time : 0.000152073 seconds Jitter asymmetry: +0.00 NTP tests : 111 111 1111 Interleaved : Yes Authenticated : No TX timestamping : Hardware RX timestamping : Hardware Total TX : 27 Total RX : 27 Total valid RX : 27
Example 18.6. Reporting the Stability of NTP Measurements
# chronyc sourcestats
With hardware timestamping enabled, stability of
NTP measurements should be in tens or hundreds of nanoseconds, under normal load. This stability is reported in the
Std Dev column of the output of the
chronyc sourcestats command:
210 Number of sources = 1 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ntp.local 12 7 11 +0.000 0.019 +0ns 49ns
18.6.8. Configuring PTP-NTP bridge
If a highly accurate Precision Time Protocol (
PTP) grandmaster is available in a network that does not have switches or routers with
PTP support, a computer may be dedicated to operate as a
PTP slave and a stratum-1
NTP server. Such a computer needs to have two or more network interfaces, and be close to the grandmaster or have a direct connection to it. This will ensure highly accurate synchronization in the network.
Configure the ptp4l and phc2sys programs from the linuxptp packages to use one interface to synchronize the system clock using
PTP. The configuration is described in the Chapter 20, Configuring PTP Using ptp4l. Configure chronyd to provide the system time using the other interface:
Example 18.7. Configuring chronyd to Provide the System Time Using the Other Interface
bindaddress 203.0.113.74 hwtimestamp eth1 local stratum 1
18.7. Additional Resources
The following sources of information provide additional resources regarding chrony.
18.7.1. Installed Documentation
chronyc(1)man page — Describes the chronyc command-line interface tool including commands and command options.
chronyd(8)man page — Describes the chronyd daemon including commands and command options.
chrony.conf(5)man page — Describes the chrony configuration file.
18.7.2. Online Documentation
For answers to FAQs, see http://chrony.tuxfamily.org/faq.html