diff options
Diffstat (limited to 'contrib/ntp/html/release.htm')
| -rw-r--r-- | contrib/ntp/html/release.htm | 199 |
1 files changed, 199 insertions, 0 deletions
diff --git a/contrib/ntp/html/release.htm b/contrib/ntp/html/release.htm new file mode 100644 index 0000000..8b29cb9 --- /dev/null +++ b/contrib/ntp/html/release.htm @@ -0,0 +1,199 @@ +<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. 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 moreaccurate. 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 +<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 distribtution. 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>udge 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 preceed 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.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: + +<OL> + +<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 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 <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 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.</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> |
