Adding upstream version 3.4.upstream/3.4upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

9 files changed, 10816 insertions, 0 deletions

diff --git a/doc/Makefile.in b/doc/Makefile.in
new file mode 100644
index 0000000..1777da5
--- /dev/null
+++ b/doc/Makefile.in
@@ -0,0 +1,76 @@
+ADOC = asciidoctor
+ADOC_FLAGS =
+SED = sed
+HTML_TO_TXT = w3m -dump -T text/html
+
+MAN_FILES = chrony.conf.man chronyc.man chronyd.man
+TXT_FILES = faq.txt installation.txt
+HTML_FILES = $(MAN_FILES:%.man=%.html) $(TXT_FILES:%.txt=%.html)
+MAN_IN_FILES = $(MAN_FILES:%.man=%.man.in)
+
+SYSCONFDIR = @SYSCONFDIR@
+BINDIR = @BINDIR@
+SBINDIR = @SBINDIR@
+MANDIR = @MANDIR@
+DOCDIR = @DOCDIR@
+CHRONYRUNDIR = @CHRONYRUNDIR@
+CHRONYVARDIR = @CHRONYVARDIR@
+CHRONY_VERSION = @CHRONY_VERSION@
+DEFAULT_USER = @DEFAULT_USER@
+DEFAULT_HWCLOCK_FILE = @DEFAULT_HWCLOCK_FILE@
+DEFAULT_PID_FILE = @DEFAULT_PID_FILE@
+DEFAULT_RTC_DEVICE = @DEFAULT_RTC_DEVICE@
+
+SED_COMMANDS = "s%\@SYSCONFDIR\@%$(SYSCONFDIR)%g;\
+	       s%\@BINDIR\@%$(BINDIR)%g;\
+	       s%\@SBINDIR\@%$(SBINDIR)%g;\
+	       s%\@CHRONY_VERSION\@%$(CHRONY_VERSION)%g;\
+	       s%\@DEFAULT_HWCLOCK_FILE\@%$(DEFAULT_HWCLOCK_FILE)%g;\
+	       s%\@DEFAULT_PID_FILE\@%$(DEFAULT_PID_FILE)%g;\
+	       s%\@DEFAULT_RTC_DEVICE\@%$(DEFAULT_RTC_DEVICE)%g;\
+	       s%\@DEFAULT_USER\@%$(DEFAULT_USER)%g;\
+	       s%\@CHRONYRUNDIR\@%$(CHRONYRUNDIR)%g;\
+	       s%\@CHRONYVARDIR\@%$(CHRONYVARDIR)%g;"
+
+man: $(MAN_FILES) $(MAN_IN_FILES)
+html: $(HTML_FILES)
+txt: $(TXT_FILES)
+docs: man html
+
+%.html: %.adoc
+	$(ADOC) $(ADOC_FLAGS) -b html -o - $< | $(SED) -e $(SED_COMMANDS) > $@
+
+%.man.in: %.adoc
+	$(ADOC) $(ADOC_FLAGS) -b manpage -o $@ $<
+
+%.man: %.man.in
+	$(SED) -e $(SED_COMMANDS) < $< > $@
+
+%.txt: %.html
+	$(HTML_TO_TXT) < $< > $@
+
+install: $(MAN_FILES)
+	[ -d $(DESTDIR)$(MANDIR)/man1 ] || mkdir -p $(DESTDIR)$(MANDIR)/man1
+	[ -d $(DESTDIR)$(MANDIR)/man5 ] || mkdir -p $(DESTDIR)$(MANDIR)/man5
+	[ -d $(DESTDIR)$(MANDIR)/man8 ] || mkdir -p $(DESTDIR)$(MANDIR)/man8
+	cp chronyc.man $(DESTDIR)$(MANDIR)/man1/chronyc.1
+	chmod 644 $(DESTDIR)$(MANDIR)/man1/chronyc.1
+	cp chronyd.man $(DESTDIR)$(MANDIR)/man8/chronyd.8
+	chmod 644 $(DESTDIR)$(MANDIR)/man8/chronyd.8
+	cp chrony.conf.man $(DESTDIR)$(MANDIR)/man5/chrony.conf.5
+	chmod 644 $(DESTDIR)$(MANDIR)/man5/chrony.conf.5
+
+install-docs: $(HTML_FILES)
+	[ -d $(DESTDIR)$(DOCDIR) ] || mkdir -p $(DESTDIR)$(DOCDIR)
+	for f in $(HTML_FILES); do \
+	  cp $$f $(DESTDIR)$(DOCDIR); \
+	  chmod 644 $(DESTDIR)$(DOCDIR)/$$f; \
+	done
+
+clean:
+	rm -f $(MAN_FILES) $(TXT_FILES) $(HTML_FILES)
+	rm -f $(MAN_IN_FILES)
+
+distclean:
+	rm -f $(MAN_FILES) $(TXT_FILES) $(HTML_FILES)
+	rm -f Makefile
diff --git a/doc/chrony.conf.adoc b/doc/chrony.conf.adoc
new file mode 100644
index 0000000..4b1239f
--- /dev/null
+++ b/doc/chrony.conf.adoc
@@ -0,0 +1,2460 @@
+// This file is part of chrony
+//
+// Copyright (C) Richard P. Curnow  1997-2003
+// Copyright (C) Stephen Wadeley  2016
+// Copyright (C) Bryan Christianson  2017
+// Copyright (C) Miroslav Lichvar  2009-2017
+//
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of version 2 of the GNU General Public License as
+// published by the Free Software Foundation.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+
+= chrony.conf(5)
+:doctype: manpage
+:man manual: Configuration Files
+:man source: chrony @CHRONY_VERSION@
+
+== NAME
+chrony.conf - chronyd configuration file
+
+== SYNOPSIS
+*chrony.conf*
+
+== DESCRIPTION
+
+This file configures the *chronyd* daemon. The compiled-in location is
+_@SYSCONFDIR@/chrony.conf_, but other locations can be specified on the
+*chronyd* command line with the *-f* option.
+
+Each directive in the configuration file is placed on a separate line. The
+following sections describe each of the directives in turn. The directives can
+occur in any order in the file and they are not case-sensitive.
+
+The configuration directives can also be specified directly on the *chronyd*
+command line. In this case each argument is parsed as a new line and the
+configuration file is ignored.
+
+While the number of supported directives is large, only a few of them are
+typically needed. See the <<examples,*EXAMPLES*>> section for configuration in
+typical operating scenarios.
+
+The configuration file might contain comment lines. A comment line is any line
+that starts with zero or more spaces followed by any one of the following
+characters: *!*, *;*, *#*, *%*. Any line with this format will be ignored.
+
+== DIRECTIVES
+
+=== Time sources
+
+[[server]]*server* _hostname_ [_option_]...::
+The *server* directive specifies an NTP server which can be used as a time
+source. The client-server relationship is strictly hierarchical: a client might
+synchronise its system time to that of the server, but the server's system time
+will never be influenced by that of a client.
++
+The *server* directive is immediately followed by either the name of the
+server, or its IP address. The *server* directive supports the following
+options:
++
+*minpoll* _poll_:::
+This option specifies the minimum interval between requests sent to the server
+as a power of 2 in seconds. For example, *minpoll 5* would mean that the
+polling interval should not drop below 32 seconds. The default is 6 (64
+seconds), the minimum is -6 (1/64th of a second), and the maximum is 24 (6
+months). Note that intervals shorter than 6 (64 seconds) should generally not
+be used with public servers on the Internet, because it might be considered
+abuse. A sub-second interval will be enabled only when the server is reachable
+and the round-trip delay is shorter than 10 milliseconds, i.e. the server
+should be in a local network.
+*maxpoll* _poll_:::
+This option specifies the maximum interval between requests sent to the server
+as a power of 2 in seconds. For example, *maxpoll 9* indicates that the polling
+interval should stay at or below 9 (512 seconds). The default is 10 (1024
+seconds), the minimum is -6 (1/64th of a second), and the maximum is 24 (6
+months).
+*iburst*:::
+With this option, the interval between the first four requests sent to the
+server will be 2 seconds or less instead of the interval specified by the
+*minpoll* option, which allows *chronyd* to make the first update of the clock
+shortly after start.
+*burst*:::
+With this option, *chronyd* will shorten the interval between up to four
+requests to 2 seconds or less when it cannot get a good measurement from the
+server. The number of requests in the burst is limited by the current polling
+interval to keep the average interval at or above the minimum interval, i.e.
+the current interval needs to be at least two times longer than the minimum
+interval in order to allow a burst with two requests.
+*key* _ID_:::
+The NTP protocol supports a message authentication code (MAC) to prevent
+computers having their system time upset by rogue packets being sent to them.
+The MAC is generated as a function of a password specified in the key file,
+which is specified by the <<keyfile,*keyfile*>> directive.
++
+The *key* option specifies which key (with an ID in the range 1 through 2^32-1)
+should *chronyd* use to authenticate requests sent to the server and verify its
+responses. The server must have the same key for this number configured,
+otherwise no relationship between the computers will be possible.
++
+If the server is running *ntpd* and the output size of the hash function used
+by the key is longer than 160 bits (e.g. SHA256), the *version* option needs to
+be set to 4 for compatibility.
+*maxdelay* _delay_:::
+*chronyd* uses the network round-trip delay to the server to determine how
+accurate a particular measurement is likely to be. Long round-trip delays
+indicate that the request, or the response, or both were delayed. If only one
+of the messages was delayed the measurement error is likely to be substantial.
++
+For small variations in the round-trip delay, *chronyd* uses a weighting scheme
+when processing the measurements. However, beyond a certain level of delay the
+measurements are likely to be so corrupted as to be useless. (This is
+particularly so on dial-up or other slow links, where a long delay probably
+indicates a highly asymmetric delay caused by the response waiting behind a lot
+of packets related to a download of some sort).
++
+If the user knows that round trip delays above a certain level should cause the
+measurement to be ignored, this level can be defined with the *maxdelay*
+option. For example, *maxdelay 0.3* would indicate that measurements with a
+round-trip delay of 0.3 seconds or more should be ignored. The default value is
+3 seconds and the maximum value is 1000 seconds.
+*maxdelayratio* _ratio_:::
+This option is similar to the *maxdelay* option above. *chronyd* keeps a record
+of the minimum round-trip delay amongst the previous measurements that it has
+buffered. If a measurement has a round trip delay that is greater than the
+maxdelayratio times the minimum delay, it will be rejected.
+*maxdelaydevratio* _ratio_:::
+If a measurement has a ratio of the increase in the round-trip delay from the
+minimum delay amongst the previous measurements to the standard deviation of
+the previous measurements that is greater than the specified ratio, it will be
+rejected. The default is 10.0.
+*mindelay* _delay_:::
+This option specifies a fixed minimum round-trip delay to be used instead of
+the minimum amongst the previous measurements. This can be useful in networks
+with static configuration to improve the stability of corrections for
+asymmetric jitter, weighting of the measurements, and the *maxdelayratio* and
+*maxdelaydevratio* tests. The value should be set accurately in order to have a
+positive effect on the synchronisation.
+*asymmetry* _ratio_:::
+This option specifies the asymmetry of the network jitter on the path to the
+source, which is used to correct the measured offset according to the delay.
+The asymmetry can be between -0.5 and +0.5. A negative value means the delay of
+packets sent to the source is more variable than the delay of packets sent from
+the source back. By default, *chronyd* estimates the asymmetry automatically.
+*offset* _offset_:::
+This option specifies a correction (in seconds) which will be applied to
+offsets measured with this source. It's particularly useful to compensate for a
+known asymmetry in network delay or timestamping errors. For example, if
+packets sent to the source were on average delayed by 100 microseconds more
+than packets sent from the source back, the correction would be -0.00005 (-50
+microseconds). The default is 0.0.
+*minsamples* _samples_:::
+Set the minimum number of samples kept for this source. This overrides the
+<<minsamples,*minsamples*>> directive.
+*maxsamples* _samples_:::
+Set the maximum number of samples kept for this source. This overrides the
+<<maxsamples,*maxsamples*>> directive.
+*filter* _samples_:::
+This option enables a median filter to reduce noise in NTP measurements. The
+filter will reduce the specified number of samples to a single sample. It is
+intended to be used with very short polling intervals in local networks where
+it is acceptable to generate a lot of NTP traffic.
+*offline*:::
+If the server will not be reachable when *chronyd* is started, the *offline*
+option can be specified. *chronyd* will not try to poll the server until it is
+enabled to do so (by using the <<chronyc.adoc#online,*online*>> command in
+*chronyc*).
+*auto_offline*:::
+With this option, the server will be assumed to have gone offline when sending
+a request fails, e.g. due to a missing route to the network. This option avoids
+the need to run the <<chronyc.adoc#offline,*offline*>> command from *chronyc*
+when disconnecting the network link. (It will still be necessary to use the
+<<chronyc.adoc#online,*online*>> command when the link has been established, to
+enable measurements to start.)
+*prefer*:::
+Prefer this source over sources without the *prefer* option.
+*noselect*:::
+Never select this source. This is particularly useful for monitoring.
+*trust*:::
+Assume time from this source is always true. It can be rejected as a
+falseticker in the source selection only if another source with this option
+does not agree with it.
+*require*:::
+Require that at least one of the sources specified with this option is
+selectable (i.e. recently reachable and not a falseticker) before updating the
+clock. Together with the *trust* option this might be useful to allow a trusted
+authenticated source to be safely combined with unauthenticated sources in
+order to improve the accuracy of the clock. They can be selected and used for
+synchronisation only if they agree with the trusted and required source.
+*xleave*:::
+This option enables an interleaved mode which allows the server or the peer to
+send transmit timestamps captured after the actual transmission (e.g. when the
+server or the peer is running *chronyd* with software (kernel) or hardware
+timestamping). This can significantly improve the accuracy of the measurements.
++
+The interleaved mode is compatible with servers that support only the basic
+mode, but peers must both support and have enabled the interleaved mode,
+otherwise the synchronisation will work only in one direction. Note that even
+servers that support the interleaved mode might respond in the basic mode as
+the interleaved mode requires the servers to keep some state for each client
+and the state might be dropped when there are too many clients (e.g.
+<<clientloglimit,*clientloglimit*>> is too small), or it might be overwritten
+by other clients that have the same IP address (e.g. computers behind NAT or
+someone sending requests with a spoofed source address).
++
+The *xleave* option can be combined with the *presend* option in order to
+shorten the interval in which the server has to keep the state to be able to
+respond in the interleaved mode.
+*polltarget* _target_:::
+Target number of measurements to use for the regression algorithm which
+*chronyd* will try to maintain by adjusting the polling interval between
+*minpoll* and *maxpoll*. A higher target makes *chronyd* prefer shorter polling
+intervals. The default is 8 and a useful range is from 6 to 60.
+*port* _port_:::
+This option allows the UDP port on which the server understands NTP requests to
+be specified. For normal servers this option should not be required (the
+default is 123, the standard NTP port).
+*presend* _poll_:::
+If the timing measurements being made by *chronyd* are the only network data
+passing between two computers, you might find that some measurements are badly
+skewed due to either the client or the server having to do an ARP lookup on the
+other party prior to transmitting a packet. This is more of a problem with long
+sampling intervals, which might be similar in duration to the lifetime of entries
+in the ARP caches of the machines.
++
+In order to avoid this problem, the *presend* option can be used. It takes a
+single integer argument, which is the smallest polling interval for which an
+extra pair of NTP packets will be exchanged between the client and the server
+prior to the actual measurement. For example, with the following option
+included in a *server* directive:
++
+----
+presend 9
+----
++
+when the polling interval is 512 seconds or more, an extra NTP client packet
+will be sent to the server a short time (2 seconds) before making the actual
+measurement.
++
+The *presend* option cannot be used in the *peer* directive. If it is used
+with the *xleave* option, *chronyd* will send two extra packets instead of one.
+*minstratum* _stratum_:::
+When the synchronisation source is selected from available sources, sources
+with lower stratum are normally slightly preferred. This option can be used to
+increase stratum of the source to the specified minimum, so *chronyd* will
+avoid selecting that source. This is useful with low stratum sources that are
+known to be unreliable or inaccurate and which should be used only when other
+sources are unreachable.
+*version* _version_:::
+This option sets the NTP version of packets sent to the server. This can be
+useful when the server runs an old NTP implementation that does not respond to
+requests using a newer version. The default version depends on whether a key is
+specified by the *key* option and which authentication hash function the key
+is using. If the output size of the hash function is longer than 160 bits, the
+default version is 3 for compatibility with older *chronyd* servers. Otherwise,
+the default version is 4.
+
+[[pool]]*pool* _name_ [_option_]...::
+The syntax of this directive is similar to that for the <<server,*server*>>
+directive, except that it is used to specify a pool of NTP servers rather than
+a single NTP server. The pool name is expected to resolve to multiple addresses
+which might change over time.
++
+All options valid in the <<server,*server*>> directive can be used in this
+directive too. There is one option specific to the *pool* directive:
+*maxsources* sets the maximum number of sources that can be used from the pool,
+the default value is 4.
++
+On start, when the pool name is resolved, *chronyd* will add up to 16 sources,
+one for each resolved address. When the number of sources from which at least
+one valid reply was received reaches the number specified by the *maxsources*
+option, the other sources will be removed. When a pool source is unreachable,
+marked as a falseticker, or has a distance larger than the limit set by the
+<<maxdistance,*maxdistance*>> directive, *chronyd* will try to replace the
+source with a newly resolved address from the pool.
++
+An example of the *pool* directive is
++
+----
+pool pool.ntp.org iburst maxsources 3
+----
+
+[[peer]]*peer* _hostname_ [_option_]...::
+The syntax of this directive is identical to that for the <<server,*server*>>
+directive, except that it specifies a symmetric association with an NTP peer
+instead of a client/server association with an NTP server. A single symmetric
+association allows the peers to be both servers and clients to each other. This
+is mainly useful when the NTP implementation of the peer (e.g. *ntpd*) supports
+ephemeral symmetric associations and does not need to be configured with an
+address of this host. *chronyd* does not support ephemeral associations.
++
+When a key is specified by the *key* option to enable authentication, both
+peers must use the same key and the same key number.
++
+Note that the symmetric mode is less secure than the client/server mode. A
+denial-of-service attack is possible on unauthenticated symmetric associations,
+i.e. when the peer was specified without the *key* option. An attacker who does
+not see network traffic between two hosts, but knows that they are peering with
+each other, can periodically send them unauthenticated packets with spoofed
+source addresses in order to disrupt their NTP state and prevent them from
+synchronising to each other. When the association is authenticated, an attacker
+who does see the network traffic, but cannot prevent the packets from reaching
+the other host, can still disrupt the state by replaying old packets. The
+attacker has effectively the same power as a man-in-the-middle attacker. A
+partial protection against this attack is implemented in *chronyd*, which can
+protect the peers if they are using the same polling interval and they never
+sent an authenticated packet with a timestamp from future, but it should not be
+relied on as it is difficult to ensure the conditions are met. If two hosts
+should be able to synchronise to each other in both directions, it is
+recommended to use two separate client/server associations (specified by the
+<<server,*server*>> directive on both hosts) instead.
+
+[[initstepslew]]*initstepslew* _step-threshold_ [_hostname_]...::
+In normal operation, *chronyd* slews the time when it needs to adjust the
+system clock. For example, to correct a system clock which is 1 second slow,
+*chronyd* slightly increases the amount by which the system clock is advanced
+on each clock interrupt, until the error is removed. Note that at no time does
+time run backwards with this method.
++
+On most Unix systems it is not desirable to step the system clock, because many
+programs rely on time advancing monotonically forwards.
++
+When the *chronyd* daemon is initially started, it is possible that the system
+clock is considerably in error. Attempting to correct such an error by slewing
+might not be sensible, since it might take several hours to correct the error by
+this means.
++
+The purpose of the *initstepslew* directive is to allow *chronyd* to make a
+rapid measurement of the system clock error at boot time, and to correct the
+system clock by stepping before normal operation begins. Since this would
+normally be performed only at an appropriate point in the system boot sequence,
+no other software should be adversely affected by the step.
++
+If the correction required is less than a specified threshold, a slew is used
+instead. This makes it safer to restart *chronyd* whilst the system is in
+normal operation.
++
+The *initstepslew* directive takes a threshold and a list of NTP servers as
+arguments. Each of the servers is rapidly polled several times, and a majority
+voting mechanism used to find the most likely range of system clock error that
+is present. A step or slew is applied to the system clock to correct this
+error. *chronyd* then enters its normal operating mode.
++
+An example of the use of the directive is:
++
+----
+initstepslew 30 foo.example.net bar.example.net
+----
++
+where 2 NTP servers are used to make the measurement. The _30_ indicates that
+if the system's error is found to be 30 seconds or less, a slew will be used to
+correct it; if the error is above 30 seconds, a step will be used.
++
+The *initstepslew* directive can also be used in an isolated LAN environment,
+where the clocks are set manually. The most stable computer is chosen as the
+master, and the other computers are slaved to it. If each of the slaves is
+configured with the <<local,*local*>> directive, the master can be set up with
+an *initstepslew* directive which references some or all of the slaves. Then,
+if the master machine has to be rebooted, the slaves can be relied on to act
+analogously to a flywheel and preserve the time for a short period while the
+master completes its reboot.
++
+The *initstepslew* directive is functionally similar to a combination of the
+<<makestep,*makestep*>> and <<server,*server*>> directives with the *iburst*
+option. The main difference is that the *initstepslew* servers are used only
+before normal operation begins and that the foreground *chronyd* process waits
+for *initstepslew* to finish before exiting. This is useful to prevent programs
+started in the boot sequence after *chronyd* from reading the clock before it
+has been stepped.
+
+[[refclock]]*refclock* _driver_ _parameter_[:__option__,...] [_option_]...::
+The *refclock* directive specifies a hardware reference clock to be used as a
+time source. It has two mandatory parameters, a driver name and a
+driver-specific parameter. The two parameters are followed by zero or more
+refclock options. Some drivers have special options, which can be appended to
+the driver-specific parameter (separated by the *:* and *,* characters).
++
+There are four drivers included in *chronyd*:
++
+*PPS*:::
+Driver for the kernel PPS (pulse per second) API. The parameter is the path to
+the PPS device (typically _/dev/pps?_). As PPS refclocks do not supply full
+time, another time source (e.g. NTP server or non-PPS refclock) is needed to
+complete samples from the PPS refclock. An alternative is to enable the
+<<local,*local*>> directive to allow synchronisation with some unknown but
+constant offset. The driver supports the following option:
++
+*clear*::::
+By default, the PPS refclock uses assert events (rising edge) for
+synchronisation. With this option, it will use clear events (falling edge)
+instead.
++
+:::
+Examples:
++
+----
+refclock PPS /dev/pps0 lock NMEA refid GPS
+refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect
+refclock PPS /dev/pps1:clear refid GPS2
+----
++
+*SHM*:::
+NTP shared memory driver. This driver uses a shared memory segment to receive
+samples from another process (e.g. *gpsd*). The parameter is the number of the
+shared memory segment, typically a small number like 0, 1, 2, or 3. The driver
+supports the following option:
++
+*perm*=_mode_::::
+This option specifies the permissions of the shared memory segment created by
+*chronyd*. They are specified as a numeric mode. The default value is 0600
+(read-write access for owner only).
+:::
++
+Examples:
++
+----
+refclock SHM 0 poll 3 refid GPS1
+refclock SHM 1:perm=0644 refid GPS2
+----
++
+*SOCK*:::
+Unix domain socket driver. It is similar to the SHM driver, but samples are
+received from a Unix domain socket instead of shared memory and the messages
+have a different format. The parameter is the path to the socket, which
+*chronyd* creates on start. An advantage over the SHM driver is that SOCK does
+not require polling and it can receive PPS samples with incomplete time. The
+format of the messages is described in the _refclock_sock.c_ file in the chrony
+source code.
++
+An application which supports the SOCK protocol is the *gpsd* daemon. The path
+where *gpsd* expects the socket to be created is described in the *gpsd(8)* man
+page. For example:
++
+----
+refclock SOCK /var/run/chrony.ttyS0.sock
+----
++
+*PHC*:::
+PTP hardware clock (PHC) driver. The parameter is the path to the device of
+the PTP clock which should be used as a time source. If the clock is kept in
+TAI instead of UTC (e.g. it is synchronised by a PTP daemon), the current
+UTC-TAI offset needs to be specified by the *offset* option. Alternatively, the
+*pps* refclock option can be enabled to treat the PHC as a PPS refclock, using
+only the sub-second offset for synchronisation. The driver supports the
+following options:
++
+*nocrossts*::::
+This option disables use of precise cross timestamping.
+*extpps*::::
+This option enables a PPS mode in which the PTP clock is timestamping pulses
+of an external PPS signal connected to the clock. The clock does not need to be
+synchronised, but another time source is needed to complete the PPS samples.
+Note that some PTP clocks cannot be configured to timestamp only assert or
+clear events, and it is necessary to use the *width* option to filter wrong
+PPS samples.
+*pin*=_index_::::
+This option specifies the index of the pin to which is connected the PPS
+signal. The default value is 0.
+*channel*=_index_::::
+This option specifies the index of the channel for the PPS mode. The default
+value is 0.
+*clear*::::
+This option enables timestamping of clear events (falling edge) instead of
+assert events (rising edge) in the PPS mode. This may not work with some
+clocks.
+:::
++
+Examples:
++
+----
+refclock PHC /dev/ptp0 poll 0 dpoll -2 offset -37
+refclock PHC /dev/ptp1:nocrossts poll 3 pps
+refclock PHC /dev/ptp2:extpps,pin=1 width 0.2 poll 2
+----
++
+::
+The *refclock* directive supports the following options:
++
+*poll* _poll_:::
+Timestamps produced by refclock drivers are not used immediately, but they are
+stored and processed by a median filter in the polling interval specified by
+this option. This is defined as a power of 2 and can be negative to specify a
+sub-second interval. The default is 4 (16 seconds). A shorter interval allows
+*chronyd* to react faster to changes in the frequency of the system clock, but
+it might have a negative effect on its accuracy if the samples have a lot of
+jitter.
+*dpoll* _dpoll_:::
+Some drivers do not listen for external events and try to produce samples in
+their own polling interval. This is defined as a power of 2 and can be negative
+to specify a sub-second interval. The default is 0 (1 second).
+*refid* _refid_:::
+This option is used to specify the reference ID of the refclock, as up to four
+ASCII characters. The default reference ID is composed from the first three
+characters of the driver name and the number of the refclock. Each refclock
+must have a unique reference ID.
+*lock* _refid_:::
+This option can be used to lock a PPS refclock to another refclock, which is
+specified by its reference ID. In this mode received PPS samples are paired
+directly with raw samples from the specified refclock.
+*rate* _rate_:::
+This option sets the rate of the pulses in the PPS signal (in Hz). This option
+controls how the pulses will be completed with real time. To actually receive
+more than one pulse per second, a negative *dpoll* has to be specified (-3 for
+a 5Hz signal). The default is 1.
+*maxlockage* _pulses_:::
+This option specifies in number of pulses how old can be samples from the
+refclock specified by the *lock* option to be paired with the pulses.
+Increasing this value is useful when the samples are produced at a lower rate
+than the pulses. The default is 2.
+*width* _width_:::
+This option specifies the width of the pulses (in seconds). It is used to
+filter PPS samples when the driver provides samples for both rising and falling
+edges. Note that it reduces the maximum allowed error of the time source which
+completes the PPS samples. If the duty cycle is configurable, 50% should be
+preferred in order to maximise the allowed error.
+*pps*:::
+This options forces *chronyd* to treat any refclock (e.g. SHM or PHC) as a PPS
+refclock. This can be useful when the refclock provides time with a variable
+offset of a whole number of seconds (e.g. it uses TAI instead of UTC). Another
+time source is needed to complete samples from the refclock.
+*offset* _offset_:::
+This option can be used to compensate for a constant error. The specified
+offset (in seconds) is applied to all samples produced by the reference clock.
+The default is 0.0.
+*delay* _delay_:::
+This option sets the NTP delay of the source (in seconds). Half of this value
+is included in the maximum assumed error which is used in the source selection
+algorithm. Increasing the delay is useful to avoid having no majority in the
+source selection or to make it prefer other sources. The default is 1e-9 (1
+nanosecond).
+*stratum* _stratum_:::
+This option sets the NTP stratum of the refclock. This can be useful when the
+refclock provides time with a stratum other than 0. The default is 0.
+*precision* _precision_:::
+This option sets the precision of the reference clock (in seconds). The default
+value is the estimated precision of the system clock.
+*maxdispersion* _dispersion_:::
+Maximum allowed dispersion for filtered samples (in seconds). Samples with
+larger estimated dispersion are ignored. By default, this limit is disabled.
+*filter* _samples_:::
+This option sets the length of the median filter which is used to reduce the
+noise in the measurements. With each poll about 40 percent of the stored
+samples are discarded and one final sample is calculated as an average of the
+remaining samples. If the length is 4 or more, at least 4 samples have to be
+collected between polls. For lengths below 4, the filter has to be full. The
+default is 64.
+*prefer*:::
+Prefer this source over sources without the prefer option.
+*noselect*:::
+Never select this source. This is useful for monitoring or with sources which
+are not very accurate, but are locked with a PPS refclock.
+*trust*:::
+Assume time from this source is always true. It can be rejected as a
+falseticker in the source selection only if another source with this option
+does not agree with it.
+*require*:::
+Require that at least one of the sources specified with this option is
+selectable (i.e. recently reachable and not a falseticker) before updating the
+clock. Together with the *trust* option this can be useful to allow a trusted,
+but not very precise, reference clock to be safely combined with
+unauthenticated NTP sources in order to improve the accuracy of the clock. They
+can be selected and used for synchronisation only if they agree with the
+trusted and required source.
+*tai*:::
+This option indicates that the reference clock keeps time in TAI instead of UTC
+and that *chronyd* should correct its offset by the current TAI-UTC offset. The
+<<leapsectz,*leapsectz*>> directive must be used with this option and the
+database must be kept up to date in order for this correction to work as
+expected. This option does not make sense with PPS refclocks.
+*minsamples* _samples_:::
+Set the minimum number of samples kept for this source. This overrides the
+<<minsamples,*minsamples*>> directive.
+*maxsamples* _samples_:::
+Set the maximum number of samples kept for this source. This overrides the
+<<maxsamples,*maxsamples*>> directive.
+
+[[manual]]*manual*::
+The *manual* directive enables support at run-time for the
+<<chronyc.adoc#settime,*settime*>> command in *chronyc*. If no *manual*
+directive is included, any attempt to use the *settime* command in *chronyc*
+will be met with an error message.
++
+Note that the *settime* command can be enabled at run-time using
+the <<chronyc.adoc#manual,*manual*>> command in *chronyc*. (The idea of the two
+commands is that the *manual* command controls the manual clock driver's
+behaviour, whereas the *settime* command allows samples of manually entered
+time to be provided.)
+
+[[acquisitionport]]*acquisitionport* _port_::
+By default, *chronyd* uses a separate client socket for each configured server
+and their source port is chosen arbitrarily by the operating system. However,
+you can use the *acquisitionport* directive to explicitly specify a port and
+use only one socket (per IPv4 or IPv6 address family) for all configured servers.
+This can be useful for getting through some firewalls. If set to 0, the source
+port of the socket will be chosen arbitrarily.
++
+It can be set to the same port as is used by the NTP server (which can be
+configured with the <<port,*port*>> directive) to use only one socket for all
+NTP packets.
++
+An example of the *acquisitionport* directive is:
++
+----
+acquisitionport 1123
+----
++
+This would change the source port used for client requests to UDP port 1123.
+You could then persuade the firewall administrator to open that port.
+
+[[bindacqaddress]]*bindacqaddress* _address_::
+The *bindacqaddress* directive sets the network interface to which
+*chronyd* will bind its NTP client sockets. The syntax is similar to the
+<<bindaddress,*bindaddress*>> and <<bindcmdaddress,*bindcmdaddress*>>
+directives.
++
+For each of the IPv4 and IPv6 protocols, only one *bindacqaddress* directive
+can be specified.
+
+[[dumpdir]]*dumpdir* _directory_::
+To compute the rate of gain or loss of time, *chronyd* has to store a
+measurement history for each of the time sources it uses.
++
+All supported systems, with the exception of macOS 10.12 and earlier, have
+operating system support for setting the rate of gain or loss to compensate for
+known errors.
+(On macOS 10.12 and earlier, *chronyd* must simulate such a capability by
+periodically slewing the system clock forwards or backwards by a suitable amount
+to compensate for the error built up since the previous slew.)
++
+For such systems, it is possible to save the measurement history across
+restarts of *chronyd* (assuming no changes are made to the system clock
+behaviour whilst it is not running). The *dumpdir* directive defines the
+directory where the measurement histories are saved when *chronyd* exits,
+or the <<chronyc.adoc#dump,*dump*>> command in *chronyc* is issued.
++
+An example of the directive is:
++
+----
+dumpdir @CHRONYRUNDIR@
+----
++
+A source whose IP address is _1.2.3.4_ would have its measurement history saved
+in the file _@CHRONYRUNDIR@/1.2.3.4.dat_. History of reference clocks is saved
+to files named by their reference ID in form of _refid:XXXXXXXX.dat_.
+
+[[maxsamples]]*maxsamples* _samples_::
+The *maxsamples* directive sets the default maximum number of samples that
+*chronyd* should keep for each source. This setting can be overridden for
+individual sources in the <<server,*server*>> and <<refclock,*refclock*>>
+directives. The default value is 0, which disables the configurable limit. The
+useful range is 4 to 64.
+
+[[minsamples]]*minsamples* _samples_::
+The *minsamples* directive sets the default minimum number of samples that
+*chronyd* should keep for each source. This setting can be overridden for
+individual sources in the <<server,*server*>> and <<refclock,*refclock*>>
+directives. The default value is 6. The useful range is 4 to 64.
++
+Forcing *chronyd* to keep more samples than it would normally keep reduces
+noise in the estimated frequency and offset, but slows down the response to
+changes in the frequency and offset of the clock. The offsets in the
+<<chronyc.adoc#tracking,*tracking*>> and
+<<chronyc.adoc#sourcestats,*sourcestats*>> reports (and the _tracking.log_ and
+_statistics.log_ files) may be smaller than the actual offsets.
+
+=== Source selection
+
+[[combinelimit]]*combinelimit* _limit_::
+When *chronyd* has multiple sources available for synchronisation, it has to
+select one source as the synchronisation source. The measured offsets and
+frequencies of the system clock relative to the other sources, however, can be
+combined with the selected source to improve the accuracy of the system clock.
++
+The *combinelimit* directive limits which sources are included in the combining
+algorithm. Their synchronisation distance has to be shorter than the distance
+of the selected source multiplied by the value of the limit. Also, their
+measured frequencies have to be close to the frequency of the selected source.
++
+By default, the limit is 3. Setting the limit to 0 effectively disables the
+source combining algorithm and only the selected source will be used to control
+the system clock.
+
+[[maxdistance]]*maxdistance* _distance_::
+The *maxdistance* directive sets the maximum allowed root distance of the
+sources to not be rejected by the source selection algorithm. The distance
+includes the accumulated dispersion, which might be large when the source is no
+longer synchronised, and half of the total round-trip delay to the primary
+source.
++
+By default, the maximum root distance is 3 seconds.
++
+Setting *maxdistance* to a larger value can be useful to allow synchronisation
+with a server that only has a very infrequent connection to its sources and can
+accumulate a large dispersion between updates of its clock.
+
+[[maxjitter]]*maxjitter* _jitter_::
+The *maxjitter* directive sets the maximum allowed jitter of the sources to not
+be rejected by the source selection algorithm. This prevents synchronisation
+with sources that have a small root distance, but their time is too variable.
++
+By default, the maximum jitter is 1 second.
+
+[[minsources]]*minsources* _sources_::
+The *minsources* directive 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 default value is 1.
++
+Setting this option to a larger number can be used to improve the reliability.
+More sources will have to agree with each other and the clock will not be
+updated when only one source (which could be serving incorrect time) is
+reachable.
+
+[[reselectdist]]*reselectdist* _distance_::
+When *chronyd* selects a synchronisation source from available sources, it
+will prefer the one with the shortest synchronisation 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 *reselectdist* directive. By default, the
+distance is 100 microseconds.
+
+[[stratumweight]]*stratumweight* _distance_::
+The *stratumweight* directive sets how much distance should be added per
+stratum to the synchronisation distance when *chronyd* selects the
+synchronisation source from available sources.
++
+By default, the weight is 0.001 seconds. This means that the stratum of the sources
+in the selection process matters only when the differences between the
+distances are in milliseconds.
+
+=== System clock
+
+[[corrtimeratio]]*corrtimeratio* _ratio_::
+When *chronyd* is slewing the system clock to correct an offset, the rate at
+which it is slewing adds to the frequency error of the clock. On all supported
+systems, with the exception of macOS 12 and earlier, this rate can be
+controlled.
++
+The *corrtimeratio* directive sets the ratio between the duration in which the
+clock is slewed for an average correction according to the source history and
+the interval in which the corrections are done (usually the NTP polling
+interval). Corrections larger than the average take less time and smaller
+corrections take more time, the amount of the correction and the correction
+time are inversely proportional.
++
+Increasing *corrtimeratio* improves the overall frequency error of the system
+clock, but increases the overall time error as the corrections take longer.
++
+By default, the ratio is set to 3, the time accuracy of the clock is preferred
+over its frequency accuracy.
++
+The maximum allowed slew rate can be set by the <<maxslewrate,*maxslewrate*>>
+directive. The current remaining correction is shown in the
+<<chronyc.adoc#tracking,*tracking*>> report as the *System time* value.
+
+[[driftfile]]*driftfile* _file_::
+One of the main activities of the *chronyd* program is to work out the rate at
+which the system clock gains or loses time relative to real time.
++
+Whenever *chronyd* computes a new value of the gain or loss rate, it is desirable
+to record it somewhere. This allows *chronyd* to begin compensating the system
+clock at that rate whenever it is restarted, even before it has had a chance to
+obtain an equally good estimate of the rate during the new run. (This process
+can take many minutes, at least.)
++
+The *driftfile* directive allows a file to be specified into which *chronyd*
+can store the rate information. Two parameters are recorded in the file. The
+first is the rate at which the system clock gains or loses time, expressed in
+parts per million, with gains positive. Therefore, a value of 100.0 indicates
+that when the system clock has advanced by a second, it has gained 100
+microseconds in reality (so the true time has only advanced by 999900
+microseconds). The second is an estimate of the error bound around the first
+value in which the true rate actually lies.
++
+An example of the driftfile directive is:
++
+----
+driftfile @CHRONYVARDIR@/drift
+----
+
+[[fallbackdrift]]*fallbackdrift* _min-interval_ _max-interval_::
+Fallback drifts are long-term averages of the system clock drift calculated
+over exponentially increasing intervals. They are used to avoid quickly
+drifting away from true time when the clock was not updated for a longer period
+of time and there was a short-term deviation in the drift before the updates
+stopped.
++
+The directive specifies the minimum and maximum interval since the last clock
+update to switch between fallback drifts. They are defined as a power of 2 (in
+seconds). The syntax is as follows:
++
+----
+fallbackdrift 16 19
+----
++
+In this example, the minimum interval is 16 (18 hours) and the maximum interval is
+19 (6 days). The system clock frequency will be set to the first fallback 18
+hours after last clock update, to the second after 36 hours, and so on. This
+might be a good setting to cover frequency changes due to daily and weekly
+temperature fluctuations. When the frequency is set to a fallback, the state of
+the clock will change to '`Not synchronised`'.
++
+By default (or if the specified maximum or minimum is 0), no fallbacks are used
+and the clock frequency changes only with new measurements from NTP sources,
+reference clocks, or manual input.
+
+[[leapsecmode]]*leapsecmode* _mode_::
+A leap second is an adjustment that is occasionally applied to UTC to keep it
+close to the mean solar time. When a leap second is inserted, the last day of
+June or December has an extra second 23:59:60.
++
+For computer clocks that is a problem. The Unix time is defined as number of
+seconds since 00:00:00 UTC on 1 January 1970 without leap seconds. The system
+clock cannot have time 23:59:60, every minute has 60 seconds and every day has
+86400 seconds by definition. The inserted leap second is skipped and the clock
+is suddenly ahead of UTC by one second. The *leapsecmode* directive selects how
+that error is corrected. There are four options:
++
+*system*:::
+When inserting a leap second, the kernel steps the system clock backwards by
+one second when the clock gets to 00:00:00 UTC. When deleting a leap second, it
+steps forward by one second when the clock gets to 23:59:59 UTC. This is the
+default mode when the system driver supports leap seconds (i.e. all supported
+systems with the exception of macOS 12 and earlier).
+*step*:::
+This is similar to the *system* mode, except the clock is stepped by
+*chronyd* instead of the kernel. It can be useful to avoid bugs in the kernel
+code that would be executed in the *system* mode. This is the default mode
+when the system driver does not support leap seconds.
+*slew*:::
+The clock is corrected by slewing started at 00:00:00 UTC when a leap second
+is inserted or 23:59:59 UTC when a leap second is deleted. This might be
+preferred over the *system* and *step* modes when applications running on the
+system are sensitive to jumps in the system time and it is acceptable that the
+clock will be off for a longer time. On Linux with the default
+<<maxslewrate,*maxslewrate*>> value the correction takes 12 seconds.
+*ignore*:::
+No correction is applied to the clock for the leap second. The clock will be
+corrected later in normal operation when new measurements are made and the
+estimated offset includes the one second error.
+::
++
+When serving time to NTP clients that cannot be configured to correct their
+clocks for a leap second by slewing, or to clients that would correct at
+slightly different rates when it is necessary to keep them close together, the
+*slew* mode can be combined with the <<smoothtime,*smoothtime*>> directive to
+enable a server leap smear.
++
+When smearing a leap second, the leap status is suppressed on the server and
+the served time is corrected slowly be slewing instead of stepping. The clients
+do not need any special configuration as they do not know there is any leap
+second and they follow the server time which eventually brings them back to
+UTC. Care must be taken to ensure they use only NTP servers which smear the
+leap second in exactly the same way for synchronisation.
++
+This feature must be used carefully, because the server is intentionally not
+serving its best estimate of the true time.
++
+A recommended configuration to enable a server leap smear is:
++
+----
+leapsecmode slew
+maxslewrate 1000
+smoothtime 400 0.001 leaponly
+----
++
+The first directive is necessary to disable the clock step which would reset
+the smoothing process. The second directive limits the slewing rate of the
+local clock to 1000 ppm, which improves the stability of the smoothing process
+when the local correction starts and ends. The third directive enables the
+server time smoothing process. It will start when the clock gets to 00:00:00
+UTC and it will take 17 hours 34 minutes to finish. The frequency offset will
+be changing by 0.001 ppm per second and will reach a maximum of 31.623 ppm. The
+*leaponly* option makes the duration of the leap smear constant and allows the
+clients to safely synchronise with multiple identically configured leap
+smearing servers.
+
+[[leapsectz]]*leapsectz* _timezone_::
+This directive specifies a timezone in the system tz database which *chronyd*
+can use to determine when will the next leap second occur and what is the
+current offset between TAI and UTC. It will periodically check if 23:59:59 and
+23:59:60 are valid times in the timezone. This typically works with the
+_right/UTC_ timezone.
++
+When a leap second is announced, the timezone needs to be updated at least 12
+hours before the leap second. It is not necessary to restart *chronyd*.
++
+This directive is useful with reference clocks and other time sources which do
+not announce leap seconds, or announce them too late for an NTP server to
+forward them to its own clients. Clients of leap smearing servers must not
+use this directive.
++
+It is also useful when the system clock is required to have correct TAI-UTC
+offset. Note that the offset is set only when leap seconds are handled by the
+kernel, i.e. <<leapsecmode,*leapsecmode*>> is set to *system*.
++
+The specified timezone is not used as an exclusive source of information about
+leap seconds. If a majority of time sources announce on the last day of June or
+December that a leap second should be inserted or deleted, it will be accepted
+even if it is not included in the timezone.
++
+An example of the directive is:
++
+----
+leapsectz right/UTC
+----
++
+The following shell command verifies that the timezone contains leap seconds
+and can be used with this directive:
++
+----
+$ TZ=right/UTC date -d 'Dec 31 2008 23:59:60'
+Wed Dec 31 23:59:60 UTC 2008
+----
+
+[[makestep]]*makestep* _threshold_ _limit_::
+Normally *chronyd* will 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 might be so far adrift that this slewing process would take a
+very long time to correct the system clock.
++
+This directive forces *chronyd* to step the system clock if the adjustment is
+larger than a threshold value, but only if there were no more clock updates
+since *chronyd* was started than a specified limit (a negative value can be
+used to disable the limit).
++
+This is particularly useful when using reference clocks, because the
+<<initstepslew,*initstepslew*>> directive works only with NTP sources.
++
+An example of the use of this directive is:
++
+----
+makestep 0.1 3
+----
++
+This would step the system clock if the adjustment is larger than 0.1 seconds, but
+only in the first three clock updates.
+
+[[maxchange]]*maxchange* _offset_ _start_ _ignore_::
+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 *chronyd* will 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, *chronyd* will check the offset on every clock
+update, it will ignore two adjustments larger than 1000 seconds and exit on
+another one.
+
+[[maxclockerror]]*maxclockerror* _error-in-ppm_::
+The *maxclockerror* directive sets the maximum assumed frequency error that the
+system clock can gain on its own between clock updates. It describes the
+stability of the clock.
++
+By default, the maximum error is 1 ppm.
++
+Typical values for _error-in-ppm_ might be 10 for a low quality clock and 0.1
+for a high quality clock using a temperature compensated crystal oscillator.
+
+[[maxdrift]]*maxdrift* _drift-in-ppm_::
+This directive specifies the maximum assumed drift (frequency error) of the
+system clock. It limits the frequency adjustment that *chronyd* is allowed to
+use to correct the measured drift. It is an additional limit to the maximum
+adjustment that can be set by the system driver (100000 ppm on Linux, 500 ppm
+on FreeBSD, NetBSD, and macOS 10.13+, 32500 ppm on Solaris).
++
+By default, the maximum assumed drift is 500000 ppm, i.e. the adjustment is
+limited by the system driver rather than this directive.
+
+[[maxupdateskew]]*maxupdateskew* _skew-in-ppm_::
+One of *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 probably indicates that the measurements
+have not settled down yet, and that the estimated gain or loss rate is not very
+reliable.
++
+The *maxupdateskew* directive sets the threshold for determining whether an
+estimate might be so unreliable that it should not be used. By default, the
+threshold is 1000 ppm.
++
+Typical values for _skew-in-ppm_ might be 100 for a dial-up connection to
+servers over a phone 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, *chronyd* keeps 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 *chronyd*
+has 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.
+
+[[maxslewrate]]*maxslewrate* _rate-in-ppm_::
+The *maxslewrate* directive sets the maximum rate at which *chronyd* is allowed
+to slew the time. It limits the slew rate controlled by the correction time
+ratio (which can be set by the <<corrtimeratio,*corrtimeratio*>> directive) and
+is effective only on systems where *chronyd* is able to control the rate (i.e.
+all supported systems with the exception of macOS 12 or earlier).
++
+For each system there is a maximum frequency offset of the clock that can be set
+by the driver. On Linux it is 100000 ppm, on FreeBSD, NetBSD and macOS 10.13+ it
+is 5000 ppm, and on Solaris it is 32500 ppm. Also, due to a kernel limitation,
+setting *maxslewrate* on FreeBSD, NetBSD, macOS 10.13+ to a value between 500
+ppm and 5000 ppm will effectively set it to 500 ppm.
++
+In early beta releases of macOS 13 this capability is disabled because of a
+system kernel bug. When the kernel bug is fixed, chronyd will detect this and
+re-enable the capability (see above limitations) with no recompilation required.
++
+By default, the maximum slew rate is set to 83333.333 ppm (one twelfth).
+
+[[tempcomp]]
+*tempcomp* _file_ _interval_ _T0_ _k0_ _k1_ _k2_::
+*tempcomp* _file_ _interval_ _points-file_::
+Normally, changes in the rate of drift of the system clock are caused mainly by
+changes in the temperature of the crystal oscillator on the motherboard.
++
+If there are temperature measurements available from a sensor close to the
+oscillator, the *tempcomp* directive can be used to compensate for the changes
+in the temperature and improve the stability and accuracy of the clock.
++
+The result depends on many factors, including the resolution of the sensor, the
+amount of noise in the measurements, the polling interval of the time source,
+the compensation update interval, how well the compensation is specified, and
+how close the sensor is to the oscillator. When it is working well, the
+frequency reported in the _tracking.log_ file is more stable and the maximum
+reached offset is smaller.
++
+There are two forms of the directive. The first one has six parameters: a path
+to the file containing the current temperature from the sensor (in text
+format), the compensation update interval (in seconds), and temperature
+coefficients _T0_, _k0_, _k1_, _k2_.
++
+The frequency compensation is calculated (in ppm) as
++
+----
+k0 + (T - T0) * k1 + (T - T0)^2 * k2
+----
++
+The result has to be between -10 ppm and 10 ppm, otherwise the measurement is
+considered invalid and will be ignored. The _k0_ coefficient can be adjusted to
+keep the compensation in that range.
++
+An example of the use is:
++
+----
+tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 26000 0.0 0.000183 0.0
+----
++
+The measured temperature will be read from the file in the Linux sysfs
+filesystem every 30 seconds. When the temperature is 26000 (26 degrees
+Celsius), the frequency correction will be zero. When it is 27000 (27 degrees
+Celsius), the clock will be set to run faster by 0.183 ppm, etc.
++
+The second form has three parameters: the path to the sensor file, the update
+interval, and a path to a file containing a list of (temperature, compensation)
+points, from which the compensation is linearly interpolated or extrapolated.
++
+An example is:
++
+----
+tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 /etc/chrony.tempcomp
+----
++
+where the _/etc/chrony.tempcomp_ file could have
++
+----
+20000 1.0
+21000 0.64
+22000 0.36
+23000 0.16
+24000 0.04
+25000 0.0
+26000 0.04
+27000 0.16
+28000 0.36
+29000 0.64
+30000 1.0
+----
++
+Valid measurements with corresponding compensations are logged to the
+_tempcomp.log_ file if enabled by the <<log,*log tempcomp*>> directive.
+
+=== NTP server
+
+[[allow]]*allow* [*all*] [_subnet_]::
+The *allow* directive is used to designate a particular subnet from which NTP
+clients are allowed to access the computer as an NTP server.
++
+The default is that no clients are allowed access, i.e. *chronyd* operates
+purely as an NTP client. If the *allow* directive is used, *chronyd* will be
+both a client of its servers, and a server to other clients.
++
+Examples of the use of the directive are as follows:
++
+----
+allow 1.2.3.4
+allow 1.2
+allow 3.4.5
+allow 6.7.8/22
+allow 6.7.8.9/22
+allow 2001:db8::/32
+allow 0/0
+allow ::/0
+allow
+----
++
+The first directive allows a node with IPv4 address _1.2.3.4_ to be an NTP
+client of this computer.
+The second directive allows any node with an IPv4 address of the form _1.2.x.y_
+(with _x_ and _y_ arbitrary) to be an NTP client of this computer. Likewise,
+the third directive allows any node with an IPv4 address of the form _3.4.5.x_
+to have client NTP access. The fourth and fifth forms allow access from any
+node with an IPv4 address of the form _6.7.8.x_, _6.7.9.x_, _6.7.10.x_ or
+_6.7.11.x_ (with _x_ arbitrary), i.e. the value 22 is the number of bits
+defining the specified subnet. In the fifth form, the final byte is ignored.
+The sixth form is used for IPv6 addresses. The seventh and eighth forms allow
+access by any IPv4 and IPv6 node respectively. The ninth forms allows access by
+any node (IPv4 or IPv6).
++
+A second form of the directive, *allow all*, has a greater effect, depending on
+the ordering of directives in the configuration file. To illustrate the effect,
+consider the two examples:
++
+----
+allow 1.2.3.4
+deny 1.2.3
+allow 1.2
+----
++
+and
++
+----
+allow 1.2.3.4
+deny 1.2.3
+allow all 1.2
+----
++
+In the first example, the effect is the same regardless of what order the three
+directives are given in. So the _1.2.x.y_ subnet is allowed access, except for
+the _1.2.3.x_ subnet, which is denied access, however the host _1.2.3.4_ is
+allowed access.
++
+In the second example, the *allow all 1.2* directives overrides the effect of
+_any_ previous directive relating to a subnet within the specified subnet.
+Within a configuration file this capability is probably rather moot; however,
+it is of greater use for reconfiguration at run-time via *chronyc* with the
+<<chronyc.adoc#allow,*allow all*>> command.
++
+The directive allows a hostname to be specified instead of an IP address, but
+the name must be resolvable when *chronyd* is started (i.e. *chronyd* needs
+to be started when the network is already up and DNS is working).
++
+Note, if the <<initstepslew,*initstepslew*>> directive is used in the
+configuration file, each of the computers listed in that directive must allow
+client access by this computer for it to work.
+
+[[deny]]*deny* [*all*] [_subnet_]::
+This is similar to the <<allow,*allow*>> directive, except that it denies NTP
+client access to a particular subnet or host, rather than allowing it.
++
+The syntax is identical.
++
+There is also a *deny all* directive with similar behaviour to the *allow all*
+directive.
+
+[[bindaddress]]*bindaddress* _address_::
+The *bindaddress* directive binds the socket on which *chronyd* listens for NTP
+requests to a local address of the computer. On systems other than Linux, the
+address of the computer needs to be already configured when *chronyd* is
+started.
++
+An example of the use of the directive is:
++
+----
+bindaddress 192.168.1.1
+----
++
+Currently, for each of the IPv4 and IPv6 protocols, only one *bindaddress*
+directive can be specified. Therefore, it is not useful on computers which
+should serve NTP on multiple network interfaces.
+
+[[broadcast]]*broadcast* _interval_ _address_ [_port_]::
+The *broadcast* directive is used to declare a broadcast address to which
+chronyd should send packets in the NTP broadcast mode (i.e. make *chronyd* act
+as a broadcast server). Broadcast clients on that subnet will be able to
+synchronise.
++
+The syntax is as follows:
++
+----
+broadcast 30 192.168.1.255
+broadcast 60 192.168.2.255 12123
+broadcast 60 ff02::101
+----
++
+In the first example, the destination port defaults to UDP port 123 (the normal NTP
+port). In the second example, the destination port is specified as 12123. The
+first parameter in each case (30 or 60 respectively) is the interval in seconds
+between broadcast packets being sent. The second parameter in each case is the
+broadcast address to send the packet to. This should correspond to the
+broadcast address of one of the network interfaces on the computer where
+*chronyd* is running.
++
+You can have more than 1 *broadcast* directive if you have more than 1 network
+interface onto which you want to send NTP broadcast packets.
++
+*chronyd* itself cannot act as a broadcast client; it must always be configured
+as a point-to-point client by defining specific NTP servers and peers. This
+broadcast server feature is intended for providing a time source to other NTP
+implementations.
++
+If *ntpd* is used as the broadcast client, it will try to measure the
+round-trip delay between the server and client with normal client mode packets.
+Thus, the broadcast subnet should also be the subject of an <<allow,*allow*>>
+directive.
+
+[[clientloglimit]]*clientloglimit* _limit_::
+This directive specifies the maximum amount of memory that *chronyd* is allowed
+to allocate for logging of client accesses and the state that *chronyd* as an
+NTP server needs to support the interleaved mode for its clients. The default
+limit is 524288 bytes, which is sufficient for monitoring about four thousand
+clients at the same time.
++
+In older *chrony* versions if the limit was set to 0, the memory allocation was
+unlimited.
++
+An example of the use of this directive is:
++
+----
+clientloglimit 1048576
+----
+
+[[noclientlog]]*noclientlog*::
+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 <<chronyc.adoc#clients,*clients*>> command in *chronyc*. This option
+also effectively disables server support for the NTP interleaved mode.
+
+[[local]]*local* [_option_]...::
+The *local* directive enables a local reference mode, which allows *chronyd*
+operating as an NTP server to appear synchronised to real time (from the
+viewpoint of clients polling it), even when it was never synchronised or
+the last update of the clock happened a long time ago.
++
+This directive is normally used in an isolated network, where computers are
+required to be synchronised to one another, but not necessarily to real time.
+The server can be kept vaguely in line with real time by manual input.
++
+The *local* directive has the following options:
++
+*stratum* _stratum_:::
+This option sets the stratum of the server which will be reported to clients
+when the local reference is active. The specified value is in the range 1
+through 15, and the default value is 10. It should be larger than the maximum
+expected stratum in the network when external NTP servers are accessible.
++
+Stratum 1 indicates a computer that has a true real-time reference directly
+connected to it (e.g. GPS, atomic clock, etc.), such computers are expected to
+be very close to real time. Stratum 2 computers are those which have a stratum
+1 server; stratum 3 computers have a stratum 2 server and so on. A value
+of 10 indicates that the clock is so many hops away from a reference clock that
+its time is fairly unreliable.
+*distance* _distance_:::
+This option sets the threshold for the root distance which will activate the local
+reference. If *chronyd* was synchronised to some source, the local reference
+will not be activated until its root distance reaches the specified value (the
+rate at which the distance is increasing depends on how well the clock was
+tracking the source). The default value is 1 second.
++
+The current root distance can be calculated from root delay and root dispersion
+(reported by the <<chronyc.adoc#tracking,*tracking*>> command in *chronyc*) as:
++
+----
+distance = delay / 2 + dispersion
+----
+*orphan*:::
+This option enables a special '`orphan`' mode, where sources with stratum equal
+to the local _stratum_ are assumed to not serve real time. They are ignored
+unless no other source is selectable and their reference IDs are smaller than
+the local reference ID.
++
+This allows multiple servers in the network to use the same *local*
+configuration and to be synchronised to one another, without confusing clients
+that poll more than one server. Each server needs to be configured to poll all
+other servers with the *local* directive. This ensures only the server with the
+smallest reference ID has the local reference active and others are
+synchronised to it. When that server fails, another will take over.
++
+The *orphan* mode is compatible with the *ntpd*'s orphan mode (enabled by the
+*tos orphan* command).
+::
++
+An example of the directive is:
++
+----
+local stratum 10 orphan
+----
+
+[[ntpsigndsocket]]*ntpsigndsocket* _directory_::
+This directive specifies the location of the Samba *ntp_signd* socket when it
+is running as a Domain Controller (DC). If *chronyd* is compiled with this
+feature, responses to MS-SNTP clients will be signed by the *smbd* daemon.
++
+Note that MS-SNTP requests are not authenticated and any client that is allowed
+to access the server by the <<allow,*allow*>> directive, or the
+<<chronyc.adoc#allow,*allow*>> command in *chronyc*, can get an MS-SNTP
+response signed with a trust account's password and try to crack the password
+in a brute-force attack. Access to the server should be carefully controlled.
++
+An example of the directive is:
++
+----
+ntpsigndsocket /var/lib/samba/ntp_signd
+----
+
+[[port]]*port* _port_::
+This option allows you to configure the port on which *chronyd* will listen for
+NTP requests. The port will be open only when an address is allowed by the
+<<allow,*allow*>> directive or the <<chronyc.adoc#allow,*allow*>> command in
+*chronyc*, an NTP peer is configured, or the broadcast server mode is enabled.
++
+The default value is 123, the standard NTP port. If set to 0, *chronyd* will
+never open the server port and will operate strictly in a client-only mode. The
+source port used in NTP client requests can be set by the
+<<acquisitionport,*acquisitionport*>> directive.
+
+[[ratelimit]]*ratelimit* [_option_]...::
+This directive enables response rate limiting for NTP packets. Its purpose is
+to reduce network traffic with misconfigured or broken NTP clients that are
+polling the server too frequently. The limits are applied to individual IP
+addresses. If multiple clients share one IP address (e.g. multiple hosts behind
+NAT), the sum of their traffic will be limited. If a client that increases its
+polling rate when it does not receive a reply is detected, its rate limiting
+will be temporarily suspended to avoid increasing the overall amount of
+traffic. The maximum number of IP addresses which can be monitored at the same
+time depends on the memory limit set by the <<clientloglimit,*clientloglimit*>>
+directive.
++
+The *ratelimit* directive supports a number of options (which can be defined
+in any order):
++
+*interval*:::
+This option sets the minimum interval between responses. It is defined as a
+power of 2 in seconds. The default value is 3 (8 seconds). The minimum value
+is -19 (524288 packets per second) and the maximum value is 12 (one packet per
+4096 seconds). Note that with values below -4 the rate limiting is coarse
+(responses are allowed in bursts, even if the interval between them is shorter
+than the specified interval).
+*burst*:::
+This option sets the maximum number of responses that can be sent in a burst,
+temporarily exceeding the limit specified by the *interval* option. This is
+useful for clients that make rapid measurements on start (e.g. *chronyd* with
+the *iburst* option). The default value is 8. The minimum value is 1 and the
+maximum value is 255.
+*leak*:::
+This option sets the rate at which responses are randomly allowed even if the
+limits specified by the *interval* and *burst* options are exceeded. This is
+necessary to prevent an attacker who is sending requests with a spoofed
+source address from completely blocking responses to that address. The leak
+rate is defined as a power of 1/2 and it is 2 by default, i.e. on average at
+least every fourth request has a response. The minimum value is 1 and the
+maximum value is 4.
+::
++
+An example use of the directive is:
++
+----
+ratelimit interval 1 burst 16
+----
++
+This would reduce the response rate for IP addresses sending packets on average
+more than once per 2 seconds, or sending packets in bursts of more than 16
+packets, by up to 75% (with default *leak* of 2).
+
+[[smoothtime]]*smoothtime* _max-freq_ _max-wander_ [*leaponly*]::
+The *smoothtime* directive can be used to enable smoothing of the time that
+*chronyd* serves to its clients to make it easier for them to track it and keep
+their clocks close together even when large offset or frequency corrections are
+applied to the server's clock, for example after being offline for a longer
+time.
++
+BE WARNED: The server is intentionally not serving its best estimate of the
+true time. If a large offset has been accumulated, it can take a very long time
+to smooth it out. This directive should be used only when the clients are not
+configured to also poll another NTP server, because they could reject this
+server as a falseticker or fail to select a source completely.
++
+The smoothing process is implemented with a quadratic spline function with two
+or three pieces. It is independent from any slewing applied to the local system
+clock, but the accumulated offset and frequency will be reset when the clock is
+corrected by stepping, e.g. by the <<makestep,*makestep*>> directive or the
+<<chronyc.adoc#makestep,*makestep*>> command in *chronyc*. The process can be
+reset without stepping the clock by the <<chronyc.adoc#smoothtime,*smoothtime
+reset*>> command.
++
+The first two arguments of the directive are the maximum frequency offset of
+the smoothed time to the tracked NTP time (in ppm) and the maximum rate at
+which the frequency offset is allowed to change (in ppm per second). *leaponly*
+is an optional third argument which enables a mode where only leap seconds are
+smoothed out and normal offset and frequency changes are ignored. The *leaponly*
+option is useful in a combination with the <<leapsecmode,*leapsecmode slew*>>
+directive to allow the clients to use multiple time smoothing servers safely.
++
+The smoothing process is activated automatically when 1/10000 of the estimated
+skew of the local clock falls below the maximum rate of frequency change. It
+can be also activated manually by the <<chronyc.adoc#smoothtime,*smoothtime
+activate*>> command, which is particularly useful when the clock is
+synchronised only with manual input and the skew is always larger than the
+threshold. The <<chronyc.adoc#smoothing,*smoothing*>> command can be used to
+monitor the process.
++
+An example suitable for clients using *ntpd* and 1024 second polling interval
+could be:
++
+----
+smoothtime 400 0.001
+----
++
+An example suitable for clients using *chronyd* on Linux could be:
++
+----
+smoothtime 50000 0.01
+----
+
+=== Command and monitoring access
+
+[[bindcmdaddress]]*bindcmdaddress* _address_::
+The *bindcmdaddress* directive allows you to specify an IP address of an
+interface on which *chronyd* will listen for monitoring command packets (issued
+by *chronyc*). On systems other than Linux, the address of the interface needs
+to be already configured when *chronyd* is started.
++
+This directive can also change the path of the Unix domain command socket,
+which is used by *chronyc* to send configuration commands. The socket must be
+in a directory that is accessible only by the root or _chrony_ user. The
+directory will be created on start if it does not exist. The compiled-in default
+path of the socket is _@CHRONYRUNDIR@/chronyd.sock_. The socket can be
+disabled by setting the path to _/_.
++
+By default, *chronyd* binds to the loopback interface (with addresses
+_127.0.0.1_ and _::1_). This blocks all access except from localhost. To listen
+for command packets on all interfaces, you can add the lines:
++
+----
+bindcmdaddress 0.0.0.0
+bindcmdaddress ::
+----
++
+to the configuration file.
++
+For each of the IPv4, IPv6, and Unix domain protocols, only one
+*bindcmdaddress* directive can be specified.
++
+An example that sets the path of the Unix domain command socket is:
++
+----
+bindcmdaddress /var/run/chrony/chronyd.sock
+----
+
+[[cmdallow]]*cmdallow* [*all*] [_subnet_]::
+This is similar to the <<allow,*allow*>> directive, except that it allows
+monitoring access (rather than NTP client access) to a particular subnet or
+host. (By '`monitoring access`' is meant that *chronyc* can be run on those
+hosts and retrieve monitoring data from *chronyd* on this computer.)
++
+The syntax is identical to the *allow* directive.
++
+There is also a *cmdallow all* directive with similar behaviour to the *allow
+all* directive (but applying to monitoring access in this case, of course).
++
+Note that *chronyd* has to be configured with the
+<<bindcmdaddress,*bindcmdaddress*>> directive to not listen only on the
+loopback interface to actually allow remote access.
+
+[[cmddeny]]*cmddeny* [*all*] [_subnet_]::
+This is similar to the <<cmdallow,*cmdallow*>> directive, except that it denies
+monitoring access to a particular subnet or host, rather than allowing it.
++
+The syntax is identical.
++
+There is also a *cmddeny all* directive with similar behaviour to the *cmdallow
+all* directive.
+
+[[cmdport]]*cmdport* _port_::
+The *cmdport* directive allows the port that is used for run-time monitoring
+(via the *chronyc* program) to be altered from its default (323). If set to 0,
+*chronyd* will not open the port, this is useful to disable *chronyc*
+access from the Internet. (It does not disable the Unix domain command socket.)
++
+An example shows the syntax:
++
+----
+cmdport 257
+----
++
+This would make *chronyd* use UDP 257 as its command port. (*chronyc* would
+need to be run with the *-p 257* switch to inter-operate correctly.)
+
+[[cmdratelimit]]*cmdratelimit* [_option_]...::
+This directive enables response rate limiting for command packets. It is
+similar to the <<ratelimit,*ratelimit*>> directive, except responses to
+localhost are never limited and the default interval is -4 (16 packets per
+second).
++
+An example of the use of the directive is:
++
+----
+cmdratelimit interval 2
+----
+
+=== Real-time clock (RTC)
+
+[[hwclockfile]]*hwclockfile* _file_::
+The *hwclockfile* directive sets the location of the adjtime file which is
+used by the *hwclock* program on Linux. *chronyd* parses the file to find out
+if the RTC keeps local time or UTC. It overrides the <<rtconutc,*rtconutc*>>
+directive.
++
+The compiled-in default value is '_@DEFAULT_HWCLOCK_FILE@_'.
++
+An example of the directive is:
++
+----
+hwclockfile /etc/adjtime
+----
+
+[[rtcautotrim]]*rtcautotrim* _threshold_::
+The *rtcautotrim* directive is used to keep the RTC close to the system clock
+automatically. When the system clock is synchronised and the estimated error
+between the two clocks is larger than the specified threshold, *chronyd* will
+trim the RTC as if the <<chronyc.adoc#trimrtc,*trimrtc*>> command in *chronyc*
+was issued.
++
+This directive is effective only with the <<rtcfile,*rtcfile*>> directive.
++
+An example of the use of this directive is:
++
+----
+rtcautotrim 30
+----
++
+This would set the threshold error to 30 seconds.
+
+[[rtcdevice]]*rtcdevice* _device_::
+The *rtcdevice* directive sets the path to the device file for accessing the
+RTC. The default path is _@DEFAULT_RTC_DEVICE@_.
+
+[[rtcfile]]*rtcfile* _file_::
+The *rtcfile* directive defines the name of the file in which *chronyd* can
+save parameters associated with tracking the accuracy of the RTC.
++
+An example of the directive is:
++
+----
+rtcfile @CHRONYVARDIR@/rtc
+----
++
+*chronyd* saves information in this file when it exits and when the *writertc*
+command 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.
++
+So far, the support for real-time clocks is limited; their code is even more
+system-specific than the rest of the software. You can only use the RTC
+facilities (the <<rtcfile,*rtcfile*>> directive and the *-s* command-line
+option to *chronyd*) if the following three conditions apply:
++
+. You are running Linux.
+. The kernel is compiled with extended real-time clock support (i.e. the
+  _/dev/rtc_ device is capable of doing useful things).
+. You do not have other applications that need to make use of _/dev/rtc_ at all.
+
+[[rtconutc]]*rtconutc*::
+*chronyd* assumes by default that the RTC keeps local time (including any
+daylight saving changes). This is convenient on PCs running Linux which are
+dual-booted with Windows.
++
+If you keep the RTC on local time and your computer is off when daylight saving
+(summer time) starts or ends, the computer's system time will be one hour in
+error when you next boot and start chronyd.
++
+An alternative is for the RTC to keep Universal Coordinated Time (UTC). This
+does not suffer from the 1 hour problem when daylight saving starts or ends.
++
+If the *rtconutc* directive appears, it means the RTC is required to keep UTC.
+The directive takes no arguments. It is equivalent to specifying the *-u*
+switch to the Linux *hwclock* program.
++
+Note that this setting is overridden when the <<hwclockfile,*hwclockfile*>>
+directive is specified.
+
+[[rtcsync]]*rtcsync*::
+The *rtcsync* directive enables a mode where the system time is periodically
+copied to the RTC and *chronyd* does not try to track its drift. This directive
+cannot be used with the <<rtcfile,*rtcfile*>> directive.
++
+On Linux, the RTC copy is performed by the kernel every 11 minutes.
++
+On macOS, <<chronyd,*chronyd*>> will perform the RTC copy every 60 minutes
+when the system clock is in a synchronised state.
++
+On other systems this directive does nothing.
+
+=== Logging
+
+[[log]]*log* [_option_]...::
+The *log* directive indicates that certain information is to be logged.
+The log files are written to the directory specified by the <<logdir,*logdir*>>
+directive. A banner is periodically written to the files to indicate the
+meanings of the columns.
++
+*rawmeasurements*:::
+This option logs the raw NTP measurements and related information to a file
+called _measurements.log_. An entry is made for each packet received from the
+source. This can be useful when debugging a problem. An example line (which
+actually appears as a single line in the file) from the log file is shown
+below.
++
+----
+2016-11-09 05:40:50 203.0.113.15    N  2 111 111 1111  10 10 1.0 \
+   -4.966e-03  2.296e-01  1.577e-05  1.615e-01  7.446e-03 CB00717B 4B D K
+----
++
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
++
+. Date [2015-10-13]
+. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
+  local time zone. [05:40:50]
+. IP address of server or peer from which measurement came [203.0.113.15]
+. Leap status (_N_ means normal, _+_ means that the last minute of the current
+  month has 61 seconds, _-_ means that the last minute of the month has 59
+  seconds, _?_ means the remote computer is not currently synchronised.) [N]
+. Stratum of remote computer. [2]
+. RFC 5905 tests 1 through 3 (1=pass, 0=fail) [111]
+. RFC 5905 tests 5 through 7 (1=pass, 0=fail) [111]
+. Tests for maximum delay, maximum delay ratio and maximum delay dev ratio,
+  against defined parameters, and a test for synchronisation loop (1=pass,
+  0=fail) [1111]
+. Local poll [10]
+. Remote poll [10]
+. '`Score`' (an internal score within each polling level used to decide when to
+  increase or decrease the polling level. This is adjusted based on number of
+  measurements currently being used for the regression algorithm). [1.0]
+. The estimated local clock error (_theta_ in RFC 5905). Positive indicates
+  that the local clock is slow of the remote source. [-4.966e-03]
+. The peer delay (_delta_ in RFC 5905). [2.296e-01]
+. The peer dispersion (_epsilon_ in RFC 5905). [1.577e-05]
+. The root delay (_DELTA_ in RFC 5905). [1.615e-01]
+. The root dispersion (_EPSILON_ in RFC 5905). [7.446e-03]
+. Reference ID of the server's source as a hexadecimal number. [CB00717B]
+. NTP mode of the received packet (_1_=active peer, _2_=passive peer,
+  _4_=server, _B_=basic, _I_=interleaved). [4B]
+. Source of the local transmit timestamp
+  (_D_=daemon, _K_=kernel, _H_=hardware). [D]
+. Source of the local receive timestamp
+  (_D_=daemon, _K_=kernel, _H_=hardware). [K]
++
+*measurements*:::
+This option is identical to the *rawmeasurements* option, except it logs only
+valid measurements from synchronised sources, i.e. measurements which passed
+the RFC 5905 tests 1 through 7. This can be useful for producing graphs of the
+source's performance.
++
+*statistics*:::
+This option logs information about the regression processing to a file called
+_statistics.log_. An example line (which actually appears as a single line in
+the file) from the log file is shown below.
++
+----
+2016-08-10 05:40:50 203.0.113.15     6.261e-03 -3.247e-03 \
+     2.220e-03  1.874e-06  1.080e-06 7.8e-02  16   0   8  0.00
+----
++
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
++
+. Date [2015-07-22]
+. Hour:Minute:Second. Note that the date-time pair is expressed in
+  UTC, not the local time zone. [05:40:50]
+. IP address of server or peer from which measurement comes [203.0.113.15]
+. The estimated standard deviation of the measurements from the source (in
+  seconds). [6.261e-03]
+. The estimated offset of the source (in seconds, positive means the local
+  clock is estimated to be fast, in this case). [-3.247e-03]
+. The estimated standard deviation of the offset estimate (in seconds).
+  [2.220e-03]
+. The estimated rate at which the local clock is gaining or losing time
+  relative to the source (in seconds per second, positive means the local clock
+  is gaining). This is relative to the compensation currently being applied to
+  the local clock, _not_ to the local clock without any compensation.
+  [1.874e-06]
+. The estimated error in the rate value (in seconds per second). [1.080e-06].
+. The ratio of |old_rate - new_rate| / old_rate_error. Large values
+  indicate the statistics are not modelling the source very well. [7.8e-02]
+. The number of measurements currently being used for the regression
+  algorithm. [16]
+. The new starting index (the oldest sample has index 0; this is the method
+  used to prune old samples when it no longer looks like the measurements fit a
+  linear model). [0, i.e. no samples discarded this time]
+. The number of runs. The number of runs of regression residuals with the same
+  sign is computed. If this is too small it indicates that the measurements are
+  no longer represented well by a linear model and that some older samples need
+  to be discarded. The number of runs for the data that is being retained is
+  tabulated. Values of approximately half the number of samples are expected.
+  [8]
+. The estimated or configured asymmetry of network jitter on the path to the
+  source which was used to correct the measured offsets. The asymmetry can be
+  between -0.5 and +0.5. A negative value means the delay of packets sent to
+  the source is more variable than the delay of packets sent from the source
+  back. [0.00, i.e. no correction for asymmetry]
++
+*tracking*:::
+This option logs changes to the estimate of the system's gain or loss rate, and
+any slews made, to a file called _tracking.log_. An example line (which
+actually appears as a single line in the file) from the log file is shown
+below.
++
+----
+2017-08-22 13:22:36 203.0.113.15     2     -3.541      0.075 -8.621e-06 N \
+            2  2.940e-03 -2.084e-04  1.534e-02  3.472e-04  8.304e-03
+----
++
+The columns are as follows (the quantities in square brackets are the
+values from the example line above) :
++
+. Date [2017-08-22]
+. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
+  local time zone. [13:22:36]
+. The IP address of the server or peer to which the local system is synchronised.
+  [203.0.113.15]
+. The stratum of the local system. [2]
+. The local system frequency (in ppm, positive means the local system runs fast
+  of UTC). [-3.541]
+. The error bounds on the frequency (in ppm). [0.075]
+. The estimated local offset at the epoch, which is normally corrected by
+  slewing the local clock (in seconds, positive indicates the clock is fast of
+  UTC). [-8.621e-06]
+. Leap status (_N_ means normal, _+_ means that the last minute of this month
+  has 61 seconds, _-_ means that the last minute of the month has 59 seconds,
+  _?_ means the clock is not currently synchronised.) [N]
+. The number of combined sources. [2]
+. The estimated standard deviation of the combined offset (in seconds).
+  [2.940e-03]
+. The remaining offset correction from the previous update (in seconds,
+  positive means the system clock is slow of UTC). [-2.084e-04]
+. The total of the network path delays to the reference clock to which
+  the local clock is ultimately synchronised (in seconds). [1.534e-02]
+. The total dispersion accumulated through all the servers back to the
+  reference clock to which the local clock is ultimately synchronised
+  (in seconds). [3.472e-04]
+. The maximum estimated error of the system clock in the interval since the
+  previous update (in seconds). It includes the offset, remaining offset
+  correction, root delay, and dispersion from the previous update with the
+  dispersion which accumulated in the interval. [8.304e-03]
++
+*rtc*:::
+This option logs information about the system's real-time clock. An example
+line (which actually appears as a single line in the file) from the _rtc.log_
+file is shown below.
++
+----
+2015-07-22 05:40:50     -0.037360 1       -0.037434\
+          -37.948  12   5  120
+----
++
+The columns are as follows (the quantities in square brackets are the
+values from the example line above):
++
+. Date [2015-07-22]
+. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
+  local time zone. [05:40:50]
+. The measured offset between the RTC and the system clock in seconds.
+  Positive indicates that the RTC is fast of the system time [-0.037360].
+. Flag indicating whether the regression has produced valid coefficients.
+  (1 for yes, 0 for no). [1]
+. Offset at the current time predicted by the regression process. A large
+  difference between this value and the measured offset tends to indicate that
+  the measurement is an outlier with a serious measurement error. [-0.037434]
+. The rate at which the RTC is losing or gaining time relative to the system
+  clock. In ppm, with positive indicating that the RTC is gaining time.
+  [-37.948]
+. The number of measurements used in the regression. [12]
+. The number of runs of regression residuals of the same sign. Low values
+  indicate that a straight line is no longer a good model of the measured data
+  and that older measurements should be discarded. [5]
+. The measurement interval used prior to the measurement being made (in
+  seconds). [120]
++
+*refclocks*:::
+This option logs the raw and filtered reference clock measurements to a file
+called _refclocks.log_. An example line (which actually appears as a single
+line in the file) from the log file is shown below.
++
+----
+2009-11-30 14:33:27.000000 PPS2    7 N 1  4.900000e-07 -6.741777e-07  1.000e-06
+----
++
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
++
+. Date [2009-11-30]
+. Hour:Minute:Second.Microsecond. Note that the date-time pair is expressed in
+  UTC, not the local time zone. [14:33:27.000000]
+. Reference ID of the reference clock from which the measurement came. [PPS2]
+. Sequence number of driver poll within one polling interval for raw samples,
+  or _-_ for filtered samples. [7]
+. Leap status (_N_ means normal, _+_ means that the last minute of the current
+  month has 61 seconds, _-_ means that the last minute of the month has 59
+  seconds). [N]
+. Flag indicating whether the sample comes from PPS source. (1 for yes,
+  0 for no, or _-_ for filtered sample). [1]
+. Local clock error measured by reference clock driver, or _-_ for filtered sample.
+  [4.900000e-07]
+. Local clock error with applied corrections. Positive indicates that the local
+  clock is slow. [-6.741777e-07]
+. Assumed dispersion of the sample. [1.000e-06]
++
+*tempcomp*:::
+This option logs the temperature measurements and system rate compensations to
+a file called _tempcomp.log_. An example line (which actually appears as a
+single line in the file) from the log file is shown below.
++
+----
+2015-04-19 10:39:48  2.8000e+04  3.6600e-01
+----
++
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
++
+. Date [2015-04-19]
+. Hour:Minute:Second. Note that the date-time pair is expressed in UTC, not the
+  local time zone. [10:39:48]
+. Temperature read from the sensor. [2.8000e+04]
+. Applied compensation in ppm, positive means the system clock is running
+  faster than it would be without the compensation. [3.6600e-01]
++
+::
+An example of the directive is:
++
+----
+log measurements statistics tracking
+----
+
+[[logbanner]]*logbanner* _entries_::
+A banner is periodically written to the log files enabled by the <<log,*log*>>
+directive to indicate the meanings of the columns.
++
+The *logbanner* directive specifies after how many entries in the log file
+should be the banner written. The default is 32, and 0 can be used to disable
+it entirely.
+
+[[logchange]]*logchange* _threshold_::
+This directive sets the threshold for the adjustment of the system clock that
+will generate a syslog message. Clock errors detected via NTP packets,
+reference clocks, or timestamps entered via the
+<<chronyc.adoc#settime,*settime*>> command of *chronyc* are logged.
++
+By default, the threshold is 1 second.
++
+An example of the use is:
++
+----
+logchange 0.1
+----
++
+which would cause a syslog message to be generated if a system clock error of over
+0.1 seconds starts to be compensated.
+
+[[logdir]]*logdir* _directory_::
+This directive allows the directory where log files are written to be
+specified.
++
+An example of the use of this directive is:
++
+----
+logdir /var/log/chrony
+----
+
+[[mailonchange]]*mailonchange* _email_ _threshold_::
+This directive defines an email address to which mail should be sent if
+*chronyd* applies a correction exceeding a particular threshold to the system
+clock.
++
+An example of the use of this directive is:
++
+----
+mailonchange root@localhost 0.5
+----
++
+This would send a mail message to root if a change of more than 0.5 seconds
+were applied to the system clock.
++
+This directive cannot be used when a system call filter is enabled by the *-F*
+option as the *chronyd* process will not be allowed to fork and execute the
+sendmail binary.
+
+=== Miscellaneous
+
+[[hwtimestamp]]*hwtimestamp* _interface_ [_option_]...::
+This directive enables hardware timestamping of NTP packets sent to and
+received from the specified network interface. The network interface controller
+(NIC) uses its own clock to accurately timestamp the actual transmissions and
+receptions, avoiding processing and queueing delays in the kernel, network
+driver, and hardware. This can significantly improve the accuracy of the
+timestamps and the measured offset, which is used for synchronisation of the
+system clock. In order to get the best results, both sides receiving and
+sending NTP packets (i.e. server and client, or two peers) need to use HW
+timestamping. If the server or peer supports the interleaved mode, it needs to
+be enabled by the *xleave* option in the <<server,*server*>> or the
+<<peer,*peer*>> directive.
++
+This directive is supported on Linux 3.19 and newer. The NIC must support HW
+timestamping, which can be verified with the *ethtool -T* command. The list of
+capabilities should include _SOF_TIMESTAMPING_RAW_HARDWARE_,
+_SOF_TIMESTAMPING_TX_HARDWARE_, and _SOF_TIMESTAMPING_RX_HARDWARE_. Receive
+filter _HWTSTAMP_FILTER_ALL_, or _HWTSTAMP_FILTER_NTP_ALL_, is necessary for
+timestamping of received packets. Timestamping of packets received from bridged
+and bonded interfaces is supported on Linux 4.13 and newer. When *chronyd* is
+running, no other process (e.g. a PTP daemon) should be working with the NIC
+clock.
++
+If the kernel supports software timestamping, it will be enabled for all
+interfaces. The source of timestamps (i.e. hardware, kernel, or daemon) is
+indicated in the _measurements.log_ file if enabled by the <<log,*log
+measurements*>> directive, and the <<chronyc.adoc#ntpdata,*ntpdata*>> report in
+*chronyc*.
++
+If the specified interface is _*_, *chronyd* will try to enable HW timestamping
+on all available interfaces.
++
+The *hwtimestamp* directive has the following options:
++
+*minpoll* _poll_:::
+This option specifies the minimum interval between readings of the NIC clock.
+It's defined as a power of two. It should correspond to the minimum polling
+interval of all NTP sources and the minimum expected polling interval of NTP
+clients. The default value is 0 (1 second) and the minimum value is -6 (1/64th
+of a second).
+*minsamples* _samples_:::
+This option specifies the minimum number of readings kept for tracking of the
+NIC clock. The default value is 2.
+*maxsamples* _samples_:::
+This option specifies the maximum number of readings kept for tracking of the
+NIC clock. The default value is 16.
+*precision* _precision_:::
+This option specifies the assumed precision of reading of the NIC clock. The
+default value is 100e-9 (100 nanoseconds).
+*txcomp* _compensation_:::
+This option specifies the difference in seconds between the actual transmission
+time at the physical layer and the reported transmit timestamp. This value will
+be added to transmit timestamps obtained from the NIC. The default value is 0.
+*rxcomp* _compensation_:::
+This option specifies the difference in seconds between the reported receive
+timestamp and the actual reception time at the physical layer. This value will
+be subtracted from receive timestamps obtained from the NIC. The default value
+is 0.
+*nocrossts*:::
+Some hardware can precisely cross timestamp the NIC clock with the system
+clock. This option disables the use of the cross timestamping.
+*rxfilter* _filter_:::
+This option selects the receive timestamping filter. The _filter_ can be one of
+the following:
+_all_::::
+Enables timestamping of all received packets.
+_ntp_::::
+Enables timestamping of received NTP packets.
+_none_::::
+Disables timestamping of received packets.
+:::
+The most specific filter for timestamping NTP packets which is supported by the
+NIC is selected by default. Some NICs can timestamp only PTP packets, which
+limits the selection to the _none_ filter. Forcing timestamping of all packets
+with the _all_ filter when the NIC supports both _all_ and _ntp_ filters can be
+useful when packets are received from or on a non-standard UDP port (e.g.
+specified by the *port* directive).
+::
++
+Examples of the directive are:
++
+----
+hwtimestamp eth0
+hwtimestamp eth1 txcomp 300e-9 rxcomp 645e-9
+hwtimestamp *
+----
+
+[[include]]*include* _pattern_::
+The *include* directive includes a configuration file or multiple configuration
+files if a wildcard pattern is specified. This can be useful when maintaining
+configuration on multiple hosts to keep the differences in separate files.
++
+An example of the directive is:
++
+----
+include @SYSCONFDIR@/chrony.d/*.conf
+----
+
+[[keyfile]]*keyfile* _file_::
+This directive is used to specify the location of the file containing ID-key
+pairs for authentication of NTP packets.
++
+The format of the directive is shown in the example below:
++
+----
+keyfile @SYSCONFDIR@/chrony.keys
+----
++
+The argument is simply the name of the file containing the ID-key pairs. The
+format of the file is shown below:
++
+----
+10 tulip
+11 hyacinth
+20 MD5 ASCII:crocus
+25 SHA1 HEX:1dc764e0791b11fa67efc7ecbc4b0d73f68a070c
+ ...
+----
++
+Each line consists of an ID, name of an authentication hash function (optional),
+and a password. The ID can be any unsigned integer in the range 1 through
+2^32-1. The default hash function is *MD5*, which is always supported.
++
+If *chronyd* was built with enabled support for hashing using a crypto library
+(nettle, nss, or libtomcrypt), the following functions are available: *MD5*,
+*SHA1*, *SHA256*, *SHA384*, *SHA512*. Depending on which library and version is
+*chronyd* using, some or all of the following functions may also be available:
+*SHA3-224*, *SHA3-256*, *SHA3-384*, *SHA3-512*, *RMD128*, *RMD160*, *RMD256*,
+*RMD320*, *TIGER*, *WHIRLPOOL*.
++
+The password can be specified as a string of characters not containing white
+space with an optional *ASCII:* prefix, or as a hexadecimal number with the
+*HEX:* prefix. The maximum length of the line is 2047 characters.
++
+The password is used with the hash function to generate and verify a message
+authentication code (MAC) in NTP packets. It is recommended to use SHA1, or
+stronger, hash function with random passwords specified in the hexadecimal
+format that have at least 128 bits. *chronyd* will log a warning to
+syslog on start if a source is specified in the configuration file with a key
+that has password shorter than 80 bits.
++
+The <<chronyc.adoc#keygen,*keygen*>> command of *chronyc* can be used to
+generate random keys for the key file. By default, it generates 160-bit MD5 or
+SHA1 keys.
++
+For security reasons, the file should be readable only by root and the user
+under which *chronyd* is normally running (to allow *chronyd* to re-read the
+file when the <<chronyc.adoc#rekey,*rekey*>> command is issued by *chronyc*).
+
+[[lock_all]]*lock_all*::
+The *lock_all* directive will lock chronyd into RAM so that it will never be
+paged out. This mode is only supported on Linux. This directive uses the Linux
+*mlockall()* system call to prevent *chronyd* from ever being swapped out. This
+should result in lower and more consistent latency. It should not have
+significant impact on performance as *chronyd's* memory usage is modest. The
+*mlockall(2)* man page has more details.
+
+[[pidfile]]*pidfile* _file_::
+Unless *chronyd* is started with the *-Q* option, it writes its process ID
+(PID) to a file, and checks this file on startup to see if another *chronyd*
+might already be running on the system. By default, the file used is
+_@DEFAULT_PID_FILE@_. The *pidfile* directive allows the name to be changed,
+e.g.:
++
+----
+pidfile /run/chronyd.pid
+----
+
+[[sched_priority]]*sched_priority* _priority_::
+On Linux, the *sched_priority* directive will select the SCHED_FIFO real-time
+scheduler at the specified priority (which must be between 0 and 100). On
+macOS, this option must have either a value of 0 (the default) to disable the
+thread time constraint policy or 1 for the policy to be enabled. Other systems
+do not support this option.
++
+On Linux, this directive uses the *sched_setscheduler()* system call to
+instruct the kernel to use the SCHED_FIFO first-in, first-out real-time
+scheduling policy for *chronyd* with the specified priority. This means that
+whenever *chronyd* is ready to run it will run, interrupting whatever else is
+running unless it is a higher priority real-time process. This should not
+impact performance as *chronyd* resource requirements are modest, but it should
+result in lower and more consistent latency since *chronyd* will not need to
+wait for the scheduler to get around to running it. You should not use this
+unless you really need it. The *sched_setscheduler(2)* man page has more
+details.
++
+On macOS, this directive uses the *thread_policy_set()* kernel call to
+specify real-time scheduling. As noted for Linux, you should not use this
+directive unless you really need it.
+
+[[user]]*user* _user_::
+The *user* directive sets the name of the system user to which *chronyd* will
+switch after start in order to drop root privileges.
++
+On Linux, *chronyd* needs to be compiled with support for the *libcap* library.
+On macOS, FreeBSD, NetBSD and Solaris *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.
++
+The compiled-in default value is _@DEFAULT_USER@_.
+
+[[examples]]
+== EXAMPLES
+
+=== NTP client with permanent connection to NTP servers
+
+This section shows how to configure *chronyd* for computers that are connected
+to the Internet (or to any network containing true NTP servers which ultimately
+derive their time from a reference clock) permanently or most of the time.
+
+To operate in this mode, you will need to know the names of the NTP servers
+you want to use. You might be able to find names of suitable servers by one of
+the following methods:
+
+* Your institution might already operate servers on its network.
+  Contact your system administrator to find out.
+* Your ISP probably has one or more NTP servers available for its
+  customers.
+* Somewhere under the NTP homepage there is a list of public
+  stratum 1 and stratum 2 servers. You should find one or more servers that are
+  near to you. Check that their access policy allows you to use their
+  facilities.
+* Use public servers from the http://www.pool.ntp.org/[pool.ntp.org] project.
+
+Assuming that your NTP servers are called _foo.example.net_, _bar.example.net_
+and _baz.example.net_, your _chrony.conf_ file could contain as a minimum:
+
+----
+server foo.example.net
+server bar.example.net
+server baz.example.net
+----
+
+However, you will probably want to include some of the other directives. The
+<<driftfile,*driftfile*>>, <<makestep,*makestep*>> and <<rtcsync,*rtcsync*>>
+might be particularly useful. Also, the *iburst* option of the
+<<server,*server*>> directive is useful to speed up the initial
+synchronisation. The smallest useful configuration file would look something
+like:
+
+----
+server foo.example.net iburst
+server bar.example.net iburst
+server baz.example.net iburst
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+----
+
+When using a pool of NTP servers (one name is used for multiple servers which
+might change over time), it is better to specify them with the <<pool,*pool*>>
+directive instead of multiple *server* directives. The configuration file could
+in this case look like:
+
+----
+pool pool.ntp.org iburst
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+----
+
+=== NTP client with infrequent connection to NTP servers
+
+This section shows how to configure *chronyd* for computers that have
+occasional connections to NTP servers. In this case, you will need some
+additional configuration to tell *chronyd* when the connection goes up and
+down. This saves the program from continuously trying to poll the servers when
+they are inaccessible.
+
+Again, assuming that your NTP servers are called _foo.example.net_,
+_bar.example.net_ and _baz.example.net_, your _chrony.conf_ file would now
+contain:
+
+----
+server foo.example.net offline
+server bar.example.net offline
+server baz.example.net offline
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+----
+
+The *offline* keyword indicates that the servers start in an offline state, and
+that they should not be contacted until *chronyd* receives notification from
+*chronyc* that the link to the Internet is present. To tell *chronyd* when to
+start and finish sampling the servers, the <<chronyc.adoc#online,*online*>> and
+<<chronyc.adoc#offline,*offline*>> commands of *chronyc* need to be used.
+
+To give an example of their use, assuming that *pppd* is the program being
+used to connect to the Internet and that *chronyc* has been installed at
+_@BINDIR@/chronyc_, the script _/etc/ppp/ip-up_ would include:
+
+----
+@BINDIR@/chronyc online
+----
+
+and the script _/etc/ppp/ip-down_ would include:
+
+----
+@BINDIR@/chronyc offline
+----
+
+*chronyd*'s polling of the servers would now only occur whilst the machine is
+actually connected to the Internet.
+
+=== Isolated networks
+
+This section shows how to configure *chronyd* for computers that never have
+network conectivity to any computer which ultimately derives its time from a
+reference clock.
+
+In this situation, one computer is selected to be the master timeserver. The
+other computers are either direct clients of the master, or clients of clients.
+
+The <<local,*local*>> directive enables a local reference mode, which allows
+*chronyd* to appear synchronised even when it is not.
+
+The rate value in the master's drift file needs to be set to the average rate
+at which the master gains or loses time. *chronyd* includes support for this,
+in the form of the <<manual,*manual*>> directive and the
+<<chronyc.adoc#settime,*settime*>> command in the *chronyc* program.
+
+If the master is rebooted, *chronyd* can re-read the drift rate from the drift
+file. However, the master has no accurate estimate of the current time. To get
+around this, the system can be configured so that the master can initially set
+itself to a '`majority-vote`' of selected clients' times; this allows the
+clients to '`flywheel`' the master while it is rebooting.
+
+The <<smoothtime,*smoothtime*>> directive is useful when the clocks of the
+clients need to stay close together when the local time is adjusted by the
+<<chronyc.adoc#settime,*settime*>> command. The smoothing process needs to be
+activated by the <<chronyc.adoc#smoothtime,*smoothtime activate*>> command when
+the local time is ready to be served. After that point, any adjustments will be
+smoothed out.
+
+A typical configuration file for the master (called _master_) might be
+(assuming the clients and the master are in the _192.168.165.x_ subnet):
+
+----
+initstepslew 1 client1 client3 client6
+driftfile @CHRONYVARDIR@/drift
+local stratum 8
+manual
+allow 192.168.165.0/24
+smoothtime 400 0.01
+rtcsync
+----
+
+For the clients that have to resynchronise the master when it restarts,
+the configuration file might be:
+
+----
+server master iburst
+driftfile @CHRONYVARDIR@/drift
+allow 192.168.165.0/24
+makestep 1.0 3
+rtcsync
+----
+
+The rest of the clients would be the same, except that the *allow* directive is
+not required.
+
+If there is no suitable computer to be designated as the master, or there is a
+requirement to keep the clients synchronised even when it fails, the *orphan*
+option of the *local* directive enables a special mode where the master is
+selected from multiple computers automatically. They all need to use the same
+*local* configuration and poll one another. The server with the smallest
+reference ID (which is based on its IP address) will take the role of the
+master and others will be synchronised to it. When it fails, the server with
+the second smallest reference ID will take over and so on.
+
+A configuration file for the first server might be (assuming there are three
+servers called _master1_, _master2_, and _master3_):
+
+----
+initstepslew 1 master2 master3
+server master2
+server master3
+driftfile @CHRONYVARDIR@/drift
+local stratum 8 orphan
+manual
+allow 192.168.165.0/24
+rtcsync
+----
+
+The other servers would be the same, except the hostnames in the *initstepslew*
+and *server* directives would be modified to specify the other servers. Their
+clients might be configured to poll all three servers.
+
+=== RTC tracking
+
+This section considers a computer which has occasional connections to the
+Internet and is turned off between '`sessions`'. In this case, *chronyd* relies
+on the computer's RTC to maintain the time between the periods when it is
+powered up. It assumes that Linux is run exclusively on the computer. Dual-boot
+systems might work; it depends what (if anything) the other system does to the
+RTC. On 2.6 and later kernels, if your motherboard has a HPET, you will need to
+enable the *HPET_EMULATE_RTC* option in your kernel configuration. Otherwise,
+*chronyd* will not be able to interact with the RTC device and will give up
+using it.
+
+When the computer is connected to the Internet, *chronyd* has access to
+external NTP servers which it makes measurements from. These measurements are
+saved, and straight-line fits are performed on them to provide an estimate of
+the computer's time error and rate of gaining or losing time.
+
+When the computer is taken offline from the Internet, the best estimate of the
+gain or loss rate is used to free-run the computer until it next goes online.
+
+Whilst the computer is running, *chronyd* makes measurements of the RTC (via
+the _/dev/rtc_ interface, which must be compiled into the kernel). An estimate
+is made of the RTC error at a particular RTC second, and the rate at which the
+RTC gains or loses time relative to true time.
+
+When the computer is powered down, the measurement histories for all the NTP
+servers are saved to files, and the RTC tracking information is also
+saved to a file (if the <<rtcfile,*rtcfile*>> directive has been specified).
+These pieces of information are also saved if the <<chronyc.adoc#dump,*dump*>>
+and <<chronyc.adoc#writertc,*writertc*>> commands respectively are issued
+through *chronyc*.
+
+When the computer is rebooted, *chronyd* reads the current RTC time and the RTC
+information saved at the last shutdown. This information is used to set the
+system clock to the best estimate of what its time would have been now, had it
+been left running continuously. The measurement histories for the servers are
+then reloaded.
+
+The next time the computer goes online, the previous sessions' measurements can
+contribute to the line-fitting process, which gives a much better estimate of
+the computer's gain or loss rate.
+
+One problem with saving the measurements and RTC data when the machine is shut
+down is what happens if there is a power failure; the most recent data will not
+be saved. Although *chronyd* is robust enough to cope with this, some
+performance might be lost. (The main danger arises if the RTC has been changed
+during the session, with the *trimrtc* command in *chronyc*. Because of this,
+*trimrtc* will make sure that a meaningful RTC file is saved after the
+change is completed).
+
+The easiest protection against power failure is to put the *dump* and
+*writertc* commands in the same place as the *offline* command is issued to
+take *chronyd* offline; because *chronyd* free-runs between online sessions, no
+parameters will change significantly between going offline from the Internet
+and any power failure.
+
+A final point regards computers which are left running for extended periods and
+where it is desired to spin down the hard disc when it is not in use (e.g. when
+not accessed for 15 minutes). *chronyd* has been planned so it supports such
+operation; this is the reason why the RTC tracking parameters are not saved to
+disc after every update, but only when the user requests such a write, or
+during the shutdown sequence. The only other facility that will generate
+periodic writes to the disc is the *log rtc* facility in the configuration
+file; this option should not be used if you want your disc to spin down.
+
+To illustrate how a computer might be configured for this case, example
+configuration files are shown.
+
+For the _chrony.conf_ file, the following can be used as an example.
+
+----
+server foo.example.net maxdelay 0.4 offline
+server bar.example.net maxdelay 0.4 offline
+server baz.example.net maxdelay 0.4 offline
+logdir /var/log/chrony
+log statistics measurements tracking
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+maxupdateskew 100.0
+dumpdir @CHRONYVARDIR@
+rtcfile @CHRONYVARDIR@/rtc
+----
+
+*pppd* is used for connecting to the Internet. This runs two scripts
+_/etc/ppp/ip-up_ and _/etc/ppp/ip-down_ when the link goes online and offline
+respectively.
+
+The relevant part of the _/etc/ppp/ip-up_ file is:
+
+----
+@BINDIR@/chronyc online
+----
+
+and the relevant part of the _/etc/ppp/ip-down_ script is:
+
+----
+@BINDIR@/chronyc -m offline dump writertc
+----
+
+*chronyd* is started during the boot sequence with the *-r* and *-s* options.
+It might need to be started before any software that depends on the system clock
+not jumping or moving backwards, depending on the directives in *chronyd*'s
+configuration file.
+
+For the system shutdown, *chronyd* should receive a SIGTERM several seconds
+before the final SIGKILL; the SIGTERM causes the measurement histories and RTC
+information to be saved.
+
+=== Public NTP server
+
+*chronyd* can be configured to operate as a public NTP server, e.g. to join the
+http://www.pool.ntp.org/en/join.html[pool.ntp.org] project. The configuration
+is similar to the NTP client with permanent connection, except it needs to
+allow client access from all addresses. It is recommended to find at least four
+good servers (e.g. from the pool, or on the NTP homepage). If the server has a
+hardware reference clock (e.g. a GPS receiver), it can be specified by the
+<<refclock,*refclock*>> directive.
+
+The amount of memory used for logging client accesses can be increased in order
+to enable clients to use the interleaved mode even when the server has a large
+number of clients, and better support rate limiting if it is enabled by the
+<<ratelimit,*ratelimit*>> directive. The system timezone database, if it is
+kept up to date and includes the _right/UTC_ timezone, can be used as a
+reliable source to determine when a leap second will be applied to UTC. The
+*-r* option with the <<dumpdir,*dumpdir*>> directive shortens the time in which
+*chronyd* will not be able to serve time to its clients when it needs to be
+restarted (e.g. after upgrading to a newer version, or a change in the
+configuration).
+
+The configuration file could look like:
+
+----
+server foo.example.net iburst
+server bar.example.net iburst
+server baz.example.net iburst
+server qux.example.net iburst
+makestep 1.0 3
+rtcsync
+allow
+clientloglimit 100000000
+leapsectz right/UTC
+driftfile @CHRONYVARDIR@/drift
+dumpdir @CHRONYRUNDIR@
+----
+
+== SEE ALSO
+
+<<chronyc.adoc#,*chronyc(1)*>>, <<chronyd.adoc#,*chronyd(8)*>>
+
+== BUGS
+
+For instructions on how to report bugs, please visit
+https://chrony.tuxfamily.org/.
+
+== AUTHORS
+
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
diff --git a/doc/chrony.conf.man.in b/doc/chrony.conf.man.in
new file mode 100644
index 0000000..d50e825
--- /dev/null
+++ b/doc/chrony.conf.man.in
@@ -0,0 +1,3981 @@
+'\" t
+.\"     Title: chrony.conf
+.\"    Author: [see the "AUTHORS" section]
+.\" Generator: Asciidoctor 1.5.6.1
+.\"      Date: 2018-09-19
+.\"    Manual: Configuration Files
+.\"    Source: chrony @CHRONY_VERSION@
+.\"  Language: English
+.\"
+.TH "CHRONY.CONF" "5" "2018-09-19" "chrony @CHRONY_VERSION@" "Configuration Files"
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.ss \n[.ss] 0
+.nh
+.ad l
+.de URL
+\\$2 \(laURL: \\$1 \(ra\\$3
+..
+.if \n[.g] .mso www.tmac
+.LINKSTYLE blue R < >
+.SH "NAME"
+chrony.conf \- chronyd configuration file
+.SH "SYNOPSIS"
+.sp
+\fBchrony.conf\fP
+.SH "DESCRIPTION"
+.sp
+This file configures the \fBchronyd\fP daemon. The compiled\-in location is
+\fI@SYSCONFDIR@/chrony.conf\fP, but other locations can be specified on the
+\fBchronyd\fP command line with the \fB\-f\fP option.
+.sp
+Each directive in the configuration file is placed on a separate line. The
+following sections describe each of the directives in turn. The directives can
+occur in any order in the file and they are not case\-sensitive.
+.sp
+The configuration directives can also be specified directly on the \fBchronyd\fP
+command line. In this case each argument is parsed as a new line and the
+configuration file is ignored.
+.sp
+While the number of supported directives is large, only a few of them are
+typically needed. See the \fBEXAMPLES\fP section for configuration in
+typical operating scenarios.
+.sp
+The configuration file might contain comment lines. A comment line is any line
+that starts with zero or more spaces followed by any one of the following
+characters: \fB!\fP, \fB;\fP, \fB#\fP, \fB%\fP. Any line with this format will be ignored.
+.SH "DIRECTIVES"
+.SS "Time sources"
+.sp
+\fBserver\fP \fIhostname\fP [\fIoption\fP]...
+.RS 4
+The \fBserver\fP directive specifies an NTP server which can be used as a time
+source. The client\-server relationship is strictly hierarchical: a client might
+synchronise its system time to that of the server, but the server\(cqs system time
+will never be influenced by that of a client.
+.sp
+The \fBserver\fP directive is immediately followed by either the name of the
+server, or its IP address. The \fBserver\fP directive supports the following
+options:
+.sp
+\fBminpoll\fP \fIpoll\fP
+.RS 4
+This option specifies the minimum interval between requests sent to the server
+as a power of 2 in seconds. For example, \fBminpoll 5\fP would mean that the
+polling interval should not drop below 32 seconds. The default is 6 (64
+seconds), the minimum is \-6 (1/64th of a second), and the maximum is 24 (6
+months). Note that intervals shorter than 6 (64 seconds) should generally not
+be used with public servers on the Internet, because it might be considered
+abuse. A sub\-second interval will be enabled only when the server is reachable
+and the round\-trip delay is shorter than 10 milliseconds, i.e. the server
+should be in a local network.
+.RE
+.sp
+\fBmaxpoll\fP \fIpoll\fP
+.RS 4
+This option specifies the maximum interval between requests sent to the server
+as a power of 2 in seconds. For example, \fBmaxpoll 9\fP indicates that the polling
+interval should stay at or below 9 (512 seconds). The default is 10 (1024
+seconds), the minimum is \-6 (1/64th of a second), and the maximum is 24 (6
+months).
+.RE
+.sp
+\fBiburst\fP
+.RS 4
+With this option, the interval between the first four requests sent to the
+server will be 2 seconds or less instead of the interval specified by the
+\fBminpoll\fP option, which allows \fBchronyd\fP to make the first update of the clock
+shortly after start.
+.RE
+.sp
+\fBburst\fP
+.RS 4
+With this option, \fBchronyd\fP will shorten the interval between up to four
+requests to 2 seconds or less when it cannot get a good measurement from the
+server. The number of requests in the burst is limited by the current polling
+interval to keep the average interval at or above the minimum interval, i.e.
+the current interval needs to be at least two times longer than the minimum
+interval in order to allow a burst with two requests.
+.RE
+.sp
+\fBkey\fP \fIID\fP
+.RS 4
+The NTP protocol supports a message authentication code (MAC) to prevent
+computers having their system time upset by rogue packets being sent to them.
+The MAC is generated as a function of a password specified in the key file,
+which is specified by the \fBkeyfile\fP directive.
+.sp
+The \fBkey\fP option specifies which key (with an ID in the range 1 through 2^32\-1)
+should \fBchronyd\fP use to authenticate requests sent to the server and verify its
+responses. The server must have the same key for this number configured,
+otherwise no relationship between the computers will be possible.
+.sp
+If the server is running \fBntpd\fP and the output size of the hash function used
+by the key is longer than 160 bits (e.g. SHA256), the \fBversion\fP option needs to
+be set to 4 for compatibility.
+.RE
+.sp
+\fBmaxdelay\fP \fIdelay\fP
+.RS 4
+\fBchronyd\fP uses the network round\-trip delay to the server to determine how
+accurate a particular measurement is likely to be. Long round\-trip delays
+indicate that the request, or the response, or both were delayed. If only one
+of the messages was delayed the measurement error is likely to be substantial.
+.sp
+For small variations in the round\-trip delay, \fBchronyd\fP uses a weighting scheme
+when processing the measurements. However, beyond a certain level of delay the
+measurements are likely to be so corrupted as to be useless. (This is
+particularly so on dial\-up or other slow links, where a long delay probably
+indicates a highly asymmetric delay caused by the response waiting behind a lot
+of packets related to a download of some sort).
+.sp
+If the user knows that round trip delays above a certain level should cause the
+measurement to be ignored, this level can be defined with the \fBmaxdelay\fP
+option. For example, \fBmaxdelay 0.3\fP would indicate that measurements with a
+round\-trip delay of 0.3 seconds or more should be ignored. The default value is
+3 seconds and the maximum value is 1000 seconds.
+.RE
+.sp
+\fBmaxdelayratio\fP \fIratio\fP
+.RS 4
+This option is similar to the \fBmaxdelay\fP option above. \fBchronyd\fP keeps a record
+of the minimum round\-trip delay amongst the previous measurements that it has
+buffered. If a measurement has a round trip delay that is greater than the
+maxdelayratio times the minimum delay, it will be rejected.
+.RE
+.sp
+\fBmaxdelaydevratio\fP \fIratio\fP
+.RS 4
+If a measurement has a ratio of the increase in the round\-trip delay from the
+minimum delay amongst the previous measurements to the standard deviation of
+the previous measurements that is greater than the specified ratio, it will be
+rejected. The default is 10.0.
+.RE
+.sp
+\fBmindelay\fP \fIdelay\fP
+.RS 4
+This option specifies a fixed minimum round\-trip delay to be used instead of
+the minimum amongst the previous measurements. This can be useful in networks
+with static configuration to improve the stability of corrections for
+asymmetric jitter, weighting of the measurements, and the \fBmaxdelayratio\fP and
+\fBmaxdelaydevratio\fP tests. The value should be set accurately in order to have a
+positive effect on the synchronisation.
+.RE
+.sp
+\fBasymmetry\fP \fIratio\fP
+.RS 4
+This option specifies the asymmetry of the network jitter on the path to the
+source, which is used to correct the measured offset according to the delay.
+The asymmetry can be between \-0.5 and +0.5. A negative value means the delay of
+packets sent to the source is more variable than the delay of packets sent from
+the source back. By default, \fBchronyd\fP estimates the asymmetry automatically.
+.RE
+.sp
+\fBoffset\fP \fIoffset\fP
+.RS 4
+This option specifies a correction (in seconds) which will be applied to
+offsets measured with this source. It\(cqs particularly useful to compensate for a
+known asymmetry in network delay or timestamping errors. For example, if
+packets sent to the source were on average delayed by 100 microseconds more
+than packets sent from the source back, the correction would be \-0.00005 (\-50
+microseconds). The default is 0.0.
+.RE
+.sp
+\fBminsamples\fP \fIsamples\fP
+.RS 4
+Set the minimum number of samples kept for this source. This overrides the
+\fBminsamples\fP directive.
+.RE
+.sp
+\fBmaxsamples\fP \fIsamples\fP
+.RS 4
+Set the maximum number of samples kept for this source. This overrides the
+\fBmaxsamples\fP directive.
+.RE
+.sp
+\fBfilter\fP \fIsamples\fP
+.RS 4
+This option enables a median filter to reduce noise in NTP measurements. The
+filter will reduce the specified number of samples to a single sample. It is
+intended to be used with very short polling intervals in local networks where
+it is acceptable to generate a lot of NTP traffic.
+.RE
+.sp
+\fBoffline\fP
+.RS 4
+If the server will not be reachable when \fBchronyd\fP is started, the \fBoffline\fP
+option can be specified. \fBchronyd\fP will not try to poll the server until it is
+enabled to do so (by using the \fBonline\fP command in
+\fBchronyc\fP).
+.RE
+.sp
+\fBauto_offline\fP
+.RS 4
+With this option, the server will be assumed to have gone offline when sending
+a request fails, e.g. due to a missing route to the network. This option avoids
+the need to run the \fBoffline\fP command from \fBchronyc\fP
+when disconnecting the network link. (It will still be necessary to use the
+\fBonline\fP command when the link has been established, to
+enable measurements to start.)
+.RE
+.sp
+\fBprefer\fP
+.RS 4
+Prefer this source over sources without the \fBprefer\fP option.
+.RE
+.sp
+\fBnoselect\fP
+.RS 4
+Never select this source. This is particularly useful for monitoring.
+.RE
+.sp
+\fBtrust\fP
+.RS 4
+Assume time from this source is always true. It can be rejected as a
+falseticker in the source selection only if another source with this option
+does not agree with it.
+.RE
+.sp
+\fBrequire\fP
+.RS 4
+Require that at least one of the sources specified with this option is
+selectable (i.e. recently reachable and not a falseticker) before updating the
+clock. Together with the \fBtrust\fP option this might be useful to allow a trusted
+authenticated source to be safely combined with unauthenticated sources in
+order to improve the accuracy of the clock. They can be selected and used for
+synchronisation only if they agree with the trusted and required source.
+.RE
+.sp
+\fBxleave\fP
+.RS 4
+This option enables an interleaved mode which allows the server or the peer to
+send transmit timestamps captured after the actual transmission (e.g. when the
+server or the peer is running \fBchronyd\fP with software (kernel) or hardware
+timestamping). This can significantly improve the accuracy of the measurements.
+.sp
+The interleaved mode is compatible with servers that support only the basic
+mode, but peers must both support and have enabled the interleaved mode,
+otherwise the synchronisation will work only in one direction. Note that even
+servers that support the interleaved mode might respond in the basic mode as
+the interleaved mode requires the servers to keep some state for each client
+and the state might be dropped when there are too many clients (e.g.
+\fBclientloglimit\fP is too small), or it might be overwritten
+by other clients that have the same IP address (e.g. computers behind NAT or
+someone sending requests with a spoofed source address).
+.sp
+The \fBxleave\fP option can be combined with the \fBpresend\fP option in order to
+shorten the interval in which the server has to keep the state to be able to
+respond in the interleaved mode.
+.RE
+.sp
+\fBpolltarget\fP \fItarget\fP
+.RS 4
+Target number of measurements to use for the regression algorithm which
+\fBchronyd\fP will try to maintain by adjusting the polling interval between
+\fBminpoll\fP and \fBmaxpoll\fP. A higher target makes \fBchronyd\fP prefer shorter polling
+intervals. The default is 8 and a useful range is from 6 to 60.
+.RE
+.sp
+\fBport\fP \fIport\fP
+.RS 4
+This option allows the UDP port on which the server understands NTP requests to
+be specified. For normal servers this option should not be required (the
+default is 123, the standard NTP port).
+.RE
+.sp
+\fBpresend\fP \fIpoll\fP
+.RS 4
+If the timing measurements being made by \fBchronyd\fP are the only network data
+passing between two computers, you might find that some measurements are badly
+skewed due to either the client or the server having to do an ARP lookup on the
+other party prior to transmitting a packet. This is more of a problem with long
+sampling intervals, which might be similar in duration to the lifetime of entries
+in the ARP caches of the machines.
+.sp
+In order to avoid this problem, the \fBpresend\fP option can be used. It takes a
+single integer argument, which is the smallest polling interval for which an
+extra pair of NTP packets will be exchanged between the client and the server
+prior to the actual measurement. For example, with the following option
+included in a \fBserver\fP directive:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+presend 9
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+when the polling interval is 512 seconds or more, an extra NTP client packet
+will be sent to the server a short time (2 seconds) before making the actual
+measurement.
+.sp
+The \fBpresend\fP option cannot be used in the \fBpeer\fP directive. If it is used
+with the \fBxleave\fP option, \fBchronyd\fP will send two extra packets instead of one.
+.RE
+.sp
+\fBminstratum\fP \fIstratum\fP
+.RS 4
+When the synchronisation source is selected from available sources, sources
+with lower stratum are normally slightly preferred. This option can be used to
+increase stratum of the source to the specified minimum, so \fBchronyd\fP will
+avoid selecting that source. This is useful with low stratum sources that are
+known to be unreliable or inaccurate and which should be used only when other
+sources are unreachable.
+.RE
+.sp
+\fBversion\fP \fIversion\fP
+.RS 4
+This option sets the NTP version of packets sent to the server. This can be
+useful when the server runs an old NTP implementation that does not respond to
+requests using a newer version. The default version depends on whether a key is
+specified by the \fBkey\fP option and which authentication hash function the key
+is using. If the output size of the hash function is longer than 160 bits, the
+default version is 3 for compatibility with older \fBchronyd\fP servers. Otherwise,
+the default version is 4.
+.RE
+.RE
+.sp
+\fBpool\fP \fIname\fP [\fIoption\fP]...
+.RS 4
+The syntax of this directive is similar to that for the \fBserver\fP
+directive, except that it is used to specify a pool of NTP servers rather than
+a single NTP server. The pool name is expected to resolve to multiple addresses
+which might change over time.
+.sp
+All options valid in the \fBserver\fP directive can be used in this
+directive too. There is one option specific to the \fBpool\fP directive:
+\fBmaxsources\fP sets the maximum number of sources that can be used from the pool,
+the default value is 4.
+.sp
+On start, when the pool name is resolved, \fBchronyd\fP will add up to 16 sources,
+one for each resolved address. When the number of sources from which at least
+one valid reply was received reaches the number specified by the \fBmaxsources\fP
+option, the other sources will be removed. When a pool source is unreachable,
+marked as a falseticker, or has a distance larger than the limit set by the
+\fBmaxdistance\fP directive, \fBchronyd\fP will try to replace the
+source with a newly resolved address from the pool.
+.sp
+An example of the \fBpool\fP directive is
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+pool pool.ntp.org iburst maxsources 3
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBpeer\fP \fIhostname\fP [\fIoption\fP]...
+.RS 4
+The syntax of this directive is identical to that for the \fBserver\fP
+directive, except that it specifies a symmetric association with an NTP peer
+instead of a client/server association with an NTP server. A single symmetric
+association allows the peers to be both servers and clients to each other. This
+is mainly useful when the NTP implementation of the peer (e.g. \fBntpd\fP) supports
+ephemeral symmetric associations and does not need to be configured with an
+address of this host. \fBchronyd\fP does not support ephemeral associations.
+.sp
+When a key is specified by the \fBkey\fP option to enable authentication, both
+peers must use the same key and the same key number.
+.sp
+Note that the symmetric mode is less secure than the client/server mode. A
+denial\-of\-service attack is possible on unauthenticated symmetric associations,
+i.e. when the peer was specified without the \fBkey\fP option. An attacker who does
+not see network traffic between two hosts, but knows that they are peering with
+each other, can periodically send them unauthenticated packets with spoofed
+source addresses in order to disrupt their NTP state and prevent them from
+synchronising to each other. When the association is authenticated, an attacker
+who does see the network traffic, but cannot prevent the packets from reaching
+the other host, can still disrupt the state by replaying old packets. The
+attacker has effectively the same power as a man\-in\-the\-middle attacker. A
+partial protection against this attack is implemented in \fBchronyd\fP, which can
+protect the peers if they are using the same polling interval and they never
+sent an authenticated packet with a timestamp from future, but it should not be
+relied on as it is difficult to ensure the conditions are met. If two hosts
+should be able to synchronise to each other in both directions, it is
+recommended to use two separate client/server associations (specified by the
+\fBserver\fP directive on both hosts) instead.
+.RE
+.sp
+\fBinitstepslew\fP \fIstep\-threshold\fP [\fIhostname\fP]...
+.RS 4
+In normal operation, \fBchronyd\fP slews the time when it needs to adjust the
+system clock. For example, to correct a system clock which is 1 second slow,
+\fBchronyd\fP slightly increases the amount by which the system clock is advanced
+on each clock interrupt, until the error is removed. Note that at no time does
+time run backwards with this method.
+.sp
+On most Unix systems it is not desirable to step the system clock, because many
+programs rely on time advancing monotonically forwards.
+.sp
+When the \fBchronyd\fP daemon is initially started, it is possible that the system
+clock is considerably in error. Attempting to correct such an error by slewing
+might not be sensible, since it might take several hours to correct the error by
+this means.
+.sp
+The purpose of the \fBinitstepslew\fP directive is to allow \fBchronyd\fP to make a
+rapid measurement of the system clock error at boot time, and to correct the
+system clock by stepping before normal operation begins. Since this would
+normally be performed only at an appropriate point in the system boot sequence,
+no other software should be adversely affected by the step.
+.sp
+If the correction required is less than a specified threshold, a slew is used
+instead. This makes it safer to restart \fBchronyd\fP whilst the system is in
+normal operation.
+.sp
+The \fBinitstepslew\fP directive takes a threshold and a list of NTP servers as
+arguments. Each of the servers is rapidly polled several times, and a majority
+voting mechanism used to find the most likely range of system clock error that
+is present. A step or slew is applied to the system clock to correct this
+error. \fBchronyd\fP then enters its normal operating mode.
+.sp
+An example of the use of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+initstepslew 30 foo.example.net bar.example.net
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+where 2 NTP servers are used to make the measurement. The \fI30\fP indicates that
+if the system\(cqs error is found to be 30 seconds or less, a slew will be used to
+correct it; if the error is above 30 seconds, a step will be used.
+.sp
+The \fBinitstepslew\fP directive can also be used in an isolated LAN environment,
+where the clocks are set manually. The most stable computer is chosen as the
+master, and the other computers are slaved to it. If each of the slaves is
+configured with the \fBlocal\fP directive, the master can be set up with
+an \fBinitstepslew\fP directive which references some or all of the slaves. Then,
+if the master machine has to be rebooted, the slaves can be relied on to act
+analogously to a flywheel and preserve the time for a short period while the
+master completes its reboot.
+.sp
+The \fBinitstepslew\fP directive is functionally similar to a combination of the
+\fBmakestep\fP and \fBserver\fP directives with the \fBiburst\fP
+option. The main difference is that the \fBinitstepslew\fP servers are used only
+before normal operation begins and that the foreground \fBchronyd\fP process waits
+for \fBinitstepslew\fP to finish before exiting. This is useful to prevent programs
+started in the boot sequence after \fBchronyd\fP from reading the clock before it
+has been stepped.
+.RE
+.sp
+\fBrefclock\fP \fIdriver\fP \fIparameter\fP[:\fIoption\fP,...] [\fIoption\fP]...
+.RS 4
+The \fBrefclock\fP directive specifies a hardware reference clock to be used as a
+time source. It has two mandatory parameters, a driver name and a
+driver\-specific parameter. The two parameters are followed by zero or more
+refclock options. Some drivers have special options, which can be appended to
+the driver\-specific parameter (separated by the \fB:\fP and \fB,\fP characters).
+.sp
+There are four drivers included in \fBchronyd\fP:
+.sp
+\fBPPS\fP
+.RS 4
+Driver for the kernel PPS (pulse per second) API. The parameter is the path to
+the PPS device (typically \fI/dev/pps?\fP). As PPS refclocks do not supply full
+time, another time source (e.g. NTP server or non\-PPS refclock) is needed to
+complete samples from the PPS refclock. An alternative is to enable the
+\fBlocal\fP directive to allow synchronisation with some unknown but
+constant offset. The driver supports the following option:
+.sp
+\fBclear\fP
+.RS 4
+By default, the PPS refclock uses assert events (rising edge) for
+synchronisation. With this option, it will use clear events (falling edge)
+instead.
+.RE
+.RE
+.sp
+
+.RS 4
+Examples:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+refclock PPS /dev/pps0 lock NMEA refid GPS
+refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect
+refclock PPS /dev/pps1:clear refid GPS2
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBSHM\fP
+.RS 4
+NTP shared memory driver. This driver uses a shared memory segment to receive
+samples from another process (e.g. \fBgpsd\fP). The parameter is the number of the
+shared memory segment, typically a small number like 0, 1, 2, or 3. The driver
+supports the following option:
+.sp
+\fBperm\fP=\fImode\fP
+.RS 4
+This option specifies the permissions of the shared memory segment created by
+\fBchronyd\fP. They are specified as a numeric mode. The default value is 0600
+(read\-write access for owner only).
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+Examples:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+refclock SHM 0 poll 3 refid GPS1
+refclock SHM 1:perm=0644 refid GPS2
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBSOCK\fP
+.RS 4
+Unix domain socket driver. It is similar to the SHM driver, but samples are
+received from a Unix domain socket instead of shared memory and the messages
+have a different format. The parameter is the path to the socket, which
+\fBchronyd\fP creates on start. An advantage over the SHM driver is that SOCK does
+not require polling and it can receive PPS samples with incomplete time. The
+format of the messages is described in the \fIrefclock_sock.c\fP file in the chrony
+source code.
+.sp
+An application which supports the SOCK protocol is the \fBgpsd\fP daemon. The path
+where \fBgpsd\fP expects the socket to be created is described in the \fBgpsd(8)\fP man
+page. For example:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+refclock SOCK /var/run/chrony.ttyS0.sock
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBPHC\fP
+.RS 4
+PTP hardware clock (PHC) driver. The parameter is the path to the device of
+the PTP clock which should be used as a time source. If the clock is kept in
+TAI instead of UTC (e.g. it is synchronised by a PTP daemon), the current
+UTC\-TAI offset needs to be specified by the \fBoffset\fP option. Alternatively, the
+\fBpps\fP refclock option can be enabled to treat the PHC as a PPS refclock, using
+only the sub\-second offset for synchronisation. The driver supports the
+following options:
+.sp
+\fBnocrossts\fP
+.RS 4
+This option disables use of precise cross timestamping.
+.RE
+.sp
+\fBextpps\fP
+.RS 4
+This option enables a PPS mode in which the PTP clock is timestamping pulses
+of an external PPS signal connected to the clock. The clock does not need to be
+synchronised, but another time source is needed to complete the PPS samples.
+Note that some PTP clocks cannot be configured to timestamp only assert or
+clear events, and it is necessary to use the \fBwidth\fP option to filter wrong
+PPS samples.
+.RE
+.sp
+\fBpin\fP=\fIindex\fP
+.RS 4
+This option specifies the index of the pin to which is connected the PPS
+signal. The default value is 0.
+.RE
+.sp
+\fBchannel\fP=\fIindex\fP
+.RS 4
+This option specifies the index of the channel for the PPS mode. The default
+value is 0.
+.RE
+.sp
+\fBclear\fP
+.RS 4
+This option enables timestamping of clear events (falling edge) instead of
+assert events (rising edge) in the PPS mode. This may not work with some
+clocks.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+Examples:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+refclock PHC /dev/ptp0 poll 0 dpoll \-2 offset \-37
+refclock PHC /dev/ptp1:nocrossts poll 3 pps
+refclock PHC /dev/ptp2:extpps,pin=1 width 0.2 poll 2
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.RE
+.sp
+
+.RS 4
+The \fBrefclock\fP directive supports the following options:
+.sp
+\fBpoll\fP \fIpoll\fP
+.RS 4
+Timestamps produced by refclock drivers are not used immediately, but they are
+stored and processed by a median filter in the polling interval specified by
+this option. This is defined as a power of 2 and can be negative to specify a
+sub\-second interval. The default is 4 (16 seconds). A shorter interval allows
+\fBchronyd\fP to react faster to changes in the frequency of the system clock, but
+it might have a negative effect on its accuracy if the samples have a lot of
+jitter.
+.RE
+.sp
+\fBdpoll\fP \fIdpoll\fP
+.RS 4
+Some drivers do not listen for external events and try to produce samples in
+their own polling interval. This is defined as a power of 2 and can be negative
+to specify a sub\-second interval. The default is 0 (1 second).
+.RE
+.sp
+\fBrefid\fP \fIrefid\fP
+.RS 4
+This option is used to specify the reference ID of the refclock, as up to four
+ASCII characters. The default reference ID is composed from the first three
+characters of the driver name and the number of the refclock. Each refclock
+must have a unique reference ID.
+.RE
+.sp
+\fBlock\fP \fIrefid\fP
+.RS 4
+This option can be used to lock a PPS refclock to another refclock, which is
+specified by its reference ID. In this mode received PPS samples are paired
+directly with raw samples from the specified refclock.
+.RE
+.sp
+\fBrate\fP \fIrate\fP
+.RS 4
+This option sets the rate of the pulses in the PPS signal (in Hz). This option
+controls how the pulses will be completed with real time. To actually receive
+more than one pulse per second, a negative \fBdpoll\fP has to be specified (\-3 for
+a 5Hz signal). The default is 1.
+.RE
+.sp
+\fBmaxlockage\fP \fIpulses\fP
+.RS 4
+This option specifies in number of pulses how old can be samples from the
+refclock specified by the \fBlock\fP option to be paired with the pulses.
+Increasing this value is useful when the samples are produced at a lower rate
+than the pulses. The default is 2.
+.RE
+.sp
+\fBwidth\fP \fIwidth\fP
+.RS 4
+This option specifies the width of the pulses (in seconds). It is used to
+filter PPS samples when the driver provides samples for both rising and falling
+edges. Note that it reduces the maximum allowed error of the time source which
+completes the PPS samples. If the duty cycle is configurable, 50% should be
+preferred in order to maximise the allowed error.
+.RE
+.sp
+\fBpps\fP
+.RS 4
+This options forces \fBchronyd\fP to treat any refclock (e.g. SHM or PHC) as a PPS
+refclock. This can be useful when the refclock provides time with a variable
+offset of a whole number of seconds (e.g. it uses TAI instead of UTC). Another
+time source is needed to complete samples from the refclock.
+.RE
+.sp
+\fBoffset\fP \fIoffset\fP
+.RS 4
+This option can be used to compensate for a constant error. The specified
+offset (in seconds) is applied to all samples produced by the reference clock.
+The default is 0.0.
+.RE
+.sp
+\fBdelay\fP \fIdelay\fP
+.RS 4
+This option sets the NTP delay of the source (in seconds). Half of this value
+is included in the maximum assumed error which is used in the source selection
+algorithm. Increasing the delay is useful to avoid having no majority in the
+source selection or to make it prefer other sources. The default is 1e\-9 (1
+nanosecond).
+.RE
+.sp
+\fBstratum\fP \fIstratum\fP
+.RS 4
+This option sets the NTP stratum of the refclock. This can be useful when the
+refclock provides time with a stratum other than 0. The default is 0.
+.RE
+.sp
+\fBprecision\fP \fIprecision\fP
+.RS 4
+This option sets the precision of the reference clock (in seconds). The default
+value is the estimated precision of the system clock.
+.RE
+.sp
+\fBmaxdispersion\fP \fIdispersion\fP
+.RS 4
+Maximum allowed dispersion for filtered samples (in seconds). Samples with
+larger estimated dispersion are ignored. By default, this limit is disabled.
+.RE
+.sp
+\fBfilter\fP \fIsamples\fP
+.RS 4
+This option sets the length of the median filter which is used to reduce the
+noise in the measurements. With each poll about 40 percent of the stored
+samples are discarded and one final sample is calculated as an average of the
+remaining samples. If the length is 4 or more, at least 4 samples have to be
+collected between polls. For lengths below 4, the filter has to be full. The
+default is 64.
+.RE
+.sp
+\fBprefer\fP
+.RS 4
+Prefer this source over sources without the prefer option.
+.RE
+.sp
+\fBnoselect\fP
+.RS 4
+Never select this source. This is useful for monitoring or with sources which
+are not very accurate, but are locked with a PPS refclock.
+.RE
+.sp
+\fBtrust\fP
+.RS 4
+Assume time from this source is always true. It can be rejected as a
+falseticker in the source selection only if another source with this option
+does not agree with it.
+.RE
+.sp
+\fBrequire\fP
+.RS 4
+Require that at least one of the sources specified with this option is
+selectable (i.e. recently reachable and not a falseticker) before updating the
+clock. Together with the \fBtrust\fP option this can be useful to allow a trusted,
+but not very precise, reference clock to be safely combined with
+unauthenticated NTP sources in order to improve the accuracy of the clock. They
+can be selected and used for synchronisation only if they agree with the
+trusted and required source.
+.RE
+.sp
+\fBtai\fP
+.RS 4
+This option indicates that the reference clock keeps time in TAI instead of UTC
+and that \fBchronyd\fP should correct its offset by the current TAI\-UTC offset. The
+\fBleapsectz\fP directive must be used with this option and the
+database must be kept up to date in order for this correction to work as
+expected. This option does not make sense with PPS refclocks.
+.RE
+.sp
+\fBminsamples\fP \fIsamples\fP
+.RS 4
+Set the minimum number of samples kept for this source. This overrides the
+\fBminsamples\fP directive.
+.RE
+.sp
+\fBmaxsamples\fP \fIsamples\fP
+.RS 4
+Set the maximum number of samples kept for this source. This overrides the
+\fBmaxsamples\fP directive.
+.RE
+.RE
+.sp
+\fBmanual\fP
+.RS 4
+The \fBmanual\fP directive enables support at run\-time for the
+\fBsettime\fP command in \fBchronyc\fP. If no \fBmanual\fP
+directive is included, any attempt to use the \fBsettime\fP command in \fBchronyc\fP
+will be met with an error message.
+.sp
+Note that the \fBsettime\fP command can be enabled at run\-time using
+the \fBmanual\fP command in \fBchronyc\fP. (The idea of the two
+commands is that the \fBmanual\fP command controls the manual clock driver\(cqs
+behaviour, whereas the \fBsettime\fP command allows samples of manually entered
+time to be provided.)
+.RE
+.sp
+\fBacquisitionport\fP \fIport\fP
+.RS 4
+By default, \fBchronyd\fP uses a separate client socket for each configured server
+and their source port is chosen arbitrarily by the operating system. However,
+you can use the \fBacquisitionport\fP directive to explicitly specify a port and
+use only one socket (per IPv4 or IPv6 address family) for all configured servers.
+This can be useful for getting through some firewalls. If set to 0, the source
+port of the socket will be chosen arbitrarily.
+.sp
+It can be set to the same port as is used by the NTP server (which can be
+configured with the \fBport\fP directive) to use only one socket for all
+NTP packets.
+.sp
+An example of the \fBacquisitionport\fP directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+acquisitionport 1123
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This would change the source port used for client requests to UDP port 1123.
+You could then persuade the firewall administrator to open that port.
+.RE
+.sp
+\fBbindacqaddress\fP \fIaddress\fP
+.RS 4
+The \fBbindacqaddress\fP directive sets the network interface to which
+\fBchronyd\fP will bind its NTP client sockets. The syntax is similar to the
+\fBbindaddress\fP and \fBbindcmdaddress\fP
+directives.
+.sp
+For each of the IPv4 and IPv6 protocols, only one \fBbindacqaddress\fP directive
+can be specified.
+.RE
+.sp
+\fBdumpdir\fP \fIdirectory\fP
+.RS 4
+To compute the rate of gain or loss of time, \fBchronyd\fP has to store a
+measurement history for each of the time sources it uses.
+.sp
+All supported systems, with the exception of macOS 10.12 and earlier, have
+operating system support for setting the rate of gain or loss to compensate for
+known errors.
+(On macOS 10.12 and earlier, \fBchronyd\fP must simulate such a capability by
+periodically slewing the system clock forwards or backwards by a suitable amount
+to compensate for the error built up since the previous slew.)
+.sp
+For such systems, it is possible to save the measurement history across
+restarts of \fBchronyd\fP (assuming no changes are made to the system clock
+behaviour whilst it is not running). The \fBdumpdir\fP directive defines the
+directory where the measurement histories are saved when \fBchronyd\fP exits,
+or the \fBdump\fP command in \fBchronyc\fP is issued.
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+dumpdir @CHRONYRUNDIR@
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+A source whose IP address is \fI1.2.3.4\fP would have its measurement history saved
+in the file \fI@CHRONYRUNDIR@/1.2.3.4.dat\fP. History of reference clocks is saved
+to files named by their reference ID in form of \fIrefid:XXXXXXXX.dat\fP.
+.RE
+.sp
+\fBmaxsamples\fP \fIsamples\fP
+.RS 4
+The \fBmaxsamples\fP directive sets the default maximum number of samples that
+\fBchronyd\fP should keep for each source. This setting can be overridden for
+individual sources in the \fBserver\fP and \fBrefclock\fP
+directives. The default value is 0, which disables the configurable limit. The
+useful range is 4 to 64.
+.RE
+.sp
+\fBminsamples\fP \fIsamples\fP
+.RS 4
+The \fBminsamples\fP directive sets the default minimum number of samples that
+\fBchronyd\fP should keep for each source. This setting can be overridden for
+individual sources in the \fBserver\fP and \fBrefclock\fP
+directives. The default value is 6. The useful range is 4 to 64.
+.sp
+Forcing \fBchronyd\fP to keep more samples than it would normally keep reduces
+noise in the estimated frequency and offset, but slows down the response to
+changes in the frequency and offset of the clock. The offsets in the
+\fBtracking\fP and
+\fBsourcestats\fP reports (and the \fItracking.log\fP and
+\fIstatistics.log\fP files) may be smaller than the actual offsets.
+.RE
+.SS "Source selection"
+.sp
+\fBcombinelimit\fP \fIlimit\fP
+.RS 4
+When \fBchronyd\fP has multiple sources available for synchronisation, it has to
+select one source as the synchronisation source. The measured offsets and
+frequencies of the system clock relative to the other sources, however, can be
+combined with the selected source to improve the accuracy of the system clock.
+.sp
+The \fBcombinelimit\fP directive limits which sources are included in the combining
+algorithm. Their synchronisation distance has to be shorter than the distance
+of the selected source multiplied by the value of the limit. Also, their
+measured frequencies have to be close to the frequency of the selected source.
+.sp
+By default, the limit is 3. Setting the limit to 0 effectively disables the
+source combining algorithm and only the selected source will be used to control
+the system clock.
+.RE
+.sp
+\fBmaxdistance\fP \fIdistance\fP
+.RS 4
+The \fBmaxdistance\fP directive sets the maximum allowed root distance of the
+sources to not be rejected by the source selection algorithm. The distance
+includes the accumulated dispersion, which might be large when the source is no
+longer synchronised, and half of the total round\-trip delay to the primary
+source.
+.sp
+By default, the maximum root distance is 3 seconds.
+.sp
+Setting \fBmaxdistance\fP to a larger value can be useful to allow synchronisation
+with a server that only has a very infrequent connection to its sources and can
+accumulate a large dispersion between updates of its clock.
+.RE
+.sp
+\fBmaxjitter\fP \fIjitter\fP
+.RS 4
+The \fBmaxjitter\fP directive sets the maximum allowed jitter of the sources to not
+be rejected by the source selection algorithm. This prevents synchronisation
+with sources that have a small root distance, but their time is too variable.
+.sp
+By default, the maximum jitter is 1 second.
+.RE
+.sp
+\fBminsources\fP \fIsources\fP
+.RS 4
+The \fBminsources\fP directive 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 default value is 1.
+.sp
+Setting this option to a larger number can be used to improve the reliability.
+More sources will have to agree with each other and the clock will not be
+updated when only one source (which could be serving incorrect time) is
+reachable.
+.RE
+.sp
+\fBreselectdist\fP \fIdistance\fP
+.RS 4
+When \fBchronyd\fP selects a synchronisation source from available sources, it
+will prefer the one with the shortest synchronisation 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 \fBreselectdist\fP directive. By default, the
+distance is 100 microseconds.
+.RE
+.sp
+\fBstratumweight\fP \fIdistance\fP
+.RS 4
+The \fBstratumweight\fP directive sets how much distance should be added per
+stratum to the synchronisation distance when \fBchronyd\fP selects the
+synchronisation source from available sources.
+.sp
+By default, the weight is 0.001 seconds. This means that the stratum of the sources
+in the selection process matters only when the differences between the
+distances are in milliseconds.
+.RE
+.SS "System clock"
+.sp
+\fBcorrtimeratio\fP \fIratio\fP
+.RS 4
+When \fBchronyd\fP is slewing the system clock to correct an offset, the rate at
+which it is slewing adds to the frequency error of the clock. On all supported
+systems, with the exception of macOS 12 and earlier, this rate can be
+controlled.
+.sp
+The \fBcorrtimeratio\fP directive sets the ratio between the duration in which the
+clock is slewed for an average correction according to the source history and
+the interval in which the corrections are done (usually the NTP polling
+interval). Corrections larger than the average take less time and smaller
+corrections take more time, the amount of the correction and the correction
+time are inversely proportional.
+.sp
+Increasing \fBcorrtimeratio\fP improves the overall frequency error of the system
+clock, but increases the overall time error as the corrections take longer.
+.sp
+By default, the ratio is set to 3, the time accuracy of the clock is preferred
+over its frequency accuracy.
+.sp
+The maximum allowed slew rate can be set by the \fBmaxslewrate\fP
+directive. The current remaining correction is shown in the
+\fBtracking\fP report as the \fBSystem time\fP value.
+.RE
+.sp
+\fBdriftfile\fP \fIfile\fP
+.RS 4
+One of the main activities of the \fBchronyd\fP program is to work out the rate at
+which the system clock gains or loses time relative to real time.
+.sp
+Whenever \fBchronyd\fP computes a new value of the gain or loss rate, it is desirable
+to record it somewhere. This allows \fBchronyd\fP to begin compensating the system
+clock at that rate whenever it is restarted, even before it has had a chance to
+obtain an equally good estimate of the rate during the new run. (This process
+can take many minutes, at least.)
+.sp
+The \fBdriftfile\fP directive allows a file to be specified into which \fBchronyd\fP
+can store the rate information. Two parameters are recorded in the file. The
+first is the rate at which the system clock gains or loses time, expressed in
+parts per million, with gains positive. Therefore, a value of 100.0 indicates
+that when the system clock has advanced by a second, it has gained 100
+microseconds in reality (so the true time has only advanced by 999900
+microseconds). The second is an estimate of the error bound around the first
+value in which the true rate actually lies.
+.sp
+An example of the driftfile directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+driftfile @CHRONYVARDIR@/drift
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBfallbackdrift\fP \fImin\-interval\fP \fImax\-interval\fP
+.RS 4
+Fallback drifts are long\-term averages of the system clock drift calculated
+over exponentially increasing intervals. They are used to avoid quickly
+drifting away from true time when the clock was not updated for a longer period
+of time and there was a short\-term deviation in the drift before the updates
+stopped.
+.sp
+The directive specifies the minimum and maximum interval since the last clock
+update to switch between fallback drifts. They are defined as a power of 2 (in
+seconds). The syntax is as follows:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+fallbackdrift 16 19
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+In this example, the minimum interval is 16 (18 hours) and the maximum interval is
+19 (6 days). The system clock frequency will be set to the first fallback 18
+hours after last clock update, to the second after 36 hours, and so on. This
+might be a good setting to cover frequency changes due to daily and weekly
+temperature fluctuations. When the frequency is set to a fallback, the state of
+the clock will change to \(oqNot synchronised\(cq.
+.sp
+By default (or if the specified maximum or minimum is 0), no fallbacks are used
+and the clock frequency changes only with new measurements from NTP sources,
+reference clocks, or manual input.
+.RE
+.sp
+\fBleapsecmode\fP \fImode\fP
+.RS 4
+A leap second is an adjustment that is occasionally applied to UTC to keep it
+close to the mean solar time. When a leap second is inserted, the last day of
+June or December has an extra second 23:59:60.
+.sp
+For computer clocks that is a problem. The Unix time is defined as number of
+seconds since 00:00:00 UTC on 1 January 1970 without leap seconds. The system
+clock cannot have time 23:59:60, every minute has 60 seconds and every day has
+86400 seconds by definition. The inserted leap second is skipped and the clock
+is suddenly ahead of UTC by one second. The \fBleapsecmode\fP directive selects how
+that error is corrected. There are four options:
+.sp
+\fBsystem\fP
+.RS 4
+When inserting a leap second, the kernel steps the system clock backwards by
+one second when the clock gets to 00:00:00 UTC. When deleting a leap second, it
+steps forward by one second when the clock gets to 23:59:59 UTC. This is the
+default mode when the system driver supports leap seconds (i.e. all supported
+systems with the exception of macOS 12 and earlier).
+.RE
+.sp
+\fBstep\fP
+.RS 4
+This is similar to the \fBsystem\fP mode, except the clock is stepped by
+\fBchronyd\fP instead of the kernel. It can be useful to avoid bugs in the kernel
+code that would be executed in the \fBsystem\fP mode. This is the default mode
+when the system driver does not support leap seconds.
+.RE
+.sp
+\fBslew\fP
+.RS 4
+The clock is corrected by slewing started at 00:00:00 UTC when a leap second
+is inserted or 23:59:59 UTC when a leap second is deleted. This might be
+preferred over the \fBsystem\fP and \fBstep\fP modes when applications running on the
+system are sensitive to jumps in the system time and it is acceptable that the
+clock will be off for a longer time. On Linux with the default
+\fBmaxslewrate\fP value the correction takes 12 seconds.
+.RE
+.sp
+\fBignore\fP
+.RS 4
+No correction is applied to the clock for the leap second. The clock will be
+corrected later in normal operation when new measurements are made and the
+estimated offset includes the one second error.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+When serving time to NTP clients that cannot be configured to correct their
+clocks for a leap second by slewing, or to clients that would correct at
+slightly different rates when it is necessary to keep them close together, the
+\fBslew\fP mode can be combined with the \fBsmoothtime\fP directive to
+enable a server leap smear.
+.sp
+When smearing a leap second, the leap status is suppressed on the server and
+the served time is corrected slowly be slewing instead of stepping. The clients
+do not need any special configuration as they do not know there is any leap
+second and they follow the server time which eventually brings them back to
+UTC. Care must be taken to ensure they use only NTP servers which smear the
+leap second in exactly the same way for synchronisation.
+.sp
+This feature must be used carefully, because the server is intentionally not
+serving its best estimate of the true time.
+.sp
+A recommended configuration to enable a server leap smear is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+leapsecmode slew
+maxslewrate 1000
+smoothtime 400 0.001 leaponly
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The first directive is necessary to disable the clock step which would reset
+the smoothing process. The second directive limits the slewing rate of the
+local clock to 1000 ppm, which improves the stability of the smoothing process
+when the local correction starts and ends. The third directive enables the
+server time smoothing process. It will start when the clock gets to 00:00:00
+UTC and it will take 17 hours 34 minutes to finish. The frequency offset will
+be changing by 0.001 ppm per second and will reach a maximum of 31.623 ppm. The
+\fBleaponly\fP option makes the duration of the leap smear constant and allows the
+clients to safely synchronise with multiple identically configured leap
+smearing servers.
+.RE
+.sp
+\fBleapsectz\fP \fItimezone\fP
+.RS 4
+This directive specifies a timezone in the system tz database which \fBchronyd\fP
+can use to determine when will the next leap second occur and what is the
+current offset between TAI and UTC. It will periodically check if 23:59:59 and
+23:59:60 are valid times in the timezone. This typically works with the
+\fIright/UTC\fP timezone.
+.sp
+When a leap second is announced, the timezone needs to be updated at least 12
+hours before the leap second. It is not necessary to restart \fBchronyd\fP.
+.sp
+This directive is useful with reference clocks and other time sources which do
+not announce leap seconds, or announce them too late for an NTP server to
+forward them to its own clients. Clients of leap smearing servers must not
+use this directive.
+.sp
+It is also useful when the system clock is required to have correct TAI\-UTC
+offset. Note that the offset is set only when leap seconds are handled by the
+kernel, i.e. \fBleapsecmode\fP is set to \fBsystem\fP.
+.sp
+The specified timezone is not used as an exclusive source of information about
+leap seconds. If a majority of time sources announce on the last day of June or
+December that a leap second should be inserted or deleted, it will be accepted
+even if it is not included in the timezone.
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+leapsectz right/UTC
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The following shell command verifies that the timezone contains leap seconds
+and can be used with this directive:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+$ TZ=right/UTC date \-d \(aqDec 31 2008 23:59:60\(aq
+Wed Dec 31 23:59:60 UTC 2008
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBmakestep\fP \fIthreshold\fP \fIlimit\fP
+.RS 4
+Normally \fBchronyd\fP will 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 might be so far adrift that this slewing process would take a
+very long time to correct the system clock.
+.sp
+This directive forces \fBchronyd\fP to step the system clock if the adjustment is
+larger than a threshold value, but only if there were no more clock updates
+since \fBchronyd\fP was started than a specified limit (a negative value can be
+used to disable the limit).
+.sp
+This is particularly useful when using reference clocks, because the
+\fBinitstepslew\fP directive works only with NTP sources.
+.sp
+An example of the use of this directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+makestep 0.1 3
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This would step the system clock if the adjustment is larger than 0.1 seconds, but
+only in the first three clock updates.
+.RE
+.sp
+\fBmaxchange\fP \fIoffset\fP \fIstart\fP \fIignore\fP
+.RS 4
+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 \fBchronyd\fP will give up and exit (a negative value can be used to never
+exit). In both cases a message is sent to syslog.
+.sp
+An example of the use of this directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+maxchange 1000 1 2
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+After the first clock update, \fBchronyd\fP will check the offset on every clock
+update, it will ignore two adjustments larger than 1000 seconds and exit on
+another one.
+.RE
+.sp
+\fBmaxclockerror\fP \fIerror\-in\-ppm\fP
+.RS 4
+The \fBmaxclockerror\fP directive sets the maximum assumed frequency error that the
+system clock can gain on its own between clock updates. It describes the
+stability of the clock.
+.sp
+By default, the maximum error is 1 ppm.
+.sp
+Typical values for \fIerror\-in\-ppm\fP might be 10 for a low quality clock and 0.1
+for a high quality clock using a temperature compensated crystal oscillator.
+.RE
+.sp
+\fBmaxdrift\fP \fIdrift\-in\-ppm\fP
+.RS 4
+This directive specifies the maximum assumed drift (frequency error) of the
+system clock. It limits the frequency adjustment that \fBchronyd\fP is allowed to
+use to correct the measured drift. It is an additional limit to the maximum
+adjustment that can be set by the system driver (100000 ppm on Linux, 500 ppm
+on FreeBSD, NetBSD, and macOS 10.13+, 32500 ppm on Solaris).
+.sp
+By default, the maximum assumed drift is 500000 ppm, i.e. the adjustment is
+limited by the system driver rather than this directive.
+.RE
+.sp
+\fBmaxupdateskew\fP \fIskew\-in\-ppm\fP
+.RS 4
+One of \fBchronyd\fP\(cqs tasks is to work out how fast or slow the computer\(cqs clock
+runs relative to its reference sources. In addition, it computes an estimate of
+the error bounds around the estimated value.
+.sp
+If the range of error is too large, it probably indicates that the measurements
+have not settled down yet, and that the estimated gain or loss rate is not very
+reliable.
+.sp
+The \fBmaxupdateskew\fP directive sets the threshold for determining whether an
+estimate might be so unreliable that it should not be used. By default, the
+threshold is 1000 ppm.
+.sp
+Typical values for \fIskew\-in\-ppm\fP might be 100 for a dial\-up connection to
+servers over a phone line, and 5 or 10 for a computer on a LAN.
+.sp
+It should be noted that this is not the only means of protection against using
+unreliable estimates. At all times, \fBchronyd\fP keeps 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 \fBchronyd\fP
+has 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.
+.RE
+.sp
+\fBmaxslewrate\fP \fIrate\-in\-ppm\fP
+.RS 4
+The \fBmaxslewrate\fP directive sets the maximum rate at which \fBchronyd\fP is allowed
+to slew the time. It limits the slew rate controlled by the correction time
+ratio (which can be set by the \fBcorrtimeratio\fP directive) and
+is effective only on systems where \fBchronyd\fP is able to control the rate (i.e.
+all supported systems with the exception of macOS 12 or earlier).
+.sp
+For each system there is a maximum frequency offset of the clock that can be set
+by the driver. On Linux it is 100000 ppm, on FreeBSD, NetBSD and macOS 10.13+ it
+is 5000 ppm, and on Solaris it is 32500 ppm. Also, due to a kernel limitation,
+setting \fBmaxslewrate\fP on FreeBSD, NetBSD, macOS 10.13+ to a value between 500
+ppm and 5000 ppm will effectively set it to 500 ppm.
+.sp
+In early beta releases of macOS 13 this capability is disabled because of a
+system kernel bug. When the kernel bug is fixed, chronyd will detect this and
+re\-enable the capability (see above limitations) with no recompilation required.
+.sp
+By default, the maximum slew rate is set to 83333.333 ppm (one twelfth).
+.RE
+.sp
+\fBtempcomp\fP \fIfile\fP \fIinterval\fP \fIT0\fP \fIk0\fP \fIk1\fP \fIk2\fP, \fBtempcomp\fP \fIfile\fP \fIinterval\fP \fIpoints\-file\fP
+.RS 4
+Normally, changes in the rate of drift of the system clock are caused mainly by
+changes in the temperature of the crystal oscillator on the motherboard.
+.sp
+If there are temperature measurements available from a sensor close to the
+oscillator, the \fBtempcomp\fP directive can be used to compensate for the changes
+in the temperature and improve the stability and accuracy of the clock.
+.sp
+The result depends on many factors, including the resolution of the sensor, the
+amount of noise in the measurements, the polling interval of the time source,
+the compensation update interval, how well the compensation is specified, and
+how close the sensor is to the oscillator. When it is working well, the
+frequency reported in the \fItracking.log\fP file is more stable and the maximum
+reached offset is smaller.
+.sp
+There are two forms of the directive. The first one has six parameters: a path
+to the file containing the current temperature from the sensor (in text
+format), the compensation update interval (in seconds), and temperature
+coefficients \fIT0\fP, \fIk0\fP, \fIk1\fP, \fIk2\fP.
+.sp
+The frequency compensation is calculated (in ppm) as
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+k0 + (T \- T0) * k1 + (T \- T0)^2 * k2
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The result has to be between \-10 ppm and 10 ppm, otherwise the measurement is
+considered invalid and will be ignored. The \fIk0\fP coefficient can be adjusted to
+keep the compensation in that range.
+.sp
+An example of the use is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 26000 0.0 0.000183 0.0
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The measured temperature will be read from the file in the Linux sysfs
+filesystem every 30 seconds. When the temperature is 26000 (26 degrees
+Celsius), the frequency correction will be zero. When it is 27000 (27 degrees
+Celsius), the clock will be set to run faster by 0.183 ppm, etc.
+.sp
+The second form has three parameters: the path to the sensor file, the update
+interval, and a path to a file containing a list of (temperature, compensation)
+points, from which the compensation is linearly interpolated or extrapolated.
+.sp
+An example is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 /etc/chrony.tempcomp
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+where the \fI/etc/chrony.tempcomp\fP file could have
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+20000 1.0
+21000 0.64
+22000 0.36
+23000 0.16
+24000 0.04
+25000 0.0
+26000 0.04
+27000 0.16
+28000 0.36
+29000 0.64
+30000 1.0
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+Valid measurements with corresponding compensations are logged to the
+\fItempcomp.log\fP file if enabled by the \fBlog tempcomp\fP directive.
+.RE
+.SS "NTP server"
+.sp
+\fBallow\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+The \fBallow\fP directive is used to designate a particular subnet from which NTP
+clients are allowed to access the computer as an NTP server.
+.sp
+The default is that no clients are allowed access, i.e. \fBchronyd\fP operates
+purely as an NTP client. If the \fBallow\fP directive is used, \fBchronyd\fP will be
+both a client of its servers, and a server to other clients.
+.sp
+Examples of the use of the directive are as follows:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+allow 1.2.3.4
+allow 1.2
+allow 3.4.5
+allow 6.7.8/22
+allow 6.7.8.9/22
+allow 2001:db8::/32
+allow 0/0
+allow ::/0
+allow
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The first directive allows a node with IPv4 address \fI1.2.3.4\fP to be an NTP
+client of this computer.
+The second directive allows any node with an IPv4 address of the form \fI1.2.x.y\fP
+(with \fIx\fP and \fIy\fP arbitrary) to be an NTP client of this computer. Likewise,
+the third directive allows any node with an IPv4 address of the form \fI3.4.5.x\fP
+to have client NTP access. The fourth and fifth forms allow access from any
+node with an IPv4 address of the form \fI6.7.8.x\fP, \fI6.7.9.x\fP, \fI6.7.10.x\fP or
+\fI6.7.11.x\fP (with \fIx\fP arbitrary), i.e. the value 22 is the number of bits
+defining the specified subnet. In the fifth form, the final byte is ignored.
+The sixth form is used for IPv6 addresses. The seventh and eighth forms allow
+access by any IPv4 and IPv6 node respectively. The ninth forms allows access by
+any node (IPv4 or IPv6).
+.sp
+A second form of the directive, \fBallow all\fP, has a greater effect, depending on
+the ordering of directives in the configuration file. To illustrate the effect,
+consider the two examples:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+allow 1.2.3.4
+deny 1.2.3
+allow 1.2
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+and
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+allow 1.2.3.4
+deny 1.2.3
+allow all 1.2
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+In the first example, the effect is the same regardless of what order the three
+directives are given in. So the \fI1.2.x.y\fP subnet is allowed access, except for
+the \fI1.2.3.x\fP subnet, which is denied access, however the host \fI1.2.3.4\fP is
+allowed access.
+.sp
+In the second example, the \fBallow all 1.2\fP directives overrides the effect of
+\fIany\fP previous directive relating to a subnet within the specified subnet.
+Within a configuration file this capability is probably rather moot; however,
+it is of greater use for reconfiguration at run\-time via \fBchronyc\fP with the
+\fBallow all\fP command.
+.sp
+The directive allows a hostname to be specified instead of an IP address, but
+the name must be resolvable when \fBchronyd\fP is started (i.e. \fBchronyd\fP needs
+to be started when the network is already up and DNS is working).
+.sp
+Note, if the \fBinitstepslew\fP directive is used in the
+configuration file, each of the computers listed in that directive must allow
+client access by this computer for it to work.
+.RE
+.sp
+\fBdeny\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+This is similar to the \fBallow\fP directive, except that it denies NTP
+client access to a particular subnet or host, rather than allowing it.
+.sp
+The syntax is identical.
+.sp
+There is also a \fBdeny all\fP directive with similar behaviour to the \fBallow all\fP
+directive.
+.RE
+.sp
+\fBbindaddress\fP \fIaddress\fP
+.RS 4
+The \fBbindaddress\fP directive binds the socket on which \fBchronyd\fP listens for NTP
+requests to a local address of the computer. On systems other than Linux, the
+address of the computer needs to be already configured when \fBchronyd\fP is
+started.
+.sp
+An example of the use of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+bindaddress 192.168.1.1
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+Currently, for each of the IPv4 and IPv6 protocols, only one \fBbindaddress\fP
+directive can be specified. Therefore, it is not useful on computers which
+should serve NTP on multiple network interfaces.
+.RE
+.sp
+\fBbroadcast\fP \fIinterval\fP \fIaddress\fP [\fIport\fP]
+.RS 4
+The \fBbroadcast\fP directive is used to declare a broadcast address to which
+chronyd should send packets in the NTP broadcast mode (i.e. make \fBchronyd\fP act
+as a broadcast server). Broadcast clients on that subnet will be able to
+synchronise.
+.sp
+The syntax is as follows:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+broadcast 30 192.168.1.255
+broadcast 60 192.168.2.255 12123
+broadcast 60 ff02::101
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+In the first example, the destination port defaults to UDP port 123 (the normal NTP
+port). In the second example, the destination port is specified as 12123. The
+first parameter in each case (30 or 60 respectively) is the interval in seconds
+between broadcast packets being sent. The second parameter in each case is the
+broadcast address to send the packet to. This should correspond to the
+broadcast address of one of the network interfaces on the computer where
+\fBchronyd\fP is running.
+.sp
+You can have more than 1 \fBbroadcast\fP directive if you have more than 1 network
+interface onto which you want to send NTP broadcast packets.
+.sp
+\fBchronyd\fP itself cannot act as a broadcast client; it must always be configured
+as a point\-to\-point client by defining specific NTP servers and peers. This
+broadcast server feature is intended for providing a time source to other NTP
+implementations.
+.sp
+If \fBntpd\fP is used as the broadcast client, it will try to measure the
+round\-trip delay between the server and client with normal client mode packets.
+Thus, the broadcast subnet should also be the subject of an \fBallow\fP
+directive.
+.RE
+.sp
+\fBclientloglimit\fP \fIlimit\fP
+.RS 4
+This directive specifies the maximum amount of memory that \fBchronyd\fP is allowed
+to allocate for logging of client accesses and the state that \fBchronyd\fP as an
+NTP server needs to support the interleaved mode for its clients. The default
+limit is 524288 bytes, which is sufficient for monitoring about four thousand
+clients at the same time.
+.sp
+In older \fBchrony\fP versions if the limit was set to 0, the memory allocation was
+unlimited.
+.sp
+An example of the use of this directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+clientloglimit 1048576
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBnoclientlog\fP
+.RS 4
+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 \fBclients\fP command in \fBchronyc\fP. This option
+also effectively disables server support for the NTP interleaved mode.
+.RE
+.sp
+\fBlocal\fP [\fIoption\fP]...
+.RS 4
+The \fBlocal\fP directive enables a local reference mode, which allows \fBchronyd\fP
+operating as an NTP server to appear synchronised to real time (from the
+viewpoint of clients polling it), even when it was never synchronised or
+the last update of the clock happened a long time ago.
+.sp
+This directive is normally used in an isolated network, where computers are
+required to be synchronised to one another, but not necessarily to real time.
+The server can be kept vaguely in line with real time by manual input.
+.sp
+The \fBlocal\fP directive has the following options:
+.sp
+\fBstratum\fP \fIstratum\fP
+.RS 4
+This option sets the stratum of the server which will be reported to clients
+when the local reference is active. The specified value is in the range 1
+through 15, and the default value is 10. It should be larger than the maximum
+expected stratum in the network when external NTP servers are accessible.
+.sp
+Stratum 1 indicates a computer that has a true real\-time reference directly
+connected to it (e.g. GPS, atomic clock, etc.), such computers are expected to
+be very close to real time. Stratum 2 computers are those which have a stratum
+1 server; stratum 3 computers have a stratum 2 server and so on. A value
+of 10 indicates that the clock is so many hops away from a reference clock that
+its time is fairly unreliable.
+.RE
+.sp
+\fBdistance\fP \fIdistance\fP
+.RS 4
+This option sets the threshold for the root distance which will activate the local
+reference. If \fBchronyd\fP was synchronised to some source, the local reference
+will not be activated until its root distance reaches the specified value (the
+rate at which the distance is increasing depends on how well the clock was
+tracking the source). The default value is 1 second.
+.sp
+The current root distance can be calculated from root delay and root dispersion
+(reported by the \fBtracking\fP command in \fBchronyc\fP) as:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+distance = delay / 2 + dispersion
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBorphan\fP
+.RS 4
+This option enables a special \(oqorphan\(cq mode, where sources with stratum equal
+to the local \fIstratum\fP are assumed to not serve real time. They are ignored
+unless no other source is selectable and their reference IDs are smaller than
+the local reference ID.
+.sp
+This allows multiple servers in the network to use the same \fBlocal\fP
+configuration and to be synchronised to one another, without confusing clients
+that poll more than one server. Each server needs to be configured to poll all
+other servers with the \fBlocal\fP directive. This ensures only the server with the
+smallest reference ID has the local reference active and others are
+synchronised to it. When that server fails, another will take over.
+.sp
+The \fBorphan\fP mode is compatible with the \fBntpd\fP\(cqs orphan mode (enabled by the
+\fBtos orphan\fP command).
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+local stratum 10 orphan
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBntpsigndsocket\fP \fIdirectory\fP
+.RS 4
+This directive specifies the location of the Samba \fBntp_signd\fP socket when it
+is running as a Domain Controller (DC). If \fBchronyd\fP is compiled with this
+feature, responses to MS\-SNTP clients will be signed by the \fBsmbd\fP daemon.
+.sp
+Note that MS\-SNTP requests are not authenticated and any client that is allowed
+to access the server by the \fBallow\fP directive, or the
+\fBallow\fP command in \fBchronyc\fP, can get an MS\-SNTP
+response signed with a trust account\(cqs password and try to crack the password
+in a brute\-force attack. Access to the server should be carefully controlled.
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+ntpsigndsocket /var/lib/samba/ntp_signd
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBport\fP \fIport\fP
+.RS 4
+This option allows you to configure the port on which \fBchronyd\fP will listen for
+NTP requests. The port will be open only when an address is allowed by the
+\fBallow\fP directive or the \fBallow\fP command in
+\fBchronyc\fP, an NTP peer is configured, or the broadcast server mode is enabled.
+.sp
+The default value is 123, the standard NTP port. If set to 0, \fBchronyd\fP will
+never open the server port and will operate strictly in a client\-only mode. The
+source port used in NTP client requests can be set by the
+\fBacquisitionport\fP directive.
+.RE
+.sp
+\fBratelimit\fP [\fIoption\fP]...
+.RS 4
+This directive enables response rate limiting for NTP packets. Its purpose is
+to reduce network traffic with misconfigured or broken NTP clients that are
+polling the server too frequently. The limits are applied to individual IP
+addresses. If multiple clients share one IP address (e.g. multiple hosts behind
+NAT), the sum of their traffic will be limited. If a client that increases its
+polling rate when it does not receive a reply is detected, its rate limiting
+will be temporarily suspended to avoid increasing the overall amount of
+traffic. The maximum number of IP addresses which can be monitored at the same
+time depends on the memory limit set by the \fBclientloglimit\fP
+directive.
+.sp
+The \fBratelimit\fP directive supports a number of options (which can be defined
+in any order):
+.sp
+\fBinterval\fP
+.RS 4
+This option sets the minimum interval between responses. It is defined as a
+power of 2 in seconds. The default value is 3 (8 seconds). The minimum value
+is \-19 (524288 packets per second) and the maximum value is 12 (one packet per
+4096 seconds). Note that with values below \-4 the rate limiting is coarse
+(responses are allowed in bursts, even if the interval between them is shorter
+than the specified interval).
+.RE
+.sp
+\fBburst\fP
+.RS 4
+This option sets the maximum number of responses that can be sent in a burst,
+temporarily exceeding the limit specified by the \fBinterval\fP option. This is
+useful for clients that make rapid measurements on start (e.g. \fBchronyd\fP with
+the \fBiburst\fP option). The default value is 8. The minimum value is 1 and the
+maximum value is 255.
+.RE
+.sp
+\fBleak\fP
+.RS 4
+This option sets the rate at which responses are randomly allowed even if the
+limits specified by the \fBinterval\fP and \fBburst\fP options are exceeded. This is
+necessary to prevent an attacker who is sending requests with a spoofed
+source address from completely blocking responses to that address. The leak
+rate is defined as a power of 1/2 and it is 2 by default, i.e. on average at
+least every fourth request has a response. The minimum value is 1 and the
+maximum value is 4.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+An example use of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+ratelimit interval 1 burst 16
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This would reduce the response rate for IP addresses sending packets on average
+more than once per 2 seconds, or sending packets in bursts of more than 16
+packets, by up to 75% (with default \fBleak\fP of 2).
+.RE
+.sp
+\fBsmoothtime\fP \fImax\-freq\fP \fImax\-wander\fP [\fBleaponly\fP]
+.RS 4
+The \fBsmoothtime\fP directive can be used to enable smoothing of the time that
+\fBchronyd\fP serves to its clients to make it easier for them to track it and keep
+their clocks close together even when large offset or frequency corrections are
+applied to the server\(cqs clock, for example after being offline for a longer
+time.
+.sp
+BE WARNED: The server is intentionally not serving its best estimate of the
+true time. If a large offset has been accumulated, it can take a very long time
+to smooth it out. This directive should be used only when the clients are not
+configured to also poll another NTP server, because they could reject this
+server as a falseticker or fail to select a source completely.
+.sp
+The smoothing process is implemented with a quadratic spline function with two
+or three pieces. It is independent from any slewing applied to the local system
+clock, but the accumulated offset and frequency will be reset when the clock is
+corrected by stepping, e.g. by the \fBmakestep\fP directive or the
+\fBmakestep\fP command in \fBchronyc\fP. The process can be
+reset without stepping the clock by the \fBsmoothtime
+reset\fP command.
+.sp
+The first two arguments of the directive are the maximum frequency offset of
+the smoothed time to the tracked NTP time (in ppm) and the maximum rate at
+which the frequency offset is allowed to change (in ppm per second). \fBleaponly\fP
+is an optional third argument which enables a mode where only leap seconds are
+smoothed out and normal offset and frequency changes are ignored. The \fBleaponly\fP
+option is useful in a combination with the \fBleapsecmode slew\fP
+directive to allow the clients to use multiple time smoothing servers safely.
+.sp
+The smoothing process is activated automatically when 1/10000 of the estimated
+skew of the local clock falls below the maximum rate of frequency change. It
+can be also activated manually by the \fBsmoothtime
+activate\fP command, which is particularly useful when the clock is
+synchronised only with manual input and the skew is always larger than the
+threshold. The \fBsmoothing\fP command can be used to
+monitor the process.
+.sp
+An example suitable for clients using \fBntpd\fP and 1024 second polling interval
+could be:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+smoothtime 400 0.001
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+An example suitable for clients using \fBchronyd\fP on Linux could be:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+smoothtime 50000 0.01
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.SS "Command and monitoring access"
+.sp
+\fBbindcmdaddress\fP \fIaddress\fP
+.RS 4
+The \fBbindcmdaddress\fP directive allows you to specify an IP address of an
+interface on which \fBchronyd\fP will listen for monitoring command packets (issued
+by \fBchronyc\fP). On systems other than Linux, the address of the interface needs
+to be already configured when \fBchronyd\fP is started.
+.sp
+This directive can also change the path of the Unix domain command socket,
+which is used by \fBchronyc\fP to send configuration commands. The socket must be
+in a directory that is accessible only by the root or \fIchrony\fP user. The
+directory will be created on start if it does not exist. The compiled\-in default
+path of the socket is \fI@CHRONYRUNDIR@/chronyd.sock\fP. The socket can be
+disabled by setting the path to \fI/\fP.
+.sp
+By default, \fBchronyd\fP binds to the loopback interface (with addresses
+\fI127.0.0.1\fP and \fI::1\fP). This blocks all access except from localhost. To listen
+for command packets on all interfaces, you can add the lines:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+bindcmdaddress 0.0.0.0
+bindcmdaddress ::
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+to the configuration file.
+.sp
+For each of the IPv4, IPv6, and Unix domain protocols, only one
+\fBbindcmdaddress\fP directive can be specified.
+.sp
+An example that sets the path of the Unix domain command socket is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+bindcmdaddress /var/run/chrony/chronyd.sock
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBcmdallow\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+This is similar to the \fBallow\fP directive, except that it allows
+monitoring access (rather than NTP client access) to a particular subnet or
+host. (By \(oqmonitoring access\(cq is meant that \fBchronyc\fP can be run on those
+hosts and retrieve monitoring data from \fBchronyd\fP on this computer.)
+.sp
+The syntax is identical to the \fBallow\fP directive.
+.sp
+There is also a \fBcmdallow all\fP directive with similar behaviour to the \fBallow
+all\fP directive (but applying to monitoring access in this case, of course).
+.sp
+Note that \fBchronyd\fP has to be configured with the
+\fBbindcmdaddress\fP directive to not listen only on the
+loopback interface to actually allow remote access.
+.RE
+.sp
+\fBcmddeny\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+This is similar to the \fBcmdallow\fP directive, except that it denies
+monitoring access to a particular subnet or host, rather than allowing it.
+.sp
+The syntax is identical.
+.sp
+There is also a \fBcmddeny all\fP directive with similar behaviour to the \fBcmdallow
+all\fP directive.
+.RE
+.sp
+\fBcmdport\fP \fIport\fP
+.RS 4
+The \fBcmdport\fP directive allows the port that is used for run\-time monitoring
+(via the \fBchronyc\fP program) to be altered from its default (323). If set to 0,
+\fBchronyd\fP will not open the port, this is useful to disable \fBchronyc\fP
+access from the Internet. (It does not disable the Unix domain command socket.)
+.sp
+An example shows the syntax:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+cmdport 257
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This would make \fBchronyd\fP use UDP 257 as its command port. (\fBchronyc\fP would
+need to be run with the \fB\-p 257\fP switch to inter\-operate correctly.)
+.RE
+.sp
+\fBcmdratelimit\fP [\fIoption\fP]...
+.RS 4
+This directive enables response rate limiting for command packets. It is
+similar to the \fBratelimit\fP directive, except responses to
+localhost are never limited and the default interval is \-4 (16 packets per
+second).
+.sp
+An example of the use of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+cmdratelimit interval 2
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.SS "Real\-time clock (RTC)"
+.sp
+\fBhwclockfile\fP \fIfile\fP
+.RS 4
+The \fBhwclockfile\fP directive sets the location of the adjtime file which is
+used by the \fBhwclock\fP program on Linux. \fBchronyd\fP parses the file to find out
+if the RTC keeps local time or UTC. It overrides the \fBrtconutc\fP
+directive.
+.sp
+The compiled\-in default value is \(aq\fI@DEFAULT_HWCLOCK_FILE@\fP\(aq.
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+hwclockfile /etc/adjtime
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBrtcautotrim\fP \fIthreshold\fP
+.RS 4
+The \fBrtcautotrim\fP directive is used to keep the RTC close to the system clock
+automatically. When the system clock is synchronised and the estimated error
+between the two clocks is larger than the specified threshold, \fBchronyd\fP will
+trim the RTC as if the \fBtrimrtc\fP command in \fBchronyc\fP
+was issued.
+.sp
+This directive is effective only with the \fBrtcfile\fP directive.
+.sp
+An example of the use of this directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+rtcautotrim 30
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This would set the threshold error to 30 seconds.
+.RE
+.sp
+\fBrtcdevice\fP \fIdevice\fP
+.RS 4
+The \fBrtcdevice\fP directive sets the path to the device file for accessing the
+RTC. The default path is \fI@DEFAULT_RTC_DEVICE@\fP.
+.RE
+.sp
+\fBrtcfile\fP \fIfile\fP
+.RS 4
+The \fBrtcfile\fP directive defines the name of the file in which \fBchronyd\fP can
+save parameters associated with tracking the accuracy of the RTC.
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+rtcfile @CHRONYVARDIR@/rtc
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+\fBchronyd\fP saves information in this file when it exits and when the \fBwritertc\fP
+command is issued in \fBchronyc\fP. The information saved is the RTC\(cqs error at
+some epoch, that epoch (in seconds since January 1 1970), and the rate at which
+the RTC gains or loses time.
+.sp
+So far, the support for real\-time clocks is limited; their code is even more
+system\-specific than the rest of the software. You can only use the RTC
+facilities (the \fBrtcfile\fP directive and the \fB\-s\fP command\-line
+option to \fBchronyd\fP) if the following three conditions apply:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+You are running Linux.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The kernel is compiled with extended real\-time clock support (i.e. the
+\fI/dev/rtc\fP device is capable of doing useful things).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+You do not have other applications that need to make use of \fI/dev/rtc\fP at all.
+.RE
+.RE
+.sp
+\fBrtconutc\fP
+.RS 4
+\fBchronyd\fP assumes by default that the RTC keeps local time (including any
+daylight saving changes). This is convenient on PCs running Linux which are
+dual\-booted with Windows.
+.sp
+If you keep the RTC on local time and your computer is off when daylight saving
+(summer time) starts or ends, the computer\(cqs system time will be one hour in
+error when you next boot and start chronyd.
+.sp
+An alternative is for the RTC to keep Universal Coordinated Time (UTC). This
+does not suffer from the 1 hour problem when daylight saving starts or ends.
+.sp
+If the \fBrtconutc\fP directive appears, it means the RTC is required to keep UTC.
+The directive takes no arguments. It is equivalent to specifying the \fB\-u\fP
+switch to the Linux \fBhwclock\fP program.
+.sp
+Note that this setting is overridden when the \fBhwclockfile\fP
+directive is specified.
+.RE
+.sp
+\fBrtcsync\fP
+.RS 4
+The \fBrtcsync\fP directive enables a mode where the system time is periodically
+copied to the RTC and \fBchronyd\fP does not try to track its drift. This directive
+cannot be used with the \fBrtcfile\fP directive.
+.sp
+On Linux, the RTC copy is performed by the kernel every 11 minutes.
+.sp
+On macOS, \fBchronyd\fP will perform the RTC copy every 60 minutes
+when the system clock is in a synchronised state.
+.sp
+On other systems this directive does nothing.
+.RE
+.SS "Logging"
+.sp
+\fBlog\fP [\fIoption\fP]...
+.RS 4
+The \fBlog\fP directive indicates that certain information is to be logged.
+The log files are written to the directory specified by the \fBlogdir\fP
+directive. A banner is periodically written to the files to indicate the
+meanings of the columns.
+.sp
+\fBrawmeasurements\fP
+.RS 4
+This option logs the raw NTP measurements and related information to a file
+called \fImeasurements.log\fP. An entry is made for each packet received from the
+source. This can be useful when debugging a problem. An example line (which
+actually appears as a single line in the file) from the log file is shown
+below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+2016\-11\-09 05:40:50 203.0.113.15    N  2 111 111 1111  10 10 1.0 \(rs
+   \-4.966e\-03  2.296e\-01  1.577e\-05  1.615e\-01  7.446e\-03 CB00717B 4B D K
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Date [2015\-10\-13]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Hour:Minute:Second. Note that the date\-time pair is expressed in UTC, not the
+local time zone. [05:40:50]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+IP address of server or peer from which measurement came [203.0.113.15]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+Leap status (\fIN\fP means normal, \fI+\fP means that the last minute of the current
+month has 61 seconds, \fI\-\fP means that the last minute of the month has 59
+seconds, \fI?\fP means the remote computer is not currently synchronised.) [N]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+Stratum of remote computer. [2]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 6." 4.2
+.\}
+RFC 5905 tests 1 through 3 (1=pass, 0=fail) [111]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 7." 4.2
+.\}
+RFC 5905 tests 5 through 7 (1=pass, 0=fail) [111]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 8." 4.2
+.\}
+Tests for maximum delay, maximum delay ratio and maximum delay dev ratio,
+against defined parameters, and a test for synchronisation loop (1=pass,
+0=fail) [1111]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 9." 4.2
+.\}
+Local poll [10]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 10.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 10." 4.2
+.\}
+Remote poll [10]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 11.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 11." 4.2
+.\}
+\(oqScore\(cq (an internal score within each polling level used to decide when to
+increase or decrease the polling level. This is adjusted based on number of
+measurements currently being used for the regression algorithm). [1.0]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 12.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 12." 4.2
+.\}
+The estimated local clock error (\fItheta\fP in RFC 5905). Positive indicates
+that the local clock is slow of the remote source. [\-4.966e\-03]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 13.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 13." 4.2
+.\}
+The peer delay (\fIdelta\fP in RFC 5905). [2.296e\-01]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 14.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 14." 4.2
+.\}
+The peer dispersion (\fIepsilon\fP in RFC 5905). [1.577e\-05]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 15.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 15." 4.2
+.\}
+The root delay (\fIDELTA\fP in RFC 5905). [1.615e\-01]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 16.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 16." 4.2
+.\}
+The root dispersion (\fIEPSILON\fP in RFC 5905). [7.446e\-03]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 17.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 17." 4.2
+.\}
+Reference ID of the server\(cqs source as a hexadecimal number. [CB00717B]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 18.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 18." 4.2
+.\}
+NTP mode of the received packet (\fI1\fP=active peer, \fI2\fP=passive peer,
+\fI4\fP=server, \fIB\fP=basic, \fII\fP=interleaved). [4B]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 19.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 19." 4.2
+.\}
+Source of the local transmit timestamp
+(\fID\fP=daemon, \fIK\fP=kernel, \fIH\fP=hardware). [D]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 20.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 20." 4.2
+.\}
+Source of the local receive timestamp
+(\fID\fP=daemon, \fIK\fP=kernel, \fIH\fP=hardware). [K]
+.RE
+.RE
+.sp
+\fBmeasurements\fP
+.RS 4
+This option is identical to the \fBrawmeasurements\fP option, except it logs only
+valid measurements from synchronised sources, i.e. measurements which passed
+the RFC 5905 tests 1 through 7. This can be useful for producing graphs of the
+source\(cqs performance.
+.RE
+.sp
+\fBstatistics\fP
+.RS 4
+This option logs information about the regression processing to a file called
+\fIstatistics.log\fP. An example line (which actually appears as a single line in
+the file) from the log file is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+2016\-08\-10 05:40:50 203.0.113.15     6.261e\-03 \-3.247e\-03 \(rs
+     2.220e\-03  1.874e\-06  1.080e\-06 7.8e\-02  16   0   8  0.00
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Date [2015\-07\-22]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Hour:Minute:Second. Note that the date\-time pair is expressed in
+UTC, not the local time zone. [05:40:50]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+IP address of server or peer from which measurement comes [203.0.113.15]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+The estimated standard deviation of the measurements from the source (in
+seconds). [6.261e\-03]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+The estimated offset of the source (in seconds, positive means the local
+clock is estimated to be fast, in this case). [\-3.247e\-03]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 6." 4.2
+.\}
+The estimated standard deviation of the offset estimate (in seconds).
+[2.220e\-03]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 7." 4.2
+.\}
+The estimated rate at which the local clock is gaining or losing time
+relative to the source (in seconds per second, positive means the local clock
+is gaining). This is relative to the compensation currently being applied to
+the local clock, \fInot\fP to the local clock without any compensation.
+[1.874e\-06]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 8." 4.2
+.\}
+The estimated error in the rate value (in seconds per second). [1.080e\-06].
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 9." 4.2
+.\}
+The ratio of |old_rate \- new_rate| / old_rate_error. Large values
+indicate the statistics are not modelling the source very well. [7.8e\-02]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 10.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 10." 4.2
+.\}
+The number of measurements currently being used for the regression
+algorithm. [16]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 11.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 11." 4.2
+.\}
+The new starting index (the oldest sample has index 0; this is the method
+used to prune old samples when it no longer looks like the measurements fit a
+linear model). [0, i.e. no samples discarded this time]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 12.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 12." 4.2
+.\}
+The number of runs. The number of runs of regression residuals with the same
+sign is computed. If this is too small it indicates that the measurements are
+no longer represented well by a linear model and that some older samples need
+to be discarded. The number of runs for the data that is being retained is
+tabulated. Values of approximately half the number of samples are expected.
+[8]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 13.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 13." 4.2
+.\}
+The estimated or configured asymmetry of network jitter on the path to the
+source which was used to correct the measured offsets. The asymmetry can be
+between \-0.5 and +0.5. A negative value means the delay of packets sent to
+the source is more variable than the delay of packets sent from the source
+back. [0.00, i.e. no correction for asymmetry]
+.RE
+.RE
+.sp
+\fBtracking\fP
+.RS 4
+This option logs changes to the estimate of the system\(cqs gain or loss rate, and
+any slews made, to a file called \fItracking.log\fP. An example line (which
+actually appears as a single line in the file) from the log file is shown
+below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+2017\-08\-22 13:22:36 203.0.113.15     2     \-3.541      0.075 \-8.621e\-06 N \(rs
+            2  2.940e\-03 \-2.084e\-04  1.534e\-02  3.472e\-04  8.304e\-03
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows (the quantities in square brackets are the
+values from the example line above) :
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Date [2017\-08\-22]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Hour:Minute:Second. Note that the date\-time pair is expressed in UTC, not the
+local time zone. [13:22:36]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The IP address of the server or peer to which the local system is synchronised.
+[203.0.113.15]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+The stratum of the local system. [2]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+The local system frequency (in ppm, positive means the local system runs fast
+of UTC). [\-3.541]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 6." 4.2
+.\}
+The error bounds on the frequency (in ppm). [0.075]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 7." 4.2
+.\}
+The estimated local offset at the epoch, which is normally corrected by
+slewing the local clock (in seconds, positive indicates the clock is fast of
+UTC). [\-8.621e\-06]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 8." 4.2
+.\}
+Leap status (\fIN\fP means normal, \fI+\fP means that the last minute of this month
+has 61 seconds, \fI\-\fP means that the last minute of the month has 59 seconds,
+\fI?\fP means the clock is not currently synchronised.) [N]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 9." 4.2
+.\}
+The number of combined sources. [2]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 10.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 10." 4.2
+.\}
+The estimated standard deviation of the combined offset (in seconds).
+[2.940e\-03]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 11.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 11." 4.2
+.\}
+The remaining offset correction from the previous update (in seconds,
+positive means the system clock is slow of UTC). [\-2.084e\-04]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 12.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 12." 4.2
+.\}
+The total of the network path delays to the reference clock to which
+the local clock is ultimately synchronised (in seconds). [1.534e\-02]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 13.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 13." 4.2
+.\}
+The total dispersion accumulated through all the servers back to the
+reference clock to which the local clock is ultimately synchronised
+(in seconds). [3.472e\-04]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 14.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 14." 4.2
+.\}
+The maximum estimated error of the system clock in the interval since the
+previous update (in seconds). It includes the offset, remaining offset
+correction, root delay, and dispersion from the previous update with the
+dispersion which accumulated in the interval. [8.304e\-03]
+.RE
+.RE
+.sp
+\fBrtc\fP
+.RS 4
+This option logs information about the system\(cqs real\-time clock. An example
+line (which actually appears as a single line in the file) from the \fIrtc.log\fP
+file is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+2015\-07\-22 05:40:50     \-0.037360 1       \-0.037434\(rs
+          \-37.948  12   5  120
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows (the quantities in square brackets are the
+values from the example line above):
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Date [2015\-07\-22]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Hour:Minute:Second. Note that the date\-time pair is expressed in UTC, not the
+local time zone. [05:40:50]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The measured offset between the RTC and the system clock in seconds.
+Positive indicates that the RTC is fast of the system time [\-0.037360].
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+Flag indicating whether the regression has produced valid coefficients.
+(1 for yes, 0 for no). [1]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+Offset at the current time predicted by the regression process. A large
+difference between this value and the measured offset tends to indicate that
+the measurement is an outlier with a serious measurement error. [\-0.037434]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 6." 4.2
+.\}
+The rate at which the RTC is losing or gaining time relative to the system
+clock. In ppm, with positive indicating that the RTC is gaining time.
+[\-37.948]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 7." 4.2
+.\}
+The number of measurements used in the regression. [12]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 8." 4.2
+.\}
+The number of runs of regression residuals of the same sign. Low values
+indicate that a straight line is no longer a good model of the measured data
+and that older measurements should be discarded. [5]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 9." 4.2
+.\}
+The measurement interval used prior to the measurement being made (in
+seconds). [120]
+.RE
+.RE
+.sp
+\fBrefclocks\fP
+.RS 4
+This option logs the raw and filtered reference clock measurements to a file
+called \fIrefclocks.log\fP. An example line (which actually appears as a single
+line in the file) from the log file is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+2009\-11\-30 14:33:27.000000 PPS2    7 N 1  4.900000e\-07 \-6.741777e\-07  1.000e\-06
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Date [2009\-11\-30]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Hour:Minute:Second.Microsecond. Note that the date\-time pair is expressed in
+UTC, not the local time zone. [14:33:27.000000]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+Reference ID of the reference clock from which the measurement came. [PPS2]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+Sequence number of driver poll within one polling interval for raw samples,
+or \fI\-\fP for filtered samples. [7]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+Leap status (\fIN\fP means normal, \fI+\fP means that the last minute of the current
+month has 61 seconds, \fI\-\fP means that the last minute of the month has 59
+seconds). [N]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 6." 4.2
+.\}
+Flag indicating whether the sample comes from PPS source. (1 for yes,
+0 for no, or \fI\-\fP for filtered sample). [1]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 7." 4.2
+.\}
+Local clock error measured by reference clock driver, or \fI\-\fP for filtered sample.
+[4.900000e\-07]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 8." 4.2
+.\}
+Local clock error with applied corrections. Positive indicates that the local
+clock is slow. [\-6.741777e\-07]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 9." 4.2
+.\}
+Assumed dispersion of the sample. [1.000e\-06]
+.RE
+.RE
+.sp
+\fBtempcomp\fP
+.RS 4
+This option logs the temperature measurements and system rate compensations to
+a file called \fItempcomp.log\fP. An example line (which actually appears as a
+single line in the file) from the log file is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+2015\-04\-19 10:39:48  2.8000e+04  3.6600e\-01
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows (the quantities in square brackets are the values
+from the example line above):
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Date [2015\-04\-19]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Hour:Minute:Second. Note that the date\-time pair is expressed in UTC, not the
+local time zone. [10:39:48]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+Temperature read from the sensor. [2.8000e+04]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+Applied compensation in ppm, positive means the system clock is running
+faster than it would be without the compensation. [3.6600e\-01]
+.RE
+.RE
+.RE
+.sp
+
+.RS 4
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+log measurements statistics tracking
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBlogbanner\fP \fIentries\fP
+.RS 4
+A banner is periodically written to the log files enabled by the \fBlog\fP
+directive to indicate the meanings of the columns.
+.sp
+The \fBlogbanner\fP directive specifies after how many entries in the log file
+should be the banner written. The default is 32, and 0 can be used to disable
+it entirely.
+.RE
+.sp
+\fBlogchange\fP \fIthreshold\fP
+.RS 4
+This directive sets the threshold for the adjustment of the system clock that
+will generate a syslog message. Clock errors detected via NTP packets,
+reference clocks, or timestamps entered via the
+\fBsettime\fP command of \fBchronyc\fP are logged.
+.sp
+By default, the threshold is 1 second.
+.sp
+An example of the use is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+logchange 0.1
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+which would cause a syslog message to be generated if a system clock error of over
+0.1 seconds starts to be compensated.
+.RE
+.sp
+\fBlogdir\fP \fIdirectory\fP
+.RS 4
+This directive allows the directory where log files are written to be
+specified.
+.sp
+An example of the use of this directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+logdir /var/log/chrony
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBmailonchange\fP \fIemail\fP \fIthreshold\fP
+.RS 4
+This directive defines an email address to which mail should be sent if
+\fBchronyd\fP applies a correction exceeding a particular threshold to the system
+clock.
+.sp
+An example of the use of this directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+mailonchange root@localhost 0.5
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This would send a mail message to root if a change of more than 0.5 seconds
+were applied to the system clock.
+.sp
+This directive cannot be used when a system call filter is enabled by the \fB\-F\fP
+option as the \fBchronyd\fP process will not be allowed to fork and execute the
+sendmail binary.
+.RE
+.SS "Miscellaneous"
+.sp
+\fBhwtimestamp\fP \fIinterface\fP [\fIoption\fP]...
+.RS 4
+This directive enables hardware timestamping of NTP packets sent to and
+received from the specified network interface. The network interface controller
+(NIC) uses its own clock to accurately timestamp the actual transmissions and
+receptions, avoiding processing and queueing delays in the kernel, network
+driver, and hardware. This can significantly improve the accuracy of the
+timestamps and the measured offset, which is used for synchronisation of the
+system clock. In order to get the best results, both sides receiving and
+sending NTP packets (i.e. server and client, or two peers) need to use HW
+timestamping. If the server or peer supports the interleaved mode, it needs to
+be enabled by the \fBxleave\fP option in the \fBserver\fP or the
+\fBpeer\fP directive.
+.sp
+This directive is supported on Linux 3.19 and newer. The NIC must support HW
+timestamping, which can be verified with the \fBethtool \-T\fP command. The list of
+capabilities should include \fISOF_TIMESTAMPING_RAW_HARDWARE\fP,
+\fISOF_TIMESTAMPING_TX_HARDWARE\fP, and \fISOF_TIMESTAMPING_RX_HARDWARE\fP. Receive
+filter \fIHWTSTAMP_FILTER_ALL\fP, or \fIHWTSTAMP_FILTER_NTP_ALL\fP, is necessary for
+timestamping of received packets. Timestamping of packets received from bridged
+and bonded interfaces is supported on Linux 4.13 and newer. When \fBchronyd\fP is
+running, no other process (e.g. a PTP daemon) should be working with the NIC
+clock.
+.sp
+If the kernel supports software timestamping, it will be enabled for all
+interfaces. The source of timestamps (i.e. hardware, kernel, or daemon) is
+indicated in the \fImeasurements.log\fP file if enabled by the \fBlog
+measurements\fP directive, and the \fBntpdata\fP report in
+\fBchronyc\fP.
+.sp
+If the specified interface is \fI*\fP, \fBchronyd\fP will try to enable HW timestamping
+on all available interfaces.
+.sp
+The \fBhwtimestamp\fP directive has the following options:
+.sp
+\fBminpoll\fP \fIpoll\fP
+.RS 4
+This option specifies the minimum interval between readings of the NIC clock.
+It\(cqs defined as a power of two. It should correspond to the minimum polling
+interval of all NTP sources and the minimum expected polling interval of NTP
+clients. The default value is 0 (1 second) and the minimum value is \-6 (1/64th
+of a second).
+.RE
+.sp
+\fBminsamples\fP \fIsamples\fP
+.RS 4
+This option specifies the minimum number of readings kept for tracking of the
+NIC clock. The default value is 2.
+.RE
+.sp
+\fBmaxsamples\fP \fIsamples\fP
+.RS 4
+This option specifies the maximum number of readings kept for tracking of the
+NIC clock. The default value is 16.
+.RE
+.sp
+\fBprecision\fP \fIprecision\fP
+.RS 4
+This option specifies the assumed precision of reading of the NIC clock. The
+default value is 100e\-9 (100 nanoseconds).
+.RE
+.sp
+\fBtxcomp\fP \fIcompensation\fP
+.RS 4
+This option specifies the difference in seconds between the actual transmission
+time at the physical layer and the reported transmit timestamp. This value will
+be added to transmit timestamps obtained from the NIC. The default value is 0.
+.RE
+.sp
+\fBrxcomp\fP \fIcompensation\fP
+.RS 4
+This option specifies the difference in seconds between the reported receive
+timestamp and the actual reception time at the physical layer. This value will
+be subtracted from receive timestamps obtained from the NIC. The default value
+is 0.
+.RE
+.sp
+\fBnocrossts\fP
+.RS 4
+Some hardware can precisely cross timestamp the NIC clock with the system
+clock. This option disables the use of the cross timestamping.
+.RE
+.sp
+\fBrxfilter\fP \fIfilter\fP
+.RS 4
+This option selects the receive timestamping filter. The \fIfilter\fP can be one of
+the following:
+.sp
+\fIall\fP
+.RS 4
+Enables timestamping of all received packets.
+.RE
+.sp
+\fIntp\fP
+.RS 4
+Enables timestamping of received NTP packets.
+.RE
+.sp
+\fInone\fP
+.RS 4
+Disables timestamping of received packets.
+.RE
+.RE
+.sp
+
+.RS 4
+The most specific filter for timestamping NTP packets which is supported by the
+NIC is selected by default. Some NICs can timestamp only PTP packets, which
+limits the selection to the \fInone\fP filter. Forcing timestamping of all packets
+with the \fIall\fP filter when the NIC supports both \fIall\fP and \fIntp\fP filters can be
+useful when packets are received from or on a non\-standard UDP port (e.g.
+specified by the \fBport\fP directive).
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+Examples of the directive are:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+hwtimestamp eth0
+hwtimestamp eth1 txcomp 300e\-9 rxcomp 645e\-9
+hwtimestamp *
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBinclude\fP \fIpattern\fP
+.RS 4
+The \fBinclude\fP directive includes a configuration file or multiple configuration
+files if a wildcard pattern is specified. This can be useful when maintaining
+configuration on multiple hosts to keep the differences in separate files.
+.sp
+An example of the directive is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+include @SYSCONFDIR@/chrony.d/*.conf
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBkeyfile\fP \fIfile\fP
+.RS 4
+This directive is used to specify the location of the file containing ID\-key
+pairs for authentication of NTP packets.
+.sp
+The format of the directive is shown in the example below:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+keyfile @SYSCONFDIR@/chrony.keys
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The argument is simply the name of the file containing the ID\-key pairs. The
+format of the file is shown below:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+10 tulip
+11 hyacinth
+20 MD5 ASCII:crocus
+25 SHA1 HEX:1dc764e0791b11fa67efc7ecbc4b0d73f68a070c
+ ...
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+Each line consists of an ID, name of an authentication hash function (optional),
+and a password. The ID can be any unsigned integer in the range 1 through
+2^32\-1. The default hash function is \fBMD5\fP, which is always supported.
+.sp
+If \fBchronyd\fP was built with enabled support for hashing using a crypto library
+(nettle, nss, or libtomcrypt), the following functions are available: \fBMD5\fP,
+\fBSHA1\fP, \fBSHA256\fP, \fBSHA384\fP, \fBSHA512\fP. Depending on which library and version is
+\fBchronyd\fP using, some or all of the following functions may also be available:
+\fBSHA3\-224\fP, \fBSHA3\-256\fP, \fBSHA3\-384\fP, \fBSHA3\-512\fP, \fBRMD128\fP, \fBRMD160\fP, \fBRMD256\fP,
+\fBRMD320\fP, \fBTIGER\fP, \fBWHIRLPOOL\fP.
+.sp
+The password can be specified as a string of characters not containing white
+space with an optional \fBASCII:\fP prefix, or as a hexadecimal number with the
+\fBHEX:\fP prefix. The maximum length of the line is 2047 characters.
+.sp
+The password is used with the hash function to generate and verify a message
+authentication code (MAC) in NTP packets. It is recommended to use SHA1, or
+stronger, hash function with random passwords specified in the hexadecimal
+format that have at least 128 bits. \fBchronyd\fP will log a warning to
+syslog on start if a source is specified in the configuration file with a key
+that has password shorter than 80 bits.
+.sp
+The \fBkeygen\fP command of \fBchronyc\fP can be used to
+generate random keys for the key file. By default, it generates 160\-bit MD5 or
+SHA1 keys.
+.sp
+For security reasons, the file should be readable only by root and the user
+under which \fBchronyd\fP is normally running (to allow \fBchronyd\fP to re\-read the
+file when the \fBrekey\fP command is issued by \fBchronyc\fP).
+.RE
+.sp
+\fBlock_all\fP
+.RS 4
+The \fBlock_all\fP directive will lock chronyd into RAM so that it will never be
+paged out. This mode is only supported on Linux. This directive uses the Linux
+\fBmlockall()\fP system call to prevent \fBchronyd\fP from ever being swapped out. This
+should result in lower and more consistent latency. It should not have
+significant impact on performance as \fBchronyd\(cqs\fP memory usage is modest. The
+\fBmlockall(2)\fP man page has more details.
+.RE
+.sp
+\fBpidfile\fP \fIfile\fP
+.RS 4
+Unless \fBchronyd\fP is started with the \fB\-Q\fP option, it writes its process ID
+(PID) to a file, and checks this file on startup to see if another \fBchronyd\fP
+might already be running on the system. By default, the file used is
+\fI@DEFAULT_PID_FILE@\fP. The \fBpidfile\fP directive allows the name to be changed,
+e.g.:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+pidfile /run/chronyd.pid
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBsched_priority\fP \fIpriority\fP
+.RS 4
+On Linux, the \fBsched_priority\fP directive will select the SCHED_FIFO real\-time
+scheduler at the specified priority (which must be between 0 and 100). On
+macOS, this option must have either a value of 0 (the default) to disable the
+thread time constraint policy or 1 for the policy to be enabled. Other systems
+do not support this option.
+.sp
+On Linux, this directive uses the \fBsched_setscheduler()\fP system call to
+instruct the kernel to use the SCHED_FIFO first\-in, first\-out real\-time
+scheduling policy for \fBchronyd\fP with the specified priority. This means that
+whenever \fBchronyd\fP is ready to run it will run, interrupting whatever else is
+running unless it is a higher priority real\-time process. This should not
+impact performance as \fBchronyd\fP resource requirements are modest, but it should
+result in lower and more consistent latency since \fBchronyd\fP will not need to
+wait for the scheduler to get around to running it. You should not use this
+unless you really need it. The \fBsched_setscheduler(2)\fP man page has more
+details.
+.sp
+On macOS, this directive uses the \fBthread_policy_set()\fP kernel call to
+specify real\-time scheduling. As noted for Linux, you should not use this
+directive unless you really need it.
+.RE
+.sp
+\fBuser\fP \fIuser\fP
+.RS 4
+The \fBuser\fP directive sets the name of the system user to which \fBchronyd\fP will
+switch after start in order to drop root privileges.
+.sp
+On Linux, \fBchronyd\fP needs to be compiled with support for the \fBlibcap\fP library.
+On macOS, FreeBSD, NetBSD and Solaris \fBchronyd\fP 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.
+.sp
+The compiled\-in default value is \fI@DEFAULT_USER@\fP.
+.RE
+.SH "EXAMPLES"
+.SS "NTP client with permanent connection to NTP servers"
+.sp
+This section shows how to configure \fBchronyd\fP for computers that are connected
+to the Internet (or to any network containing true NTP servers which ultimately
+derive their time from a reference clock) permanently or most of the time.
+.sp
+To operate in this mode, you will need to know the names of the NTP servers
+you want to use. You might be able to find names of suitable servers by one of
+the following methods:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Your institution might already operate servers on its network.
+Contact your system administrator to find out.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Your ISP probably has one or more NTP servers available for its
+customers.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Somewhere under the NTP homepage there is a list of public
+stratum 1 and stratum 2 servers. You should find one or more servers that are
+near to you. Check that their access policy allows you to use their
+facilities.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+Use public servers from the \c
+.URL "http://www.pool.ntp.org/" "pool.ntp.org" " "
+project.
+.RE
+.sp
+Assuming that your NTP servers are called \fIfoo.example.net\fP, \fIbar.example.net\fP
+and \fIbaz.example.net\fP, your \fIchrony.conf\fP file could contain as a minimum:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+server foo.example.net
+server bar.example.net
+server baz.example.net
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+However, you will probably want to include some of the other directives. The
+\fBdriftfile\fP, \fBmakestep\fP and \fBrtcsync\fP
+might be particularly useful. Also, the \fBiburst\fP option of the
+\fBserver\fP directive is useful to speed up the initial
+synchronisation. The smallest useful configuration file would look something
+like:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+server foo.example.net iburst
+server bar.example.net iburst
+server baz.example.net iburst
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+When using a pool of NTP servers (one name is used for multiple servers which
+might change over time), it is better to specify them with the \fBpool\fP
+directive instead of multiple \fBserver\fP directives. The configuration file could
+in this case look like:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+pool pool.ntp.org iburst
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fi
+.if n \{\
+.RE
+.\}
+.SS "NTP client with infrequent connection to NTP servers"
+.sp
+This section shows how to configure \fBchronyd\fP for computers that have
+occasional connections to NTP servers. In this case, you will need some
+additional configuration to tell \fBchronyd\fP when the connection goes up and
+down. This saves the program from continuously trying to poll the servers when
+they are inaccessible.
+.sp
+Again, assuming that your NTP servers are called \fIfoo.example.net\fP,
+\fIbar.example.net\fP and \fIbaz.example.net\fP, your \fIchrony.conf\fP file would now
+contain:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+server foo.example.net offline
+server bar.example.net offline
+server baz.example.net offline
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The \fBoffline\fP keyword indicates that the servers start in an offline state, and
+that they should not be contacted until \fBchronyd\fP receives notification from
+\fBchronyc\fP that the link to the Internet is present. To tell \fBchronyd\fP when to
+start and finish sampling the servers, the \fBonline\fP and
+\fBoffline\fP commands of \fBchronyc\fP need to be used.
+.sp
+To give an example of their use, assuming that \fBpppd\fP is the program being
+used to connect to the Internet and that \fBchronyc\fP has been installed at
+\fI@BINDIR@/chronyc\fP, the script \fI/etc/ppp/ip\-up\fP would include:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+@BINDIR@/chronyc online
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+and the script \fI/etc/ppp/ip\-down\fP would include:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+@BINDIR@/chronyc offline
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+\fBchronyd\fP\(cqs polling of the servers would now only occur whilst the machine is
+actually connected to the Internet.
+.SS "Isolated networks"
+.sp
+This section shows how to configure \fBchronyd\fP for computers that never have
+network conectivity to any computer which ultimately derives its time from a
+reference clock.
+.sp
+In this situation, one computer is selected to be the master timeserver. The
+other computers are either direct clients of the master, or clients of clients.
+.sp
+The \fBlocal\fP directive enables a local reference mode, which allows
+\fBchronyd\fP to appear synchronised even when it is not.
+.sp
+The rate value in the master\(cqs drift file needs to be set to the average rate
+at which the master gains or loses time. \fBchronyd\fP includes support for this,
+in the form of the \fBmanual\fP directive and the
+\fBsettime\fP command in the \fBchronyc\fP program.
+.sp
+If the master is rebooted, \fBchronyd\fP can re\-read the drift rate from the drift
+file. However, the master has no accurate estimate of the current time. To get
+around this, the system can be configured so that the master can initially set
+itself to a \(oqmajority\-vote\(cq of selected clients\(aq times; this allows the
+clients to \(oqflywheel\(cq the master while it is rebooting.
+.sp
+The \fBsmoothtime\fP directive is useful when the clocks of the
+clients need to stay close together when the local time is adjusted by the
+\fBsettime\fP command. The smoothing process needs to be
+activated by the \fBsmoothtime activate\fP command when
+the local time is ready to be served. After that point, any adjustments will be
+smoothed out.
+.sp
+A typical configuration file for the master (called \fImaster\fP) might be
+(assuming the clients and the master are in the \fI192.168.165.x\fP subnet):
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+initstepslew 1 client1 client3 client6
+driftfile @CHRONYVARDIR@/drift
+local stratum 8
+manual
+allow 192.168.165.0/24
+smoothtime 400 0.01
+rtcsync
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+For the clients that have to resynchronise the master when it restarts,
+the configuration file might be:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+server master iburst
+driftfile @CHRONYVARDIR@/drift
+allow 192.168.165.0/24
+makestep 1.0 3
+rtcsync
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The rest of the clients would be the same, except that the \fBallow\fP directive is
+not required.
+.sp
+If there is no suitable computer to be designated as the master, or there is a
+requirement to keep the clients synchronised even when it fails, the \fBorphan\fP
+option of the \fBlocal\fP directive enables a special mode where the master is
+selected from multiple computers automatically. They all need to use the same
+\fBlocal\fP configuration and poll one another. The server with the smallest
+reference ID (which is based on its IP address) will take the role of the
+master and others will be synchronised to it. When it fails, the server with
+the second smallest reference ID will take over and so on.
+.sp
+A configuration file for the first server might be (assuming there are three
+servers called \fImaster1\fP, \fImaster2\fP, and \fImaster3\fP):
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+initstepslew 1 master2 master3
+server master2
+server master3
+driftfile @CHRONYVARDIR@/drift
+local stratum 8 orphan
+manual
+allow 192.168.165.0/24
+rtcsync
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The other servers would be the same, except the hostnames in the \fBinitstepslew\fP
+and \fBserver\fP directives would be modified to specify the other servers. Their
+clients might be configured to poll all three servers.
+.SS "RTC tracking"
+.sp
+This section considers a computer which has occasional connections to the
+Internet and is turned off between \(oqsessions\(cq. In this case, \fBchronyd\fP relies
+on the computer\(cqs RTC to maintain the time between the periods when it is
+powered up. It assumes that Linux is run exclusively on the computer. Dual\-boot
+systems might work; it depends what (if anything) the other system does to the
+RTC. On 2.6 and later kernels, if your motherboard has a HPET, you will need to
+enable the \fBHPET_EMULATE_RTC\fP option in your kernel configuration. Otherwise,
+\fBchronyd\fP will not be able to interact with the RTC device and will give up
+using it.
+.sp
+When the computer is connected to the Internet, \fBchronyd\fP has access to
+external NTP servers which it makes measurements from. These measurements are
+saved, and straight\-line fits are performed on them to provide an estimate of
+the computer\(cqs time error and rate of gaining or losing time.
+.sp
+When the computer is taken offline from the Internet, the best estimate of the
+gain or loss rate is used to free\-run the computer until it next goes online.
+.sp
+Whilst the computer is running, \fBchronyd\fP makes measurements of the RTC (via
+the \fI/dev/rtc\fP interface, which must be compiled into the kernel). An estimate
+is made of the RTC error at a particular RTC second, and the rate at which the
+RTC gains or loses time relative to true time.
+.sp
+When the computer is powered down, the measurement histories for all the NTP
+servers are saved to files, and the RTC tracking information is also
+saved to a file (if the \fBrtcfile\fP directive has been specified).
+These pieces of information are also saved if the \fBdump\fP
+and \fBwritertc\fP commands respectively are issued
+through \fBchronyc\fP.
+.sp
+When the computer is rebooted, \fBchronyd\fP reads the current RTC time and the RTC
+information saved at the last shutdown. This information is used to set the
+system clock to the best estimate of what its time would have been now, had it
+been left running continuously. The measurement histories for the servers are
+then reloaded.
+.sp
+The next time the computer goes online, the previous sessions\(aq measurements can
+contribute to the line\-fitting process, which gives a much better estimate of
+the computer\(cqs gain or loss rate.
+.sp
+One problem with saving the measurements and RTC data when the machine is shut
+down is what happens if there is a power failure; the most recent data will not
+be saved. Although \fBchronyd\fP is robust enough to cope with this, some
+performance might be lost. (The main danger arises if the RTC has been changed
+during the session, with the \fBtrimrtc\fP command in \fBchronyc\fP. Because of this,
+\fBtrimrtc\fP will make sure that a meaningful RTC file is saved after the
+change is completed).
+.sp
+The easiest protection against power failure is to put the \fBdump\fP and
+\fBwritertc\fP commands in the same place as the \fBoffline\fP command is issued to
+take \fBchronyd\fP offline; because \fBchronyd\fP free\-runs between online sessions, no
+parameters will change significantly between going offline from the Internet
+and any power failure.
+.sp
+A final point regards computers which are left running for extended periods and
+where it is desired to spin down the hard disc when it is not in use (e.g. when
+not accessed for 15 minutes). \fBchronyd\fP has been planned so it supports such
+operation; this is the reason why the RTC tracking parameters are not saved to
+disc after every update, but only when the user requests such a write, or
+during the shutdown sequence. The only other facility that will generate
+periodic writes to the disc is the \fBlog rtc\fP facility in the configuration
+file; this option should not be used if you want your disc to spin down.
+.sp
+To illustrate how a computer might be configured for this case, example
+configuration files are shown.
+.sp
+For the \fIchrony.conf\fP file, the following can be used as an example.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+server foo.example.net maxdelay 0.4 offline
+server bar.example.net maxdelay 0.4 offline
+server baz.example.net maxdelay 0.4 offline
+logdir /var/log/chrony
+log statistics measurements tracking
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+maxupdateskew 100.0
+dumpdir @CHRONYVARDIR@
+rtcfile @CHRONYVARDIR@/rtc
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+\fBpppd\fP is used for connecting to the Internet. This runs two scripts
+\fI/etc/ppp/ip\-up\fP and \fI/etc/ppp/ip\-down\fP when the link goes online and offline
+respectively.
+.sp
+The relevant part of the \fI/etc/ppp/ip\-up\fP file is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+@BINDIR@/chronyc online
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+and the relevant part of the \fI/etc/ppp/ip\-down\fP script is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+@BINDIR@/chronyc \-m offline dump writertc
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+\fBchronyd\fP is started during the boot sequence with the \fB\-r\fP and \fB\-s\fP options.
+It might need to be started before any software that depends on the system clock
+not jumping or moving backwards, depending on the directives in \fBchronyd\fP\(cqs
+configuration file.
+.sp
+For the system shutdown, \fBchronyd\fP should receive a SIGTERM several seconds
+before the final SIGKILL; the SIGTERM causes the measurement histories and RTC
+information to be saved.
+.SS "Public NTP server"
+.sp
+\fBchronyd\fP can be configured to operate as a public NTP server, e.g. to join the
+.URL "http://www.pool.ntp.org/en/join.html" "pool.ntp.org" " "
+project. The configuration
+is similar to the NTP client with permanent connection, except it needs to
+allow client access from all addresses. It is recommended to find at least four
+good servers (e.g. from the pool, or on the NTP homepage). If the server has a
+hardware reference clock (e.g. a GPS receiver), it can be specified by the
+\fBrefclock\fP directive.
+.sp
+The amount of memory used for logging client accesses can be increased in order
+to enable clients to use the interleaved mode even when the server has a large
+number of clients, and better support rate limiting if it is enabled by the
+\fBratelimit\fP directive. The system timezone database, if it is
+kept up to date and includes the \fIright/UTC\fP timezone, can be used as a
+reliable source to determine when a leap second will be applied to UTC. The
+\fB\-r\fP option with the \fBdumpdir\fP directive shortens the time in which
+\fBchronyd\fP will not be able to serve time to its clients when it needs to be
+restarted (e.g. after upgrading to a newer version, or a change in the
+configuration).
+.sp
+The configuration file could look like:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+server foo.example.net iburst
+server bar.example.net iburst
+server baz.example.net iburst
+server qux.example.net iburst
+makestep 1.0 3
+rtcsync
+allow
+clientloglimit 100000000
+leapsectz right/UTC
+driftfile @CHRONYVARDIR@/drift
+dumpdir @CHRONYRUNDIR@
+.fi
+.if n \{\
+.RE
+.\}
+.SH "SEE ALSO"
+.sp
+\fBchronyc(1)\fP, \fBchronyd(8)\fP
+.SH "BUGS"
+.sp
+For instructions on how to report bugs, please visit
+.URL "https://chrony.tuxfamily.org/" "" "."
+.SH "AUTHORS"
+.sp
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
\ No newline at end of file
diff --git a/doc/chronyc.adoc b/doc/chronyc.adoc
new file mode 100644
index 0000000..b80cc1c
--- /dev/null
+++ b/doc/chronyc.adoc
@@ -0,0 +1,1224 @@
+// This file is part of chrony
+//
+// Copyright (C) Richard P. Curnow  1997-2003
+// Copyright (C) Stephen Wadeley  2016
+// Copyright (C) Miroslav Lichvar  2009-2017
+//
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of version 2 of the GNU General Public License as
+// published by the Free Software Foundation.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+
+= chronyc(1)
+:doctype: manpage
+:man manual: User manual
+:man source: chrony @CHRONY_VERSION@
+
+== NAME
+
+chronyc - command-line interface for chrony daemon
+
+== SYNOPSIS
+
+*chronyc* [_OPTION_]... [_COMMAND_]...
+
+== DESCRIPTION
+
+*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.
+
+If no commands are specified on the command line, *chronyc* will expect input
+from the user. The prompt _chronyc>_ will be displayed when it is being run
+from a terminal. If *chronyc*'s input or output are redirected from or to a file,
+the prompt is not shown.
+
+There are two ways *chronyc* can access *chronyd*. One is the Internet
+Protocol (IPv4 or IPv6) and the other is a Unix domain socket, which is
+accessible locally by the root or _chrony_ user. By default, *chronyc* first
+tries to connect to the Unix domain socket. The compiled-in default path is
+_@CHRONYRUNDIR@/chronyd.sock_. If that fails (e.g. because *chronyc* is
+running under a non-root user), it will try to connect to 127.0.0.1 and then
+::1.
+
+Only the following monitoring commands, which do not affect the behaviour of
+*chronyd*, are allowed from the network: *activity*, *manual list*,
+*rtcdata*, *smoothing*, *sources*, *sourcestats*, *tracking*, *waitsync*. The
+set of hosts from which *chronyd* will accept these commands can be configured
+with the <<chrony.conf.adoc#cmdallow,*cmdallow*>> directive in the *chronyd*'s
+configuration file or the <<cmdallow,*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* will respond with a '`Not authorised`' error, even
+if it is from localhost. In chrony versions before 2.2 they were allowed
+from the network if they were authenticated with a password, but that is no
+longer supported.
+
+Having full access to *chronyd* via *chronyc* is more or less equivalent to
+being able to modify the *chronyd*'s configuration file and restart it.
+
+== OPTIONS
+
+*-4*::
+With this option hostnames will be resolved only to IPv4 addresses.
+
+*-6*::
+With this option hostnames will be resolved only to IPv6 addresses.
+
+*-n*::
+This option disables resolving of IP addresses to hostnames, e.g. to avoid slow
+DNS lookups. Long addresses will not be truncated to fit into the column.
+
+*-c*::
+This option enables printing of reports in a comma-separated values (CSV)
+format. IP addresses will not be resolved to hostnames, time will be printed as
+number of seconds since the epoch and values in seconds will not be converted
+to other units.
+
+*-d*::
+This option enables printing of debugging messages if *chronyc* was compiled
+with debugging support.
+
+*-m*::
+Normally, all arguments on the command line are interpreted as one command.
+With this option multiple commands can be specified. Each argument will be
+interpreted as a whole command.
+
+*-h* _host_::
+This option allows the user to specify which host (or comma-separated list of
+addresses) running the *chronyd* program is to be contacted. This allows for
+remote monitoring, without having to connect over SSH to the other host first.
++
+The default is to contact *chronyd* running on the same host where
+*chronyc* is being run.
+
+*-p* _port_::
+This option allows the user to specify the UDP port number which the target
+*chronyd* is using for its monitoring connections. This defaults to 323; there
+would rarely be a need to change this.
+
+*-f* _file_::
+This option is ignored and is provided only for compatibility.
+
+*-a*::
+This option is ignored and is provided only for compatibility.
+
+*-v*::
+With this option *chronyc* displays its version number on the terminal and
+exits.
+
+== COMMANDS
+
+This section describes each of the commands available within the *chronyc*
+program.
+
+=== System clock
+
+[[tracking]]*tracking*::
+The *tracking* command displays parameters about the system's clock
+performance. An example of the output is shown below.
++
+----
+Reference 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 explained as follows:
++
+*Reference ID*:::
+This is the reference ID and name (or IP address) of the server to which the
+computer is currently synchronised. For IPv4 addresses, the reference ID is
+equal to the address and for IPv6 addresses it is the first 32 bits of the MD5
+sum of the address.
++
+If the reference ID is _7F7F0101_ and there is no name or IP address, it means
+the computer is not synchronised to any external source and that you have the
+_local_ mode operating (via the <<local,*local*>> command in *chronyc*, or the
+<<chrony.conf.adoc#local,*local*>> directive in the configuration file).
++
+The reference ID is printed as a hexadecimal number. Note that in older
+versions it used to be printed in quad-dotted notation and could be confused
+with an IPv4 address.
+*Stratum*:::
+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 (i.e. _foo.example.net_ is a
+stratum-2 and is synchronised 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, *chronyd* by default never steps the system clock, because
+any jump in the time 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)
+will be different from *chronyd*'s estimate of the current true time (which it
+reports to NTP clients 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.
+*Frequency*:::
+The '`frequency`' is the rate by which the system's clock would be wrong if
+*chronyd* was 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
+'`skew`' next) 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.
+*Skew*:::
+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 synchronised.
+*Root dispersion*:::
+This is the total dispersion accumulated through all the computers back to
+the stratum-1 computer from which the computer is ultimately synchronised.
+Dispersion is due to system clock resolution, statistical measurement
+variations, etc.
++
+An absolute bound on the computer's clock accuracy (assuming the stratum-1
+computer is correct) is given by:
++
+----
+clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)
+----
+*Update interval*:::
+This is the interval between the last two clock updates.
+*Leap status*:::
+This is the leap status, which can be _Normal_, _Insert second_, _Delete
+second_ or _Not synchronised_.
+
+[[makestep]]*makestep*::
+*makestep* _threshold_ _limit_::
+Normally *chronyd* will 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 might be so far adrift that this slewing process would take a
+very long time to correct the system clock.
++
+The *makestep* command can be used in this situation. There are two forms of
+the command. The first form has no parameters. It tells *chronyd* to cancel any
+remaining correction that was being slewed and jump the system clock by the
+equivalent amount, making it correct immediately.
++
+The second form configures the automatic stepping, similarly to the
+<<chrony.conf.adoc#makestep,*makestep*>> directive. It has two parameters,
+stepping threshold (in seconds) and number of future clock updates for which
+the threshold will be active. This can be used with the <<burst,*burst*>>
+command to quickly make a new measurement and correct the clock by stepping if
+needed, without waiting for *chronyd* to complete the measurement and update
+the clock.
++
+----
+makestep 0.1 1
+burst 1/2
+----
++
+BE WARNED: Certain software will be seriously affected by such jumps in the
+system time. (That is the reason why *chronyd* uses slewing normally.)
+
+[[maxupdateskew]]*maxupdateskew* _skew-in-ppm_::
+This command has the same effect as the
+<<chrony.conf.adoc#maxupdateskew,*maxupdateskew*>> directive in the
+configuration file.
+
+[[waitsync]]*waitsync* [_max-tries_ [_max-correction_ [_max-skew_ [_interval_]]]]::
+The *waitsync* command waits for *chronyd* to synchronise.
++
+Up to four optional arguments can be specified. The first is the maximum number
+of tries before giving up and returning a non-zero error code. When 0 is
+specified, or there are no arguments, the number of tries will not be limited.
++
+The second and third arguments are the maximum allowed remaining correction of
+the system clock and the maximum allowed skew (in ppm) as reported by the
+<<tracking,*tracking*>> command in the *System time* and *Skew* fields. If not
+specified or zero, the value will not be checked.
++
+The fourth argument is the interval specified in seconds in which the check is
+repeated. The interval is 10 seconds by default.
++
+An example is:
++
+----
+waitsync 60 0.01
+----
++
+which will wait up to about 10 minutes (60 times 10 seconds) for *chronyd* to
+synchronise to a source and the remaining correction to be less than 10
+milliseconds.
+
+=== Time sources
+
+[[sources]]*sources* [*-v*]::
+This 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.
++
+----
+210 Number of sources = 3
+MS Name/IP address         Stratum Poll Reach LastRx Last sample
+===============================================================================
+#* GPS0                          0   4   377    11   -479ns[ -621ns] +/-  134ns
+^? foo.example.net               2   6   377    23   -923us[ -924us] +/-   43ms
+^+ bar.example.net               1   6   377    21  -2629us[-2619us] +/-   86ms
+----
++
+The columns are as follows:
++
+*M*:::
+This indicates the mode of the source. _^_ means a server, _=_ means a peer
+and _#_ indicates a locally connected reference clock.
+*S*:::
+This column indicates the state of the source.
+* _*_ indicates the source to which *chronyd* is currently synchronised.
+* _+_ 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. It is also shown at start-up, until at least 3 samples
+  have been gathered from it.
+* _x_ indicates a clock which *chronyd* thinks is a falseticker (i.e. its
+  time is inconsistent with a majority of other sources).
+* _~_ indicates a source whose time appears to have too much variability.
+*Name/IP address*:::
+This shows the name or the IP address of the source, or reference ID for reference
+clocks.
+*Stratum*:::
+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 synchronised to a stratum 1 computer is
+at stratum 2. A computer that is synchronised to a stratum 2 computer is at
+stratum 3, and so on.
+*Poll*:::
+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. *chronyd* automatically varies
+the polling rate in response to prevailing conditions.
+*Reach*:::
+This shows the source's reachability 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
+from the last eight transmissions.
+*LastRx*:::
+This column shows how long ago the last good sample (which is shown in the next
+column) was received from the source. Measurements that failed some tests are
+ignored. This is normally in seconds. The letters _m_, _h_, _d_ or _y_ indicate
+minutes, hours, days, or years.
+*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 can be suffixed by _ns_ (indicating nanoseconds), _us_
+(indicating microseconds), _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.
+
+[[sourcestats]]*sourcestats* [*-v*]::
+The *sourcestats* command displays information about the drift rate and offset
+estimation process for each of the sources currently being examined by
+*chronyd*.
++
+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.
++
+An example report is:
++
+----
+210 Number of sources = 1
+Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
+===============================================================================
+foo.example.net            11   5   46m     -0.001      0.045      1us    25us
+----
++
+The columns are as follows:
++
+*Name/IP Address*:::
+This is the name or IP address of the NTP server (or peer) or reference ID of the
+reference clock to which the rest of the line relates.
+*NP*:::
+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.
+*NR*:::
+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, *chronyd* discards older
+samples and re-runs the regression until the number of runs becomes
+acceptable.
+*Span*:::
+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.
+*Frequency*:::
+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 10^9 slow relative to the server.
+*Freq Skew*:::
+This is the estimated error bounds on *Freq* (again in parts per million).
+*Offset*:::
+This is the estimated offset of the source.
+*Std Dev*:::
+This is the estimated sample standard deviation.
+
+[[reselect]]*reselect*::
+To avoid excessive switching between sources, *chronyd* can stay synchronised
+to a source even when it is not currently the best one among the available
+sources.
++
+The *reselect* command can be used to force *chronyd* to reselect the best
+synchronisation source.
+
+[[reselectdist]]*reselectdist* _distance_::
+The *reselectdist* command sets the reselection distance. It is equivalent to
+the <<chrony.conf.adoc#reselectdist,*reselectdist*>> directive in the
+configuration file.
+
+=== NTP sources
+
+[[activity]]*activity*::
+This command reports the number of servers and peers that are online and
+offline. If the *auto_offline* option is used in specifying some of the servers
+or peers, the *activity* command can be useful for detecting when all of them
+have entered the offline state after the network link has been disconnected.
++
+The report shows the number of servers and peers in 5 states:
++
+*online*:::
+the server or peer is currently online (i.e. assumed by *chronyd* to be reachable)
+*offline*:::
+the server or peer is currently offline (i.e. assumed by *chronyd* to be
+unreachable, and no measurements from it will be attempted.)
+*burst_online*:::
+a burst command has been initiated for the server or peer and is being
+performed; after the burst is complete, the server or peer will be returned to
+the online state.
+*burst_offline*:::
+a burst command has been initiated for the server or peer and is being
+performed; after the burst is complete, the server or peer will be returned to
+the offline state.
+*unresolved*:::
+the name of the server or peer was not resolved to an address yet; this source is
+not visible in the *sources* and *sourcestats* reports.
+
+[[ntpdata]]*ntpdata* [_address_]::
+The *ntpdata* command displays the last valid measurement and other
+NTP-specific information about the specified NTP source, or all NTP sources if
+no address was specified. An example of the output is shown below.
++
+----
+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   : 10 (1024 seconds)
+Precision       : -24 (0.000000060 seconds)
+Root delay      : 0.000015 seconds
+Root dispersion : 0.000015 seconds
+Reference ID    : 47505300 (GPS)
+Reference time  : Fri Nov 25 15:22:12 2016
+Offset          : -0.000060878 seconds
+Peer delay      : 0.000175634 seconds
+Peer dispersion : 0.000000681 seconds
+Response time   : 0.000053050 seconds
+Jitter asymmetry: +0.00
+NTP tests       : 111 111 1111
+Interleaved     : No
+Authenticated   : No
+TX timestamping : Kernel
+RX timestamping : Kernel
+Total TX        : 24
+Total RX        : 24
+Total valid RX  : 24
+----
++
+The fields are explained as follows:
++
+*Remote address*:::
+The IP address of the NTP server or peer, and the corresponding reference ID.
+*Remote port*:::
+The UDP port number to which the request was sent. The standard NTP port is
+123.
+*Local address*:::
+The local IP address which received the response, and the corresponding
+reference ID.
+*Leap status*:::
+*Version*:::
+*Mode*:::
+*Stratum*:::
+*Poll interval*:::
+*Precision*:::
+*Root delay*:::
+*Root dispersion*:::
+*Reference ID*:::
+*Reference time*:::
+The NTP values from the last valid response.
+*Offset*:::
+*Peer delay*:::
+*Peer dispersion*:::
+The measured values.
+*Response time*:::
+The time the server or peer spent in processing of the request and waiting
+before sending the response.
+*Jitter asymmetry*:::
+The estimated asymmetry of network jitter on the path to the source. The
+asymmetry can be between -0.5 and 0.5. A negative value means the delay of
+packets sent to the source is more variable than the delay of packets sent
+from the source back.
+*NTP tests*:::
+Results of RFC 5905 tests 1 through 3, 5 through 7, and tests for maximum
+delay, delay ratio, delay dev ratio, and synchronisation loop.
+*Interleaved*:::
+This shows if the response was in the interleaved mode.
+*Authenticated*:::
+This shows if the response was authenticated.
+*TX timestamping*:::
+The source of the local transmit timestamp. Valid values are _Daemon_,
+_Kernel_, and _Hardware_.
+*RX timestamping*:::
+The source of the local receive timestamp.
+*Total TX*:::
+The number of packets sent to the source.
+*Total RX*:::
+The number of all packets received from the source.
+*Total valid RX*:::
+The number of valid packets received from the source.
+
+[[add_peer]]*add peer* _address_ [_option_]...::
+The *add peer* command allows a new NTP peer to be added whilst
+*chronyd* is running.
++
+Following the words *add peer*, the syntax of the following
+parameters and options is similar to that for the
+<<chrony.conf.adoc#peer,*peer*>> directive in the configuration file.
+The following peer options can be set in the command: *port*, *minpoll*,
+*maxpoll*, *presend*, *maxdelayratio*, *maxdelay*, *key*.
++
+An example of using this command is shown below.
++
+----
+add peer foo.example.net minpoll 6 maxpoll 10 key 25
+----
+
+[[add_server]]*add server* _address_ [_option_]...::
+The *add server* command allows a new NTP server to be added whilst
+*chronyd* is running.
++
+Following the words *add server*, the syntax of the following parameters and
+options is similar to that for the <<chrony.conf.adoc#server,*server*>>
+directive in the configuration file.
+The following server options can be set in the command: *port*, *minpoll*,
+*maxpoll*, *presend*, *maxdelayratio*, *maxdelay*, *key*.
++
+An example of using this command is shown below:
++
+----
+add server foo.example.net minpoll 6 maxpoll 10 key 25
+----
+
+[[delete]]*delete* _address_::
+The *delete* command allows an NTP server or peer to be removed
+from the current set of sources.
+
+[[burst]]
+*burst* _good_/_max_ [_mask_/_masked-address_]::
+*burst* _good_/_max_ [_masked-address_/_masked-bits_]::
+*burst* _good_/_max_ [_address_]::
+The *burst* command tells *chronyd* to make a set of measurements to each of
+its NTP sources over a short duration (rather than the usual periodic
+measurements that it makes). After such a burst, *chronyd* will revert to the
+previous state for each source. This might be either online, if the source was
+being periodically measured in the normal way, or offline, if the source had
+been indicated as being offline. (A source can be switched between the online
+and offline states with the <<online,*online*>> and <<offline,*offline*>>
+commands.)
++
+The _mask_ and _masked-address_ arguments are optional, in which case *chronyd*
+will initiate a burst for all of its currently defined sources.
++
+The arguments have the following meaning and format:
++
+_good_:::
+This defines the number of good measurements that *chronyd* will want to
+obtain from each source. A measurement is good if it passes certain tests,
+for example, the round trip time to the source must be acceptable. (This
+allows *chronyd* to reject measurements that are likely to be bogus.)
+_max_:::
+This defines the maximum number of measurements that *chronyd* will attempt
+to make, even if the required number of good measurements has not been
+obtained.
+_mask_:::
+This is an IP address with which the IP address of each of *chronyd*'s
+sources is to be masked.
+_masked-address_:::
+This is an IP address. If the masked IP address of a source matches this
+value then the burst command is applied to that source.
+_masked-bits_:::
+This can be used with _masked-address_ for CIDR notation, which is a shorter
+alternative to the form with mask.
+_address_:::
+This is an IP address or a hostname. The burst command is applied only to
+that source.
+::
++
+If no _mask_ or _masked-address_ arguments are provided, every source will be
+matched.
++
+An example of the two-argument form of the command is:
++
+----
+burst 2/10
+----
++
+This will cause *chronyd* to attempt to get two good measurements from each
+source, stopping after two have been obtained, but in no event will it try more
+than ten probes to the source.
++
+Examples of the four-argument form of the command are:
++
+----
+burst 2/10 255.255.0.0/1.2.0.0
+burst 2/10 2001:db8:789a::/48
+----
++
+In the first case, the two out of ten sampling will only be applied to sources
+whose IPv4 addresses are of the form _1.2.x.y_, where _x_ and _y_ are
+arbitrary. In the second case, the sampling will be applied to sources whose
+IPv6 addresses have first 48 bits equal to _2001:db8:789a_.
++
+Example of the three-argument form of the command is:
++
+----
+burst 2/10 foo.example.net
+----
+
+[[maxdelay]]*maxdelay* _address_ _delay_::
+This allows the *maxdelay* option for one of the sources to be modified, in the
+same way as specifying the *maxdelay* option for the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
+
+[[maxdelaydevratio]]*maxdelaydevratio* _address_ _ratio_::
+This allows the *maxdelaydevratio* option for one of the sources to be
+modified, in the same way as specifying the *maxdelaydevratio* option for the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
+
+[[maxdelayratio]]*maxdelayratio* _address_ _ratio_::
+This allows the *maxdelayratio* option for one of the sources to be modified,
+in the same way as specifying the *maxdelayratio* option for the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
+
+[[maxpoll]]*maxpoll* _address_ _maxpoll_::
+The *maxpoll* command is used to modify the maximum polling interval for one of
+the current set of sources. It is equivalent to the *maxpoll* option in the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
++
+Note that the new maximum polling interval only takes effect after the next
+measurement has been made.
+
+[[minpoll]]*minpoll* _address_ _minpoll_::
+The *minpoll* command is used to modify the minimum polling interval for one of
+the current set of sources. It is equivalent to the *minpoll* option in the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
++
+Note that the new minimum polling interval only takes effect after the next
+measurement has been made.
+
+[[minstratum]]*minstratum* _address_ _minstratum_::
+The *minstratum* command is used to modify the minimum stratum for one of the
+current set of sources. It is equivalent to the *minstratum* option in the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
+
+[[offline]]
+*offline* [_address_]::
+*offline* [_masked-address_/_masked-bits_]::
+*offline* [_mask_/_masked-address_]::
+The *offline* command is used to warn *chronyd* that the network connection to
+a particular host or hosts is about to be lost, e.g. on computers with
+intermittent connection to their time sources.
++
+Another case where *offline* could be used is where a computer serves time to a
+local group of computers, and has a permanent connection to true time servers
+outside the organisation. However, the external connection is heavily loaded at
+certain times of the day and the measurements obtained are less reliable at
+those times. In this case, it is probably most useful to determine the
+gain or loss rate during the quiet periods and let the whole network coast through
+the loaded periods. The *offline* and *online* commands can be used to achieve
+this.
++
+There are four forms of the *offline* command. The first form is a wildcard,
+meaning all sources. The second form allows an IP address mask and a masked
+address to be specified. The third form uses CIDR notation. The fourth form
+uses an IP address or a hostname. These forms are illustrated below.
++
+----
+offline
+offline 255.255.255.0/1.2.3.0
+offline 2001:db8:789a::/48
+offline foo.example.net
+----
++
+The second form means that the *offline* command is to be applied to any source
+whose IPv4 address is in the _1.2.3_ subnet. (The host's address is logically
+and-ed with the mask, and if the result matches the _masked-address_ the host
+is processed.) The third form means that the command is to be applied to all
+sources whose IPv6 addresses have their first 48 bits equal to _2001:db8:789a_. The
+fourth form means that the command is to be applied only to that one source.
++
+The wildcard form of the address is equivalent to:
++
+----
+offline 0.0.0.0/0.0.0.0
+offline ::/0
+----
+
+[[online]]
+*online* [_address_]::
+*online* [_masked-address_/_masked-bits_]::
+*online* [_mask_/_masked-address_]::
+The *online* command is opposite in function to the <<offline,*offline*>>
+command. It is used to advise *chronyd* that network connectivity to a
+particular source or sources has been restored.
++
+The syntax is identical to that of the <<offline,*offline*>> command.
+
+[[onoffline]]
+*onoffline*::
+The *onoffline* command tells *chronyd* to switch all sources to the online or
+offline status according to the current network configuration. A source is
+considered online if it is possible to send requests to it, i.e. a route to the
+network is present.
+
+[[polltarget]]*polltarget* _address_ _polltarget_::
+The *polltarget* command is used to modify the poll target for one of the
+current set of sources. It is equivalent to the *polltarget* option in the
+<<chrony.conf.adoc#server,*server*>> directive in the configuration file.
+
+[[refresh]]*refresh*::
+The *refresh* command can be used to force *chronyd* to resolve the names of
+configured sources to IP addresses again, e.g. after suspending and resuming
+the machine in a different network.
++
+Sources that stop responding will be replaced with newly resolved addresses
+automatically after 8 polling intervals, but this command can still be useful
+to replace them immediately and not wait until they are marked as unreachable.
+
+=== Manual time input
+
+[[manual]]
+*manual* *on*::
+*manual* *off*::
+*manual* *delete* _index_::
+*manual* *list*::
+*manual* *reset*::
+The manual command enables and disables use of the <<settime,*settime*>>
+command, and is used to modify the behaviour of the manual clock driver.
++
+The *on* form of the command enables use of the *settime* command.
++
+The *off* form of the command disables use of the *settime* command.
++
+The *list* form of the command lists all the samples currently stored in
+*chronyd*. The output is illustrated below.
++
+----
+210 n_samples = 1
+#    Date  Time(UTC)    Slewed   Original   Residual
+====================================================
+ 0 27Jan99 22:09:20       0.00       0.97       0.00
+----
++
+The columns are as as follows:
++
+. The sample index (used for the *manual delete* command).
+. The date and time of the sample.
+. The system clock error when the timestamp was entered, adjusted to allow
+  for changes made to the system clock since.
+. The system clock error when the timestamp was entered, as it originally was
+  (without allowing for changes to the system clock since).
+. The regression residual at this point, in seconds. This allows '`outliers`'
+  to be easily spotted, so that they can be deleted using the *manual delete*
+  command.
+::
++
+The *delete* form of the command deletes a single sample. The parameter is the
+index of the sample, as shown in the first column of the output from *manual
+list*. Following deletion of the data point, the current error and drift rate
+are re-estimated from the remaining data points and the system clock trimmed if
+necessary. This option is intended to allow '`outliers`' to be discarded, i.e.
+samples where the administrator realises they have entered a very poor
+timestamp.
++
+The *reset* form of the command deletes all samples at once. The system clock
+is left running as it was before the command was entered.
+
+[[settime]]*settime* _time_::
+The *settime* command allows the current time to be entered manually, if this
+option has been configured into *chronyd*. (It can be configured either with
+the <<chrony.conf.adoc#manual,*manual*>> directive in the configuration file,
+or with the <<manual,*manual*>> command of *chronyc*.)
++
+It should be noted that the computer's sense of time will only be as accurate
+as the reference you use for providing this input (e.g. your watch), as well as
+how well you can time the press of the return key.
++
+Providing your computer's time zone is set up properly, you will be able to
+enter a local time (rather than UTC).
++
+The response to a successful *settime* command indicates the amount that the
+computer's clock was wrong. It should be apparent from this if you have entered
+the time wrongly, e.g. with the wrong time zone.
++
+The rate of drift of the system clock is estimated by a regression process
+using the entered measurement and all previous measurements entered during the
+present run of *chronyd*. However, the entered measurement is used for
+adjusting the current clock offset (rather than the estimated intercept from
+the regression, which is ignored). Contrast what happens with the
+<<manual,*manual delete*>> command, where the intercept is used to set the
+current offset (since there is no measurement that has just been entered in
+that case).
++
+The time is parsed by the public domain _getdate_ algorithm. Consequently, you
+can only specify time to the nearest second.
++
+Examples of inputs that are valid are shown below:
++
+----
+settime 16:30
+settime 16:30:05
+settime Nov 21, 2015 16:30:05
+----
++
+For a full description of getdate, see the getdate documentation
+(bundled, for example, with the source for GNU tar).
+
+=== NTP access
+
+[[accheck]]*accheck* _address_::
+This command allows you to check whether client NTP access is allowed from a
+particular host.
++
+Examples of use, showing a named host and a numeric IP address, are as follows:
++
+----
+accheck foo.example.net
+accheck 1.2.3.4
+accheck 2001:db8::1
+----
++
+This command can be used to examine the effect of a series of *allow*, *allow
+all*, *deny*, and *deny all* commands specified either via *chronyc*, or in
+*chronyd*'s configuration file.
+
+[[clients]]*clients*::
+This command shows a list of clients that have accessed the server, through
+either the NTP or command ports. It does not include accesses over
+the Unix domain command socket. There are no arguments.
++
+An example of the output is:
++
+----
+Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
+===============================================================================
+localhost                       2      0   2   -   133      15      0  -1     7
+foo.example.net                12      0   6   -    23       0      0   -     -
+----
++
+Each row shows the data for a single host. Only hosts that have passed the host
+access checks (set with the <<allow,*allow*>>, <<deny,*deny*>>,
+<<cmdallow,*cmdallow*>> and <<cmddeny,*cmddeny*>> commands or configuration
+file directives) are logged. The intervals are displayed as a power of 2 in
+seconds.
++
+The columns are as follows:
++
+. The hostname of the client.
+. The number of NTP packets received from the client.
+. The number of NTP packets dropped to limit the response rate.
+. The average interval between NTP packets.
+. The average interval between NTP packets after limiting the response rate.
+. Time since the last NTP packet was received
+. The number of command packets received from the client.
+. The number of command packets dropped to limit the response rate.
+. The average interval between command packets.
+. Time since the last command packet was received.
+
+[[serverstats]]*serverstats*::
+The *serverstats* command displays how many valid NTP and command requests
+*chronyd* as a server received from clients, how many of them were dropped to
+limit the response rate as configured by the
+<<chrony.conf.adoc#ratelimit,*ratelimit*>> and
+<<chrony.conf.adoc#cmdratelimit,*cmdratelimit*>> directives, and how many
+client log records were dropped due to the memory limit configured by the
+<<chrony.conf.adoc#clientloglimit,*clientloglimit*>> directive. An example of
+the output is shown below.
++
+----
+NTP packets received       : 1598
+NTP packets dropped        : 8
+Command packets received   : 19
+Command packets dropped    : 0
+Client log records dropped : 0
+----
+
+[[allow]]*allow* [*all*] [_subnet_]::
+The effect of the allow command is identical to the
+<<chrony.conf.adoc#allow,*allow*>> directive in the configuration file.
++
+The syntax is illustrated in the following examples:
++
+----
+allow foo.example.net
+allow all 1.2
+allow 3.4.5
+allow 6.7.8/22
+allow 6.7.8.9/22
+allow 2001:db8:789a::/48
+allow 0/0
+allow ::/0
+allow
+allow all
+----
+
+[[deny]]*deny* [*all*] [_subnet_]::
+The effect of the allow command is identical to the
+<<chrony.conf.adoc#deny,*deny*>> directive in the configuration file.
++
+The syntax is illustrated in the following examples:
++
+----
+deny foo.example.net
+deny all 1.2
+deny 3.4.5
+deny 6.7.8/22
+deny 6.7.8.9/22
+deny 2001:db8:789a::/48
+deny 0/0
+deny ::/0
+deny
+deny all
+----
+
+[[local]]
+*local* [_option_]...::
+*local* *off*::
+The *local* command allows *chronyd* to be told that it is to appear as a
+reference source, even if it is not itself properly synchronised to an external
+source. (This can be used on isolated networks, to allow one computer to be a
+master time server with the other computers slaving to it.)
++
+The first form enables the local reference mode on the host. The syntax is
+identical to the <<chrony.conf.adoc#local,*local*>> directive in the
+configuration file.
++
+The second form disables the local reference mode.
+
+[[smoothing]]*smoothing*::
+The *smoothing* command displays the current state of the NTP server time
+smoothing, which can be enabled with the
+<<chrony.conf.adoc#smoothtime,*smoothtime*>> directive. An example of the
+output is shown below.
++
+----
+Active         : Yes
+Offset         : +1.000268817 seconds
+Frequency      : -0.142859 ppm
+Wander         : -0.010000 ppm per second
+Last update    : 17.8 seconds ago
+Remaining time : 19988.4 seconds
+----
++
+The fields are explained as follows:
++
+*Active*:::
+This shows if the server time smoothing is currently active. Possible values
+are _Yes_ and _No_. If the *leaponly* option is included in the *smoothtime*
+directive, _(leap second only)_ will be shown on the line.
+*Offset*:::
+This is the current offset applied to the time sent to NTP clients. Positive
+value means the clients are getting time that's ahead of true time.
+*Frequency*:::
+The current frequency offset of the served time. Negative value means the
+time observed by clients is running slower than true time.
+*Wander*:::
+The current frequency wander of the served time. Negative value means the
+time observed by clients is slowing down.
+*Last update*:::
+This field shows how long ago the time smoothing process was updated, e.g.
+*chronyd* accumulated a new measurement.
+*Remaining time*:::
+The time it would take for the smoothing process to get to zero offset and
+frequency if there were no more updates.
+
+[[smoothtime]]
+*smoothtime* *activate*::
+*smoothtime* *reset*::
+The *smoothtime* command can be used to activate or reset the server time
+smoothing process if it is configured with the
+<<chrony.conf.adoc#smoothtime,*smoothtime*>> directive.
+
+=== Monitoring access
+
+[[cmdaccheck]]*cmdaccheck* _address_::
+This command is similar to the <<accheck,*accheck*>> command, except that it is
+used to check whether monitoring access is permitted from a named host.
++
+Examples of use are as follows:
++
+----
+cmdaccheck foo.example.net
+cmdaccheck 1.2.3.4
+cmdaccheck 2001:db8::1
+----
+
+[[cmdallow]]*cmdallow* [*all*] [_subnet_]::
+This is similar to the <<allow,*allow*>> command, except that it is used to
+allow particular hosts or subnets to use *chronyc* to monitor with *chronyd* on
+the current host.
+
+[[cmddeny]]*cmddeny* [*all*] [_subnet_]::
+This is similar to the <<deny,*deny*>> command, except that it is used to allow
+particular hosts or subnets to use *chronyc* to monitor *chronyd* on the
+current host.
+
+=== Real-time clock (RTC)
+
+[[rtcdata]]*rtcdata*::
+The *rtcdata* command displays the current RTC parameters.
++
+An example output is shown below.
++
+----
+RTC ref time (GMT) : Sat May 30 07:25:56 2015
+Number of samples  : 10
+Number of runs     : 5
+Sample span period :  549
+RTC is fast by     :    -1.632736 seconds
+RTC gains time at  :  -107.623 ppm
+----
++
+The fields have the following meaning:
++
+*RTC ref time (GMT)*:::
+This is the RTC reading the last time its error was measured.
+*Number of samples*:::
+This is the number of previous measurements being used to determine the RTC
+gain or loss rate.
+*Number of runs*:::
+This is the number of runs of residuals of the same sign following the
+regression fit for (RTC error) versus (RTC time). A value which is small
+indicates that the measurements are not well approximated by a linear model,
+and that the algorithm will tend to delete the older measurements to improve
+the fit.
+*Sample span period*:::
+This is the period that the measurements span (from the oldest to the
+newest). Without a unit the value is in seconds; suffixes _m_ for minutes,
+_h_ for hours, _d_ for days or _y_ for years can be used.
+*RTC is fast by*:::
+This is the estimate of how many seconds fast the RTC when it thought
+the time was at the reference time (above). If this value is large, you
+might (or might not) want to use the <<trimrtc,*trimrtc*>> command to bring the
+RTC into line with the system clock. (Note, a large error will not affect
+*chronyd*'s operation, unless it becomes so big as to start causing rounding
+errors.)
+*RTC gains time at*:::
+This is the amount of time gained (positive) or lost (negative) by the real
+time clock for each second that it ticks. It is measured in parts per
+million. So if the value shown was +1, suppose the RTC was exactly right when
+it crosses a particular second boundary. Then it would be 1 microsecond fast
+when it crosses its next second boundary.
+
+[[trimrtc]]*trimrtc*::
+The *trimrtc* command is used to correct the system's real-time clock (RTC) to
+the main system clock. It has no effect if the error between the two clocks is
+currently estimated at less than a second.
++
+The command takes no arguments. It performs the following steps (if the RTC is
+more than 1 second away from the system clock):
++
+. Remember the currently estimated gain or loss rate of the RTC and flush the
+  previous measurements.
+. Step the real-time clock to bring it within a second of the system clock.
+. Make several measurements to accurately determine the new offset between
+  the RTC and the system clock (i.e. the remaining fraction of a second
+  error).
+. Save the RTC parameters to the RTC file (specified with the
+  <<chrony.conf.adoc#rtcfile,*rtcfile*>> directive in the configuration file).
+::
++
+The last step is done as a precaution against the computer suffering a power
+failure before either the daemon exits or the <<writertc,*writertc*>> command
+is issued.
++
+*chronyd* will still work perfectly well both whilst operating and across
+machine reboots even if the *trimrtc* command is never used (and the RTC is
+allowed to drift away from true time). The *trimrtc* command is provided as a
+method by which it can be corrected, in a manner compatible with *chronyd*
+using it to maintain accurate time across machine reboots.
++
+The *trimrtc* command can be executed automatically by *chronyd* with the
+<<chrony.conf.adoc#rtcautotrim,*rtcautotrim*>> directive in the configuration
+file.
+
+[[writertc]]*writertc*::
+The *writertc* command writes the currently estimated error and gain or loss rate
+parameters for the RTC to the RTC file (specified with the
+<<chrony.conf.adoc#rtcfile,*rtcfile*>> directive). This information is also
+written automatically when *chronyd* is killed (by the SIGHUP, SIGINT, SIGQUIT
+or SIGTERM signals) or when the <<trimrtc,*trimrtc*>> command is issued.
+
+=== Other daemon commands
+
+[[cyclelogs]]*cyclelogs*::
+The *cyclelogs* command causes all of *chronyd*'s open log files to be closed
+and re-opened. This allows them to be renamed so that they can be periodically
+purged. An example of how to do this is shown below.
++
+----
+# mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log
+# chronyc cyclelogs
+# ls -l /var/log/chrony
+-rw-r--r--   1 root     root            0 Jun  8 18:17 measurements.log
+-rw-r--r--   1 root     root        12345 Jun  8 18:17 measurements1.log
+# rm -f measurements1.log
+----
+
+[[dump]]*dump*::
+The *dump* command causes *chronyd* to write its current history of
+measurements for each of its sources to dump files in the directory specified
+in the configuration file by the <<chrony.conf.adoc#dumpdir,*dumpdir*>>
+directive. Note that *chronyd* does this automatically when it exits. This
+command is mainly useful for inspection of the history whilst *chronyd* is
+running.
+
+[[rekey]]*rekey*::
+The *rekey* command causes *chronyd* to re-read the key file specified in the
+configuration file by the <<chrony.conf.adoc#keyfile,*keyfile*>> directive.
+
+[[rekey]]*shutdown*::
+The *shutdown* command causes *chronyd* to exit. This is equivalent to sending
+the process the SIGTERM signal.
+
+=== Client commands
+
+[[dns]]*dns* _option_::
+The *dns* command configures how hostnames and IP addresses are resolved in
+*chronyc*. IP addresses can be resolved to hostnames when printing results of
+<<sources,*sources*>>, <<sourcestats,*sourcestats*>>, <<tracking,*tracking*>>
+and <<clients,*clients*>> commands. Hostnames are resolved in commands that
+take an address as argument.
++
+There are five options:
++
+*dns -n*:::
+Disables resolving IP addresses to hostnames. Raw IP addresses will be
+displayed.
+*dns +n*:::
+Enables resolving IP addresses to hostnames. This is the default unless
+*chronyc* was started with *-n* option.
+*dns -4*:::
+Resolves hostnames only to IPv4 addresses.
+*dns -6*:::
+Resolves hostnames only to IPv6 addresses.
+*dns -46*:::
+Resolves hostnames to both address families. This is the default behaviour
+unless *chronyc* was started with the *-4* or *-6* option.
+
+[[timeout]]*timeout* _timeout_::
+The *timeout* command sets the initial timeout for *chronyc* requests in
+milliseconds. If no response is received from *chronyd*, the timeout is doubled
+and the request is resent. The maximum number of retries is configured with the
+<<retries,*retries*>> command.
++
+By default, the timeout is 1000 milliseconds.
+
+[[retries]]*retries* _retries_::
+The *retries* command sets the maximum number of retries for *chronyc* requests
+before giving up. The response timeout is controlled by the
+<<timeout,*timeout*>> command.
++
+The default is 2.
+
+[[keygen]]*keygen* [_id_ [_type_ [_bits_]]]::
+The *keygen* command generates a key that can be added to the
+key file (specified with the <<chrony.conf.adoc#keyfile,*keyfile*>> directive)
+to allow NTP authentication between server and client, or peers. The key is
+generated from the _/dev/urandom_ device and it is printed to standard output.
++
+The command has three optional arguments. The first argument is the key number
+(by default 1), which will be specified with the *key* option of the *server*
+or *peer* directives in the configuration file. The second argument is the hash
+function (by default SHA1 or MD5 if SHA1 is not available) and the third
+argument is the number of bits the key should have, between 80 and 4096 bits
+(by default 160 bits).
++
+An example is:
++
+----
+keygen 73 SHA1 256
+----
++
+which generates a 256-bit SHA1 key with number 73. The printed line should
+then be securely transferred and added to the key files on both server and
+client, or peers.
+
+[[exit]]*exit*::
+[[quit]]*quit*::
+The *exit* and *quit* commands exit from *chronyc* and return the user to the shell.
+
+[[help]]*help*::
+The *help* command displays a summary of the commands and their arguments.
+
+== SEE ALSO
+
+<<chrony.conf.adoc#,*chrony.conf(5)*>>, <<chronyd.adoc#,*chronyd(8)*>>
+
+== BUGS
+
+For instructions on how to report bugs, please visit
+https://chrony.tuxfamily.org/.
+
+== AUTHORS
+
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
diff --git a/doc/chronyc.man.in b/doc/chronyc.man.in
new file mode 100644
index 0000000..1a6ec02
--- /dev/null
+++ b/doc/chronyc.man.in
@@ -0,0 +1,1914 @@
+'\" t
+.\"     Title: chronyc
+.\"    Author: [see the "AUTHORS" section]
+.\" Generator: Asciidoctor 1.5.6.1
+.\"      Date: 2018-09-19
+.\"    Manual: User manual
+.\"    Source: chrony @CHRONY_VERSION@
+.\"  Language: English
+.\"
+.TH "CHRONYC" "1" "2018-09-19" "chrony @CHRONY_VERSION@" "User manual"
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.ss \n[.ss] 0
+.nh
+.ad l
+.de URL
+\\$2 \(laURL: \\$1 \(ra\\$3
+..
+.if \n[.g] .mso www.tmac
+.LINKSTYLE blue R < >
+.SH "NAME"
+chronyc \- command\-line interface for chrony daemon
+.SH "SYNOPSIS"
+.sp
+\fBchronyc\fP [\fIOPTION\fP]... [\fICOMMAND\fP]...
+.SH "DESCRIPTION"
+.sp
+\fBchronyc\fP is a command\-line interface program which can be used to monitor
+\fBchronyd\fP\(cqs performance and to change various operating parameters whilst it is
+running.
+.sp
+If no commands are specified on the command line, \fBchronyc\fP will expect input
+from the user. The prompt \fIchronyc>\fP will be displayed when it is being run
+from a terminal. If \fBchronyc\fP\(cqs input or output are redirected from or to a file,
+the prompt is not shown.
+.sp
+There are two ways \fBchronyc\fP can access \fBchronyd\fP. One is the Internet
+Protocol (IPv4 or IPv6) and the other is a Unix domain socket, which is
+accessible locally by the root or \fIchrony\fP user. By default, \fBchronyc\fP first
+tries to connect to the Unix domain socket. The compiled\-in default path is
+\fI@CHRONYRUNDIR@/chronyd.sock\fP. If that fails (e.g. because \fBchronyc\fP is
+running under a non\-root user), it will try to connect to 127.0.0.1 and then
+::1.
+.sp
+Only the following monitoring commands, which do not affect the behaviour of
+\fBchronyd\fP, are allowed from the network: \fBactivity\fP, \fBmanual list\fP,
+\fBrtcdata\fP, \fBsmoothing\fP, \fBsources\fP, \fBsourcestats\fP, \fBtracking\fP, \fBwaitsync\fP. The
+set of hosts from which \fBchronyd\fP will accept these commands can be configured
+with the \fBcmdallow\fP directive in the \fBchronyd\fP\(cqs
+configuration file or the \fBcmdallow\fP command in \fBchronyc\fP. By
+default, the commands are accepted only from localhost (127.0.0.1 or ::1).
+.sp
+All other commands are allowed only through the Unix domain socket. When sent
+over the network, \fBchronyd\fP will respond with a \(oqNot authorised\(cq error, even
+if it is from localhost. In chrony versions before 2.2 they were allowed
+from the network if they were authenticated with a password, but that is no
+longer supported.
+.sp
+Having full access to \fBchronyd\fP via \fBchronyc\fP is more or less equivalent to
+being able to modify the \fBchronyd\fP\(cqs configuration file and restart it.
+.SH "OPTIONS"
+.sp
+\fB\-4\fP
+.RS 4
+With this option hostnames will be resolved only to IPv4 addresses.
+.RE
+.sp
+\fB\-6\fP
+.RS 4
+With this option hostnames will be resolved only to IPv6 addresses.
+.RE
+.sp
+\fB\-n\fP
+.RS 4
+This option disables resolving of IP addresses to hostnames, e.g. to avoid slow
+DNS lookups. Long addresses will not be truncated to fit into the column.
+.RE
+.sp
+\fB\-c\fP
+.RS 4
+This option enables printing of reports in a comma\-separated values (CSV)
+format. IP addresses will not be resolved to hostnames, time will be printed as
+number of seconds since the epoch and values in seconds will not be converted
+to other units.
+.RE
+.sp
+\fB\-d\fP
+.RS 4
+This option enables printing of debugging messages if \fBchronyc\fP was compiled
+with debugging support.
+.RE
+.sp
+\fB\-m\fP
+.RS 4
+Normally, all arguments on the command line are interpreted as one command.
+With this option multiple commands can be specified. Each argument will be
+interpreted as a whole command.
+.RE
+.sp
+\fB\-h\fP \fIhost\fP
+.RS 4
+This option allows the user to specify which host (or comma\-separated list of
+addresses) running the \fBchronyd\fP program is to be contacted. This allows for
+remote monitoring, without having to connect over SSH to the other host first.
+.sp
+The default is to contact \fBchronyd\fP running on the same host where
+\fBchronyc\fP is being run.
+.RE
+.sp
+\fB\-p\fP \fIport\fP
+.RS 4
+This option allows the user to specify the UDP port number which the target
+\fBchronyd\fP is using for its monitoring connections. This defaults to 323; there
+would rarely be a need to change this.
+.RE
+.sp
+\fB\-f\fP \fIfile\fP
+.RS 4
+This option is ignored and is provided only for compatibility.
+.RE
+.sp
+\fB\-a\fP
+.RS 4
+This option is ignored and is provided only for compatibility.
+.RE
+.sp
+\fB\-v\fP
+.RS 4
+With this option \fBchronyc\fP displays its version number on the terminal and
+exits.
+.RE
+.SH "COMMANDS"
+.sp
+This section describes each of the commands available within the \fBchronyc\fP
+program.
+.SS "System clock"
+.sp
+\fBtracking\fP
+.RS 4
+The \fBtracking\fP command displays parameters about the system\(cqs clock
+performance. An example of the output is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+Reference 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
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The fields are explained as follows:
+.sp
+\fBReference ID\fP
+.RS 4
+This is the reference ID and name (or IP address) of the server to which the
+computer is currently synchronised. For IPv4 addresses, the reference ID is
+equal to the address and for IPv6 addresses it is the first 32 bits of the MD5
+sum of the address.
+.sp
+If the reference ID is \fI7F7F0101\fP and there is no name or IP address, it means
+the computer is not synchronised to any external source and that you have the
+\fIlocal\fP mode operating (via the \fBlocal\fP command in \fBchronyc\fP, or the
+\fBlocal\fP directive in the configuration file).
+.sp
+The reference ID is printed as a hexadecimal number. Note that in older
+versions it used to be printed in quad\-dotted notation and could be confused
+with an IPv4 address.
+.RE
+.sp
+\fBStratum\fP
+.RS 4
+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 (i.e. \fIfoo.example.net\fP is a
+stratum\-2 and is synchronised from a stratum\-1).
+.RE
+.sp
+\fBRef time\fP
+.RS 4
+This is the time (UTC) at which the last measurement from the reference
+source was processed.
+.RE
+.sp
+\fBSystem time\fP
+.RS 4
+In normal operation, \fBchronyd\fP by default never steps the system clock, because
+any jump in the time 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\(cqs normal speed. A consequence of this is
+that there will be a period when the system clock (as read by other programs)
+will be different from \fBchronyd\fP\(cqs estimate of the current true time (which it
+reports to NTP clients when it is operating in server mode). The value reported
+on this line is the difference due to this effect.
+.RE
+.sp
+\fBLast offset\fP
+.RS 4
+This is the estimated local offset on the last clock update.
+.RE
+.sp
+\fBRMS offset\fP
+.RS 4
+This is a long\-term average of the offset value.
+.RE
+.sp
+\fBFrequency\fP
+.RS 4
+The \(oqfrequency\(cq is the rate by which the system\(cqs clock would be wrong if
+\fBchronyd\fP was not correcting it. It is expressed in ppm (parts per million).
+For example, a value of 1 ppm would mean that when the system\(cqs clock thinks it
+has advanced 1 second, it has actually advanced by 1.000001 seconds relative to
+true time.
+.RE
+.sp
+\fBResidual freq\fP
+.RS 4
+This shows the \(oqresidual frequency\(cq 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.
+.sp
+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
+\(oqskew\(cq next) 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.
+.RE
+.sp
+\fBSkew\fP
+.RS 4
+This is the estimated error bound on the frequency.
+.RE
+.sp
+\fBRoot delay\fP
+.RS 4
+This is the total of the network path delays to the stratum\-1 computer from
+which the computer is ultimately synchronised.
+.RE
+.sp
+\fBRoot dispersion\fP
+.RS 4
+This is the total dispersion accumulated through all the computers back to
+the stratum\-1 computer from which the computer is ultimately synchronised.
+Dispersion is due to system clock resolution, statistical measurement
+variations, etc.
+.sp
+An absolute bound on the computer\(cqs clock accuracy (assuming the stratum\-1
+computer is correct) is given by:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBUpdate interval\fP
+.RS 4
+This is the interval between the last two clock updates.
+.RE
+.sp
+\fBLeap status\fP
+.RS 4
+This is the leap status, which can be \fINormal\fP, \fIInsert second\fP, \fIDelete
+second\fP or \fINot synchronised\fP.
+.RE
+.RE
+.sp
+\fBmakestep\fP, \fBmakestep\fP \fIthreshold\fP \fIlimit\fP
+.RS 4
+Normally \fBchronyd\fP will 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 might be so far adrift that this slewing process would take a
+very long time to correct the system clock.
+.sp
+The \fBmakestep\fP command can be used in this situation. There are two forms of
+the command. The first form has no parameters. It tells \fBchronyd\fP to cancel any
+remaining correction that was being slewed and jump the system clock by the
+equivalent amount, making it correct immediately.
+.sp
+The second form configures the automatic stepping, similarly to the
+\fBmakestep\fP directive. It has two parameters,
+stepping threshold (in seconds) and number of future clock updates for which
+the threshold will be active. This can be used with the \fBburst\fP
+command to quickly make a new measurement and correct the clock by stepping if
+needed, without waiting for \fBchronyd\fP to complete the measurement and update
+the clock.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+makestep 0.1 1
+burst 1/2
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+BE WARNED: Certain software will be seriously affected by such jumps in the
+system time. (That is the reason why \fBchronyd\fP uses slewing normally.)
+.RE
+.sp
+\fBmaxupdateskew\fP \fIskew\-in\-ppm\fP
+.RS 4
+This command has the same effect as the
+\fBmaxupdateskew\fP directive in the
+configuration file.
+.RE
+.sp
+\fBwaitsync\fP [\fImax\-tries\fP [\fImax\-correction\fP [\fImax\-skew\fP [\fIinterval\fP]]]]
+.RS 4
+The \fBwaitsync\fP command waits for \fBchronyd\fP to synchronise.
+.sp
+Up to four optional arguments can be specified. The first is the maximum number
+of tries before giving up and returning a non\-zero error code. When 0 is
+specified, or there are no arguments, the number of tries will not be limited.
+.sp
+The second and third arguments are the maximum allowed remaining correction of
+the system clock and the maximum allowed skew (in ppm) as reported by the
+\fBtracking\fP command in the \fBSystem time\fP and \fBSkew\fP fields. If not
+specified or zero, the value will not be checked.
+.sp
+The fourth argument is the interval specified in seconds in which the check is
+repeated. The interval is 10 seconds by default.
+.sp
+An example is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+waitsync 60 0.01
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+which will wait up to about 10 minutes (60 times 10 seconds) for \fBchronyd\fP to
+synchronise to a source and the remaining correction to be less than 10
+milliseconds.
+.RE
+.SS "Time sources"
+.sp
+\fBsources\fP [\fB\-v\fP]
+.RS 4
+This command displays information about the current time sources that \fBchronyd\fP
+is accessing.
+.sp
+The optional argument \fB\-v\fP can be specified, meaning \fIverbose\fP. In this case,
+extra caption lines are shown as a reminder of the meanings of the columns.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+210 Number of sources = 3
+MS Name/IP address         Stratum Poll Reach LastRx Last sample
+===============================================================================
+#* GPS0                          0   4   377    11   \-479ns[ \-621ns] +/\-  134ns
+^? foo.example.net               2   6   377    23   \-923us[ \-924us] +/\-   43ms
+^+ bar.example.net               1   6   377    21  \-2629us[\-2619us] +/\-   86ms
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows:
+.sp
+\fBM\fP
+.RS 4
+This indicates the mode of the source. \fI^\fP means a server, \fI=\fP means a peer
+and \fI#\fP indicates a locally connected reference clock.
+.RE
+.sp
+\fBS\fP
+.RS 4
+This column indicates the state of the source.
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+\fI*\fP indicates the source to which \fBchronyd\fP is currently synchronised.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+\fI+\fP indicates acceptable sources which are combined with the selected
+source.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+\fI\-\fP indicates acceptable sources which are excluded by the combining
+algorithm.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+\fI?\fP indicates sources to which connectivity has been lost or whose packets
+do not pass all tests. It is also shown at start\-up, until at least 3 samples
+have been gathered from it.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+\fIx\fP indicates a clock which \fBchronyd\fP thinks is a falseticker (i.e. its
+time is inconsistent with a majority of other sources).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.sp -1
+.IP \(bu 2.3
+.\}
+\fI~\fP indicates a source whose time appears to have too much variability.
+.RE
+.RE
+.sp
+\fBName/IP address\fP
+.RS 4
+This shows the name or the IP address of the source, or reference ID for reference
+clocks.
+.RE
+.sp
+\fBStratum\fP
+.RS 4
+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 synchronised to a stratum 1 computer is
+at stratum 2. A computer that is synchronised to a stratum 2 computer is at
+stratum 3, and so on.
+.RE
+.sp
+\fBPoll\fP
+.RS 4
+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. \fBchronyd\fP automatically varies
+the polling rate in response to prevailing conditions.
+.RE
+.sp
+\fBReach\fP
+.RS 4
+This shows the source\(cqs reachability 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
+from the last eight transmissions.
+.RE
+.sp
+\fBLastRx\fP
+.RS 4
+This column shows how long ago the last good sample (which is shown in the next
+column) was received from the source. Measurements that failed some tests are
+ignored. This is normally in seconds. The letters \fIm\fP, \fIh\fP, \fId\fP or \fIy\fP indicate
+minutes, hours, days, or years.
+.RE
+.sp
+\fBLast sample\fP
+.RS 4
+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 can be suffixed by \fIns\fP (indicating nanoseconds), \fIus\fP
+(indicating microseconds), \fIms\fP (indicating milliseconds), or \fIs\fP (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 \fI+/\-\fP indicator shows the margin of error in
+the measurement. Positive offsets indicate that the local clock is ahead of
+the source.
+.RE
+.RE
+.sp
+\fBsourcestats\fP [\fB\-v\fP]
+.RS 4
+The \fBsourcestats\fP command displays information about the drift rate and offset
+estimation process for each of the sources currently being examined by
+\fBchronyd\fP.
+.sp
+The optional argument \fB\-v\fP can be specified, meaning \fIverbose\fP. In this case,
+extra caption lines are shown as a reminder of the meanings of the columns.
+.sp
+An example report is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+210 Number of sources = 1
+Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
+===============================================================================
+foo.example.net            11   5   46m     \-0.001      0.045      1us    25us
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as follows:
+.sp
+\fBName/IP Address\fP
+.RS 4
+This is the name or IP address of the NTP server (or peer) or reference ID of the
+reference clock to which the rest of the line relates.
+.RE
+.sp
+\fBNP\fP
+.RS 4
+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.
+.RE
+.sp
+\fBNR\fP
+.RS 4
+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, \fBchronyd\fP discards older
+samples and re\-runs the regression until the number of runs becomes
+acceptable.
+.RE
+.sp
+\fBSpan\fP
+.RS 4
+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.
+.RE
+.sp
+\fBFrequency\fP
+.RS 4
+This is the estimated residual frequency for the server, in parts per
+million. In this case, the computer\(cqs clock is estimated to be running 1 part
+in 10^9 slow relative to the server.
+.RE
+.sp
+\fBFreq Skew\fP
+.RS 4
+This is the estimated error bounds on \fBFreq\fP (again in parts per million).
+.RE
+.sp
+\fBOffset\fP
+.RS 4
+This is the estimated offset of the source.
+.RE
+.sp
+\fBStd Dev\fP
+.RS 4
+This is the estimated sample standard deviation.
+.RE
+.RE
+.sp
+\fBreselect\fP
+.RS 4
+To avoid excessive switching between sources, \fBchronyd\fP can stay synchronised
+to a source even when it is not currently the best one among the available
+sources.
+.sp
+The \fBreselect\fP command can be used to force \fBchronyd\fP to reselect the best
+synchronisation source.
+.RE
+.sp
+\fBreselectdist\fP \fIdistance\fP
+.RS 4
+The \fBreselectdist\fP command sets the reselection distance. It is equivalent to
+the \fBreselectdist\fP directive in the
+configuration file.
+.RE
+.SS "NTP sources"
+.sp
+\fBactivity\fP
+.RS 4
+This command reports the number of servers and peers that are online and
+offline. If the \fBauto_offline\fP option is used in specifying some of the servers
+or peers, the \fBactivity\fP command can be useful for detecting when all of them
+have entered the offline state after the network link has been disconnected.
+.sp
+The report shows the number of servers and peers in 5 states:
+.sp
+\fBonline\fP
+.RS 4
+the server or peer is currently online (i.e. assumed by \fBchronyd\fP to be reachable)
+.RE
+.sp
+\fBoffline\fP
+.RS 4
+the server or peer is currently offline (i.e. assumed by \fBchronyd\fP to be
+unreachable, and no measurements from it will be attempted.)
+.RE
+.sp
+\fBburst_online\fP
+.RS 4
+a burst command has been initiated for the server or peer and is being
+performed; after the burst is complete, the server or peer will be returned to
+the online state.
+.RE
+.sp
+\fBburst_offline\fP
+.RS 4
+a burst command has been initiated for the server or peer and is being
+performed; after the burst is complete, the server or peer will be returned to
+the offline state.
+.RE
+.sp
+\fBunresolved\fP
+.RS 4
+the name of the server or peer was not resolved to an address yet; this source is
+not visible in the \fBsources\fP and \fBsourcestats\fP reports.
+.RE
+.RE
+.sp
+\fBntpdata\fP [\fIaddress\fP]
+.RS 4
+The \fBntpdata\fP command displays the last valid measurement and other
+NTP\-specific information about the specified NTP source, or all NTP sources if
+no address was specified. An example of the output is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+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   : 10 (1024 seconds)
+Precision       : \-24 (0.000000060 seconds)
+Root delay      : 0.000015 seconds
+Root dispersion : 0.000015 seconds
+Reference ID    : 47505300 (GPS)
+Reference time  : Fri Nov 25 15:22:12 2016
+Offset          : \-0.000060878 seconds
+Peer delay      : 0.000175634 seconds
+Peer dispersion : 0.000000681 seconds
+Response time   : 0.000053050 seconds
+Jitter asymmetry: +0.00
+NTP tests       : 111 111 1111
+Interleaved     : No
+Authenticated   : No
+TX timestamping : Kernel
+RX timestamping : Kernel
+Total TX        : 24
+Total RX        : 24
+Total valid RX  : 24
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The fields are explained as follows:
+.sp
+\fBRemote address\fP
+.RS 4
+The IP address of the NTP server or peer, and the corresponding reference ID.
+.RE
+.sp
+\fBRemote port\fP
+.RS 4
+The UDP port number to which the request was sent. The standard NTP port is
+123.
+.RE
+.sp
+\fBLocal address\fP
+.RS 4
+The local IP address which received the response, and the corresponding
+reference ID.
+.RE
+.sp
+\fBLeap status\fP, \fBVersion\fP, \fBMode\fP, \fBStratum\fP, \fBPoll interval\fP, \fBPrecision\fP, \fBRoot delay\fP, \fBRoot dispersion\fP, \fBReference ID\fP, \fBReference time\fP
+.RS 4
+The NTP values from the last valid response.
+.RE
+.sp
+\fBOffset\fP, \fBPeer delay\fP, \fBPeer dispersion\fP
+.RS 4
+The measured values.
+.RE
+.sp
+\fBResponse time\fP
+.RS 4
+The time the server or peer spent in processing of the request and waiting
+before sending the response.
+.RE
+.sp
+\fBJitter asymmetry\fP
+.RS 4
+The estimated asymmetry of network jitter on the path to the source. The
+asymmetry can be between \-0.5 and 0.5. A negative value means the delay of
+packets sent to the source is more variable than the delay of packets sent
+from the source back.
+.RE
+.sp
+\fBNTP tests\fP
+.RS 4
+Results of RFC 5905 tests 1 through 3, 5 through 7, and tests for maximum
+delay, delay ratio, delay dev ratio, and synchronisation loop.
+.RE
+.sp
+\fBInterleaved\fP
+.RS 4
+This shows if the response was in the interleaved mode.
+.RE
+.sp
+\fBAuthenticated\fP
+.RS 4
+This shows if the response was authenticated.
+.RE
+.sp
+\fBTX timestamping\fP
+.RS 4
+The source of the local transmit timestamp. Valid values are \fIDaemon\fP,
+\fIKernel\fP, and \fIHardware\fP.
+.RE
+.sp
+\fBRX timestamping\fP
+.RS 4
+The source of the local receive timestamp.
+.RE
+.sp
+\fBTotal TX\fP
+.RS 4
+The number of packets sent to the source.
+.RE
+.sp
+\fBTotal RX\fP
+.RS 4
+The number of all packets received from the source.
+.RE
+.sp
+\fBTotal valid RX\fP
+.RS 4
+The number of valid packets received from the source.
+.RE
+.RE
+.sp
+\fBadd peer\fP \fIaddress\fP [\fIoption\fP]...
+.RS 4
+The \fBadd peer\fP command allows a new NTP peer to be added whilst
+\fBchronyd\fP is running.
+.sp
+Following the words \fBadd peer\fP, the syntax of the following
+parameters and options is similar to that for the
+\fBpeer\fP directive in the configuration file.
+The following peer options can be set in the command: \fBport\fP, \fBminpoll\fP,
+\fBmaxpoll\fP, \fBpresend\fP, \fBmaxdelayratio\fP, \fBmaxdelay\fP, \fBkey\fP.
+.sp
+An example of using this command is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+add peer foo.example.net minpoll 6 maxpoll 10 key 25
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBadd server\fP \fIaddress\fP [\fIoption\fP]...
+.RS 4
+The \fBadd server\fP command allows a new NTP server to be added whilst
+\fBchronyd\fP is running.
+.sp
+Following the words \fBadd server\fP, the syntax of the following parameters and
+options is similar to that for the \fBserver\fP
+directive in the configuration file.
+The following server options can be set in the command: \fBport\fP, \fBminpoll\fP,
+\fBmaxpoll\fP, \fBpresend\fP, \fBmaxdelayratio\fP, \fBmaxdelay\fP, \fBkey\fP.
+.sp
+An example of using this command is shown below:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+add server foo.example.net minpoll 6 maxpoll 10 key 25
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBdelete\fP \fIaddress\fP
+.RS 4
+The \fBdelete\fP command allows an NTP server or peer to be removed
+from the current set of sources.
+.RE
+.sp
+\fBburst\fP \fIgood\fP/\fImax\fP [\fImask\fP/\fImasked\-address\fP], \fBburst\fP \fIgood\fP/\fImax\fP [\fImasked\-address\fP/\fImasked\-bits\fP], \fBburst\fP \fIgood\fP/\fImax\fP [\fIaddress\fP]
+.RS 4
+The \fBburst\fP command tells \fBchronyd\fP to make a set of measurements to each of
+its NTP sources over a short duration (rather than the usual periodic
+measurements that it makes). After such a burst, \fBchronyd\fP will revert to the
+previous state for each source. This might be either online, if the source was
+being periodically measured in the normal way, or offline, if the source had
+been indicated as being offline. (A source can be switched between the online
+and offline states with the \fBonline\fP and \fBoffline\fP
+commands.)
+.sp
+The \fImask\fP and \fImasked\-address\fP arguments are optional, in which case \fBchronyd\fP
+will initiate a burst for all of its currently defined sources.
+.sp
+The arguments have the following meaning and format:
+.sp
+\fIgood\fP
+.RS 4
+This defines the number of good measurements that \fBchronyd\fP will want to
+obtain from each source. A measurement is good if it passes certain tests,
+for example, the round trip time to the source must be acceptable. (This
+allows \fBchronyd\fP to reject measurements that are likely to be bogus.)
+.RE
+.sp
+\fImax\fP
+.RS 4
+This defines the maximum number of measurements that \fBchronyd\fP will attempt
+to make, even if the required number of good measurements has not been
+obtained.
+.RE
+.sp
+\fImask\fP
+.RS 4
+This is an IP address with which the IP address of each of \fBchronyd\fP\(cqs
+sources is to be masked.
+.RE
+.sp
+\fImasked\-address\fP
+.RS 4
+This is an IP address. If the masked IP address of a source matches this
+value then the burst command is applied to that source.
+.RE
+.sp
+\fImasked\-bits\fP
+.RS 4
+This can be used with \fImasked\-address\fP for CIDR notation, which is a shorter
+alternative to the form with mask.
+.RE
+.sp
+\fIaddress\fP
+.RS 4
+This is an IP address or a hostname. The burst command is applied only to
+that source.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+If no \fImask\fP or \fImasked\-address\fP arguments are provided, every source will be
+matched.
+.sp
+An example of the two\-argument form of the command is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+burst 2/10
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This will cause \fBchronyd\fP to attempt to get two good measurements from each
+source, stopping after two have been obtained, but in no event will it try more
+than ten probes to the source.
+.sp
+Examples of the four\-argument form of the command are:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+burst 2/10 255.255.0.0/1.2.0.0
+burst 2/10 2001:db8:789a::/48
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+In the first case, the two out of ten sampling will only be applied to sources
+whose IPv4 addresses are of the form \fI1.2.x.y\fP, where \fIx\fP and \fIy\fP are
+arbitrary. In the second case, the sampling will be applied to sources whose
+IPv6 addresses have first 48 bits equal to \fI2001:db8:789a\fP.
+.sp
+Example of the three\-argument form of the command is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+burst 2/10 foo.example.net
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBmaxdelay\fP \fIaddress\fP \fIdelay\fP
+.RS 4
+This allows the \fBmaxdelay\fP option for one of the sources to be modified, in the
+same way as specifying the \fBmaxdelay\fP option for the
+\fBserver\fP directive in the configuration file.
+.RE
+.sp
+\fBmaxdelaydevratio\fP \fIaddress\fP \fIratio\fP
+.RS 4
+This allows the \fBmaxdelaydevratio\fP option for one of the sources to be
+modified, in the same way as specifying the \fBmaxdelaydevratio\fP option for the
+\fBserver\fP directive in the configuration file.
+.RE
+.sp
+\fBmaxdelayratio\fP \fIaddress\fP \fIratio\fP
+.RS 4
+This allows the \fBmaxdelayratio\fP option for one of the sources to be modified,
+in the same way as specifying the \fBmaxdelayratio\fP option for the
+\fBserver\fP directive in the configuration file.
+.RE
+.sp
+\fBmaxpoll\fP \fIaddress\fP \fImaxpoll\fP
+.RS 4
+The \fBmaxpoll\fP command is used to modify the maximum polling interval for one of
+the current set of sources. It is equivalent to the \fBmaxpoll\fP option in the
+\fBserver\fP directive in the configuration file.
+.sp
+Note that the new maximum polling interval only takes effect after the next
+measurement has been made.
+.RE
+.sp
+\fBminpoll\fP \fIaddress\fP \fIminpoll\fP
+.RS 4
+The \fBminpoll\fP command is used to modify the minimum polling interval for one of
+the current set of sources. It is equivalent to the \fBminpoll\fP option in the
+\fBserver\fP directive in the configuration file.
+.sp
+Note that the new minimum polling interval only takes effect after the next
+measurement has been made.
+.RE
+.sp
+\fBminstratum\fP \fIaddress\fP \fIminstratum\fP
+.RS 4
+The \fBminstratum\fP command is used to modify the minimum stratum for one of the
+current set of sources. It is equivalent to the \fBminstratum\fP option in the
+\fBserver\fP directive in the configuration file.
+.RE
+.sp
+\fBoffline\fP [\fIaddress\fP], \fBoffline\fP [\fImasked\-address\fP/\fImasked\-bits\fP], \fBoffline\fP [\fImask\fP/\fImasked\-address\fP]
+.RS 4
+The \fBoffline\fP command is used to warn \fBchronyd\fP that the network connection to
+a particular host or hosts is about to be lost, e.g. on computers with
+intermittent connection to their time sources.
+.sp
+Another case where \fBoffline\fP could be used is where a computer serves time to a
+local group of computers, and has a permanent connection to true time servers
+outside the organisation. However, the external connection is heavily loaded at
+certain times of the day and the measurements obtained are less reliable at
+those times. In this case, it is probably most useful to determine the
+gain or loss rate during the quiet periods and let the whole network coast through
+the loaded periods. The \fBoffline\fP and \fBonline\fP commands can be used to achieve
+this.
+.sp
+There are four forms of the \fBoffline\fP command. The first form is a wildcard,
+meaning all sources. The second form allows an IP address mask and a masked
+address to be specified. The third form uses CIDR notation. The fourth form
+uses an IP address or a hostname. These forms are illustrated below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+offline
+offline 255.255.255.0/1.2.3.0
+offline 2001:db8:789a::/48
+offline foo.example.net
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The second form means that the \fBoffline\fP command is to be applied to any source
+whose IPv4 address is in the \fI1.2.3\fP subnet. (The host\(cqs address is logically
+and\-ed with the mask, and if the result matches the \fImasked\-address\fP the host
+is processed.) The third form means that the command is to be applied to all
+sources whose IPv6 addresses have their first 48 bits equal to \fI2001:db8:789a\fP. The
+fourth form means that the command is to be applied only to that one source.
+.sp
+The wildcard form of the address is equivalent to:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+offline 0.0.0.0/0.0.0.0
+offline ::/0
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBonline\fP [\fIaddress\fP], \fBonline\fP [\fImasked\-address\fP/\fImasked\-bits\fP], \fBonline\fP [\fImask\fP/\fImasked\-address\fP]
+.RS 4
+The \fBonline\fP command is opposite in function to the \fBoffline\fP
+command. It is used to advise \fBchronyd\fP that network connectivity to a
+particular source or sources has been restored.
+.sp
+The syntax is identical to that of the \fBoffline\fP command.
+.RE
+.sp
+\fBonoffline\fP
+.RS 4
+The \fBonoffline\fP command tells \fBchronyd\fP to switch all sources to the online or
+offline status according to the current network configuration. A source is
+considered online if it is possible to send requests to it, i.e. a route to the
+network is present.
+.RE
+.sp
+\fBpolltarget\fP \fIaddress\fP \fIpolltarget\fP
+.RS 4
+The \fBpolltarget\fP command is used to modify the poll target for one of the
+current set of sources. It is equivalent to the \fBpolltarget\fP option in the
+\fBserver\fP directive in the configuration file.
+.RE
+.sp
+\fBrefresh\fP
+.RS 4
+The \fBrefresh\fP command can be used to force \fBchronyd\fP to resolve the names of
+configured sources to IP addresses again, e.g. after suspending and resuming
+the machine in a different network.
+.sp
+Sources that stop responding will be replaced with newly resolved addresses
+automatically after 8 polling intervals, but this command can still be useful
+to replace them immediately and not wait until they are marked as unreachable.
+.RE
+.SS "Manual time input"
+.sp
+\fBmanual\fP \fBon\fP, \fBmanual\fP \fBoff\fP, \fBmanual\fP \fBdelete\fP \fIindex\fP, \fBmanual\fP \fBlist\fP, \fBmanual\fP \fBreset\fP
+.RS 4
+The manual command enables and disables use of the \fBsettime\fP
+command, and is used to modify the behaviour of the manual clock driver.
+.sp
+The \fBon\fP form of the command enables use of the \fBsettime\fP command.
+.sp
+The \fBoff\fP form of the command disables use of the \fBsettime\fP command.
+.sp
+The \fBlist\fP form of the command lists all the samples currently stored in
+\fBchronyd\fP. The output is illustrated below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+210 n_samples = 1
+#    Date  Time(UTC)    Slewed   Original   Residual
+====================================================
+ 0 27Jan99 22:09:20       0.00       0.97       0.00
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The columns are as as follows:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The sample index (used for the \fBmanual delete\fP command).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The date and time of the sample.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The system clock error when the timestamp was entered, adjusted to allow
+for changes made to the system clock since.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+The system clock error when the timestamp was entered, as it originally was
+(without allowing for changes to the system clock since).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+The regression residual at this point, in seconds. This allows \(oqoutliers\(cq
+to be easily spotted, so that they can be deleted using the \fBmanual delete\fP
+command.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+The \fBdelete\fP form of the command deletes a single sample. The parameter is the
+index of the sample, as shown in the first column of the output from \fBmanual
+list\fP. Following deletion of the data point, the current error and drift rate
+are re\-estimated from the remaining data points and the system clock trimmed if
+necessary. This option is intended to allow \(oqoutliers\(cq to be discarded, i.e.
+samples where the administrator realises they have entered a very poor
+timestamp.
+.sp
+The \fBreset\fP form of the command deletes all samples at once. The system clock
+is left running as it was before the command was entered.
+.RE
+.sp
+\fBsettime\fP \fItime\fP
+.RS 4
+The \fBsettime\fP command allows the current time to be entered manually, if this
+option has been configured into \fBchronyd\fP. (It can be configured either with
+the \fBmanual\fP directive in the configuration file,
+or with the \fBmanual\fP command of \fBchronyc\fP.)
+.sp
+It should be noted that the computer\(cqs sense of time will only be as accurate
+as the reference you use for providing this input (e.g. your watch), as well as
+how well you can time the press of the return key.
+.sp
+Providing your computer\(cqs time zone is set up properly, you will be able to
+enter a local time (rather than UTC).
+.sp
+The response to a successful \fBsettime\fP command indicates the amount that the
+computer\(cqs clock was wrong. It should be apparent from this if you have entered
+the time wrongly, e.g. with the wrong time zone.
+.sp
+The rate of drift of the system clock is estimated by a regression process
+using the entered measurement and all previous measurements entered during the
+present run of \fBchronyd\fP. However, the entered measurement is used for
+adjusting the current clock offset (rather than the estimated intercept from
+the regression, which is ignored). Contrast what happens with the
+\fBmanual delete\fP command, where the intercept is used to set the
+current offset (since there is no measurement that has just been entered in
+that case).
+.sp
+The time is parsed by the public domain \fIgetdate\fP algorithm. Consequently, you
+can only specify time to the nearest second.
+.sp
+Examples of inputs that are valid are shown below:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+settime 16:30
+settime 16:30:05
+settime Nov 21, 2015 16:30:05
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+For a full description of getdate, see the getdate documentation
+(bundled, for example, with the source for GNU tar).
+.RE
+.SS "NTP access"
+.sp
+\fBaccheck\fP \fIaddress\fP
+.RS 4
+This command allows you to check whether client NTP access is allowed from a
+particular host.
+.sp
+Examples of use, showing a named host and a numeric IP address, are as follows:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+accheck foo.example.net
+accheck 1.2.3.4
+accheck 2001:db8::1
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+This command can be used to examine the effect of a series of \fBallow\fP, \fBallow
+all\fP, \fBdeny\fP, and \fBdeny all\fP commands specified either via \fBchronyc\fP, or in
+\fBchronyd\fP\(cqs configuration file.
+.RE
+.sp
+\fBclients\fP
+.RS 4
+This command shows a list of clients that have accessed the server, through
+either the NTP or command ports. It does not include accesses over
+the Unix domain command socket. There are no arguments.
+.sp
+An example of the output is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
+===============================================================================
+localhost                       2      0   2   \-   133      15      0  \-1     7
+foo.example.net                12      0   6   \-    23       0      0   \-     \-
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+Each row shows the data for a single host. Only hosts that have passed the host
+access checks (set with the \fBallow\fP, \fBdeny\fP,
+\fBcmdallow\fP and \fBcmddeny\fP commands or configuration
+file directives) are logged. The intervals are displayed as a power of 2 in
+seconds.
+.sp
+The columns are as follows:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The hostname of the client.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The number of NTP packets received from the client.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The number of NTP packets dropped to limit the response rate.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+The average interval between NTP packets.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 5." 4.2
+.\}
+The average interval between NTP packets after limiting the response rate.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 6." 4.2
+.\}
+Time since the last NTP packet was received
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 7." 4.2
+.\}
+The number of command packets received from the client.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 8." 4.2
+.\}
+The number of command packets dropped to limit the response rate.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 9." 4.2
+.\}
+The average interval between command packets.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 10.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 10." 4.2
+.\}
+Time since the last command packet was received.
+.RE
+.RE
+.sp
+\fBserverstats\fP
+.RS 4
+The \fBserverstats\fP command displays how many valid NTP and command requests
+\fBchronyd\fP as a server received from clients, how many of them were dropped to
+limit the response rate as configured by the
+\fBratelimit\fP and
+\fBcmdratelimit\fP directives, and how many
+client log records were dropped due to the memory limit configured by the
+\fBclientloglimit\fP directive. An example of
+the output is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+NTP packets received       : 1598
+NTP packets dropped        : 8
+Command packets received   : 19
+Command packets dropped    : 0
+Client log records dropped : 0
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBallow\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+The effect of the allow command is identical to the
+\fBallow\fP directive in the configuration file.
+.sp
+The syntax is illustrated in the following examples:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+allow foo.example.net
+allow all 1.2
+allow 3.4.5
+allow 6.7.8/22
+allow 6.7.8.9/22
+allow 2001:db8:789a::/48
+allow 0/0
+allow ::/0
+allow
+allow all
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBdeny\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+The effect of the allow command is identical to the
+\fBdeny\fP directive in the configuration file.
+.sp
+The syntax is illustrated in the following examples:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+deny foo.example.net
+deny all 1.2
+deny 3.4.5
+deny 6.7.8/22
+deny 6.7.8.9/22
+deny 2001:db8:789a::/48
+deny 0/0
+deny ::/0
+deny
+deny all
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBlocal\fP [\fIoption\fP]..., \fBlocal\fP \fBoff\fP
+.RS 4
+The \fBlocal\fP command allows \fBchronyd\fP to be told that it is to appear as a
+reference source, even if it is not itself properly synchronised to an external
+source. (This can be used on isolated networks, to allow one computer to be a
+master time server with the other computers slaving to it.)
+.sp
+The first form enables the local reference mode on the host. The syntax is
+identical to the \fBlocal\fP directive in the
+configuration file.
+.sp
+The second form disables the local reference mode.
+.RE
+.sp
+\fBsmoothing\fP
+.RS 4
+The \fBsmoothing\fP command displays the current state of the NTP server time
+smoothing, which can be enabled with the
+\fBsmoothtime\fP directive. An example of the
+output is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+Active         : Yes
+Offset         : +1.000268817 seconds
+Frequency      : \-0.142859 ppm
+Wander         : \-0.010000 ppm per second
+Last update    : 17.8 seconds ago
+Remaining time : 19988.4 seconds
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The fields are explained as follows:
+.sp
+\fBActive\fP
+.RS 4
+This shows if the server time smoothing is currently active. Possible values
+are \fIYes\fP and \fINo\fP. If the \fBleaponly\fP option is included in the \fBsmoothtime\fP
+directive, \fI(leap second only)\fP will be shown on the line.
+.RE
+.sp
+\fBOffset\fP
+.RS 4
+This is the current offset applied to the time sent to NTP clients. Positive
+value means the clients are getting time that\(cqs ahead of true time.
+.RE
+.sp
+\fBFrequency\fP
+.RS 4
+The current frequency offset of the served time. Negative value means the
+time observed by clients is running slower than true time.
+.RE
+.sp
+\fBWander\fP
+.RS 4
+The current frequency wander of the served time. Negative value means the
+time observed by clients is slowing down.
+.RE
+.sp
+\fBLast update\fP
+.RS 4
+This field shows how long ago the time smoothing process was updated, e.g.
+\fBchronyd\fP accumulated a new measurement.
+.RE
+.sp
+\fBRemaining time\fP
+.RS 4
+The time it would take for the smoothing process to get to zero offset and
+frequency if there were no more updates.
+.RE
+.RE
+.sp
+\fBsmoothtime\fP \fBactivate\fP, \fBsmoothtime\fP \fBreset\fP
+.RS 4
+The \fBsmoothtime\fP command can be used to activate or reset the server time
+smoothing process if it is configured with the
+\fBsmoothtime\fP directive.
+.RE
+.SS "Monitoring access"
+.sp
+\fBcmdaccheck\fP \fIaddress\fP
+.RS 4
+This command is similar to the \fBaccheck\fP command, except that it is
+used to check whether monitoring access is permitted from a named host.
+.sp
+Examples of use are as follows:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+cmdaccheck foo.example.net
+cmdaccheck 1.2.3.4
+cmdaccheck 2001:db8::1
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBcmdallow\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+This is similar to the \fBallow\fP command, except that it is used to
+allow particular hosts or subnets to use \fBchronyc\fP to monitor with \fBchronyd\fP on
+the current host.
+.RE
+.sp
+\fBcmddeny\fP [\fBall\fP] [\fIsubnet\fP]
+.RS 4
+This is similar to the \fBdeny\fP command, except that it is used to allow
+particular hosts or subnets to use \fBchronyc\fP to monitor \fBchronyd\fP on the
+current host.
+.RE
+.SS "Real\-time clock (RTC)"
+.sp
+\fBrtcdata\fP
+.RS 4
+The \fBrtcdata\fP command displays the current RTC parameters.
+.sp
+An example output is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+RTC ref time (GMT) : Sat May 30 07:25:56 2015
+Number of samples  : 10
+Number of runs     : 5
+Sample span period :  549
+RTC is fast by     :    \-1.632736 seconds
+RTC gains time at  :  \-107.623 ppm
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The fields have the following meaning:
+.sp
+\fBRTC ref time (GMT)\fP
+.RS 4
+This is the RTC reading the last time its error was measured.
+.RE
+.sp
+\fBNumber of samples\fP
+.RS 4
+This is the number of previous measurements being used to determine the RTC
+gain or loss rate.
+.RE
+.sp
+\fBNumber of runs\fP
+.RS 4
+This is the number of runs of residuals of the same sign following the
+regression fit for (RTC error) versus (RTC time). A value which is small
+indicates that the measurements are not well approximated by a linear model,
+and that the algorithm will tend to delete the older measurements to improve
+the fit.
+.RE
+.sp
+\fBSample span period\fP
+.RS 4
+This is the period that the measurements span (from the oldest to the
+newest). Without a unit the value is in seconds; suffixes \fIm\fP for minutes,
+\fIh\fP for hours, \fId\fP for days or \fIy\fP for years can be used.
+.RE
+.sp
+\fBRTC is fast by\fP
+.RS 4
+This is the estimate of how many seconds fast the RTC when it thought
+the time was at the reference time (above). If this value is large, you
+might (or might not) want to use the \fBtrimrtc\fP command to bring the
+RTC into line with the system clock. (Note, a large error will not affect
+\fBchronyd\fP\(cqs operation, unless it becomes so big as to start causing rounding
+errors.)
+.RE
+.sp
+\fBRTC gains time at\fP
+.RS 4
+This is the amount of time gained (positive) or lost (negative) by the real
+time clock for each second that it ticks. It is measured in parts per
+million. So if the value shown was +1, suppose the RTC was exactly right when
+it crosses a particular second boundary. Then it would be 1 microsecond fast
+when it crosses its next second boundary.
+.RE
+.RE
+.sp
+\fBtrimrtc\fP
+.RS 4
+The \fBtrimrtc\fP command is used to correct the system\(cqs real\-time clock (RTC) to
+the main system clock. It has no effect if the error between the two clocks is
+currently estimated at less than a second.
+.sp
+The command takes no arguments. It performs the following steps (if the RTC is
+more than 1 second away from the system clock):
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+Remember the currently estimated gain or loss rate of the RTC and flush the
+previous measurements.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+Step the real\-time clock to bring it within a second of the system clock.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+Make several measurements to accurately determine the new offset between
+the RTC and the system clock (i.e. the remaining fraction of a second
+error).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+Save the RTC parameters to the RTC file (specified with the
+\fBrtcfile\fP directive in the configuration file).
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+The last step is done as a precaution against the computer suffering a power
+failure before either the daemon exits or the \fBwritertc\fP command
+is issued.
+.sp
+\fBchronyd\fP will still work perfectly well both whilst operating and across
+machine reboots even if the \fBtrimrtc\fP command is never used (and the RTC is
+allowed to drift away from true time). The \fBtrimrtc\fP command is provided as a
+method by which it can be corrected, in a manner compatible with \fBchronyd\fP
+using it to maintain accurate time across machine reboots.
+.sp
+The \fBtrimrtc\fP command can be executed automatically by \fBchronyd\fP with the
+\fBrtcautotrim\fP directive in the configuration
+file.
+.RE
+.sp
+\fBwritertc\fP
+.RS 4
+The \fBwritertc\fP command writes the currently estimated error and gain or loss rate
+parameters for the RTC to the RTC file (specified with the
+\fBrtcfile\fP directive). This information is also
+written automatically when \fBchronyd\fP is killed (by the SIGHUP, SIGINT, SIGQUIT
+or SIGTERM signals) or when the \fBtrimrtc\fP command is issued.
+.RE
+.SS "Other daemon commands"
+.sp
+\fBcyclelogs\fP
+.RS 4
+The \fBcyclelogs\fP command causes all of \fBchronyd\fP\(cqs open log files to be closed
+and re\-opened. This allows them to be renamed so that they can be periodically
+purged. An example of how to do this is shown below.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+# mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log
+# chronyc cyclelogs
+# ls \-l /var/log/chrony
+\-rw\-r\-\-r\-\-   1 root     root            0 Jun  8 18:17 measurements.log
+\-rw\-r\-\-r\-\-   1 root     root        12345 Jun  8 18:17 measurements1.log
+# rm \-f measurements1.log
+.fi
+.if n \{\
+.RE
+.\}
+.RE
+.sp
+\fBdump\fP
+.RS 4
+The \fBdump\fP command causes \fBchronyd\fP to write its current history of
+measurements for each of its sources to dump files in the directory specified
+in the configuration file by the \fBdumpdir\fP
+directive. Note that \fBchronyd\fP does this automatically when it exits. This
+command is mainly useful for inspection of the history whilst \fBchronyd\fP is
+running.
+.RE
+.sp
+\fBrekey\fP
+.RS 4
+The \fBrekey\fP command causes \fBchronyd\fP to re\-read the key file specified in the
+configuration file by the \fBkeyfile\fP directive.
+.RE
+.sp
+\fBshutdown\fP
+.RS 4
+The \fBshutdown\fP command causes \fBchronyd\fP to exit. This is equivalent to sending
+the process the SIGTERM signal.
+.RE
+.SS "Client commands"
+.sp
+\fBdns\fP \fIoption\fP
+.RS 4
+The \fBdns\fP command configures how hostnames and IP addresses are resolved in
+\fBchronyc\fP. IP addresses can be resolved to hostnames when printing results of
+\fBsources\fP, \fBsourcestats\fP, \fBtracking\fP
+and \fBclients\fP commands. Hostnames are resolved in commands that
+take an address as argument.
+.sp
+There are five options:
+.sp
+\fBdns \-n\fP
+.RS 4
+Disables resolving IP addresses to hostnames. Raw IP addresses will be
+displayed.
+.RE
+.sp
+\fBdns +n\fP
+.RS 4
+Enables resolving IP addresses to hostnames. This is the default unless
+\fBchronyc\fP was started with \fB\-n\fP option.
+.RE
+.sp
+\fBdns \-4\fP
+.RS 4
+Resolves hostnames only to IPv4 addresses.
+.RE
+.sp
+\fBdns \-6\fP
+.RS 4
+Resolves hostnames only to IPv6 addresses.
+.RE
+.sp
+\fBdns \-46\fP
+.RS 4
+Resolves hostnames to both address families. This is the default behaviour
+unless \fBchronyc\fP was started with the \fB\-4\fP or \fB\-6\fP option.
+.RE
+.RE
+.sp
+\fBtimeout\fP \fItimeout\fP
+.RS 4
+The \fBtimeout\fP command sets the initial timeout for \fBchronyc\fP requests in
+milliseconds. If no response is received from \fBchronyd\fP, the timeout is doubled
+and the request is resent. The maximum number of retries is configured with the
+\fBretries\fP command.
+.sp
+By default, the timeout is 1000 milliseconds.
+.RE
+.sp
+\fBretries\fP \fIretries\fP
+.RS 4
+The \fBretries\fP command sets the maximum number of retries for \fBchronyc\fP requests
+before giving up. The response timeout is controlled by the
+\fBtimeout\fP command.
+.sp
+The default is 2.
+.RE
+.sp
+\fBkeygen\fP [\fIid\fP [\fItype\fP [\fIbits\fP]]]
+.RS 4
+The \fBkeygen\fP command generates a key that can be added to the
+key file (specified with the \fBkeyfile\fP directive)
+to allow NTP authentication between server and client, or peers. The key is
+generated from the \fI/dev/urandom\fP device and it is printed to standard output.
+.sp
+The command has three optional arguments. The first argument is the key number
+(by default 1), which will be specified with the \fBkey\fP option of the \fBserver\fP
+or \fBpeer\fP directives in the configuration file. The second argument is the hash
+function (by default SHA1 or MD5 if SHA1 is not available) and the third
+argument is the number of bits the key should have, between 80 and 4096 bits
+(by default 160 bits).
+.sp
+An example is:
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+keygen 73 SHA1 256
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+which generates a 256\-bit SHA1 key with number 73. The printed line should
+then be securely transferred and added to the key files on both server and
+client, or peers.
+.RE
+.sp
+\fBexit\fP, \fBquit\fP
+.RS 4
+The \fBexit\fP and \fBquit\fP commands exit from \fBchronyc\fP and return the user to the shell.
+.RE
+.sp
+\fBhelp\fP
+.RS 4
+The \fBhelp\fP command displays a summary of the commands and their arguments.
+.RE
+.SH "SEE ALSO"
+.sp
+\fBchrony.conf(5)\fP, \fBchronyd(8)\fP
+.SH "BUGS"
+.sp
+For instructions on how to report bugs, please visit
+.URL "https://chrony.tuxfamily.org/" "" "."
+.SH "AUTHORS"
+.sp
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
\ No newline at end of file
diff --git a/doc/chronyd.adoc b/doc/chronyd.adoc
new file mode 100644
index 0000000..d3b78a4
--- /dev/null
+++ b/doc/chronyd.adoc
@@ -0,0 +1,186 @@
+// This file is part of chrony
+//
+// Copyright (C) Richard P. Curnow  1997-2003
+// Copyright (C) Miroslav Lichvar  2009-2017
+//
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of version 2 of the GNU General Public License as
+// published by the Free Software Foundation.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+
+= chronyd(8)
+:doctype: manpage
+:man manual: System Administration
+:man source: chrony @CHRONY_VERSION@
+
+== NAME
+
+chronyd - chrony daemon
+
+== SYNOPSIS
+
+*chronyd* [_OPTION_]... [_DIRECTIVE_]...
+
+== DESCRIPTION
+
+*chronyd* is a daemon for synchronisation of the system clock. It can
+synchronise the clock with NTP servers, reference clocks (e.g. a GPS receiver),
+and manual input using wristwatch and keyboard via *chronyc*. It can also
+operate as an NTPv4 (RFC 5905) server and peer to provide a time service to
+other computers in the network.
+
+If no configuration directives are specified on the command line, *chronyd*
+will read them from a configuration file. The compiled-in default location of
+the file is _@SYSCONFDIR@/chrony.conf_.
+
+Information messages and warnings will be logged to syslog.
+
+== OPTIONS
+
+*-4*::
+With this option hostnames will be resolved only to IPv4 addresses and only
+IPv4 sockets will be created.
+
+*-6*::
+With this option hostnames will be resolved only to IPv6 addresses and only
+IPv6 sockets will be created.
+
+*-f* _file_::
+This option can be used to specify an alternate location for the configuration
+file (default _@SYSCONFDIR@/chrony.conf_).
+
+*-n*::
+When run in this mode, the program will not detach itself from the terminal.
+
+*-d*::
+When run in this mode, the program will not detach itself from the terminal,
+and all messages will be written to the terminal instead of syslog. When
+*chronyd* was compiled with debugging support, this option can be used twice to
+print also debugging messages.
+
+*-l* _file_::
+This option specifies a file which should be used for logging instead of syslog
+or terminal.
+
+*-q*::
+When run in this mode, *chronyd* will set the system clock once and exit. It
+will not detach from the terminal.
+
+*-Q*::
+This option is similar to the *-q* option, except it only prints the offset
+without making any corrections of the clock and it allows *chronyd* to be
+started without root privileges.
+
+*-r*::
+This option will try to reload and then delete files containing sample
+histories for each of the servers and reference clocks being used. The
+files are expected to be in the directory specified by the
+<<chrony.conf.adoc#dumpdir,*dumpdir*>>
+directive in the configuration file. This option is useful if you want to stop
+and restart *chronyd* briefly for any reason, e.g. to install a new version.
+However, it should be used only on systems where the kernel can maintain clock
+compensation whilst not under *chronyd*'s control (i.e. Linux, FreeBSD, NetBSD,
+Solaris, and macOS 10.13 or later).
+
+*-R*::
+When this option is used, the <<chrony.conf.adoc#initstepslew,*initstepslew*>>
+directive and the <<chrony.conf.adoc#makestep,*makestep*>> directive used with
+a positive limit will be ignored. This option is useful when restarting
+*chronyd* and can be used in conjunction with the *-r* option.
+
+*-s*::
+This option will set the system clock from the computer's real-time clock (RTC)
+or to the last modification time of the file specified by the
+<<chrony.conf.adoc#driftfile,*driftfile*>> directive. Real-time clocks are
+supported only on Linux.
++
+If used in conjunction with the *-r* flag, *chronyd* will attempt to preserve
+the old samples after setting the system clock from the RTC. This can be used
+to allow *chronyd* to perform long term averaging of the gain or loss rate
+across system reboots, and is useful for systems with intermittent access to
+network that are shut down when not in use. For this to work well, it relies
+on *chronyd* having been able to determine accurate statistics for the
+difference between the RTC and system clock last time the computer was on.
++
+If the last modification time of the drift file is later than both the current
+time and the RTC time, the system time will be set to it to restore the time
+when *chronyd* was previously stopped. This is useful on computers that have no
+RTC or the RTC is broken (e.g. it has no battery).
+
+*-t* _timeout_::
+This option sets a timeout (in seconds) after which *chronyd* will exit. If the
+clock is not synchronised, it will exit with a non-zero status. This is useful
+with the *-q* or *-Q* option to shorten the maximum time waiting for
+measurements, or with the *-r* option to limit the time when *chronyd* is
+running, but still allow it to adjust the frequency of the system clock.
+
+*-u* _user_::
+This option sets the name of the system user to which *chronyd* will switch
+after start in order to drop root privileges. It overrides the
+<<chrony.conf.adoc#user,*user*>> directive (default _@DEFAULT_USER@_).
++
+On Linux, *chronyd* needs to be compiled with support for the *libcap* library.
+On macOS, FreeBSD, NetBSD and Solaris *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.
+
+*-F* _level_::
+This option configures a system call filter when *chronyd* is compiled with
+support for the Linux secure computing (seccomp) facility. In level 1 the
+process is killed when a forbidden system call is made, in level -1 the SIGSYS
+signal is thrown instead and in level 0 the filter is disabled (default 0).
++
+It's recommended to enable the filter only when it's 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 may make different
+system calls. If the filter is missing some system call, *chronyd* could be
+killed even in normal operation.
+
+*-P* _priority_::
+On Linux, this option will select the SCHED_FIFO real-time scheduler at the
+specified priority (which must be between 0 and 100). On macOS, this option
+must have either a value of 0 (the default) to disable the thread time
+constraint policy or 1 for the policy to be enabled. Other systems do not
+support this option.
+
+*-m*::
+This option will lock *chronyd* into RAM so that it will never be paged out.
+This mode is only supported on Linux.
+
+*-x*::
+This option disables the control of the system clock. *chronyd* will not try to
+make any adjustments of the clock. It will assume the clock is free running and
+still track its offset and frequency relative to the estimated true time. This
+option allows *chronyd* to run without the capability to adjust or set the
+system clock (e.g. in some containers) in order to operate as an NTP server. It
+is not recommended to run *chronyd* (with or without *-x*) when another process
+is controlling the system clock.
+
+*-v*::
+With this option *chronyd* will print version number to the terminal and exit.
+
+== FILES
+
+_@SYSCONFDIR@/chrony.conf_
+
+== SEE ALSO
+
+<<chronyc.adoc#,*chronyc(1)*>>, <<chrony.conf.adoc#,*chrony.conf(5)*>>
+
+== BUGS
+
+For instructions on how to report bugs, please visit
+https://chrony.tuxfamily.org/.
+
+== AUTHORS
+
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
diff --git a/doc/chronyd.man.in b/doc/chronyd.man.in
new file mode 100644
index 0000000..6342f1b
--- /dev/null
+++ b/doc/chronyd.man.in
@@ -0,0 +1,211 @@
+'\" t
+.\"     Title: chronyd
+.\"    Author: [see the "AUTHORS" section]
+.\" Generator: Asciidoctor 1.5.6.1
+.\"      Date: 2018-09-19
+.\"    Manual: System Administration
+.\"    Source: chrony @CHRONY_VERSION@
+.\"  Language: English
+.\"
+.TH "CHRONYD" "8" "2018-09-19" "chrony @CHRONY_VERSION@" "System Administration"
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.ss \n[.ss] 0
+.nh
+.ad l
+.de URL
+\\$2 \(laURL: \\$1 \(ra\\$3
+..
+.if \n[.g] .mso www.tmac
+.LINKSTYLE blue R < >
+.SH "NAME"
+chronyd \- chrony daemon
+.SH "SYNOPSIS"
+.sp
+\fBchronyd\fP [\fIOPTION\fP]... [\fIDIRECTIVE\fP]...
+.SH "DESCRIPTION"
+.sp
+\fBchronyd\fP is a daemon for synchronisation of the system clock. It can
+synchronise the clock with NTP servers, reference clocks (e.g. a GPS receiver),
+and manual input using wristwatch and keyboard via \fBchronyc\fP. It can also
+operate as an NTPv4 (RFC 5905) server and peer to provide a time service to
+other computers in the network.
+.sp
+If no configuration directives are specified on the command line, \fBchronyd\fP
+will read them from a configuration file. The compiled\-in default location of
+the file is \fI@SYSCONFDIR@/chrony.conf\fP.
+.sp
+Information messages and warnings will be logged to syslog.
+.SH "OPTIONS"
+.sp
+\fB\-4\fP
+.RS 4
+With this option hostnames will be resolved only to IPv4 addresses and only
+IPv4 sockets will be created.
+.RE
+.sp
+\fB\-6\fP
+.RS 4
+With this option hostnames will be resolved only to IPv6 addresses and only
+IPv6 sockets will be created.
+.RE
+.sp
+\fB\-f\fP \fIfile\fP
+.RS 4
+This option can be used to specify an alternate location for the configuration
+file (default \fI@SYSCONFDIR@/chrony.conf\fP).
+.RE
+.sp
+\fB\-n\fP
+.RS 4
+When run in this mode, the program will not detach itself from the terminal.
+.RE
+.sp
+\fB\-d\fP
+.RS 4
+When run in this mode, the program will not detach itself from the terminal,
+and all messages will be written to the terminal instead of syslog. When
+\fBchronyd\fP was compiled with debugging support, this option can be used twice to
+print also debugging messages.
+.RE
+.sp
+\fB\-l\fP \fIfile\fP
+.RS 4
+This option specifies a file which should be used for logging instead of syslog
+or terminal.
+.RE
+.sp
+\fB\-q\fP
+.RS 4
+When run in this mode, \fBchronyd\fP will set the system clock once and exit. It
+will not detach from the terminal.
+.RE
+.sp
+\fB\-Q\fP
+.RS 4
+This option is similar to the \fB\-q\fP option, except it only prints the offset
+without making any corrections of the clock and it allows \fBchronyd\fP to be
+started without root privileges.
+.RE
+.sp
+\fB\-r\fP
+.RS 4
+This option will try to reload and then delete files containing sample
+histories for each of the servers and reference clocks being used. The
+files are expected to be in the directory specified by the
+\fBdumpdir\fP
+directive in the configuration file. This option is useful if you want to stop
+and restart \fBchronyd\fP briefly for any reason, e.g. to install a new version.
+However, it should be used only on systems where the kernel can maintain clock
+compensation whilst not under \fBchronyd\fP\(cqs control (i.e. Linux, FreeBSD, NetBSD,
+Solaris, and macOS 10.13 or later).
+.RE
+.sp
+\fB\-R\fP
+.RS 4
+When this option is used, the \fBinitstepslew\fP
+directive and the \fBmakestep\fP directive used with
+a positive limit will be ignored. This option is useful when restarting
+\fBchronyd\fP and can be used in conjunction with the \fB\-r\fP option.
+.RE
+.sp
+\fB\-s\fP
+.RS 4
+This option will set the system clock from the computer\(cqs real\-time clock (RTC)
+or to the last modification time of the file specified by the
+\fBdriftfile\fP directive. Real\-time clocks are
+supported only on Linux.
+.sp
+If used in conjunction with the \fB\-r\fP flag, \fBchronyd\fP will attempt to preserve
+the old samples after setting the system clock from the RTC. This can be used
+to allow \fBchronyd\fP to perform long term averaging of the gain or loss rate
+across system reboots, and is useful for systems with intermittent access to
+network that are shut down when not in use. For this to work well, it relies
+on \fBchronyd\fP having been able to determine accurate statistics for the
+difference between the RTC and system clock last time the computer was on.
+.sp
+If the last modification time of the drift file is later than both the current
+time and the RTC time, the system time will be set to it to restore the time
+when \fBchronyd\fP was previously stopped. This is useful on computers that have no
+RTC or the RTC is broken (e.g. it has no battery).
+.RE
+.sp
+\fB\-t\fP \fItimeout\fP
+.RS 4
+This option sets a timeout (in seconds) after which \fBchronyd\fP will exit. If the
+clock is not synchronised, it will exit with a non\-zero status. This is useful
+with the \fB\-q\fP or \fB\-Q\fP option to shorten the maximum time waiting for
+measurements, or with the \fB\-r\fP option to limit the time when \fBchronyd\fP is
+running, but still allow it to adjust the frequency of the system clock.
+.RE
+.sp
+\fB\-u\fP \fIuser\fP
+.RS 4
+This option sets the name of the system user to which \fBchronyd\fP will switch
+after start in order to drop root privileges. It overrides the
+\fBuser\fP directive (default \fI@DEFAULT_USER@\fP).
+.sp
+On Linux, \fBchronyd\fP needs to be compiled with support for the \fBlibcap\fP library.
+On macOS, FreeBSD, NetBSD and Solaris \fBchronyd\fP 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.
+.RE
+.sp
+\fB\-F\fP \fIlevel\fP
+.RS 4
+This option configures a system call filter when \fBchronyd\fP is compiled with
+support for the Linux secure computing (seccomp) facility. In level 1 the
+process is killed when a forbidden system call is made, in level \-1 the SIGSYS
+signal is thrown instead and in level 0 the filter is disabled (default 0).
+.sp
+It\(cqs recommended to enable the filter only when it\(cqs known to work on the
+version of the system where \fBchrony\fP is installed as the filter needs to allow
+also system calls made from libraries that \fBchronyd\fP is using (e.g. libc) and
+different versions or implementations of the libraries may make different
+system calls. If the filter is missing some system call, \fBchronyd\fP could be
+killed even in normal operation.
+.RE
+.sp
+\fB\-P\fP \fIpriority\fP
+.RS 4
+On Linux, this option will select the SCHED_FIFO real\-time scheduler at the
+specified priority (which must be between 0 and 100). On macOS, this option
+must have either a value of 0 (the default) to disable the thread time
+constraint policy or 1 for the policy to be enabled. Other systems do not
+support this option.
+.RE
+.sp
+\fB\-m\fP
+.RS 4
+This option will lock \fBchronyd\fP into RAM so that it will never be paged out.
+This mode is only supported on Linux.
+.RE
+.sp
+\fB\-x\fP
+.RS 4
+This option disables the control of the system clock. \fBchronyd\fP will not try to
+make any adjustments of the clock. It will assume the clock is free running and
+still track its offset and frequency relative to the estimated true time. This
+option allows \fBchronyd\fP to run without the capability to adjust or set the
+system clock (e.g. in some containers) in order to operate as an NTP server. It
+is not recommended to run \fBchronyd\fP (with or without \fB\-x\fP) when another process
+is controlling the system clock.
+.RE
+.sp
+\fB\-v\fP
+.RS 4
+With this option \fBchronyd\fP will print version number to the terminal and exit.
+.RE
+.SH "FILES"
+.sp
+\fI@SYSCONFDIR@/chrony.conf\fP
+.SH "SEE ALSO"
+.sp
+\fBchronyc(1)\fP, \fBchrony.conf(5)\fP
+.SH "BUGS"
+.sp
+For instructions on how to report bugs, please visit
+.URL "https://chrony.tuxfamily.org/" "" "."
+.SH "AUTHORS"
+.sp
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
\ No newline at end of file
diff --git a/doc/faq.adoc b/doc/faq.adoc
new file mode 100644
index 0000000..b07c550
--- /dev/null
+++ b/doc/faq.adoc
@@ -0,0 +1,547 @@
+// This file is part of chrony
+//
+// Copyright (C) Richard P. Curnow  1997-2003
+// Copyright (C) Miroslav Lichvar  2014-2016
+//
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of version 2 of the GNU General Public License as
+// published by the Free Software Foundation.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+
+= Frequently Asked Questions
+:toc:
+:numbered:
+
+== `chrony` compared to other programs
+
+=== How does `chrony` compare to `ntpd`?
+
+`chronyd` was designed to work well in a wide range of conditions and it can
+usually synchronise the system clock faster and with better time accuracy. It
+doesn't 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's a virtual machine), or you want to use NTP
+on an isolated network with no hardware reference clocks in sight, `chrony`
+will probably work much better for you.
+
+For a more detailed comparison of features and performance, see the
+https://chrony.tuxfamily.org/comparison.html[comparison page] on the `chrony`
+website.
+
+== Configuration issues
+
+=== 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 `server` or `pool` directive. The `pool`
+directive can be used for names that resolve to multiple addresses. For good
+reliability the client should have at least three servers. The `iburst` option
+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 `driftfile` directive.
+
+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
+that.
+
+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's 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
+macOS.
+
+If you want to use public NTP servers from the
+http://www.pool.ntp.org/[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
+----
+
+=== How do I make an NTP server from an NTP client?
+
+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.
+
+=== I have several computers on a LAN. Should be all clients of an external server?
+
+The best configuration is usually to make one computer the server, with
+the others as clients of it. Add a `local` directive 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.
+
+=== Must I specify servers by IP address if DNS is not available on chronyd start?
+
+No. Starting from version 1.25, `chronyd` will keep trying to resolve
+the names specified by the `server`, `pool`, and `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.
+
+=== How can I make `chronyd` more secure?
+
+If you don't need to serve time to NTP clients or peers, you can add `port 0`
+to the _chrony.conf_ file to completely disable the NTP server functionality
+and prevent NTP requests from reaching `chronyd`. Starting from version 2.0,
+the NTP server port is open only when client access is allowed by the `allow`
+directive or command, an NTP peer is configured, or the `broadcast` directive
+is used.
+
+If you don't need to use `chronyc` remotely, you can add the following
+directives to the configuration file to bind the command sockets to the
+loopback interface. This is done by default since version 2.0.
+
+----
+bindcmdaddress 127.0.0.1
+bindcmdaddress ::1
+----
+
+If you don't need to use `chronyc` at all or you need to run `chronyc` only
+under the root or _chrony_ user (which can access `chronyd` through a Unix
+domain socket since version 2.2), you can disable the internet command sockets
+completely by adding `cmdport 0` to the configuration file.
+
+You can specify an unprivileged user with the `-u` option, or the `user`
+directive in the _chrony.conf_ file, to which `chronyd` will switch after start
+in order to drop root privileges. The configure script has a `--with-user`
+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.
+
+Also, if `chronyd` is compiled with support for the Linux secure computing
+(seccomp) facility, you can enable a system call filter with the `-F` option.
+It will significantly reduce the kernel attack surface and possibly prevent
+kernel exploits from the `chronyd` process if it's compromised. It's
+recommended to enable the filter only when it's 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 may make different system calls.
+If the filter is missing some system call, `chronyd` could be killed even in
+normal operation.
+
+=== 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's 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
+accurate.
+
+There are also useful options which can be set in the `server` directive, they
+are `minpoll`, `maxpoll`, `polltarget`, `maxdelay`, `maxdelayratio`,
+`maxdelaydevratio`, and `xleave`.
+
+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 may significantly improve the accuracy of the system
+clock.
+
+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 may 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
+synchronisation. 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 `chronyd`),
+the `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 may be possible. For example:
+
+----
+server ntp.local minpoll 0 maxpoll 0 xleave
+hwtimestamp eth0
+----
+
+If it is acceptable for NTP clients in the network to send requests at an
+excessive rate, a sub-second polling interval may 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
+----
+
+=== Does `chronyd` have an ntpdate mode?
+
+Yes. With the `-q` option `chronyd` will set the system clock once and exit.
+With the `-Q` option it will print the measured offset without setting the
+clock. If you don't want to use a configuration file, NTP servers can be
+specified on the command line. For example:
+
+----
+# chronyd -q 'pool pool.ntp.org iburst'
+----
+
+=== Can `chronyd` be configured to control the clock like `ntpd`?
+
+It is not possible to perfectly emulate `ntpd`, but there are some options that
+can configure `chronyd` to behave more like `ntpd`.
+
+In the following example the `minsamples` directive slows down the response to
+changes in the frequency and offset of the clock. The `maxslewrate` and
+`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 `maxclockerror` directive
+increases the minimum dispersion rate.
+
+----
+minsamples 32
+maxslewrate 500
+corrtimeratio 100
+maxdrift 500
+makestep 0.128 -1
+maxchange 1000 1 1
+maxclockerror 15
+----
+
+=== What happened to the `commandkey` and `generatecommandkey` directives?
+
+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.
+
+== Computer is not synchronising
+
+This is the most common problem. There are a number of reasons, see the
+following questions.
+
+=== Behind a firewall?
+
+Check the `Reach` value printed by the ``chronyc``'s `sources` command. If it's
+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 may be blocked. Try using a tool like `wireshark` or `tcpdump` to see
+if you're getting any responses from the server.
+
+When `chronyd` is receiving responses from the servers, the output of the
+`sources` command issued few minutes after `chronyd` start might look like
+this:
+
+----
+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
+----
+
+=== Are NTP servers specified with the `offline` option?
+
+Check that you're using ``chronyc``'s `online` and `offline` commands
+appropriately. The `activity` command prints the number of sources that are
+currently online and offline. For example:
+
+----
+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
+----
+
+=== Is `chronyd` allowed to step the system clock?
+
+By default, `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
+``chronyc``'s `tracking` command is the remaining correction that needs to be
+applied to the system clock.
+
+The `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's 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 may be
+necessary to allow the step on any clock update. The example above would change
+to
+
+----
+makestep 1 -1
+----
+
+=== 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 may show a valid
+measurement, but the server is not selected for synchronisation. You can check
+the root dispersion of the server with the ``chronyc``'s `ntpdata` command.
+
+The `maxdistance` value needs to be increased in _chrony.conf_ to enable
+synchronisation to such a server. For example:
+
+----
+maxdistance 16.0
+----
+
+=== 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 `refclock` directive,
+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 `offset`
+option.
+
+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.
+
+== Issues with `chronyc`
+
+=== I keep getting the error `506 Cannot talk to daemon`
+
+When accessing `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 `bindcmdaddress`
+directive. This isn't necessary for localhost.
+
+Perhaps `chronyd` is not running. Try using the `ps` command (e.g. on Linux,
+`ps -auxw`) to see if it's running. Or try `netstat -a` and see if the ports
+123/udp and 323/udp are listening. If `chronyd` is not running, you may 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 port
+323/udp. You need to amend the firewall configuration in this case.
+
+=== I keep getting the error `501 Not authorised`
+
+Since version 2.2, the `password` command doesn't do anything and `chronyc`
+needs to run locally under the root or _chrony_ user, which are allowed to
+access the ``chronyd``'s Unix domain command socket.
+
+With older versions, you need to authenticate with the `password` command first
+or use the `-a` option to authenticate automatically on start. The
+configuration file needs to specify a file which contains keys (`keyfile`
+directive) and which key in the key file should be used for `chronyc`
+authentication (`commandkey` directive).
+
+=== Why does `chronyc tracking` always print an IPv4 address as reference ID?
+
+The reference ID is a 32-bit value and in versions before 3.0 it was printed in
+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 `refid`
+option in the `refclock` directive.
+
+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 `-n`
+option to disable resolving of IP addresses and read the second field (printed
+in parentheses) on the `Reference ID` line.
+
+=== Is the `chronyc` / `chronyd` protocol documented anywhere?
+
+Only by the source code. See _cmdmon.c_ (`chronyd` side) and _client.c_
+(`chronyc` side).
+
+== Real-time clock issues
+
+=== 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 doesn't 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 `chronyd` to
+monitor the rate at which the RTC gains or loses time. When `chronyd` is
+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's not strictly necessary if its only purpose is to set the system clock when
+`chronyd` is started on boot. See the documentation for details.
+
+=== I want to use ``chronyd``'s RTC support. Must I disable `hwclock`?
+
+The `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's important to disable `hwclock` in the shutdown
+procedure. If you don't, it will over-write the RTC with a new value, unknown
+to `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 `chronyd`
+is started after it has run.
+
+=== 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
+* an `rtcfile` directive in your _chrony.conf_ file
+
+=== I get `Could not open /dev/rtc, Device or resource busy` in my syslog file
+
+Some other program running on the system may be using the device.
+
+=== 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
+time when `chronyd` was previously stopped. The initial system time will be
+increasing across reboots and applications started after `chronyd` will not
+observe backward steps.
+
+== NTP-specific issues
+
+=== Can `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 the mode may be useful to 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
+use the `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.
+
+=== Can `chronyd` transmit broadcast NTP packets?
+
+Yes, the `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's not supported in `chronyd`, see the previous question).
+
+=== Can `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 `offset`
+option for all time sources in the _chrony.conf_ file.
+
+=== What happens if the network connection is dropped without using ``chronyc``'s `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
+offline, `chronyd` would make new measurements immediately after issuing the
+`online` command.
+
+Unless the network connection lasts only few minutes (less than the maximum
+polling interval), the delay is usually not a problem, and it may be acceptable
+to keep all sources online all the time.
+
+== Operating systems
+
+=== Does `chrony` support Windows?
+
+No. The `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
+service.
+
+=== 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.
diff --git a/doc/installation.adoc b/doc/installation.adoc
new file mode 100644
index 0000000..eea9088
--- /dev/null
+++ b/doc/installation.adoc
@@ -0,0 +1,217 @@
+// This file is part of chrony
+//
+// Copyright (C) Richard P. Curnow  1997-2003
+// Copyright (C) Miroslav Lichvar  2009-2016
+//
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of version 2 of the GNU General Public License as
+// published by the Free Software Foundation.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this program; if not, write to the Free Software Foundation, Inc.,
+// 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+
+= Installation
+
+The software is distributed as source code which has to be compiled. The source
+code is supplied in the form of a gzipped tar file, which unpacks to a
+subdirectory identifying the name and version of the program.
+
+After unpacking the source code, change directory into it, and type
+
+----
+./configure
+----
+
+This is a shell script that automatically determines the system type. There is
+an optional parameter `--prefix`, which indicates the directory tree where the
+software should be installed. For example,
+
+----
+./configure --prefix=/opt/free
+----
+
+will install the `chronyd` daemon into `/opt/free/sbin` and the `chronyc`
+control program into `/opt/free/bin`. The default value for the prefix is
+`/usr/local`.
+
+The `configure` script assumes you want to use `gcc` as your compiler. If you
+want to use a different compiler, you can configure this way:
+
+----
+CC=cc ./configure --prefix=/opt/free
+----
+
+for Bourne-family shells, or
+
+----
+setenv CC cc
+setenv CFLAGS -O
+./configure --prefix=/opt/free
+----
+
+for C-family shells.
+
+If the software cannot (yet) be built on your system, an error message will be
+shown. Otherwise, `Makefile` will be generated.
+
+On Linux, if development files for the libcap library are available, `chronyd`
+will be built with support for dropping root privileges. On other systems no
+extra library is needed. The default user which `chronyd` should run as can be
+specified with the `--with-user` option of the `configure` script.
+
+If development files for the POSIX threads library are available, `chronyd`
+will be built with support for asynchronous resolving of hostnames specified in
+the `server`, `peer`, and `pool` directives. This allows `chronyd` operating as
+a server to respond to client requests when resolving a hostname. If you don't
+want to enable the support, specify the `--disable-asyncdns` flag to
+`configure`.
+
+If development files for the https://www.lysator.liu.se/~nisse/nettle/[Nettle],
+https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS[NSS], or
+http://www.libtom.net/LibTomCrypt/[libtomcrypt] library are available,
+`chronyd` will be built with support for other cryptographic hash functions
+than MD5, which can be used for NTP authentication with a symmetric key. If you
+don't want to enable the support, specify the `--disable-sechash` flag to
+`configure`.
+
+If development files for the editline or readline library are available,
+`chronyc` will be built with line editing support. If you don't want this,
+specify the `--disable-readline` flag to `configure`.
+
+If a `timepps.h` header is available (e.g. from the
+http://linuxpps.org[LinuxPPS project]), `chronyd` will be built with PPS API
+reference clock driver. If the header is installed in a location that isn't
+normally searched by the compiler, you can add it to the searched locations by
+setting the `CPPFLAGS` variable to `-I/path/to/timepps`.
+
+The `--help` option can be specified to `configure` to print all options
+supported by the script.
+
+Now type
+
+----
+make
+----
+
+to build the programs.
+
+If you want to build the manual in HTML, type
+
+----
+make docs
+----
+
+Once the programs have been successfully compiled, they need to be installed in
+their target locations. This step normally needs to be performed by the
+superuser, and requires the following command to be entered.
+
+----
+make install
+----
+
+This will install the binaries and man pages.
+
+To install the HTML version of the manual, enter the command
+
+----
+make install-docs
+----
+
+Now that the software is successfully installed, the next step is to set up a
+configuration file. The default location of the file is _/etc/chrony.conf_.
+Several examples of configuration with comments are included in the examples
+directory. Suppose you want to use public NTP servers from the pool.ntp.org
+project as your time reference. A minimal useful configuration file could be
+
+----
+pool pool.ntp.org iburst
+makestep 1.0 3
+rtcsync
+----
+
+Then, `chronyd` can be run. For security reasons, it's recommended to create an
+unprivileged user for `chronyd` and specify it with the `-u` command-line
+option or the `user` directive in the configuration file, or set the default
+user with the `--with-user` configure option before building.
+
+== Support for system call filtering
+
+`chronyd` can be built with support for the Linux secure computing (seccomp)
+facility. This requires development files for the
+https://github.com/seccomp/libseccomp[libseccomp] library and the
+`--enable-scfilter` option specified to `configure`. The `-F` option of
+`chronyd` will enable a system call filter, which should significantly reduce
+the kernel attack surface and possibly prevent kernel exploits from `chronyd`
+if it is compromised.
+
+== Support for line editing libraries
+
+`chronyc` can be built with support for line editing, this allows you to use
+the cursor keys to replay and edit old commands. Two libraries are supported
+which provide such functionality, editline and GNU readline.
+
+Please note that readline since version 6.0 is licensed under GPLv3+ which is
+incompatible with chrony's license GPLv2. You should use editline instead if
+you don't want to use older readline versions.
+
+The `configure` script will automatically enable the line editing support if
+one of the supported libraries is available. If they are both available, the
+editline library will be used.
+
+If you don't want to use it (in which case `chronyc` will use a minimal command
+line interface), invoke `configure` like this:
+
+----
+./configure --disable-readline other-options...
+----
+
+If you have editline, readline or ncurses installed in locations that aren't
+normally searched by the compiler and linker, you need to use extra options:
+
+`--with-readline-includes=directory_name`::
+  This defines the name of the directory above the one where `readline.h` is.
+  `readline.h` is assumed to be in `editline` or `readline` subdirectory of the
+  named directory.
+
+`--with-readline-library=directory_name`::
+  This defines the directory containing the `libedit.a` or `libedit.so` file,
+  or `libreadline.a` or `libreadline.so` file.
+
+`--with-ncurses-library=directory_name`::
+  This defines the directory containing the `libncurses.a` or `libncurses.so`
+  file.
+
+== Extra options for package builders
+
+The `configure` and `make` procedures have some extra options that may be
+useful if you are building a distribution package for `chrony`.
+
+The `--mandir=DIR` option to `configure` specifies an installation directory
+for the man pages. This overrides the `man` subdirectory of the argument to the
+`--prefix` option.
+
+----
+./configure --prefix=/usr --mandir=/usr/share/man
+----
+
+to set both options together.
+
+The final option is the `DESTDIR` option to the `make` command. For example,
+you could use the commands
+
+----
+./configure --prefix=/usr --mandir=/usr/share/man
+make all docs
+make install DESTDIR=./tmp
+cd tmp
+tar cvf - . | gzip -9 > chrony.tar.gz
+----
+
+to build a package. When untarred within the root directory, this will install
+the files to the intended final locations.