NTP Version 4 Release Notes
Isaac
Newton's Apple Tree
NTP Version 4 Release Notes
This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates
new features and refinements to the NTP Version 3 (NTPv3) algorithms. However,
it continues the tradition of retaining backwards compatibility with older
versions. The NTPv4 version has been under development for quite a while
and isn't finished yet. In fact, quite a number of NTPv4 features have
already been implemented in the current NTPv3. The primary purpose of this
release is to verify the remaining new code compiles and runs in the various
architectures, operating systems and hardware complement that can't be
verified here. Of particular interest are Windows NT, VMS and various reference
clock drivers. As always, corrections and bugfixes are warmly received,
especially in the form of context diffs.
This note summarizes the differences between this software release of
NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called xntp3-5.x.x
-
Most of the extensive calculations are now done using 64-bit floating-point
format, rather than 64-bit fixed-point format. The motivation for this
is to reduce size, improve speed and avoid messy bounds checking. Workstations
of today are much faster than when the original NTP version was designed
in the early 1980s, and it is rare to find a processor architecture that
does not support it. The fixed-point format is still used with raw timestamps,
in order to retain the full precision of about 212 picoseconds. However,
the algorithms which process raw timestamps all produce fixed-point differences
before converting to double. The differences are ordinarily quite small
so can be expressed without loss of accuracy in double format.
-
The clock discipline algorithm has been redesigned to improve accuracy,
reduce the impact of network jitter and allow an increase in poll intervals
to well over one day with only moderate sacrifice in accuracy. The NTPv4
design allows servers to increase the poll intervals even when synchronized
directly to the peer. In NTPv3 the poll interval in such cases was clamped
to the minimum, usually 64 s. For those servers with hundreds of clients,
the new design can dramatically reduce the network load.
-
A burst-mode feature is available which results
in good accuracy with intermittent connections typical of PPP and ISDN
services. When enabled, at each poll interval the server sends eight messages
over the next 30-s interval and processes them in a batch. Outlyers due
to initial dial-up delays, etc., are avoided and the server synchronizes
with its peer generally within 30 s.
-
In addition to the NTPv3 authentication scheme, which uses private-key
cryptography, a new NTPv4 autokey authentication
scheme is available. Autokey uses public-key technology and avoids the
need to distribute keys by separate means. The design is such that full
accuracy is available without degradation due to processing demands of
the public-key routines. It can be used in any of the NTP association modes,
but is most useful in broadcast/multicast modes.
-
NTPv4 includes two new association modes which in most applications can
avoid per-host configuration altogether. Both of these are based on multicast
technology. They provide for automatic discovery and configuration of servers
and clients. In multicast mode, a server sends
a message at fixed intervals using specified multicast addresses, while
clients listen on these addresses. Upon receiving the message, a client
exchanges several messages with the server in order to calibrate the multicast
propagation delay between the client and server. In manycast
mode, a client sends a message and expects one or more servers to reply.
Using engineered algorithms, the client selects an appropriate subset of
servers from the messages received and continues in ordinary client/server
operation with them. The manycast scheme can provide somewhat better accuracy
than the multicast scheme at the price of additional network overhead.
-
The reference clock driver interface is smaller, more rational and more
accurate. Support for pulse-per-second (PPS) signals has been extended
to all drivers as an intrinsic function. Most of the drivers in NTPv3 have
been converted to this interface, but some, including the PARSE subinterface,
have yet to be overhauled. New drivers have been added for several GPS
receivers now on the market. Drivers for the Canadian standard time and
frequency station CHU and for audio IRIG signals have been updated and
capabilites added to allow direct connection of these signals to the Sun
audio port /dev/audio.
-
In all except a very few cases, all timing intervals are randomized, so
that the tendency for NTPv3 to bunch messages, especially with a large
number of configured associations, is minimized.
-
In NTPv3 a large number of weeds and useless code had grown over the years
since the original NTPv1 code was implemented almost ten years ago. Using
a powerful weedwacker, much of the shrubbery has been removed, with effect
a substantial reduction in size of almost 40 percent.
-
The entire distribution has been converted to gnu automake, which
should greatly ease the task of porting to new and different programming
environments, as well as reduce the incidence of bugs due to improper handling
of idiosyncratic kernel functions.
Nasty Surprises
There are a few things different about this release that have changed since
the latest NTP Version 3 release. Following are a few things to worry about:
-
As required by Defense Trade Regulations (DTR), the cryptographic routines
supporting the Data Encryption Standard (DES) and Message Digest 5 (MD5)
have been removed from the export version of the distribtution. These routines
are readily available in most countries from RSA Laboratories. Directions
for their use are in the Building and Installing the
Distribution page.
-
As the result of the above, the ./authstuff directory, intended
as a development and testing aid for porting cryptographic routines to
exotic architectures, has been removed. Developers should note the NTP
authentication routines use the interface defined in the rsaref2.0
package available from RSA laboratories.
-
The enable and disable commands have a few changes in their arguments see
the ntpd Configuration Options page
for details.
-
The scheme for enabling the ppsclock line discipline/streams module
has changed. Formerly, it was enabled by setting fudge flag3 for
the serial port connected to the PPS signal. Now, there is an explicit
command pps used to designate the device name. See the Reference
Clock Options page for details.
-
While in fact not a new problem, some obscure option combinations require
the server and peer commands to follow the others; in
particular, the enable and pps commands should preceed
these commands.
Caveats
This release has been compiled and tested on several systems, including
SunOS 4.1.3, Solaris 2.5.1 and 2.6, Alpha 4.0, Ultrix 4.4, Linux, FreeBSD
and HP-UX 10.02. It has not been compiled for Windows NT or VMS. We are
relying on the NTP volunteer brigade to do that. Known problems are summarized
below:
-
To work properly in all cases, the enable and pps commands,
if used, should appear before the server and fudge commands
in the configuration file.
-
The precision time kernel modifications now in stock Solaris 2.6 have bugs.
The kernel discipline has been disabled by default. For testing, the kernel
can be enabled using the enable kernel command either in the configuration
file or via ntpdc..
-
On Alpha 4.0 with reference clocks configured, debugging with the -d
options doesn't work.
-
The autokey function requires an NTP header extensions field, which is
documented in an internet draft and implemented in this release. This field
holds the public-key signature and certificate; however, the detailed format
for these data have not yet been determined. It is expected this will happen
in the near future and that implementation of the required algorithms will
quickly follow using available cryptographic algorithms.
-
The manycast function still needs some work. Ideally, the existing I/O
routines would be enhanced to include the capability to determine the source
address on every multicast packet sent, so that the autokey function could
reliably construct the correct cryptosum. Meanwhile, the utility of manycast
in conjunction with autokey is limited to clients with only a single network
interface.
-
The HTML documentation has been partially updated. However, most of the
NTPv3 documentation continues to apply to NTPv4. Until the update happens,
what you see is what you get. We are always happy to accept comments, corrections
and bug reports. However, we are most thrilled upon receipt of patches
to fix the dang bugs.
David L. Mills (mills@udel.edu)