chrony compared to other programs
1.1. How does
chrony compare to
ntpd are two different implementations of the Network Time
chrony is a newer implementation, which was designed to work well in a wider
range of conditions. It can usually synchronise the system clock faster and
with better time accuracy. It has many features, but it does not implement some
of the less useful NTP modes like broadcast client or multicast server/client.
If your computer is connected to the Internet only for few minutes at a time,
the network connection is often congested, you turn your computer off or
suspend it frequently, the clock is not very stable (e.g. there are rapid
changes in the temperature or it is a virtual machine), or you want to use NTP
on an isolated network with no hardware reference clocks in sight,
will probably work better for you.
For a more detailed comparison of features and performance, see the
comparison page on the
2. Configuration issues
2.1. What is the minimum recommended configuration for an NTP client?
First, the client needs to know which NTP servers it should ask for the current
time. They are specified by the
pool directive. The
directive can be used for names that resolve to multiple addresses. For good
reliability the client should have at least three servers. The
speeds up the initial synchronisation.
To stabilise the initial synchronisation on the next start, the estimated drift
of the system clock is saved to a file specified by the
If the system clock can be far from the true time after boot for any reason,
chronyd should be allowed to correct it quickly by stepping instead of
slewing, which would take a very long time. The
makestep directive does
In order to keep the real-time clock (RTC) close to the true time, so the
system time is reasonably close to the true time when it is initialised on the
next boot from the RTC, the
rtcsync directive enables a mode in which the
system time is periodically copied to the RTC. It is supported on Linux and
If you want to use public NTP servers from the pool.ntp.org project, the minimal chrony.conf file could be:
pool pool.ntp.org iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync
2.2. How do I make an NTP server?
You need to add an
allow directive to the chrony.conf file in order to open
the NTP port and allow
chronyd to reply to client requests.
allow with no
specified subnet allows access from all IPv4 and IPv6 addresses.
2.3. Should all computers on a LAN be clients of an external server?
It depends on the requirements. Usually, the best configuration is to make one
computer the server, with the others as clients of it. Add a
to the server’s chrony.conf file. This configuration will be better because
the load on the external connection is less
the load on the external NTP server(s) is less
if your external connection goes down, the computers on the LAN will maintain a common time with each other.
2.4. Must I specify servers by IP address if DNS is not available on
chronyd will keep trying to resolve
the names specified by the
peer directives in an
increasing interval until it succeeds. The
online command can be issued from
chronyc to force
chronyd to try to resolve the names immediately.
2.5. How can I make
chronyd more secure?
If you do not need to use
chronyc, or you want to run
under the root or chrony user (which can access
chronyd through a Unix
domain socket), you can disable the IPv4 and IPv6 command sockets (by default
listening on localhost) by adding
cmdport 0 to the configuration file.
You can specify an unprivileged user with the
-u option, or the
directive in the chrony.conf file, to which
chronyd will switch after start
in order to drop root privileges. The configure script has a
option, which sets the default user. On Linux,
chronyd needs to be compiled
with support for the
libcap library. On other systems,
chronyd forks into
two processes. The child process retains root privileges, but can only perform
a very limited range of privileged system calls on behalf of the parent.
chronyd is compiled with support for the Linux secure computing
(seccomp) facility, you can enable a system call filter with the
It will significantly reduce the kernel attack surface and possibly prevent
kernel exploits from the
chronyd process if it is compromised. It is
recommended to enable the filter only when it is known to work on the version of
the system where
chrony is installed as the filter needs to allow also system
calls made from libraries that
chronyd is using (e.g. libc) and different
versions or implementations of the libraries might make different system calls.
If the filter is missing some system call,
chronyd could be killed even in
2.6. How can I improve the accuracy of the system clock with NTP sources?
Select NTP servers that are well synchronised, stable and close to your
network. It is better to use more than one server, three or four is usually
recommended as the minimum, so
chronyd can detect servers that serve false
time and combine measurements from multiple sources.
If you have a network card with hardware timestamping supported on Linux, it
can be enabled by the
hwtimestamp directive in the chrony.conf file. It
should make local receive and transmit timestamps of NTP packets much more
There are also useful options which can be set in the
server directive, they
The first three options set the minimum and maximum allowed polling interval,
and how should be the actual interval adjusted in the specified range. Their
default values are 6 (64 seconds) for
minpoll, 10 (1024 seconds) for
maxpoll and 8 (samples) for
polltarget. The default values should be used
for general servers on the Internet. With your own NTP servers, or if you have
permission to poll some servers more frequently, setting these options for
shorter polling intervals might significantly improve the accuracy of the
The optimal polling interval depends mainly on two factors, stability of the network latency and stability of the system clock (which mainly depends on the temperature sensitivity of the crystal oscillator and the maximum rate of the temperature change).
Generally, if the
sourcestats command usually reports a small number of
samples retained for a source (e.g. fewer than 16), a shorter polling interval
should be considered. If the number of samples is usually at the maximum of 64,
a longer polling interval might work better.
An example of the directive for an NTP server on the Internet that you are allowed to poll frequently could be
server foo.example.net minpoll 4 maxpoll 6 polltarget 16
An example using shorter polling intervals with a server located in the same LAN could be
server ntp.local minpoll 2 maxpoll 4 polltarget 30
The maxdelay options are useful to ignore measurements with an unusally large
delay (e.g. due to congestion in the network) and improve the stability of the
maxdelaydevratio option could be added to the example
with local NTP server
server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2
If your server supports the interleaved mode (e.g. it is running
xleave option should be added to the
server directive in order to allow
the server to send the client more accurate transmit timestamps (kernel or
preferably hardware). For example:
server ntp.local minpoll 2 maxpoll 4 xleave
When combined with local hardware timestamping, good network switches, and even shorter polling intervals, a sub-microsecond accuracy and stability of a few tens of nanoseconds might be possible. For example:
server ntp.local minpoll 0 maxpoll 0 xleave hwtimestamp eth0
For best stability, the CPU should be running at a constant frequency (i.e.
disabled power saving and performance boosting). Energy-Efficient Ethernet
(EEE) should be disabled in the network. The switches should be configured to
prioritize NTP packets, especially if the network is expected to be heavily
dscp directive can be used to set the Differentiated Services
Code Point in transmitted NTP packets if needed.
If it is acceptable for NTP clients in the network to send requests at a high rate, a sub-second polling interval can be specified. A median filter can be enabled in order to update the clock at a reduced rate with more stable measurements. For example:
server ntp.local minpoll -6 maxpoll -6 filter 15 xleave hwtimestamp eth0 minpoll -6
chronyd have an ntpdate mode?
Yes. With the
chronyd will set the system clock once and exit.
-Q option it will print the measured offset without setting the
clock. If you do not want to use a configuration file, NTP servers can be
specified on the command line. For example:
# chronyd -q 'pool pool.ntp.org iburst'
The command above would normally take about 5 seconds if the servers were
well synchronised and responding to all requests. If not synchronised or
responding, it would take about 10 seconds for
chronyd to give up and exit
with a non-zero status. A faster configuration is possible. A single server can
be used instead of four servers, the number of measurements can be reduced with
maxsamples option to one (supported in
chrony version 4.0), and a
timeout can be specified with the
-t option. The following command would take
only up to about one second.
# chronyd -q -t 1 'server pool.ntp.org iburst maxsamples 1'
It is not recommended to run
chronyd with the
-q option periodically (e.g.
from a cron job) as a replacement for the daemon mode, because it performs
significantly worse (e.g. the clock is stepped and its frequency is not
corrected). If you must run it this way and you are using a public NTP server,
chronyd does not always start around the first second of a minute,
e.g. by adding a random sleep before the
chronyd command. Public servers
typically receive large bursts of requests around the first second as there is
a large number of NTP clients started from cron with no delay.
chronyd be configured to control the clock like
It is not possible to perfectly emulate
ntpd, but there are some options that
chronyd to behave more like
ntpd if there is a reason to
In the following example the
minsamples directive slows down the response to
changes in the frequency and offset of the clock. The
corrtimeratio directives reduce the maximum frequency error due to an offset
correction and the
maxdrift directive reduces the maximum assumed frequency
error of the clock. The
makestep directive enables a step threshold and the
maxchange directive enables a panic threshold. The
increases the minimum dispersion rate.
minsamples 32 maxslewrate 500 corrtimeratio 100 maxdrift 500 makestep 0.128 -1 maxchange 1000 1 1 maxclockerror 15
Note that increasing
minsamples might cause the offsets in the
sourcestats reports/logs to be significantly smaller than the actual offsets
and be unsuitable for monitoring.
2.9. Can NTP server be separated from NTP client?
Yes, it is possible to run multiple instances of
chronyd on the same
computer. One can be configured as an NTP client, and another as a server. They
need to use different pidfiles, NTP ports, command ports, and Unix domain
command sockets. The server instance should be started with the
-x option to
avoid touching the clock. It can be configured to serve the system time with
local directive, or synchronise its NTP clock to the client instance
running on localhost using a non-standard NTP port.
On Linux, starting with
chrony version 4.0, it is also possible to run
multiple server instances sharing a port to utilise multiple cores of the CPU.
Note that the client/server interleaved mode requires that all packets from an
address are handled by the same server instance.
2.10. Should be a leap smear enabled on NTP server?
leapsecmode directives it is possible to enable a
server leap smear in order to hide leap seconds from clients and force them to
follow a slow server’s adjustment instead.
This feature should be used only in local networks and only when necessary,
e.g. when the clients cannot be configured to handle the leap seconds as
needed, or their number is so large that configuring them all would be
impractical. The clients should use only one leap-smearing server, or multiple
identically configured leap-smearing servers. Note that some clients can get
leap seconds from external sources (e.g. with the
leapsectz directive in
chrony) and they will not work correctly with a leap smearing server.
chrony support PTP?
No, the Precision Time Protocol (PTP) is not supported and there are no plans to support it. It is a complex protocol, which shares some issues with the NTP broadcast mode. One of the main differences between NTP and PTP is that PTP was designed to be easily supported in hardware (e.g. network switches and routers) in order to make more stable and accurate measurements. PTP relies on the hardware support. NTP does not rely on any support in the hardware, but if it had the same support as PTP, it could perform equally well.
chrony supports hardware clocks that some NICs have for PTP. They
are called PTP hardware clocks (PHC). They can be used as reference clocks
(specified by the
refclock directive) and for hardware timestamping of NTP
packets (enabled by the
hwtimestamp directive) if the NIC can timestamp other
packets than PTP, which is usually the case at least for transmitted packets.
ethtool -T command can be used to verify the timestamping support.
2.12. What happened to the
They were removed in version 2.2. Authentication is no longer supported in the
command protocol. Commands that required authentication are now allowed only
through a Unix domain socket, which is accessible only by the root and chrony
users. If you need to configure
chronyd remotely or locally without the root
password, please consider using ssh and/or sudo to run
chronyc under the root
or chrony user on the host where
chronyd is running.
3. Computer is not synchronising
This is the most common problem. There are a number of reasons, see the following questions.
3.1. Behind a firewall?
Reach value printed by the
sources command. If it
is zero, it means
chronyd did not get any valid responses from the NTP server
you are trying to use. If there is a firewall between you and the server, the
packets might be blocked. Try using a tool like
tcpdump to see
if you are getting any responses from the server.
chronyd is receiving responses from the servers, the output of the
sources command issued few minutes after
chronyd start might look like
210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* foo.example.net 2 6 377 34 +484us[ -157us] +/- 30ms ^- bar.example.net 2 6 377 34 +33ms[ +32ms] +/- 47ms ^+ baz.example.net 3 6 377 35 -1397us[-2033us] +/- 60ms
3.2. Are NTP servers specified with the
Check that the
offline commands are used
appropriately (e.g. in the system networking scripts). The
prints the number of sources that are currently online and offline. For
200 OK 3 sources online 0 sources offline 0 sources doing burst (return to online) 0 sources doing burst (return to offline) 0 sources with unknown address
chronyd allowed to step the system clock?
chronyd adjusts the clock gradually by slowing it down or
speeding it up. If the clock is too far from the true time, it will take
a long time to correct the error. The
System time value printed by the
tracking command is the remaining correction that needs to be
applied to the system clock.
makestep directive can be used to allow
chronyd to step the clock. For
example, if chrony.conf had
makestep 1 3
the clock would be stepped in the first three updates if its offset was larger than one second. Normally, it is recommended to allow the step only in the first few updates, but in some cases (e.g. a computer without an RTC or virtual machine which can be suspended and resumed with an incorrect time) it might be necessary to allow the step on any clock update. The example above would change to
makestep 1 -1
3.4. Using a Windows NTP server?
A common issue with Windows NTP servers is that they report a very large root
dispersion (e.g. three seconds or more), which causes
chronyd to ignore the
server for being too inaccurate. The
sources command might show a valid
measurement, but the server is not selected for synchronisation. You can check
the root dispersion of the server with the
maxdistance value needs to be increased in chrony.conf to enable
synchronisation to such a server. For example:
3.5. An unreachable source is selected?
chronyd is configured with multiple time sources, it tries to select the
most accurate and stable sources for synchronisation of the system clock. They
are marked with the * or + symbol in the report printed by the
When the best source (marked with the * symbol) becomes unreachable (e.g. NTP
server stops responding),
chronyd will not immediately switch
to the second best source in an attempt to minimise the error of the clock. It
will let the clock run free for as long as its estimated error (in terms of
root distance) based on previous measurements is smaller than the estimated
error of the second source, and there is still an interval which contains some
measurements from both sources.
If the first source was significantly better than the second source, it can
take many hours before the second source is selected, depending on its polling
interval. You can force a faster reselection by increasing the clock error rate
maxclockerror directive), shortening the polling interval (
option), or reducing the number of samples (
3.6. Does selected source drop new measurements?
chronyd can drop a large number of successive NTP measurements if they are
not passing some of the NTP tests. The
sources command can report for a
selected source the fully-reachable value of 377 in the Reach column and at the
same time a LastRx value that is much larger than the current polling interval.
If the source is online, this indicates that a number of measurements was
dropped. You can use the
ntpdata command to check the NTP tests for the last
measurement. Usually, it is the test C which fails.
This can be an issue when there is a long-lasting increase in the measured
delay, e.g. due to a routing change in the network. Unfortunately,
does not know for how long it should wait for the delay to come back to the
original values, or whether it is a permanent increase and it should start from
The test C is an adaptive filter. It can take many hours before it accepts
a measurement with the larger delay, and even much longer before it drops all
measurements with smaller delay, which determine an expected delay used by the
test. You can use the
reset sources command to drop all measurements
immediately (available in chrony 4.0 and later). If this issue happens
frequently, you can effectively disable the test by setting the
maxdelaydevratio option to a very large value (e.g. 1000000), or speed up the
recovery by increasing the clock error rate with the
3.7. Using a PPS reference clock?
A pulse-per-second (PPS) reference clock requires a non-PPS time source to
determine which second of UTC corresponds to each pulse. If it is another
reference clock specified with the
lock option in the
the offset between the two reference clocks must be smaller than 0.2 seconds in
order for the PPS reference clock to work. With NMEA reference clocks it is
common to have a larger offset. It needs to be corrected with the
One approach to find out a good value of the
offset option is to configure
the reference clocks with the
noselect option and compare them to an NTP
server. For example, if the
sourcestats command showed
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== PPS0 0 0 0 +0.000 2000.000 +0ns 4000ms NMEA 58 30 231 -96.494 38.406 +504ms 6080us foo.example.net 7 3 200 -2.991 16.141 -107us 492us
the offset of the NMEA source would need to be increased by about 0.504 seconds. It does not have to be very accurate. As long as the offset of the NMEA reference clock stays below 0.2 seconds, the PPS reference clock should be able to determine the seconds corresponding to the pulses and allow the samples to be used for synchronisation.
4. Issues with
4.1. I keep getting the error
506 Cannot talk to daemon
chronyd remotely, make sure that the chrony.conf file (on
the computer where
chronyd is running) has a
cmdallow entry for the
computer you are running
chronyc on and an appropriate
directive. This is not necessary for localhost.
chronyd is not running. Try using the
ps command (e.g. on Linux,
ps -auxw) to see if it is running. Or try
netstat -a and see if the UDP
port 323 is listening. If
chronyd is not running, you might have a problem
with the way you are trying to start it (e.g. at boot time).
Perhaps you have a firewall set up in a way that blocks packets on the UDP port 323. You need to amend the firewall configuration in this case.
4.2. I keep getting the error
501 Not authorised
This error indicates that
chronyc sent the command to
chronyd using a UDP
socket instead of the Unix domain socket (e.g. /var/run/chrony/chronyd.sock),
which is required for some commands. For security reasons, only the root and
chrony users are allowed to access the socket.
It is also possible that the socket does not exist.
chronyd will not create
the socket if the directory has a wrong owner or permissions. In this case
there should be an error message from
chronyd in the system log.
4.3. What is the reference ID reported by the
The reference ID is a 32-bit value used in NTP to prevent synchronisation loops.
chrony versions before 3.0 it was printed in the
quad-dotted notation, even if the reference source did not actually have an
IPv4 address. For IPv4 addresses, the reference ID is equal to the address, but
for IPv6 addresses it is the first 32 bits of the MD5 sum of the address. For
reference clocks, the reference ID is the value specified with the
option in the
Since version 3.0, the reference ID is printed as a hexadecimal number to avoid confusion with IPv4 addresses.
If you need to get the IP address of the current reference source, use the
option to disable resolving of IP addresses and read the second field (printed
in parentheses) on the
Reference ID line.
4.4. Is the
chronyd protocol documented anywhere?
Only by the source code. See cmdmon.c (
chronyd side) and client.c
5. Real-time clock issues
5.1. What is the real-time clock (RTC)?
This is the clock which keeps the time even when your computer is turned off. It is used to initialise the system clock on boot. It normally does not drift more than few seconds per day.
There are two approaches how
chronyd can work with it. One is to use the
rtcsync directive, which tells
chronyd to enable a kernel mode which sets
the RTC from the system clock every 11 minutes.
chronyd itself won’t touch
the RTC. If the computer is not turned off for a long time, the RTC should
still be close to the true time when the system clock will be initialised from
it on the next boot.
The other option is to use the
rtcfile directive, which tells
monitor the rate at which the RTC gains or loses time. When
started with the
-s option on the next boot, it will set the system time from
the RTC and also compensate for the drift it has measured previously. The
rtcautotrim directive can be used to keep the RTC close to the true time, but
it is not strictly necessary if its only purpose is to set the system clock when
chronyd is started on boot. See the documentation for details.
hwclock have to be disabled?
hwclock program is often set-up by default in the boot and shutdown
scripts with many Linux installations. With the kernel RTC synchronisation
rtcsync directive), the RTC will be set also every 11 minutes as long as the
system clock is synchronised. If you want to use
chronyd's RTC monitoring
rtcfile directive), it is important to disable
hwclock in the shutdown
procedure. If you do not that, it will over-write the RTC with a new value, unknown
chronyd. At the next reboot,
chronyd started with the
-s option will
compensate this (wrong) time with its estimate of how far the RTC has drifted
whilst the power was off, giving a meaningless initial system time.
There is no need to remove
hwclock from the boot process, as long as
is started after it has run.
5.3. I just keep getting the
513 RTC driver not running message
For the real-time clock support to work, you need the following three things
an RTC in your computer
a Linux kernel with enabled RTC support
rtcfiledirective in your chrony.conf file
5.4. I get
Could not open /dev/rtc, Device or resource busy in my syslog file
Some other program running on the system might be using the device.
5.5. When I start
chronyd, the log says
Could not enable RTC interrupt : Invalid argument (or it may say
Your real-time clock hardware might not support the required ioctl requests:
A possible solution could be to build the Linux kernel with support for software emulation instead; try enabling the following configuration option when building the Linux kernel:
5.6. What if my computer does not have an RTC or backup battery?
In this case you can still use the
-s option to set the system clock to the
last modification time of the drift file, which should correspond to the system
chronyd was previously stopped. The initial system time will be
increasing across reboots and applications started after
chronyd will not
observe backward steps.
6. NTP-specific issues
chronyd be driven from broadcast/multicast NTP servers?
No, the broadcast/multicast client mode is not supported and there is currently no plan to implement it. While this mode can simplify configuration of clients in large networks, it is inherently less accurate and less secure (even with authentication) than the ordinary client/server mode.
When configuring a large number of clients in a network, it is recommended to
pool directive with a DNS name which resolves to addresses of
multiple NTP servers. The clients will automatically replace the servers when
they become unreachable, or otherwise unsuitable for synchronisation, with new
servers from the pool.
Even with very modest hardware, an NTP server can serve time to hundreds of thousands of clients using the ordinary client/server mode.
chronyd transmit broadcast NTP packets?
broadcast directive can be used to enable the broadcast server mode
to serve time to clients in the network which support the broadcast client mode
(it is not supported in
chronyd). Note that this mode should generally be
avoided. See the previous question.
chronyd keep the system clock a fixed offset away from real time?
Yes. Starting from version 3.0, an offset can be specified by the
option for all time sources in the chrony.conf file.
6.4. What happens if the network connection is dropped without using
offline command first?
chronyd will keep trying to access the sources that it thinks are online, and
it will take longer before new measurements are actually made and the clock is
corrected when the network is connected again. If the sources were set to
chronyd would make new measurements immediately after issuing the
Unless the network connection lasts only few minutes (less than the maximum polling interval), the delay is usually not a problem, and it might be acceptable to keep all sources online all the time.
6.5. Why is an offset measured between two computers synchronised to each another?
When two computers are synchronised to each other using the client/server or symmetric NTP mode, there is an expectation that NTP measurements between the two computers made on both ends show an average offset close to zero.
chronyd that can be expected only when the interleaved mode (
option) is enabled. Otherwise,
chronyd will use different transmit timestamps
(e.g. daemon timestamp vs kernel timestamp) for serving time and
synchronisation of its own clock, which creates an asymmetry in the
timestamping and causes the other end to measure a significant offset.
7. Operating systems
chrony support Windows?
chronyc program (the command-line client used for configuring
chronyd while it is running) has been successfully built and run under
Cygwin in the past.
chronyd is not portable, because part of it is
very system-dependent. It needs adapting to work with Windows'
equivalent of the adjtimex() call, and it needs to be made to work as a
7.2. Are there any plans to support Windows?
We have no plans to do this. Anyone is welcome to pick this work up and contribute it back to the project.