Adding upstream version 4.0.upstream/4.0upstream

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

1 files changed, 676 insertions, 0 deletions

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