doc: add new question about accuracy to FAQ
This commit is contained in:
parent
6d59234995
commit
61f15fedcd
1 changed files with 47 additions and 0 deletions
47
doc/faq.adoc
47
doc/faq.adoc
|
@ -1155,6 +1155,53 @@ There are several different clocks used by `chronyd`:
|
||||||
synchronised by `chronyd`. Its offset is tracked relative to the NTP clock in
|
synchronised by `chronyd`. Its offset is tracked relative to the NTP clock in
|
||||||
order to convert the hardware timestamps.
|
order to convert the hardware timestamps.
|
||||||
|
|
||||||
|
=== How accurate is my system clock?
|
||||||
|
|
||||||
|
`chronyd` does not know how accurate really is the clock it is synchronizing.
|
||||||
|
Even if the measured offset of the clock is stable to nanoseconds, it could be
|
||||||
|
off by milliseconds due to asymmetric network delay, e.g. caused by asymmetric
|
||||||
|
routing or queuing delays in network switches. NTP provides root delay and root
|
||||||
|
dispersion to enable clients to estimate the maximum error of their clock.
|
||||||
|
|
||||||
|
Root delay measures the sum of round-trip times between all NTP servers on the
|
||||||
|
path from the client to the primary time source (e.g. a GPS receiver). Half of
|
||||||
|
the root delay is the maximum error due to asymmetric delays, assuming one
|
||||||
|
direction (e.g. from the client to the server) has a zero delay and the other
|
||||||
|
direction (from the server to the client) takes all of the measured delay. The
|
||||||
|
root delay also covers timestamping errors if the server implementation and
|
||||||
|
hardware meet the NTP requirement for transmit timestamps to never be late and
|
||||||
|
receive timestamps to never be early.
|
||||||
|
|
||||||
|
If you have additional information about the hardware and network between the
|
||||||
|
client and primary time source, you could modify the root delay to get a better
|
||||||
|
estimate of the maximum error. For example, from the physical distance of the
|
||||||
|
server and signal propagation speed in the cables a minimum symmetric
|
||||||
|
round-trip delay can be calculated and subtracted from the root delay measured
|
||||||
|
by NTP.
|
||||||
|
|
||||||
|
Root dispersion estimates errors due to instability of clocks and NTP
|
||||||
|
measurements. `chronyd` adjusts the rate at which root dispersion grows between
|
||||||
|
updates of the clock according to the stability of its NTP measurements. The
|
||||||
|
minimum rate is set by the the `maxclockerror` directive. By default it is 1
|
||||||
|
ppm (1 microsecond per second).
|
||||||
|
|
||||||
|
The estimated maximum error of the NTP clock is the sum of the root dispersion
|
||||||
|
and half of the root delay. This value is called root distance. The current
|
||||||
|
values of root dispersion and delay are included in the `tracking` report.
|
||||||
|
|
||||||
|
The estimated maximum error of the system clock, which is synchronized to the
|
||||||
|
NTP clock, is the sum of the root distance and remaining correction of the
|
||||||
|
system clock provided as `System time` in the `tracking` report. A maximum
|
||||||
|
value of this estimate between updates of the clock is included in the
|
||||||
|
`tracking` log.
|
||||||
|
|
||||||
|
Note that the resolution of the root delay and root dispersion fields in NTP
|
||||||
|
messages is about 15 microseconds and `chronyd` rounds the values up, i.e. the
|
||||||
|
minimum root distance an NTP client can normally observe is about 22.5
|
||||||
|
microseconds. An NTP extension field containing root delay and dispersion in a
|
||||||
|
better resolution of about 4 nanoseconds can be enabled by the `extfield F323`
|
||||||
|
option.
|
||||||
|
|
||||||
== Operating systems
|
== Operating systems
|
||||||
|
|
||||||
=== Does `chrony` support Windows?
|
=== Does `chrony` support Windows?
|
||||||
|
|
Loading…
Reference in a new issue