205 lines
10 KiB
HTML
205 lines
10 KiB
HTML
<HTML><HEAD><TITLE>
|
|
NTP Version 4 Release Notes
|
|
</TITLE></HEAD><BODY><H3>
|
|
NTP Version 4 Release Notes
|
|
</H3>
|
|
|
|
<IMG align=left SRC=pic/hornraba.gif> <i>Alice's Adventures in
|
|
Wonderland</i>, by Lewis Carroll, illustrations by Sir John Tenniel
|
|
<BR clear=left><HR>
|
|
|
|
<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
|
|
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>
|
|
|
|
<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
|
|
</A> 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 <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
|
|
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 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
|
|
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
|
|
from the export version of the distribution. These routines are readily
|
|
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
|
|
setting f<TT>fudge flag3</TT> for the serial port connected to the PPS
|
|
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
|
|
should precede these commands.</LI>
|
|
|
|
</OL>
|
|
|
|
<H4>Caveats</H4>
|
|
|
|
This release has been compiled and tested on several systems, including
|
|
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:
|
|
|
|
<OL>
|
|
|
|
<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.
|
|
|
|
<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>
|
|
|
|
<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>
|
|
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>
|
|
|
|
<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>
|
|
|
|
<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
|
|
limited to clients with only a single network interface.</LI>
|
|
|
|
<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>
|
|
|
|
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
|
|
href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
|
|
</address></a></body></html>
|