Adding upstream version 4.5.upstream/4.5

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

1 files changed, 5043 insertions, 0 deletions

diff --git a/doc/chrony.conf.man.in b/doc/chrony.conf.man.in
new file mode 100644
index 0000000..66d2358
--- /dev/null
+++ b/doc/chrony.conf.man.in
@@ -0,0 +1,5043 @@
+'\" t
+.\"     Title: chrony.conf
+.\"    Author: [see the "AUTHOR(S)" section]
+.\" Generator: Asciidoctor 2.0.20
+.\"      Date: 2023-12-05
+.\"    Manual: Configuration Files
+.\"    Source: chrony @CHRONY_VERSION@
+.\"  Language: English
+.\"
+.TH "CHRONY.CONF" "5" "2023-12-05" "chrony @CHRONY_VERSION@" "Configuration Files"
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.ss \n[.ss] 0
+.nh
+.ad l
+.de URL
+\fI\\$2\fP <\\$1>\\$3
+..
+.als MTO URL
+.if \n[.g] \{\
+.  mso www.tmac
+.  am URL
+.    ad l
+.  .
+.  am MTO
+.    ad l
+.  .
+.  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. 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 are
+not case\-sensitive. Generally, the directives can occur in any order in the file
+and if a directive is specified multiple times, only the last one will be
+effective. Exceptions are noted in the descriptions.
+.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 server can be specified by its hostname or IP address. If the hostname cannot
+be resolved on start, \fBchronyd\fP will try it again in increasing intervals, and
+also when the \fBonline\fP command is issued in \fBchronyc\fP.
+.sp
+The DNS record can change over time. The used address will be replaced with a
+newly resolved address when the server becomes unreachable (i.e. no valid
+response to last 8 requests), unsynchronised, a falseticker (i.e. does not
+agree with a majority of other sources), or the root distance is too large (the
+limit can be configured by the \fBmaxdistance\fP directive). The
+automatic replacement happens at most once per 30 minutes.
+.sp
+This directive can be used multiple times to specify multiple servers.
+.sp
+The 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 \-7 (1/128th 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 \-7 (1/128th of a second), and the maximum is 24 (6
+months).
+.RE
+.sp
+\fBiburst\fP
+.RS 4
+With this option, \fBchronyd\fP will start with a burst of 4\-8 requests in order to
+make the first update of the clock sooner. It will also repeat the burst every
+time the source is switched from the offline state to online with the
+\fBonline\fP command in \fBchronyc\fP.
+.RE
+.sp
+\fBburst\fP
+.RS 4
+With this option, \fBchronyd\fP will send a burst of up to 4 requests 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 key 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
+\fBnts\fP
+.RS 4
+This option enables authentication using the Network Time Security (NTS)
+mechanism. Unlike with the \fBkey\fP option, the server and client do not need to
+share a key in a key file. NTS has a Key Establishment (NTS\-KE) protocol using
+the Transport Layer Security (TLS) protocol to get the keys and cookies
+required by NTS for authentication of NTP packets.
+.RE
+.sp
+\fBcertset\fP \fIID\fP
+.RS 4
+This option specifies which set of trusted certificates should be used to verify
+the server\(cqs certificate when the \fBnts\fP option is enabled. Sets of certificates
+can be specified with the \fBntstrustedcerts\fP directive. The
+default set is 0, which by default contains certificates of the system\(cqs
+default trusted certificate authorities.
+.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 wireless networks and 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 greater than 0.3 seconds 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
+specified ratio times the minimum delay, it will be rejected. By default, this
+test is disabled.
+.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
+\fBmaxdelayquant\fP \fIp\fP
+.RS 4
+This option disables the \fBmaxdelaydevratio\fP test and specifies the maximum
+acceptable delay as a quantile of the round\-trip delay instead of a function of
+the minimum delay amongst the buffered measurements. If a measurement has a
+round\-trip delay that is greater than a long\-term estimate of the \fIp\fP\-quantile,
+it will be rejected.
+.sp
+The specified \fIp\fP value should be between 0.05 and 0.95. For example,
+\fBmaxdelayquant 0.2\fP would indicate that only measurements with the lowest 20
+percent of round\-trip delays should be accepted. Note that it can take many
+measurements for the estimated quantile to reach the expected value. This
+option is intended for synchronisation in mostly static local networks with
+very short polling intervals and possibly combined with the \fBfilter\fP option.
+By default, this test is disabled in favour of the \fBmaxdelaydevratio\fP test.
+.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 \fIpolls\fP
+.RS 4
+This option enables a median filter to reduce noise in NTP measurements. The
+filter will process samples collected in the specified number of polls
+into 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 the interleaved mode of NTP. It enables the server to
+respond with more accurate transmit timestamps (e.g. kernel or hardware
+timestamps), which cannot be contained in the transmitted packet itself and
+need to refer to a previous packet instead. This can significantly improve the
+accuracy and stability of the measurements.
+.sp
+The interleaved mode is compatible with servers that support only the basic
+mode. 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
+\fBntsport\fP \fIport\fP
+.RS 4
+This option specifies the TCP port on which the server is listening for NTS\-KE
+connections when the \fBnts\fP option is enabled. The default is 4460.
+.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
+.fam C
+presend 9
+.fam
+.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
+If the \fBpresend\fP option is used together 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 other options.
+If the \fBextfield\fP or \fBxleave\fP option is used, the default version is 4. If
+those options are not used and the \fBkey\fP option specifies a key using a hash
+function with output size longer than 160 bits (e.g. SHA256), the default
+version is 3 for compatibility with older \fBchronyd\fP servers. In other cases,
+the default version is 4.
+.RE
+.sp
+\fBcopy\fP
+.RS 4
+This option specifies that the server and client are closely related, their
+configuration does not allow a synchronisation loop to form between them, and
+the client is allowed to assume the reference ID and stratum of the server.
+This is useful when multiple instances of \f(CRchronyd\fP are running on one computer
+(e.g. for security or performance reasons), one primarily operating as a client
+to synchronise the system clock and other instances started with the \fB\-x\fP
+option to operate as NTP servers for other computers with their NTP clocks
+synchronised to the first instance.
+.RE
+.sp
+\fBextfield\fP \fItype\fP
+.RS 4
+This option enables an NTPv4 extension field specified by its type as a
+hexadecimal number. It will be included in requests sent to the server and
+processed in received responses if the server supports it. Note that some
+server implementations do not respond to requests containing an unknown
+extension field (\fBchronyd\fP as a server responded to such requests since
+version 2.0).
+.sp
+This option can be used multiple times to enable multiple extension fields.
+.sp
+The following extension fields are supported:
+.sp
+\fIF323\fP
+.RS 4
+An experimental extension field to enable several improvements that were
+proposed for the next version of the NTP protocol (NTPv5). The field contains
+root delay and dispersion in higher resolution and a monotonic receive
+timestamp, which enables a frequency transfer between the server and client to
+significantly improve stability of the synchronisation. This field should be
+enabled only for servers known to be running \fBchronyd\fP version 4.2 or later.
+.RE
+.sp
+\fIF324\fP
+.RS 4
+An experimental extension field to enable the use of the Precision Time
+Protocol (PTP) correction field in NTP\-over\-PTP messages updated by one\-step
+end\-to\-end transparent clocks in network switches and routers to significantly
+improve accuracy and stability of the synchronisation. NTP\-over\-PTP can be
+enabled by the \fBptpport\fP directive and setting the \fBport\fP option to
+the PTP port. The corrections are applied only to NTP measurements with HW
+timestamps (enabled by the \fBhwtimestamp\fP directive). This
+field should be enabled only for servers known to be running \fBchronyd\fP version
+4.5 or later.
+.RE
+.RE
+.sp
+
+.RS 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
+This directive can be used multiple times to specify multiple pools.
+.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:
+.sp
+\fBmaxsources\fP \fIsources\fP
+.RS 4
+This option sets the desired number of sources to be used from the pool.
+\fBchronyd\fP will repeatedly try to resolve the name until it gets this number of
+sources responding to requests. The default value is 4 and the maximum value is
+16.
+.sp
+An example of the \fBpool\fP directive is
+.sp
+.if n .RS 4
+.nf
+.fam C
+pool pool.ntp.org iburst maxsources 3
+.fam
+.fi
+.if n .RE
+.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
+This directive can be used multiple times to specify multiple peers.
+.sp
+The following options of the \fBserver\fP directive do not work in the \fBpeer\fP
+directive: \fBiburst\fP, \fBburst\fP, \fBnts\fP, \fBpresend\fP, \fBcopy\fP.
+.sp
+When using the \fBxleave\fP option, both peers must support and have enabled the
+interleaved mode, otherwise the synchronisation will work in one direction
+only.
+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
+(This directive is deprecated in favour of the \fBmakestep\fP
+directive.)
+.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
+.fam C
+initstepslew 30 ntp1.example.net ntp2.example.net ntp3.example.net
+.fam
+.fi
+.if n .RE
+.sp
+where 3 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
+primary server and the other computers are its clients. If each of the clients
+is configured with the \fBlocal\fP directive, the server can be set up
+with an \fBinitstepslew\fP directive which references some or all of the clients.
+Then, if the server machine has to be rebooted, the clients can be relied on to
+act analogously to a flywheel and preserve the time for a short period while
+the server 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 prevent programs started in
+the boot sequence after \fBchronyd\fP from reading the clock before it has been
+stepped. With the \fBmakestep\fP directive, the
+\fBwaitsync\fP command of \fBchronyc\fP can be used instead.
+.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 using the \fB:\fP character.
+.sp
+This directive can be used multiple times to specify multiple reference clocks.
+.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
+.fam C
+refclock PPS /dev/pps0 lock NMEA refid GPS1
+refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.2 refid NMEA noselect
+refclock PPS /dev/pps1:clear refid GPS2
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBSOCK\fP
+.RS 4
+Unix domain socket driver. This driver uses a datagram socket to receive
+samples from another application running on the system. The parameter is the
+path to the socket, which \fBchronyd\fP will create on start. 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. It can
+provide accurate measurements using the receiver\(cqs PPS signal, and since
+version 3.25 also (much less accurate) measurements based on the timing of
+serial data (e.g. NMEA), which can be useful when the receiver does not provide
+a PPS signal, or it cannot be connected to the computer. The paths where \fBgpsd\fP
+expects the sockets to be created by \fBchronyd\fP are described in the \fBgpsd(8)\fP
+man page. Note that \fBgpsd\fP needs to be started after \fBchronyd\fP in order to
+connect to the socket.
+.sp
+Examples:
+.sp
+.if n .RS 4
+.nf
+.fam C
+refclock SOCK /var/run/chrony.ttyS0.sock refid GPS1 poll 2 filter 4
+refclock SOCK /var/run/chrony.clk.ttyUSB0.sock refid GPS2 offset 0.2 delay 0.1
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBSHM\fP
+.RS 4
+NTP shared memory driver. This driver implements the protocol of the \fBntpd\fP
+driver type 28. It is functionally similar to the SOCK driver, but uses a
+shared memory segment instead of a socket. The parameter is the unit number,
+typically a small number like 0, 1, 2, or 3, from which is derived the key of
+the memory segment as 0x4e545030 + unit.
+.sp
+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
+Unlike with the SOCK driver, there is no prescribed order of starting \fBchronyd\fP
+and the program providing measurements. Both are expected to create the memory
+segment if it does not exist. \fBchronyd\fP will attach to an existing segment even
+if it has a different owner than root or different permissions than the
+permissions specified by the \fBperm\fP option. The segment needs to be created
+before untrusted applications or users can execute code to prevent an attacker
+from feeding \fBchronyd\fP with false measurements. The owner and permissions of
+the segment can be verified with the \fBipcs \-m\fP command. For this reason, the
+SHM driver is deprecated in favor of SOCK.
+.sp
+Examples:
+.sp
+.if n .RS 4
+.nf
+.fam C
+refclock SHM 0 poll 3 refid GPS1
+refclock SHM 1:perm=0644 refid GPS2
+.fam
+.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 which should be enabled for the
+PPS timestamping. If the PHC does not have configurable pins (i.e. the channel
+function is fixed), the index needs to be set to \-1 to disable the pin
+configuration. 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
+.fam C
+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
+.fam
+.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. With drivers that perform their own polling (PPS, PHC, SHM), the
+maximum value is adjusted to the number of driver polls per source poll, i.e.
+2^(\fIpoll\fP \- \fIdpoll\fP).
+.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
+\fBlocal\fP
+.RS 4
+This option specifies that the reference clock is an unsynchronised clock which
+is more stable than the system clock (e.g. TCXO, OCXO, or atomic clock) and
+it should be used as a local standard to stabilise the system clock. The
+refclock will bypass the source selection. There should be at most one refclock
+specified with this option and it should have the shortest polling interval
+among all configured sources.
+.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 as an NTP client opens a new socket for each request with
+the source port chosen randomly by the operating system. The \fBacquisitionport\fP
+directive can be used to specify the source 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. It should not be used if not necessary as there
+is a small impact on security of the client. If set to 0, the source port of
+the permanent socket will be chosen randomly by the operating system.
+.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
+.fam C
+acquisitionport 1123
+.fam
+.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 specifies a local IP address to which
+\fBchronyd\fP will bind its NTP and NTS\-KE 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
+\fBbindacqdevice\fP \fIinterface\fP
+.RS 4
+The \fBbindacqdevice\fP directive binds the client sockets to a network device
+specified by the interface name. This can be useful when the local address is
+dynamic, or to enable an NTP source specified with a link\-local IPv6 address.
+This directive can specify only one interface and it is supported on Linux
+only.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+bindacqdevice eth0
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBdscp\fP \fIpoint\fP
+.RS 4
+The \fBdscp\fP directive sets the Differentiated Services Code Point (DSCP) in
+transmitted NTP packets to the specified value. It can improve stability of NTP
+measurements in local networks where switches or routers are configured to
+prioritise forwarding of packets with specific DSCP values. The default value
+is 0 and the maximum value is 63.
+.sp
+An example of the directive (setting the Expedited Forwarding class) is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+dscp 46
+.fam
+.fi
+.if n .RE
+.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
+If the directory does not exist, it will be created automatically.
+.sp
+The \fB\-r\fP option of \fBchronyd\fP enables loading of the dump files on start. All
+dump files found in the directory will be removed after start, even if the \fB\-r\fP
+option is not present.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+dumpdir @CHRONYRUNDIR@
+.fam
+.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.
+.sp
+As a special case, setting \fBmaxsamples\fP to 1 disables frequency tracking in
+order to make the sources immediately selectable with only one sample. This can
+be useful when \fBchronyd\fP is started with the \fB\-q\fP or \fB\-Q\fP option.
+.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
+.sp
+\fBntsdumpdir\fP \fIdirectory\fP
+.RS 4
+This directive specifies a directory for the client to save NTS cookies it
+received from the server in order to avoid making an NTS\-KE request when
+\fBchronyd\fP is started again. The cookies are saved separately for each NTP
+source in files named by the IP address of the NTS\-KE server (e.g.
+\fI1.2.3.4.nts\fP). By default, the client does not save the cookies.
+.sp
+If the directory does not exist, it will be created automatically.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+ntsdumpdir @CHRONYVARDIR@
+.fam
+.fi
+.if n .RE
+.sp
+This directory is used also by the NTS server to save keys.
+.RE
+.sp
+\fBntsrefresh\fP \fIinterval\fP
+.RS 4
+This directive specifies the maximum interval between NTS\-KE handshakes (in
+seconds) in order to refresh the keys authenticating NTP packets. The default
+value is 2419200 (4 weeks) and the maximum value is 2^31\-1 (68 years).
+.sp
+The interval must be longer than polling intervals of all configured NTP
+sources using NTS, otherwise the source with a longer polling interval will
+refresh the keys on each poll and no NTP packets will be exchanged.
+.RE
+.sp
+\fBntstrustedcerts\fP [\fIset\-ID\fP] \fIfile\fP|\fIdirectory\fP
+.RS 4
+This directive specifies a file or directory containing trusted certificates
+(in the PEM format) which are needed to verify certificates of NTS\-KE servers,
+e.g. certificates of trusted certificate authorities (CA) or self\-signed
+certificates of the servers.
+.sp
+The optional \fIset\-ID\fP argument is a number in the range 0 through 2^32\-1, which
+selects the set of certificates where certificates from the specified file
+or directory are added. The default ID is 0, which is a set containing the
+system\(cqs default trusted CAs (unless the \fBnosystemcert\fP directive is present).
+All other sets are empty by default. A set of certificates can be selected for
+verification of an NTS server by the \fBcertset\fP option in the \fBserver\fP or \fBpool\fP
+directive.
+.sp
+This directive can be used multiple times to specify one or more sets of
+trusted certificates, each containing certificates from one or more files
+and/or directories.
+.sp
+It is not necessary to restart \fBchronyd\fP in order to reload the certificates if
+they change (e.g. after a renewal).
+.sp
+An example is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+ntstrustedcerts /etc/pki/nts/ca1.example.net.crt
+ntstrustedcerts 1 /etc/pki/nts/ca2.example.net.crt
+ntstrustedcerts 1 /etc/pki/nts/ca3.example.net.crt
+ntstrustedcerts 2 /etc/pki/nts/ntp2.example.net.crt
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBnosystemcert\fP
+.RS 4
+This directive disables the system\(cqs default trusted CAs. Only certificates
+specified by the \fBntstrustedcerts\fP directive will be trusted.
+.RE
+.sp
+\fBnocerttimecheck\fP \fIlimit\fP
+.RS 4
+This directive disables the checks of the activation and expiration times of
+certificates for the specified number of clock updates. It allows the NTS
+authentication mechanism to be used on computers which start with wrong time
+(e.g. due to not having an RTC or backup battery). Disabling the time checks
+has important security implications and should be used only as a last resort,
+preferably with a minimal number of trusted certificates. The default value is
+0, which means the time checks are always enabled.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+nocerttimecheck 1
+.fam
+.fi
+.if n .RE
+.sp
+This would disable the time checks until the clock is updated for the first
+time, assuming the first update corrects the clock and later checks can work
+with correct time.
+.RE
+.sp
+\fBrefresh\fP \fIinterval\fP
+.RS 4
+This directive specifies the interval (in seconds) between refreshing IP
+addresses of NTP sources specified by hostname. If the hostname no longer
+resolves to the currently used address, it will be replaced with one of the new
+addresses to avoid using a server which is no longer intended for service, even
+if it is still responding correctly and would not be replaced as unreachable.
+Only one source is refreshed at a time. The default value is 1209600 (2 weeks)
+and the maximum value is 2^31\-1 (68 years). A value of 0 disables the periodic
+refreshment.
+.sp
+The \fBrefresh\fP command can be used to refresh all
+sources immediately.
+.RE
+.SS "Source selection"
+.sp
+\fBauthselectmode\fP \fImode\fP
+.RS 4
+NTP sources can be specified with the \fBkey\fP or \fBnts\fP option to enable
+authentication to limit the impact of man\-in\-the\-middle attacks. The
+attackers can drop or delay NTP packets (up to the \fBmaxdelay\fP and
+\fBmaxdistance\fP limits), but they cannot modify the timestamps
+contained in the packets. The attack can cause only a limited slew or step, and
+also cause the clock to run faster or slower than real time (up to double of
+the \fBmaxdrift\fP limit).
+.sp
+When authentication is enabled for an NTP source, it is important to disable
+unauthenticated NTP sources which could be exploited in the attack, e.g. if
+they are not reachable only over a trusted network. Alternatively, the source
+selection can be configured with the \fBrequire\fP and \fBtrust\fP options to
+synchronise to the unauthenticated sources only if they agree with the
+authenticated sources and might have a positive impact on the accuracy of the
+clock. Note that in this case the impact of the attack is higher. The attackers
+cannot cause an arbitrarily large step or slew, but they have more control over
+the frequency of the clock and can cause \fBchronyd\fP to report false information,
+e.g. a significantly smaller root delay and dispersion.
+.sp
+This directive determines the default selection options for authenticated and
+unauthenticated sources in order to simplify the configuration with the
+configuration file and \fBchronyc\fP commands. It sets a policy for authentication.
+.sp
+Sources specified with the \fBnoselect\fP option are ignored (not counted as either
+authenticated or unauthenticated), and they always have only the selection
+options specified in the configuration.
+.sp
+There are four modes:
+.sp
+\fBrequire\fP
+.RS 4
+Authentication is strictly required for NTP sources in this mode. If any
+unauthenticated NTP sources are specified, they will automatically get the
+\fBnoselect\fP option to prevent them from being selected for synchronisation.
+.RE
+.sp
+\fBprefer\fP
+.RS 4
+In this mode, authentication is optional and preferred. If it is enabled for at
+least one NTP source, all unauthenticated NTP sources will get the \fBnoselect\fP
+option.
+.RE
+.sp
+\fBmix\fP
+.RS 4
+In this mode, authentication is optional and synchronisation to a mix of
+authenticated and unauthenticated NTP sources is allowed. If both authenticated
+and unauthenticated NTP sources are specified, all authenticated NTP sources
+and reference clocks will get the \fBrequire\fP and \fBtrust\fP options to prevent
+synchronisation to unauthenticated NTP sources if they do not agree with a
+majority of the authenticated sources and reference clocks. This is the default
+mode.
+.RE
+.sp
+\fBignore\fP
+.RS 4
+In this mode, authentication is ignored in the source selection. All sources
+will have only the selection options that were specified in the configuration
+file, or \fBchronyc\fP command. This was the behaviour of \fBchronyd\fP in versions
+before 4.0.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+As an example, the following configuration using the default \fBmix\fP mode:
+.sp
+.if n .RS 4
+.nf
+.fam C
+server ntp1.example.net nts
+server ntp2.example.net nts
+server ntp3.example.net
+refclock SOCK /var/run/chrony.ttyS0.sock
+.fam
+.fi
+.if n .RE
+.sp
+is equivalent to the following configuration using the \fBignore\fP mode:
+.sp
+.if n .RS 4
+.nf
+.fam C
+authselectmode ignore
+server ntp1.example.net nts require trust
+server ntp2.example.net nts require trust
+server ntp3.example.net
+refclock /var/run/chrony.ttyS0.sock require trust
+.fam
+.fi
+.if n .RE
+.RE
+.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.
+If the selected source was specified with the \fBprefer\fP option, it can be
+combined only with other sources specified with this option.
+.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 root distance of a source to be
+acceptable for synchronisation of the clock. Sources that have a distance
+larger than the specified distance will be rejected. The distance estimates the
+maximum error of the source. It includes the root dispersion and half of the
+root delay (round\-trip time) accumulated on the path 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
+\fBclockprecision\fP \fIprecision\fP
+.RS 4
+The \fBclockprecision\fP directive specifies the precision of the system clock (in
+seconds). It is used by \fBchronyd\fP to estimate the minimum noise in NTP
+measurements and randomise low\-order bits of timestamps in NTP responses. By
+default, the precision is measured on start as the minimum time to read the
+clock.
+.sp
+The measured value works well in most cases. However, it generally
+overestimates the precision and it can be sensitive to the CPU speed, which can
+change over time to save power. In some cases with a high\-precision clocksource
+(e.g. the Time Stamp Counter of the CPU) and hardware timestamping, setting the
+precision on the server to a smaller value can improve stability of clients\*(Aq
+NTP measurements. The server\(cqs precision is reported on clients by the
+\fBntpdata\fP command.
+.sp
+An example setting the precision to 8 nanoseconds is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+clockprecision 8e\-9
+.fam
+.fi
+.if n .RE
+.RE
+.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
+.fam C
+driftfile @CHRONYVARDIR@/drift
+.fam
+.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
+.fam C
+fallbackdrift 16 19
+.fam
+.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. This option is particularly
+useful when multiple \fBchronyd\fP instances are running on the system, one
+controlling the system clock and others started with the \fB\-x\fP option, which
+should rely on the first instance to correct the system clock and ignore it for
+the correction of their own NTP clock running on top of the system clock.
+.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 by 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
+.fam C
+leapsecmode slew
+maxslewrate 1000
+smoothtime 400 0.001024 leaponly
+.fam
+.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 62500 seconds (about 17.36 hours) to finish. The frequency
+offset will be changing by 0.001024 ppm per second and will reach a maximum of
+32 ppm in 31250 seconds. 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.
+.sp
+The duration of the leap smear can be calculated from the specified wander as
+.sp
+.if n .RS 4
+.nf
+.fam C
+duration = sqrt(4 / wander)
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBleapsectz\fP \fItimezone\fP
+.RS 4
+This directive specifies a timezone in the system timezone 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 normally 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
+.fam C
+leapsectz right/UTC
+.fam
+.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
+.fam C
+$ TZ=right/UTC date \-d \*(AqDec 31 2008 23:59:60\*(Aq
+Wed Dec 31 23:59:60 UTC 2008
+.fam
+.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,
+e.g. when \fBchronyd\fP is initially started, 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 the specified limit. A negative value disables
+the limit.
+.sp
+On most systems it is desirable to step the system clock only on boot, before
+starting programs that rely on time advancing monotonically forwards.
+.sp
+An example of the use of this directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+makestep 0.1 3
+.fam
+.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 offset to be accepted on a clock update. The
+offset is measured relative to the current estimate of the true time, which is
+different from the system time if a previous slew did not finish.
+.sp
+The check is enabled after the specified number of clock updates to allow a
+large initial offset to be corrected on start. Offsets larger than the
+specified maximum will be ignored for the specified number of times. Another
+large offset will cause \fBchronyd\fP to give up and exit. A negative value
+can be used to disable the limit to ignore all large offsets. A syslog message
+will be generated when an offset is ignored or it causes the exit.
+.sp
+An example of the use of this directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+maxchange 1000 1 2
+.fam
+.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 illumos).
+.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\*(Aqs 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 NTP sources polled over a
+wireless network, and 10 or smaller for sources on a local wired network.
+.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 existing estimate. If it has
+significantly smaller error bounds than the new estimate, the existing estimate
+will dominate in the new combined value.
+.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 illumos 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
+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
+.fam C
+comp = k0 + (T \- T0) * k1 + (T \- T0)^2 * k2
+.fam
+.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
+.fam C
+tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 26000 0.0 0.000183 0.0
+.fam
+.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
+.fam C
+tempcomp /sys/class/hwmon/hwmon0/temp2_input 30 /etc/chrony.tempcomp
+.fam
+.fi
+.if n .RE
+.sp
+where the \fI/etc/chrony.tempcomp\fP file could have
+.sp
+.if n .RS 4
+.nf
+.fam C
+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
+.fam
+.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. It also controls
+access of NTS\-KE clients when NTS is enabled on the 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
+This directive can be used multiple times.
+.sp
+Examples of the use of the directive are as follows:
+.sp
+.if n .RS 4
+.nf
+.fam C
+allow 1.2.3.4
+allow 3.4.5.0/24
+allow 3.4.5
+allow 2001:db8::/32
+allow 0/0
+allow ::/0
+allow
+.fam
+.fi
+.if n .RE
+.sp
+The first directive allows access from an IPv4 address. The second directive
+allows access from all computers in an IPv4 subnet specified in the CIDR
+notation. The third directive specifies the same subnet using a simpler
+notation where the prefix length is determined by the number of dots. The
+fourth directive specifies an IPv6 subnet. The fifth and sixth directives allow
+access from all IPv4 and IPv6 addresses respectively. The seventh directive
+allows access from all addresses (both 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
+.fam C
+allow 1.2.3.4
+deny 1.2.3.0/24
+allow 1.2.0.0/16
+.fam
+.fi
+.if n .RE
+.sp
+and
+.sp
+.if n .RS 4
+.nf
+.fam C
+allow 1.2.3.4
+deny 1.2.3.0/24
+allow all 1.2.0.0/16
+.fam
+.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.0.0/16\fP subnet is allowed access, except
+for the \fI1.2.3.0/24\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.0.0/16\fP directive 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 rules are internally represented as a tree of tables with one level per
+four bits of the IPv4 or IPv6 address. The order of the \fBallow\fP and \fBdeny\fP
+directives matters if they modify the same records of one table, i.e. if one
+subnet is included in the other subnet and their prefix lengths are at the same
+level. For example, \fI1.2.3.0/28\fP and \fI1.2.3.0/29\fP are in different tables, but
+\fI1.2.3.0/25\fP and \fI1.2.3.0/28\fP are in the same table. The configuration can be
+verified for individual addresses with the \fBaccheck\fP
+command in \fBchronyc\fP.
+.sp
+A hostname can be specified in the directives instead of the IP address, but
+the name must be resolvable when \fBchronyd\fP is started, i.e. the network is
+already up and DNS is working. If the hostname resolves to multiple addresses,
+only the first address (in the order returned by the system resolver) will be
+allowed or denied.
+.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
+and NTS\-KE client access to a particular subnet or host, rather than allowing
+it.
+.sp
+The syntax is identical and the directive can be used multiple times too.
+.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 sockets on which \fBchronyd\fP listens for
+NTP and NTS\-KE 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
+.fam C
+bindaddress 192.168.1.1
+.fam
+.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
+\fBbinddevice\fP \fIinterface\fP
+.RS 4
+The \fBbinddevice\fP directive binds the NTP and NTS\-KE server sockets to a network
+device specified by the interface name. This directive can specify only one
+interface and it is supported on Linux only.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+binddevice eth0
+.fam
+.fi
+.if n .RE
+.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
+This directive can be used multiple times to specify multiple addresses.
+.sp
+The syntax is as follows:
+.sp
+.if n .RS 4
+.nf
+.fam C
+broadcast 32 192.168.1.255
+broadcast 64 192.168.2.255 12123
+broadcast 64 ff02::101
+.fam
+.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 (32 or 64 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 enables monitoring of up to 4096 IP addresses at
+the same time and holding NTP timestamps for up to 4096 clients using the
+interleaved mode (depending on uniformity of their polling interval). The
+number of addresses and timestamps is always a power of 2. The maximum
+effective value is 2147483648 (2 GB), which corresponds to 16777216 addresses
+and timestamps.
+.sp
+An example of the use of this directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+clientloglimit 1048576
+.fam
+.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
+.fam C
+distance = delay / 2 + dispersion
+.fam
+.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. If that server stops responding, the server with the second
+smallest reference ID will take over when its local reference mode activates
+(root distance reaches the threshold configured by the \fBdistance\fP option).
+.sp
+The \fBorphan\fP mode is compatible with the \fBntpd\fP\*(Aqs 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
+.fam C
+local stratum 10 orphan distance 0.1
+.fam
+.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
+.fam C
+ntpsigndsocket /var/lib/samba/ntp_signd
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBntsport\fP \fIport\fP
+.RS 4
+This directive specifies the TCP port on which \fBchronyd\fP will provide the NTS
+Key Establishment (NTS\-KE) service. The default port is 4460.
+.sp
+The port will be open only when a certificate and key is specified by the
+\fBntsservercert\fP and \fBntsserverkey\fP directives.
+.RE
+.sp
+\fBntsservercert\fP \fIfile\fP
+.RS 4
+This directive specifies a file containing a certificate in the PEM format
+for \fBchronyd\fP to operate as an NTS server. The file should also include
+any intermediate certificates that the clients will need to validate the
+server\(cqs certificate. The file needs to be readable by the user under which
+\fBchronyd\fP is running after dropping root privileges.
+.sp
+This directive can be used multiple times to specify multiple certificates for
+different names of the server.
+.sp
+The files are loaded only once. \fBchronyd\fP needs to be restarted in order to
+load a renewed certificate. The \fBntsdumpdir\fP and
+\fBdumpdir\fP directives with the \fB\-r\fP option of \fBchronyd\fP are
+recommended for a near\-seamless server operation.
+.RE
+.sp
+\fBntsserverkey\fP \fIfile\fP
+.RS 4
+This directive specifies a file containing a private key in the PEM format
+for \fBchronyd\fP to operate as an NTS server. The file needs to be readable by
+the user under which \fBchronyd\fP is running after dropping root privileges. For
+security reasons, it should not be readable by other users.
+.sp
+This directive can be used multiple times to specify multiple keys. The number
+of keys must be the same as the number of certificates and the corresponding
+files must be specified in the same order.
+.RE
+.sp
+\fBntsprocesses\fP \fIprocesses\fP
+.RS 4
+This directive specifies how many helper processes will \fBchronyd\fP operating
+as an NTS server start for handling client NTS\-KE requests in order to improve
+performance with multi\-core CPUs and multithreading. If set to 0, no helper
+process will be started and all NTS\-KE requests will be handled by the main
+\fBchronyd\fP process. The default value is 1.
+.RE
+.sp
+\fBmaxntsconnections\fP \fIconnections\fP
+.RS 4
+This directive specifies the maximum number of concurrent NTS\-KE connections
+per process that the NTS server will accept. The default value is 100. The
+maximum practical value is half of the system \fBFD_SETSIZE\fP constant (usually
+1024).
+.RE
+.sp
+\fBntsdumpdir\fP \fIdirectory\fP
+.RS 4
+This directive specifies a directory where \fBchronyd\fP operating as an NTS server
+can save the keys which encrypt NTS cookies provided to clients. The keys are
+saved to a single file named \fIntskeys\fP. When \fBchronyd\fP is restarted, reloading
+the keys allows the clients to continue using old cookies and avoids a storm of
+NTS\-KE requests. By default, the server does not save the keys.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+ntsdumpdir @CHRONYVARDIR@
+.fam
+.fi
+.if n .RE
+.sp
+This directory is used also by the NTS client to save NTS cookies.
+.RE
+.sp
+\fBntsntpserver\fP \fIhostname\fP
+.RS 4
+This directive specifies the hostname (as a fully qualified domain name) or
+address of the NTP server(s) which is
+provided in the NTS\-KE response to the clients. It allows the NTS\-KE server to
+be separated from the NTP server. However, the servers need to share the keys,
+i.e. external key management needs to be enabled by setting
+\fBntsrotate\fP to 0. By default, no hostname or address is provided
+to the clients, which means they should use the same server for NTS\-KE and NTP.
+.RE
+.sp
+\fBntsrotate\fP \fIinterval\fP
+.RS 4
+This directive specifies the rotation interval (in seconds) of the server key
+which encrypts the NTS cookies. New keys are generated automatically from the
+\fI/dev/urandom\fP device. The server keeps two previous keys to give the clients
+time to get new cookies encrypted by the latest key. The interval is measured
+as the server\(cqs operating time, i.e. the actual interval can be longer if
+\fBchronyd\fP is not running continuously. The default interval is 604800 seconds
+(1 week). The maximum value is 2^31\-1 (68 years).
+.sp
+The automatic rotation of the keys can be disabled by setting \fBntsrotate\fP to 0.
+In this case the keys are assumed to be managed externally. \fBchronyd\fP will not
+save the keys to the \fIntskeys\fP file and will reload the keys from the file when
+the \fBrekey\fP command is issued in \fBchronyc\fP. The file can
+be periodically copied from another server running \fBchronyd\fP (which does
+not have \fBntsrotate\fP set to 0) in order to have one or more servers dedicated
+to NTS\-KE. The file includes the subsequent key to which the NTS\-KE server will
+switch on the next rotation, i.e. the process copying and reloading the file
+does not need to be timed precisely (it can be delayed by up to one rotation
+interval). The NTS\-KE servers need to be configured with the
+\fBntsntpserver\fP directive to point the clients to the right NTP
+server.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+ntsrotate 2592000
+.fam
+.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 \fIinterval\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 \fIresponses\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 \fIrate\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
+.fam C
+ratelimit interval 1 burst 16
+.fam
+.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
+\fBntsratelimit\fP [\fIoption\fP]...
+.RS 4
+This directive enables rate limiting of NTS\-KE requests. It is similar to the
+\fBratelimit\fP directive, except the default interval is 6
+(1 connection per 64 seconds).
+.sp
+An example of the use of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+ntsratelimit interval 3 burst 1
+.fam
+.fi
+.if n .RE
+.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
+.fam C
+smoothtime 400 0.001
+.fam
+.fi
+.if n .RE
+.sp
+An example suitable for clients using \fBchronyd\fP on Linux could be:
+.sp
+.if n .RS 4
+.nf
+.fam C
+smoothtime 50000 0.01
+.fam
+.fi
+.if n .RE
+.RE
+.SS "Command and monitoring access"
+.sp
+\fBbindcmdaddress\fP \fIaddress\fP
+.RS 4
+The \fBbindcmdaddress\fP directive specifies a local IP address to which \fBchronyd\fP
+will bind the UDP socket listening 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 the UDP sockets to the addresses \fI127.0.0.1\fP and
+\fI::1\fP (i.e. the loopback interface). 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
+.fam C
+bindcmdaddress 0.0.0.0
+bindcmdaddress ::
+.fam
+.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
+.fam C
+bindcmdaddress /var/run/chrony/chronyd.sock
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBbindcmddevice\fP \fIinterface\fP
+.RS 4
+The \fBbindcmddevice\fP directive binds the UDP command sockets to a network device
+specified by the interface name. This directive can specify only one interface
+and it is supported on Linux only.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+bindcmddevice eth0
+.fam
+.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, which disables remote \fBchronyc\fP access (with
+a non\-default \fBbindcmdaddress\fP) and local access for unprivileged users. It
+does not disable the Unix domain command socket.
+.sp
+An example shows the syntax:
+.sp
+.if n .RS 4
+.nf
+.fam C
+cmdport 257
+.fam
+.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 option 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
+.fam C
+cmdratelimit interval 2
+.fam
+.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
+.fam C
+hwclockfile /etc/adjtime
+.fam
+.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. The trimming operation is accurate to only about 1 second, which is
+the minimum effective threshold.
+.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
+.fam C
+rtcautotrim 30
+.fam
+.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
+.fam C
+rtcfile @CHRONYVARDIR@/rtc
+.fam
+.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 by the \fBhwclockfile\fP file
+and is not relevant for the \fBrtcsync\fP directive.
+.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
+.fam C
+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
+.fam
+.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
+.\}
+Results of the \fBmaxdelay\fP, \fBmaxdelayratio\fP, and \fBmaxdelaydevratio\fP (or
+\fBmaxdelayquant\fP) tests, and a test for synchronisation loop (1=pass,
+0=fail). The first test from these four also checks the server precision,
+response time, and whether an interleaved response is acceptable for
+synchronisation. [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
+.fam C
+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
+.fam
+.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
+\fBselection\fP
+.RS 4
+This option logs information about selection of sources for synchronisation to
+a file called \fIselection.log\fP. Note that the rate of entries written to this
+file grows quadratically with the number of specified sources (each measurement
+triggers the selection for all sources). 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
+.fam C
+2022\-05\-01 02:01:20 203.0.113.15    * \-\-\-\-\-  377  1.00  \(rs
+     4.228e+01 \-1.575e\-04  1.239e\-04
+.fam
+.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 [2022\-05\-01]
+.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. [02:01:20]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 3." 4.2
+.\}
+IP address or reference ID of the source. [203.0.113.15]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 4." 4.2
+.\}
+State of the source indicated with one of the following symbols. [*]
+.sp
+
+.RS 4
+Not considered selectable for synchronisation:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIN\fP \- has the \fBnoselect\fP option.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIs\fP \- is not synchronised.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIM\fP \- does not have enough measurements.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fId\fP \- has a root distance larger than the maximum distance (configured by the
+\fBmaxdistance\fP directive).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fI~\fP \- has a jitter larger than the maximum jitter (configured by the
+\fBmaxjitter\fP directive).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIw\fP \- waits for other sources to get out of the \fIM\fP state.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIS\fP \- has older measurements than other sources.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIO\fP \- has a stratum equal or larger than the orphan stratum (configured by
+the \fBlocal\fP directive).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIT\fP \- does not fully agree with sources that have the \fBtrust\fP option.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIx\fP \- does not agree with other sources (falseticker).
+.RE
+.RE
+.sp
+
+.RS 4
+Considered selectable for synchronisation, but not currently used:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIW\fP \- waits for other sources to be selectable (required by the
+\fBminsources\fP directive, or the \fBrequire\fP option of
+another source).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIP\fP \- another selectable source is preferred due to the \fBprefer\fP option.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIU\fP \- waits for a new measurement (after selecting a different best source).
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fID\fP \- has, or recently had, a root distance which is too large to be combined
+with other sources (configured by the \fBcombinelimit\fP
+directive).
+.RE
+.RE
+.sp
+
+.RS 4
+Used for synchronisation of the local clock:
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fI+\fP \- combined with the best source.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fI*\fP \- selected as the best source to update the reference data (e.g. root
+delay, root dispersion).
+.RE
+.RE
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 5.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 5." 4.2
+.\}
+Current effective selection options of the source. which can be different
+from the configured options due to the authentication selection mode
+(configured by the \fBauthselectmode\fP directive). [\-\-\-\-\-]
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIN\fP indicates the \fBnoselect\fP option.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIP\fP indicates the \fBprefer\fP option.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIT\fP indicates the \fBtrust\fP option.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04'\(bu\h'+03'\c
+.\}
+.el \{\
+.  sp -1
+.  IP \(bu 2.3
+.\}
+\fIR\fP indicates the \fBrequire\fP option.
+.RE
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 6.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 6." 4.2
+.\}
+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. [377]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 7.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 7." 4.2
+.\}
+Current score against the source in the \fI*\fP state. The scoring system avoids
+frequent reselection when multiple sources have a similar root distance. A
+value larger than 1 indicates this source was better than the \fI*\fP source in
+recent selections. If the score reaches 10, the best source will be reselected
+and the scores will be reset to 1. [1.00]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 8.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 8." 4.2
+.\}
+Interval since the last measurement of the source in seconds. [4.228e+01]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 9.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 9." 4.2
+.\}
+Lower endpoint of the interval which was expected to contain the true offset
+of the local clock determined by the root distance of the source. [\-1.575e\-04]
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 10.\h'+01'\c
+.\}
+.el \{\
+.  sp -1
+.  IP " 10." 4.2
+.\}
+Upper endpoint of the interval which was expected to contain the true offset
+of the local clock determined by the root distance of the source. [1.239e\-04]
+.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
+.fam C
+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
+.fam
+.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
+.fam C
+2015\-07\-22 05:40:50     \-0.037360 1       \-0.037434\(rs
+          \-37.948  12   5  120
+.fam
+.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
+.fam C
+2009\-11\-30 14:33:27.000000 PPS2    7 N 1  4.900000e\-07 \-6.741777e\-07  1.000e\-06
+.fam
+.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
+.fam C
+2015\-04\-19 10:39:48  2.8000e+04  3.6600e\-01
+.fam
+.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
+.fam C
+log measurements statistics tracking
+.fam
+.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
+.fam C
+logchange 0.1
+.fam
+.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 specifies the directory for writing log files enabled by the
+\fBlog\fP directive. If the directory does not exist, it will be created
+automatically.
+.sp
+An example of the use of this directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+logdir /var/log/chrony
+.fam
+.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
+.fam C
+mailonchange root@localhost 0.5
+.fam
+.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
+\fBconfdir\fP \fIdirectory\fP...
+.RS 4
+The \fBconfdir\fP directive includes configuration files with the \fI.conf\fP suffix
+from a directory. The files are included in the lexicographical order of the
+file names.
+.sp
+Multiple directories (up to 10) can be specified with a single \fBconfdir\fP
+directive. In this case, if multiple directories contain a file with the same
+name, only the first file in the order of the specified directories will be
+included. This enables a fragmented configuration where existing fragments can
+be replaced by adding files to a different directory.
+.sp
+This directive can be used multiple times.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+confdir @SYSCONFDIR@/chrony.d
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBsourcedir\fP \fIdirectory\fP...
+.RS 4
+The \fBsourcedir\fP directive is identical to the \fBconfdir\fP directive, except the
+configuration files have the \fI.sources\fP suffix, they can only specify NTP
+sources (i.e. the \fBserver\fP, \fBpool\fP, and \fBpeer\fP directives), they are expected
+to have all lines terminated by the newline character, and they can be
+reloaded by the \fBreload sources\fP command in
+\fBchronyc\fP. It is particularly useful with dynamic sources like NTP servers
+received from a DHCP server, which can be written to a file specific to the
+network interface by a networking script.
+.sp
+This directive can be used multiple times.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+sourcedir /var/run/chrony\-dhcp
+.fam
+.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. Unlike with the \fBconfdir\fP directive,
+the full name of the files needs to be specified and at least one file is
+required to exist.
+.sp
+This directive can be used multiple times.
+.sp
+An example of the directive is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+include @SYSCONFDIR@/chrony.d/*.conf
+.fam
+.fi
+.if n .RE
+.RE
+.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 \fIhardware\-raw\-clock\fP, \fIhardware\-transmit\fP, and
+\fIhardware\-receive\fP. The receive filter \fIall\fP, or \fIntp\fP, is necessary for
+timestamping of received NTP packets. Timestamping of packets received on
+bridged and bonded interfaces is supported on Linux 4.13 and newer. If HW
+timestamping does not work for received packets, \fBchronyd\fP will use kernel
+receive timestamps instead. Transmit\-only HW timestamping can still be useful
+to improve stability of the synchronisation.
+.sp
+\fBchronyd\fP does not synchronise the NIC clock. It assumes the clock is running
+free. Multiple instances of \fBchronyd\fP can use the same interface with enabled
+HW timestamping. Applications which need HW timestamping with a synchronised
+clock (e.g. a PTP daemon) should use a virtual clock running on top of the
+physical clock created by writing to \fI/sys/class/ptp/ptpX/n_vclocks\fP. This
+feature is available on Linux 5.14 and newer.
+.sp
+If the kernel supports software timestamping, it will be enabled for all
+interfaces automatically.
+.sp
+The source of timestamps (i.e. hardware, kernel, or daemon) is indicated on the
+client side in the \fImeasurements.log\fP file (if enabled by the \fBlog\fP
+directive) and the \fBntpdata\fP report. On the server
+side, the number of served timestamps from each source is provided in the
+\fBserverstats\fP report.
+.sp
+This directive can be used multiple times to enable HW timestamping on multiple
+interfaces. 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 2. 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), the minimum value is \-6 (1/64th
+of a second), and the maximum value is 20 (about 12 days).
+.RE
+.sp
+\fBmaxpoll\fP \fIpoll\fP
+.RS 4
+This option specifies the maximum interval between readings of the NIC clock,
+as a power of 2. The default value is \fBminpoll\fP + 1, i.e. 1 (2 seconds) with
+the default \fBminpoll\fP of 0. The minimum and maximum values are the same as with
+the \fBminpoll\fP option.
+.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
+\fIptp\fP
+.RS 4
+Enables timestamping of received PTP packets.
+.RE
+.sp
+\fInone\fP
+.RS 4
+Disables timestamping of received packets.
+.RE
+.RE
+.sp
+
+.RS 4
+The most specific filter for timestamping of NTP packets supported by the NIC
+is selected by default. Some NICs can timestamp PTP packets only. By default,
+they will be configured with the \fInone\fP filter and expected to provide hardware
+timestamps for transmitted packets only. Timestamping of PTP packets is useful
+with NTP\-over\-PTP enabled by the \fBptpport\fP
+directive, or when another application is receiving PTP packets on the
+interface. Forcing timestamping of all packets with the \fIall\fP filter could be
+useful if the NIC supported both the \fIall\fP and \fIntp\fP filters, and it should
+timestamp both NTP and PTP packets, or NTP packets on a different UDP port.
+.RE
+.RE
+.sp
+
+.RS 4
+.sp
+Examples of the directive are:
+.sp
+.if n .RS 4
+.nf
+.fam C
+hwtimestamp eth0
+hwtimestamp eth1 txcomp 300e\-9 rxcomp 645e\-9
+hwtimestamp *
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBhwtstimeout\fP \fItimeout\fP
+.RS 4
+If hardware timestamping is used with a close NTP server, or the NIC or its
+driver is slow in providing the transmit timestamp of NTP requests, a response
+from the server can be received before the transmit timestamp of the request.
+To avoid calculating the offset with a less accurate transmit timestamp,
+\fBchronyd\fP can save the response for later processing and wait for the hardware
+transmit timestamp. There is no guarantee that the timestamp will be provided
+(NICs typically have a limited rate of transmit timestamping). This directive
+configures how long should \fBchronyd\fP wait for the timestamp after receiving a
+valid response from the server. If a second valid response is received from the
+server while waiting for the timestamp, they will be both processed
+immediately.
+.sp
+The default value is 0.001 seconds, which should be sufficient with most
+hardware. If you frequently see kernel transmit timestamps in the
+\fImeasurements.log\fP file or \fBntpdata\fP report, and it is
+not a server handling a high rate of requests in the interleaved mode on the
+same interface (which would compete with timestamping of the server\(cqs own
+requests), increasing the timeout to 0.01 or possibly even longer might help.
+Note that the maximum timeout is limited by the NTP polling interval.
+.RE
+.sp
+\fBkeyfile\fP \fIfile\fP
+.RS 4
+This directive is used to specify the location of the file containing symmetric
+keys which are shared between NTP servers and clients, or peers, in order to
+authenticate NTP packets with a message authentication code (MAC) using a
+cryptographic hash function or cipher.
+.sp
+The format of the directive is shown in the example below:
+.sp
+.if n .RS 4
+.nf
+.fam C
+keyfile @SYSCONFDIR@/chrony.keys
+.fam
+.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
+.fam C
+10 tulip
+11 hyacinth
+20 MD5 ASCII:crocus
+25 SHA1 HEX:933F62BE1D604E68A81B557F18CFA200483F5B70
+30 AES128 HEX:7EA62AE64D190114D46D5A082F948EC1
+31 AES256 HEX:37DDCBC67BB902BCB8E995977FAB4D2B5642F5B32EBCEEE421921D97E5CBFE39
+ ...
+.fam
+.fi
+.if n .RE
+.sp
+Each line consists of an ID, optional type, and key.
+.sp
+The ID can be any positive integer in the range 1 through 2^32\-1.
+.sp
+The type is a name of a cryptographic hash function or cipher which is used to
+generate and verify the MAC. The default type is \fBMD5\fP, which is always
+supported.
+If \fBchronyd\fP was built with enabled support for hashing using a crypto library
+(Nettle, GnuTLS, 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 of the following hash functions and ciphers may
+also be available:
+\fBSHA3\-224\fP, \fBSHA3\-256\fP, \fBSHA3\-384\fP, \fBSHA3\-512\fP, \fBTIGER\fP, \fBWHIRLPOOL\fP, \fBAES128\fP,
+\fBAES256\fP.
+.sp
+The key can be specified as a string of ASCII 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.
+If the type is a cipher, the length of the key must match the cipher (i.e. 128
+bits for AES128 and 256 bits for AES256).
+.sp
+It is recommended to use randomly generated keys, specified in the hexadecimal
+format, which are at least 128 bits long (i.e. they have at least 32 characters
+after the \fBHEX:\fP prefix). \fBchronyd\fP will log a warning to syslog on start if a
+source is specified in the configuration file with a key shorter than 80 bits.
+.sp
+The recommended key types are AES ciphers and SHA3 hash functions. MD5 should
+be avoided unless no other type is supported on the server and client, or
+peers.
+.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 the \fBchronyd\fP process into RAM so that it
+will never be paged out. This can result in lower and more consistent latency.
+The directive is supported on Linux, FreeBSD, NetBSD, and illumos.
+.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
+.fam C
+pidfile /run/chronyd.pid
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBptpport\fP \fIport\fP
+.RS 4
+The \fBptpport\fP directive enables \fBchronyd\fP to send and receive NTP messages
+contained in PTP event messages (NTP\-over\-PTP) to enable hardware timestamping
+on NICs which cannot timestamp NTP packets, but can timestamp unicast PTP
+packets, and also use corrections provided by PTP one\-step end\-to\-end
+transparent clocks in network switches and routers. The port recognized by the
+NICs and PTP transparent clocks is 319 (PTP event port). The default value is 0
+(disabled).
+.sp
+The NTP\-over\-PTP support is experimental. The protocol and configuration can
+change in future. It should be used only in local networks.
+.sp
+The PTP port will be open even if \fBchronyd\fP is not configured to operate as a
+server or client. The directive does not change the default protocol of
+specified NTP sources. Each NTP source that should use NTP\-over\-PTP needs to
+be specified with the \fBport\fP option set to the PTP port. To actually enable
+hardware timestamping on NICs which can timestamp PTP packets only, the
+\fBrxfilter\fP option of the \fBhwtimestamp\fP directive needs to be set to \fIptp\fP. The
+extension field \fIF324\fP needs to be enabled to use the corrections provided by
+the PTP transparent clocks.
+.sp
+An example of client configuration is:
+.sp
+.if n .RS 4
+.nf
+.fam C
+server ntp1.example.net minpoll 0 maxpoll 0 xleave port 319 extfield F324
+hwtimestamp * rxfilter ptp
+ptpport 319
+.fam
+.fi
+.if n .RE
+.RE
+.sp
+\fBsched_priority\fP \fIpriority\fP
+.RS 4
+On Linux, FreeBSD, NetBSD, and illumos, 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.
+.sp
+On systems other than macOS, this directive uses the \fBpthread_setschedparam()\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 \fBpthread_setschedparam(3)\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 above, 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 illumos \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 "https://www.pool.ntp.org/" "pool.ntp.org" ""
+project.
+.RE
+.sp
+Assuming that your NTP servers are called \fIntp1.example.net\fP, \fIntp2.example.net\fP
+and \fIntp3.example.net\fP, your \fIchrony.conf\fP file could contain as a minimum:
+.sp
+.if n .RS 4
+.nf
+.fam C
+server ntp1.example.net
+server ntp2.example.net
+server ntp3.example.net
+.fam
+.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
+.fam C
+server ntp1.example.net iburst
+server ntp2.example.net iburst
+server ntp3.example.net iburst
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fam
+.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
+.fam C
+pool pool.ntp.org iburst
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fam
+.fi
+.if n .RE
+.sp
+If the servers (or pool) support the Network Time Security (NTS)
+authentication mechanism and \fBchronyd\fP is compiled with NTS support, the \fBnts\fP
+option will enable a secure synchronisation to the servers. The configuration
+file could look like:
+.sp
+.if n .RS 4
+.nf
+.fam C
+server ntp1.example.net iburst nts
+server ntp2.example.net iburst nts
+server ntp3.example.net iburst nts
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fam
+.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 \fIntp1.example.net\fP,
+\fIntp2.example.net\fP and \fIntp3.example.net\fP, your \fIchrony.conf\fP file would now
+contain:
+.sp
+.if n .RS 4
+.nf
+.fam C
+server ntp1.example.net offline
+server ntp2.example.net offline
+server ntp3.example.net offline
+driftfile @CHRONYVARDIR@/drift
+makestep 1.0 3
+rtcsync
+.fam
+.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
+.fam C
+@BINDIR@/chronyc online
+.fam
+.fi
+.if n .RE
+.sp
+and the script \fI/etc/ppp/ip\-down\fP would include:
+.sp
+.if n .RS 4
+.nf
+.fam C
+@BINDIR@/chronyc offline
+.fam
+.fi
+.if n .RE
+.sp
+\fBchronyd\fP\*(Aqs 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 connectivity to any computer which ultimately derives its time from a
+reference clock.
+.sp
+In this situation, one computer is selected to be the primary timeserver. The
+other computers are either direct clients of the server, 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 server\(cqs drift file needs to be set to the average rate
+at which the server 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 server is rebooted, \fBchronyd\fP can re\-read the drift rate from the drift
+file. However, the server has no accurate estimate of the current time. To get
+around this, the system can be configured so that the server can initially set
+itself to a \(oqmajority\-vote\(cq of selected clients\*(Aq times; this allows the
+clients to \(oqflywheel\(cq the server 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 server (called \fIntp.local\fP) might be
+(assuming the clients and the server are in the \fI192.168.165.x\fP subnet):
+.sp
+.if n .RS 4
+.nf
+.fam C
+initstepslew 1 client1 client3 client6
+driftfile @CHRONYVARDIR@/drift
+local stratum 8
+manual
+allow 192.168.165.0/24
+smoothtime 400 0.01
+rtcsync
+.fam
+.fi
+.if n .RE
+.sp
+For the clients that have to resynchronise the server when it restarts,
+the configuration file might be:
+.sp
+.if n .RS 4
+.nf
+.fam C
+server ntp.local iburst
+driftfile @CHRONYVARDIR@/drift
+allow 192.168.165.0/24
+makestep 1.0 3
+rtcsync
+.fam
+.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 primary server, 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
+server 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 primary server 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 \fIntp1.local\fP, \fIntp2.local\fP, and \fIntp3.local\fP):
+.sp
+.if n .RS 4
+.nf
+.fam C
+initstepslew 1 ntp2.local ntp3.local
+server ntp2.local
+server ntp3.local
+driftfile @CHRONYVARDIR@/drift
+local stratum 8 orphan
+manual
+allow 192.168.165.0/24
+rtcsync
+.fam
+.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
+.fam C
+server ntp1.example.net maxdelay 0.4 offline
+server ntp2.example.net maxdelay 0.4 offline
+server ntp3.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
+.fam
+.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
+.fam C
+@BINDIR@/chronyc online
+.fam
+.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
+.fam C
+@BINDIR@/chronyc \-m offline dump writertc
+.fam
+.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\*(Aqs
+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 "https://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
+.fam C
+server ntp1.example.net iburst
+server ntp2.example.net iburst
+server ntp3.example.net iburst
+server ntp4.example.net iburst
+makestep 1.0 3
+rtcsync
+allow
+clientloglimit 100000000
+leapsectz right/UTC
+driftfile @CHRONYVARDIR@/drift
+dumpdir @CHRONYRUNDIR@
+.fam
+.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\-project.org/" "" "."
+.SH "AUTHORS"
+.sp
+chrony was written by Richard Curnow, Miroslav Lichvar, and others.
\ No newline at end of file