Update comparison with ntpd

diff --git a/chrony.texi.in b/chrony.texi.in
index e902ac746b1296b5820264121744cd9928c98a8f..cc9a4f9017ce45c38a369fdea37f8a0bcf33a3bd 100644 (file)
--- a/chrony.texi.in
+++ b/chrony.texi.in
@@ -94,9 +94,9 @@ messages between different machines on the network.
 
 In writing the @code{chronyd} program, extensive use has been made of
 RFC1305, written by David Mills.  I have occasionally referred to the
-@code{xntp} suite's source code to check details of the protocol that
+@code{ntp} suite's source code to check details of the protocol that
 the RFC did not make absolutely clear.  The core algorithms in
-@code{chronyd} are all completely distinct from @code{xntp}, however.
+@code{chronyd} are all completely distinct from @code{ntp}, however.
 @c }}}
 @c {{{ S:Availability
 @node Availability
@@ -148,34 +148,50 @@ requires access to such systems to test out the driver.
 @node Other time synchronisation packages
 @section Relationship to other software packages
 @menu
-* Comparison with xntpd::       
+* Comparison with ntpd::
 * Comparison with timed::       
 @end menu
 
-@node Comparison with xntpd
-@subsection xntpd
+@node Comparison with ntpd
+@subsection ntpd
 The `reference' implementation of the Network Time Protocol is the
-program @code{xntpd}, available via
-@uref{http://www.eecis.udel.edu/~ntp, The NTP home page}.
+program @code{ntpd}, available via
+@uref{http://www.ntp.org/, The NTP home page}.
 
-@code{xntpd} is designed to support all the operating modes defined by
-RFC1305, and has driver support for a large number of reference clocks
-(such as GPS receivers) that can be connected directly to a computer,
-thereby providing a so-called 'stratum 1' server.
-
-Things @code{chronyd} can do that @code{xntpd} can't:
+One of the main differences between @code{ntpd} and @code{chronyd} is in
+the algorithms used to control the computer's clock. Things
+@code{chronyd} can do better than @code{ntpd}:
 
 @itemize @bullet
 @item
 @code{chronyd} can perform usefully in an environment where access to
-the time reference is intermittent.  @code{chronyd} estimates
-@emph{both} the current time offset @emph{and} the rate at which the
-computer's clock gains or loses time, and can use that rate estimate to
-trim the clock after the reference disappears.  @code{xntpd} corrects
-any time offset by speeding up and slowing down the computer clock, and
-so could be left with a significant rate error if the reference
-disappears whilst it is trying to correct a big offset.
+the time reference is intermittent.  @code{ntpd} needs regular polling
+of the reference to work well.
+@item
+@code{chronyd} can usually synchronise the clock faster and with better
+time accuracy.
+@item
+@code{chronyd} quickly adapts to sudden changes in the rate of the clock
+(e.g. due to changes in the temperature of the crystal oscillator).
+@code{ntpd} may need a long time to settle down again.
+@item
+@code{chronyd} can perform well even when the network is congested for
+longer periods of time.
+@item
+@code{chronyd} in the default configuration never steps the time to not
+upset other running programs.  @code{ntpd} can be configured to never
+step the time too, but it has to use a different means of adjusting the
+clock, which has some
+disadvantages.
+@item
+@code{chronyd} can adjust the rate of the clock on Linux in a larger
+range, which allows it to operate even on machines with broken or
+unstable clock (e.g. in some virtual machines).
+@end itemize
+
+Things @code{chronyd} can do that @code{ntpd} can't:
 
+@itemize @bullet
 @item
 @code{chronyd} provides support for isolated networks whether the only
 method of time correction is manual entry (e.g. by the administrator
@@ -189,33 +205,27 @@ subsequently.
 `real-time clock', i.e. the clock that maintains the time when the
 computer is turned off.  It can use this data when the system boots to
 set the system time from a corrected version of the real-time clock.
-These real-time clock facilities are only available on certain releases
-of Linux, so far.
-
-@item
-The @code{xntpd} program is supported by other programs to carry out
-certain functions.  @code{ntpdate} is used to provide an initial
-correction to the system clock based on a `one-shot' sampling of other
-NTP servers.  @code{tickadj} is used to adjust certain operating system
-parameters to make @code{xntpd} work better.  All this functionality is
-integrated into @code{chronyd}.
+These real-time clock facilities are only available on Linux, so far.
 @end itemize
 
-Things @code{xntpd} can do that @code{chronyd} can't:
+Things @code{ntpd} can do that @code{chronyd} can't:
 
 @itemize @bullet
 @item
-@code{xntpd} supports effectively all of RFC1305, including broadcast /
-multicast clients and extra encryption schemes for authenticating
-data packets.
+@code{ntpd} fully supports NTP version 4 (RFC5905), including broadcast,
+multicast, manycast clients / servers and the orphan mode.  It also
+supports extra authentication schemes based on public-key cryptography
+(RFC5906). @code{chronyd} uses NTP version 3 (RFC1305), which is
+compatible with version 4.
 
 @item
-@code{xntpd} has been ported to more types of computer / operating
-system (so far).
+@code{ntpd} has been ported to more types of computer / operating
+system.
 
 @item
-xntpd is designed to work solely with integer arithmetic (i.e. does not
-require floating point support from its host).
+@code{ntpd} includes drivers for many reference clocks. @code{chronyd}
+relies on other programs (e.g. gpsd) to access the data from the
+reference clocks.
 @end itemize
 
 @node Comparison with timed
@@ -1417,7 +1427,7 @@ 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 software (e.g. various MS Windows clients).
 
-If xntpd is used as the broadcast client, it will try to use a point-to-point
+If ntpd is used as the broadcast client, it will try to use a point-to-point
 client/server NTP access to measure the round-trip delay.  Thus, the broadcast
 subnet should also be the subject of an @code{allow} directive (@pxref{allow
 directive}).
@@ -2492,7 +2502,7 @@ on your machine.
 The compiled in default is udp/123, the standard NTP port.  It is
 unlikely that you would ever need to change this value.  A possible
 exception would be if you wanted to operate strictly in client-only
-mode and never be available as a server to xntpd clients.
+mode and never be available as a server to ntpd clients.
 
 An example of the port command is