2000-03-29 16:38:44 +04:00
< HTML > < HEAD > < TITLE >
NTP Version 4 Release Notes
< / TITLE > < / HEAD > < BODY > < H3 >
NTP Version 4 Release Notes
< / H3 >
< H4 > NTP Version 4 Release Notes< / H4 >
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.
< P > 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
< OL >
< P > < LI > 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.< / LI >
< P > < LI > 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.< / LI >
< P > < LI > A < A HREF = assoc.htm > burst-mode< / A > 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
2000-04-22 18:51:59 +04:00
batch. However, the interval between the first and subsequent messages
is about 20 s in order for a dialup modem to complete the call. Outlyers
due to initial dial-up delays, etc., are avoided and the server
synchronizes with its peer generally within 30 s.< / LI >
2000-03-29 16:38:44 +04:00
< P > < LI > In addition to the NTPv3 authentication scheme, which uses
private-key cryptography, a new NTPv4 < A HREF = authopt.htm > autokey
< / A > 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.< / LI >
< P > < LI > 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 < A HREF = assoc.htm > multicast
2000-04-22 18:51:59 +04:00
< / A > mode, a server sends a message at fixed intervals using specified
2000-03-29 16:38:44 +04:00
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 < A HREF = assoc.htm > manycast < / A > 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.< / LI >
< P > < LI > The reference clock driver interface is smaller, more rational
2000-04-22 18:51:59 +04:00
and more accurate. Support for pulse-per-second (PPS) signals has been
2000-03-29 16:38:44 +04:00
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
2000-04-22 18:51:59 +04:00
added for several GPS receivers now on the market for a total of 37
drivers. Drivers for the Canadian standard time and frequency station
CHU, the US standard time and frequency stations WWV/H and for IRIG
signals have been updated and capabilities added to allow direct
2000-03-29 16:38:44 +04:00
connection of these signals to the Sun audio port
< TT > /dev/audio< / TT > .< / LI >
< P > < LI > 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.< / LI >
< P > < LI > 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.< / LI >
< P > < LI > The entire distribution has been converted to < TT > gnu
automake< / TT > , 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.< / LI >
< / OL >
< H4 > Nasty Surprises< / H4 >
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:
< OL >
< P > < LI > As required by Defense Trade Regulations (DTR), the cryptographic
routines supporting the Data Encryption Standard (DES) has been removed
2000-04-22 18:51:59 +04:00
from the export version of the distribution. These routines are readily
2000-03-29 16:38:44 +04:00
available in most countries from RSA Laboratories. Directions for their
use are in the < A HREF = build.htm > Building and Installing the
Distribution< / A > page.< / LI >
< P > < LI > As the result of the above, the < TT > ./authstuff< / TT > 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
< TT > rsaref2.0< / TT > package available from RSA laboratories.< / LI >
< P > < LI > The enable and disable commands have a few changes in their
arguments see the < TT > ntpd< / TT > < A HREF = confopt.htm > Configuration
Options< / A > page for details.< / LI >
< P > < LI > The scheme for enabling the < TT > ppsclock< / TT > line
discipline/streams module has changed. Formerly, it was enabled by
2000-04-22 18:51:59 +04:00
setting f< TT > fudge flag3< / TT > for the serial port connected to the PPS
2000-03-29 16:38:44 +04:00
signal. Now, there is an explicit command < TT > pps< / TT > used to designate
the device name. See the < A HREF = clockopt.htm > Reference Clock
Options< / A > page for details.< / LI >
< P > < LI > While in fact not a new problem, some obscure option combinations
require the < TT > server< / TT > and < TT > peer< / TT > commands to follow the
others; in particular, the < TT > enable< / TT > and < TT > pps< / TT > commands
2000-04-22 18:51:59 +04:00
should precede these commands.< / LI >
2000-03-29 16:38:44 +04:00
< / OL >
< H4 > Caveats< / H4 >
This release has been compiled and tested on several systems, including
2000-04-22 18:51:59 +04:00
SunOS 4.1.3, Solaris 2.5.1 and 2.7, Alpha 4.0, Ultrix 4.4, Linux,
FreeBSD 3.4 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:
2000-03-29 16:38:44 +04:00
< OL >
2000-04-22 18:51:59 +04:00
< p > < li > The latest NTPv4 < tt > ntpdc< / tt > does not work with previous versions of < tt > ntpd< / tt > and previous versions of < tt > ntpdc< / tt > do not work with latest < tt > ntpd< / tt > . This situation is regrettable and may be fixed in future; however, it is necessary in order for the autokey function to retrieve canonical names and certificates from directory services such as Secure DNS.
2000-03-29 16:38:44 +04:00
< P > < LI > To work properly in all cases, the < TT > enable< / TT > and
< TT > pps< / TT > commands, if used, should appear before the < TT > server< / TT >
and < TT > fudge< / TT > commands in the configuration file.< / LI >
2000-04-22 18:51:59 +04:00
< P > < LI > The precision time kernel modifications formerly in stock Solaris
2.6 have bugs that were fixed in 2.7. A patch is available that fixes
the 2.6 bugs. The 2.6 kernel discipline has been disabled by default.
For testing, the kernel can be enabled using the < TT > enable kernel< / TT >
2000-03-29 16:38:44 +04:00
command either in the configuration file or via < TT > ntpdc< / TT > .< / LI >
< P > < LI > On Alpha 4.0 with reference clocks configured, debugging with the
< TT > -d< / TT > options doesn't work.< / LI >
2000-04-22 18:51:59 +04:00
< P > < LI > The autokey function uses NTP header extensions fields,
which is documented in an Internet Draft and implemented in this
release. At present the keys and related cryptographic data are stored
in the form of files generated by the < a
href=genkeys.htm>ntp_genkeys< / a > program. It is expected that in future
these values will be obtained automatically from the Secure DNS
following deployment.< / LI >
2000-03-29 16:38:44 +04:00
< P > < LI > 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
2000-04-22 18:51:59 +04:00
limited to clients with only a single network interface.< / LI >
2000-03-29 16:38:44 +04:00
< P > < LI > 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.< / LI >
< / OL >
2000-04-22 20:46:49 +04:00
< hr > < a href = index.htm > Home< / a > < address > < a
2000-03-29 16:38:44 +04:00
href=mailto:mills@udel.edu> David L. Mills < mills@udel.edu> < / a >
< / address > < / a > < / body > < / html >
