-Protocol Conformance Statement -

From: Harlan Stenn Date: Sat, 14 Dec 2002 17:37:57 +0000 (-0500) Subject: Documentation cleanup from Dave Mills. X-Git-Tag: NTP_4_1_73~20^2~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8f66656cd0210034b9205f4e4b47f561f025d029;p=thirdparty%2Fntp.git Documentation cleanup from Dave Mills. bk: 3dfb6c75pZZI9fvUWmUnL7qi9WsicQ --- diff --git a/html/accopt.html b/html/accopt.html index ac419c092a..74d8ca3fbc 100644 --- a/html/accopt.html +++ b/html/accopt.html @@ -10,13 +10,12 @@

Access Control Options

from Pogo, Walt Kelly + gif

from Pogo, Walt Kelly

The skunk watches for intruders and sprays.

Last update: 20:34 UTC Monday, December 02, 2002

Association Management

from Alice's Adventures in Wonderland, Lewis Carroll + gif

from Alice's Adventures in Wonderland, Lewis Carroll

Make sure who your friends are.

Last update: 20:34 UTC Monday, December 02, 2002

Association Modes

NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the Configuration Options and Authentication Options pages and in the papers, reports, memoranda and briefings at www.ntp.org.

There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message.

There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a Manycast client association is mobilized upon arrival of a Manycast server message.

Ordinarily, successful mobilization of an ephemeral association requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric-key or public-key cryptography, as described in the Authentication Options page. The cryptographic means insure an unbroken chain of trust between the dependent client and the primary servers at the root of the synchronization subnet. We call this chain the provenance of the client and define new vocabulary as to proventicate a client or provide proventic credentials. Once mobilized, ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) the server refreshes the key media without notifying the client.

There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP Multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and proventic values and means of configuration. Following is a summary of the operations in each mode.

There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP Multicast support: multicast and Manycast. These modes are selected based on the scope of service, intended flow of time and proventic values and means of configuration. Following is a summary of the operations in each mode.

Client/Server Mode

Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and proventic values from the server. A client is configured in client mode using the server (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme. In addition, two burst modes described below can be used in appropriate cases.

Symmetric Active/Passive Mode

@@ -47,7 +46,7 @@

A multicast client is configured using the broadcast command, but with a multicast group address instead of a local subnet broadcast address. However, there is a subtle difference between IPv4 broadcasting and multicasting. IPv4 broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate broadcast command applies to each one separately. This provides a way to limit exposure in a firewall, for example. For IPv6 the same distinction can be made using prefix FF02 for link-local and FF05 for site-local.

IP multicasting is a different paradigm. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which may require these messages emit from one or all interfaces, but carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple broadcast commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.

Manycasting

Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes client associations with some number of the "best" of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic NTP Configuration Options page.

Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating Manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each Manycast client mobilizes client associations with some number of the "best" of the nearbyanycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic NTP Configuration Options page.

Burst Modes

There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the usual one. The burst mode sends a burst when the server is reachable, while the iburst mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. The calldelay command can be used to increase the interval between the first and second packets in the burst in order to allow a modem to complete a call. Received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.

The iburst keyword can be configured for cases where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first message.

diff --git a/html/audio.html b/html/audio.html index f5f1b02749..46665d5672 100644 --- a/html/audio.html +++ b/html/audio.html @@ -10,10 +10,11 @@

Reference Clock Audio Drivers

ICOM R-72 shortwave receiver and Sure audio mixer +

Last update: 20:34 UTC Monday, December 02, 2002

Sound Card Drivers

There are some applications in which the computer time can be disciplined to an audio signal, rather than a serial timecode and communications port or special purpose bus peripheral. This is useful in such cases where the audio signal is sent over a telephone circuit, for example, or received directly from a shortwave receiver. In such cases the audio signal can be connected via an ordinary sound card or baseboard audio codec. The suite of NTP reference clock drivers currently includes three drivers suitable for these applications. They include a driver for the Inter Range Instrumentation Group (IRIG) signals produced by most radio clocks and timing devices, another for the Canadian time/frequency radio station CHU and a third for the NIST time/frequency radio stations WWV and WWVH. The radio drivers are designed to work with ordinary inexpensive shortwave radios and may be one of the least expensive ways to build a good primary time server.

There are some applications in which the computer time can be disciplined to an audio signal, rather than a serial timecode and communications port or special purpose bus peripheral. This is useful in such cases where the audio signal is sent over a telephone circuit, for example, or received directly from a shortwave receiver. In such cases the audio signal can be connected via an ordinary sound card or baseboard audio codec. The suite of NTP reference clock drivers currently includes three drivers suitable for these applications. They include a driver for the Inter Range Instrumentation Group (IRIG) signals produced by many radio clocks and timing devices, another for the Canadian time/frequency radio station CHU and a third for the NIST time/frequency radio stations WWV and WWVH. The radio drivers are designed to work with ordinary inexpensive shortwave radios and may be one of the least expensive ways to build a good primary time server.

All three drivers make ample use of sophisticated digital signal processing algorithms designed to efficiently extract timing signals from noise and interference. The radio station drivers in particular implement optimum linear demodulation and decoding techniques, including maximum likelihood and soft-decision methods. The documentation page for each driver contains an in-depth discussion on the algorithms and performance expectations. In some cases the algorithms are further analyzed, modelled and evaluated in a technical report.

Currently, the audio drivers are compatible with Sun operating systems and audio codecs, including SunOS 4.1.3 and Solaris 2.8 and probably all others in between. In fact, the interface is quite generic and support for other systems, in particular the various Unix generics, should not be difficult. Volunteers are solicited.

Currently, the audio drivers work with with Sun operating systems and audio codecs, including SunOS 4.1.3 and Solaris from 2.6 and probably all others in between. They also work with FreeBSD from 4.1 with compatible sound card. In fact, the interface is quite generic and support for other systems, in particular the various Unix generics, should not be difficult. Volunteers are solicited.

The audio drivers include a number of common features designed to groom input signals, suppress spikes and normalize signal levels. An automatic gain control (AGC) feature provides protection against overdriven or underdriven input signals. It is designed to maintain adequate demodulator signal amplitude while avoiding occasional noise spikes. In order to assure reliable operation, the signal level must be in the range where the audio gain control is effective. In general, this means the input signal level must be such as to cause the AGC to set the gain somewhere in the middle of the range from 0 to 255, as indicated in the timecode displayed by the ntpq program.

The drivers operate by disciplining a logical clock based on the codec sample clock to the audio signal as received. This is done by stuffing or slipping samples as required to maintain exact frequency to the order of 0.1 PPM. In order for the driver to reliably lock on the audio signal, the sample clock frequency tolerance must be less than 250 PPM (.025 percent) for the IRIG driver and half that for the radio drivers. The largest error observed so far is about 60 PPM, but it is possible some sound cards or codecs may exceed that value.

The drivers include provisions to select the input port and to monitor the input signal. The fudge flag 2 selects the microphone port if set to zero or the line-in port if set to one. It does not seem useful to specify the compact disc player port. The fudge flag 3 enables the input signal monitor using the previously selected output port and output gain. Both of these flags can be set in the configuration file or remotely using the ntpdc utility program.

@@ -44,10 +45,8 @@

The best way to choose a frequency is to listen at various times over the day and determine the best highest (daytime) and lowest (nighttime) frequencies. Then, assuming one is available, choose the highest frequency between these frequencies. This strategy assumes that the high frequency is more problematic than the low, that the low frequency probably comes with severe multipath and static, and insures that probably twice a day the chosen frequency will work. For instance, on the east coast the best compromise CHU frequency is probably 7335 kHz and the best WWV frequency is probably 15 MHz.

Setup and Debugging Aids

The audio drivers include extensive setup and debugging support to help hook up the audio signals and monitor the driver operations. The documentation page for each driver describes the various messages that can be produced either in real time or written to the clockstats file for later analysis. Of particular help in verifying signal connections and compatibility is a provision to monitor the signal via headphones or speaker.

Connecting radios and IRIG devices to the computer and verifying correct configuration is somewhat of a black art for some. The signals have to be connected to the correct ports and the signal level maintained within tolerances. Some radios have recorder outputs which produce a line level signal not affected by the volume control. These signals can be connected to the line-in port on the computer. If the level is too low, connect to the microphone-in port instead. The drivers use the fudge flag2 command to set the input port; 0 (default) selects the microphone-in, 1 selects the line-in port. The carrier level indicated by the driver should be comfortably above the minimum specified and the AGC level somewhere in the middle of the range 0-255. If the radio does not have a recorder output, connect the headphone or speaker output to the line-in port and adjust the volume control so the driver indicates comfortably above the minimum specified and the AGC level somewhere in the middle of the range 0-255.

IRIG signals are usually much larger in the range several volts and may even overload the line-in port. In such cases an attenuator must be used to reduce the signal level below the overload point.

It is very easy to underdrive or overdrive the audio codec, in which case the drivers will not synchronize to the signal. The most useful drive indicator is the AGC level provided in the driver debug display. A value of zero indicates either the signal is absent, connected to the wrong port or below the minimum threshold. A value of 255 indicates an overdriven condition and the signal level must be reduced. Usually this happens when the signal is connected to the microphone-in port and is easily corrected by connecting to the line-in port instead.

The drivers use fudge flag2 to enable audio monitoring of the input signal. This is useful during setup to confirm the signal is actually reaching the audio codec and generally free of hum and interference. This feature is not intended for regular use, since it does increase the processor load on the system. Note that the speaker volume must be set before the driver is started.

Connecting radios and IRIG devices to the computer and verifying correct configuration is somewhat of a black art. The signals have to be connected to the correct ports and the signal level maintained within tolerances. Some radios have recorder outputs which produce a line level signal not affected by the volume control. These signals can be connected to the line-in port on the computer. If the level is too low, connect to the microphone-in port instead. If the radio does not have a recorder output, connect the headphone or speaker output to the line-in port and adjust the volume control so the driver indicates comfortably above the minimum specified and the AGC level somewhere in the middle of the range 0-255. IRIG signals are usually much larger than radio outputs, usually in the range to several volts and may even overload the line-in port. In such cases an attenuator must be used to reduce the signal level below the overload point.

It is very easy to underdrive or overdrive the audio codec, in which case the drivers will not synchronize to the signal. The drivers use fudge flag2 to enable audio monitoring of the input signal. This is useful during setup to confirm the signal is actually reaching the audio codec and generally free of hum and interference. This feature is not intended for regular use, since it does increase the processor load on the system. Note that the speaker volume must be set before the driver is started.

The drivers write a synthesized timecode to the clockstats file each time the clock is set or verified and at other times if verbose monitoring is enabled. The format includes several fixed-length fields defining the UTC time to the millisecond, together with additional variable-length fields specific to each driver. The data include the intervals since the clock was last set or verified, the audio gain and various state variables and counters specific to each driver.

diff --git a/html/authopt.html b/html/authopt.html index ae656676af..0c7da159b7 100644 --- a/html/authopt.html +++ b/html/authopt.html @@ -10,11 +10,12 @@

Authentication Options

from Alice's Adventures in Wonderland, Lewis Carroll + gif

from Alice's Adventures in Wonderland, Lewis Carroll

Our resident cryptographer; now you see him, now you don't.

Last update: 20:35 UTC Monday, December 02, 2002

Public Key Cryptography

NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. The Autokey Version 2 protocol verifies packet integrity using MD5 message digests and verifies the source with digital signatures and any of several digest/signature schemes. Optional identity schemes based on cryptographic challenge/response algorithms are also available. Using all of these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.

NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the Autokey Protocol page verifies packet integrity using MD5 message digests and verifies the source with digital signatures and any of several digest/signature schemes. Optional identity schemes based on cryptographic challenge/response algorithms are also available. Using all of these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.

The cryptographic means necessary for all Autokey operations provided by the OpenSSL software library. This library is available from http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the interface routines required.

The Autokey protocol has several modes of operation corresponding to the various NTP modes supported. Most modes use a special cookie which can be computed independently by the client and server, but encrypted in transmission. All modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. These schemes are described along with an executive summary, current status, briefing slides and reading list, on the Autonomous Authentication page.

The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links. This includes a required host key file, required certificate file and optional sign key file, leapsecond file and identity scheme files. The digest/signature scheme is specified in the X.509 certificate along with the matching sign key. There are several schemes available in the OpenSSL software library, each identified by a specific string such as md5WithRSAEncryption, which stands for the MD5 message digest with RSA encryption scheme. The current NTP distribution supports all the schemes in the OpenSSL library, including those based on RSA and DSA digital signatures. The schemes currently available are described in the ntp-keygen page.

The digest/signature scheme and certificate are provided to dependent clients in the Autokey protocol. Different client or peer associations can use different schemes; each of two symmetric peers can use different schemes. Note that the digest/signature scheme is separate and distinct from the NTP message digest used to construct the packet MAC. The only requirement is that the server sign key and signature algorithm must match the public key and verification algorithm specified in the certificate.

Autokey Dances

The Autokey protocol is somewhat intricate and a detailed explanation of the subprotocols, called dances, is beyond the scope of this page. Detailed information and briefings can be found on the Autonomous Authentication page cited above. Briefly, the dances start when a client requests the server name and status word. Next, the client requests the server certificate containing the public key used to sign subsequent messages. If the issuer of that certificate is not the server, the issuer certificate is requested. This process continues until a trusted, self-signed certificate is obtained.

The Autokey protocol is somewhat intricate and a detailed explanation of the subprotocols, called dances, is beyond the scope of this page. Detailed information and briefings can be found on the Autokey Protocol page. Briefly, the dances start when a client requests the server name and status word. Next, the client requests the server certificate containing the public key used to sign subsequent messages. If the issuer of that certificate is not the server, the issuer certificate is requested. This process continues until a trusted, self-signed certificate is obtained.

Next comes the optional identity scheme which confirms the server group membership. A group is a clique of client and server hosts conforming to the following:

Each group member holds a private group key generated by a trusted authority. diff --git a/html/biblio.html b/html/biblio.html deleted file mode 100644 index 7f621d3555..0000000000 --- a/html/biblio.html +++ /dev/null @@ -1,106 +0,0 @@ - -Protocol Conformance Statement -

-Protocol Conformance Statement -

- -

From The -Wizard of Oz, L. Frank Baum - -

Say it three times and it must be right. -
-

- -

The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC), as provided by a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks. - -

Information on the NTP architecture, protocol and algorithms can be found in the following articles and reports, which are available online. General issues of the concepts and facilities assumed by NTP are discussed in the Executive Summary - Computer Network Time Synchronization page, while issues related to the NTP timescale and pending century are discussed in the Network Time Protocol Year 2000 Conformance Statement page, both of which are included in this software distribution. Network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP community, see the David L. Mills web page. A historical perspective is available in - -

Mills, D.L. A brief history of NTP time: confessions of an Internet timekeeper. Submitted for publication; please do not cite or redistribute. PostScript | PDF - -

- -

The NTP architecture, protocol and algorithm models are described in - -

Mills, D.L. Internet time synchronization: the Network Time Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-1493. PostScript | PDF. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and Time in Distributed Systems. IEEE Computer Society Press, Los Alamitos, CA, 1994, 91-102. - -

- -

The NTP specification and implementation has evolved over the last two decades to the current Version 4 of the protocol. This version includes significant enhancements in accuracy and reliability, as determined by experience in an estimated total of well over 100,000 clients and servers in the Internet, while retaining backward compatibility with previous versions. This software distribution contains an implementation of the NTP Version 4 architecture, protocol and algorithms. While a formal specification of this version is not yet available, this version is fully compliant with the previous NTP Version 3 specification and implementation defined in -

Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: PostScript) | PDF, Body: PostScript) | PDF, Appendices: PostScript | PDF. - -

- -

The NTP Version 4 implementation adds a number of extensions and refinements to the previous version, including an autonomous configuration and authentication capability, improved clock discipline algorithms capable of submicrosecond accuracy and many other refinements. Specific changes since the Version 3 specification was issued include: - -

Support for precision-time kernel modifications, as described in - -
Mills, D.L., and P.-H. Kamp. The nanokernel. Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Reston VA, November 2000). Paper: PostScript | PDF, Slides: HTML | PostScript | PowerPoint - -
Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: PostScript | PDF, Body: PostScript | PDF. Major revision and update of: Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. ASCII - -
Support for IP Multicasting, as described the Association Management page and in - -
Mills, D.L, and A. Thyagarajan. Network time protocol version 4 proposed changes. Electrical Engineering Department Report 94-10-2, University of Delaware, October 1994, 32 pp. Abstract: PostScript | PDF, Body: PostScript | PDF - -
A new hybrid phase/frequency-lock clock discipline, which -replaces the RFC-1305 local clock algorithm, as described in

Mills, D.L. Improved algorithms for synchronizing computer network clocks. IEEE/ACM Trans. Networks 3, 3 (June 1995), 245-254. PostScript | PDF - -

Mills, D.L. Clock discipline algorithms for the Network Time Protocol Version 4. Electrical Engineering Report 97-3-3, University of Delaware, March 1997, 35 pp. Abstract: PostScript | PDF, Body: PostScript | PDF - -

Simple Network Monitoring Protocol (SNMP) monitoring tools, as described in

Sethi, A.S., H. Gao, and D.L. Mills. Management of the Network Time Protocol (NTP) with SNMP. Computer and Information Sciences Report 98-09, University of Delaware, November 1998, 32 pp. PostScript | PDF - -

Engineered refinements to radio clock drivers and interface code, as described in in the Pulse-per-second (PPS) Signal Interfacing page and

Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. ASCII - -

Mills, D.L. Precision synchronization of computer network clocks. ACM Computer Communication Review 24, 2 (April 1994). 28-43. PostScript | PDF - -

Support for over two dozen reference clock drivers for all known national and international radio, satellite and modem standard time services known at this time. See the Reference Clock Drivers page.

A new security model and authentication scheme based on public-key cryptography called Autokey, as described in the Authentication Options page and in

Mills, D.L. Public-Key cryptography for the Network Time Protocol. Internet Draft draft-ietf-stime-ntpauth-00.txt, University of Delaware, June 2000, 36 pp. ASCII - -

Mills, D.L. Public key cryptography for the Network Time Protocol. Electrical Engineering Report 00-5-1, University of Delaware, May 2000. 23 pp. Abstract: PostScript | PDF, Body: PostScript | PDF - -

Mills, D.L. Authentication scheme for distributed, ubiquitous, real-time protocols. Proc. Advanced Telecommunications/Information Distribution Research Program (ATIRP) Conference (College Park MD, January 1997), 293-298. PostScript | PDF - -

Mills, D.L. Proposed authentication enhancements for the Network Time -Protocol version 4. Electrical Engineering Report 96-10-3, University of -Delaware, October 1996, 36 pp. Abstract: PostScript | PDF, Body: PostScript | PDF - -

Support for the MD5 cryptographic hash algorithm, in addition to the DES-CBC algorithm described in RFC-1305, as described in the ntpd - Network Time Protocol (NTP) daemon page.

The prefer-peer scheme, as described in the Mitigation Rules and the prefer Keyword page.

Specification for the Simple Network Time Protocol (SNTP), as described in

Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4, IPv6 and OSI. Network Working Group Report RFC-2030, University of Delaware, October 1996, 18 pp. ASCII. Obsoletes RFC-1769 and RFC-1361. - -

Support for International Atomic Time (TAI), as described in

Levine, J., and D. Mills. Using the Network Time Protocol to transmit International Atomic Time (TAI). Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Reston VA, November 2000). Paper: PostScript | PDF - -

Performance surveys for NTP Version 4 can be found in

Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet timekeeping around the globe. Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Long Beach CA, December 1997), 365-371. Paper: PostScript | PDF, Slides: HTML | PostScript | PowerPoint | PDF - -

Mills, D.L. The network computer as precision timekeeper. Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Reston VA, December 1996), 96-108. Paper: PostScript | PDF, Slides: HTML | PostScript | PowerPoint | PDF - -

- -

David L. Mills <mills@udel.edu>

diff --git a/html/build.html b/html/build.html index a2c350f597..ae7e1d7b77 100644 --- a/html/build.html +++ b/html/build.html @@ -10,13 +10,12 @@

Building and Installing the Distribution

from Pogo, Walt Kelly + gif

from Pogo, Walt Kelly

For putting out compiler fires.

Last update: 20:36 UTC Monday, December 02, 2002

Reference Clock Options

from Pogo, Walt Kelly + gif

from Pogo, Walt Kelly

See the radios, all in a row.

Last update: 20:36 UTC Monday, December 02, 2002

Configuration Options

from Pogo, Walt Kelly -

Gnu autoconfigure tools are in the backpack.
-

from Pogo, Walt Kelly +

Gnu autoconfigure tools are in the backpack.

Last update: 20:36 UTC Monday, December 02, 2002

Basic Configuration Options - the configure utility -
Options -
Directory and File Names -
Host Type -
Optional Packages -
Optional Features -
Radio Clocks -
PARSE Clocks - - +
Basic Configuration Options - the configure utility +
Options +
Directory and File Names +
Host Type +
Optional Packages +
Optional Features +
Radio Clocks +
PARSE Clocks

Basic Configuration Options - the `configure` utility

The following options are for compiling and installing a working version of the NTP distribution. In most cases, the build process is completely automatic. In some cases where memory space is at a premium, or the binaries are to be installed in a different place, it is possible to tailor the configuration to remove such features as reference clock driver support, debugging support, and so forth.

Configuration options are specified as arguments to the configure script. Following is a summary of the current options, as of the 4.0.99m version:

Usage: configure [options] [host]
-

Options

[defaults in brackets after descriptions] Configuration:

Options

[defaults in brackets after descriptions] Configuration:

  --cache-file=FILE      cache test results in FILE
  --help                 print this message
@@ -41,7 +41,7 @@
  --version              print the version of autoconf that created
 configure

Directory and File Names

  --prefix=PREFIX        install architecture-independent files in PREFIX [/usr/local]
  --exec-prefix=EPREFIX  install architecture-dependent files in EPREFIX [same as prefix]
@@ -64,13 +64,13 @@ configure
  --program-suffix=SUFFIX           append SUFFIX to installed program names
  --program-transform-name=PROGRAM  run sed PROGRAM on installed program names

Host Type

  --build=BUILD          configure for building on BUILD [BUILD=HOST]
  --host=HOST            configure for HOST [guessed]
  --target=TARGET        configure for TARGET [TARGET=HOST]

Optional Packages

  --with-PACKAGE[=ARG]   use PACKAGE [ARG=yes]
  --without-PACKAGE      do not use PACKAGE (same as --with-PACKAGE=no)
@@ -81,7 +81,7 @@ configure
  crypto=rsaref          Use the RSAREF library
  electricfence          Compile with ElectricFence malloc debugger

Optional Features

  --disable-FEATURE      do not include FEATURE (same as
  --enable-FEATURE=no)
@@ -104,8 +104,8 @@ configure
  tickadj=VALUE          Force a value for 'tickadj'
  udp-wildcard           Use UDP wildcard delivery

Radio Clocks

(these are ordinarily enabled, if supported by the machine and operating system): +

Radio Clocks

(these are ordinarily enabled, if supported by the machine and operating system):

  all-clocks             Include drivers for all suitable non-PARSE clocks [enable]
  ACTS                   NIST dialup clock
@@ -146,7 +146,7 @@ configure
  USNO                   US Naval Observatory dialup clock
  WWV                    WWV audio receiver

PARSE Clocks

  parse-clocks           Include drivers for all suitable PARSE clocks [enable]
  COMPUTIME              Diem Computime Radio Clock
@@ -165,4 +165,4 @@ configure
         
     
 
-
+
\ No newline at end of file
diff --git a/html/confopt.html b/html/confopt.html
index af748ffbb7..74ccd9d87d 100644
--- a/html/confopt.html
+++ b/html/confopt.html
@@ -10,11 +10,12 @@
 
     
         Server Options
-        from Pogo, Walt Kelly
+        from Pogo, Walt Kelly
         The chicken is getting configuration advice.
+        Last update: 20:36 UTC Monday, December 02, 2002
+        

         Related Links
         
-        

         Table of Contents
         
             Configuration Commands
diff --git a/html/copyright.html b/html/copyright.html
index 2bc39a34b4..d1310660e7 100644
--- a/html/copyright.html
+++ b/html/copyright.html
@@ -9,7 +9,9 @@
 
     
         Copyright Notice
-        "Clone me," says Dolly sheepishly

+         "Clone me," says Dolly sheepishly
+        Last update: 20:31 UTC Monday, December 02, 2002
+        

         
         The following copyright notice applies to all files collectively called the Network Time Protocol Version 4 Distribution. Unless specifically declared otherwise in an individual file, this notice applies as if the text was explicitly included in the file.

         
diff --git a/html/debug.html b/html/debug.html
index 0764c3a4b5..37dc30dc75 100644
--- a/html/debug.html
+++ b/html/debug.html
@@ -10,9 +10,10 @@
 
     
         NTP Debugging Techniques
-        from Pogo, Walt Kelly
-        We make house calls and bring our own bugs.

-        
+        from Pogo, Walt Kelly
+        We make house calls and bring our own bugs.
+        Last update: 20:28 UTC Monday, December 02, 2002
+        

         
         Once the NTP software distribution has been compiled and installed and the configuration file constructed, the next step is to verify correct operation and fix any bugs that may result. Usually, the command line that starts the daemon is included in the system startup file, so it is executed only at system boot time; however, the daemon can be stopped and restarted from root at any time. Usually, no command-line arguments are required, unless special actions described in the ntpd - Network Time Protocol (NTP) daemon page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.
         Initial Startup
diff --git a/html/driver36.html b/html/driver36.html
index 169d38dc3a..84470cea27 100644
--- a/html/driver36.html
+++ b/html/driver36.html
@@ -262,9 +262,6 @@
             flag4 0 | 1
             
Enable verbose clockstats recording if set.
         
-        Additional Information
-        Reference Clock Drivers

-            Reference Clock Audio Drivers
         
         
     
diff --git a/html/driver6.html b/html/driver6.html
index 07ffbc2501..b7fdb5ec44 100644
--- a/html/driver6.html
+++ b/html/driver6.html
@@ -40,7 +40,8 @@
         Other devices set these elements to zero.
         Performance
         The mu-law companded data format allows considerable latitude in signal levels; however, an automatic gain control (AGC) function is implemented to further compensate for varying input signal levels and to avoid signal distortion. For proper operation, the IRIG signal source should be configured for analog signal levels, NOT digital TTL levels.
-        The accuracy of the system clock synchronized to the IRIG-B source with this driver and the ntpd daemon is 10-20 ms with a Sun UltraSPARC II and maybe twice that with a Sun SPARC IPC. The processor resources consumed by the daemon can be significant, ranging from about 1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC IPC. However, the overall timing accuracy is limited by the resolution and stability of the CPU clock oscillator and the interval between clock corrections, which is 64 s with this driver. This performance, while probably the best that can be achieved by the daemon itself, can be improved with assist from the PPS discipline as described elsewhere in the documentation.
+        The accuracy of the system clock synchronized to the IRIG-B source with this driver and the ntpd daemon is 10-20 ms with a Sun UltraSPARC II running Solaris 2.6 and maybe twice that with a Sun SPARC IPC running SunOS 4.1.3. Be however acutely aware that the accuracy with Solaris 2.8 and presumably beyond has seriously degraded to the order of several milliseconds. For whatever reason the Sun  kernel driver has a sawtooth modulation with amplitude 10 ms peak-peak and period 8-10 s. The IRIG driver reduces the amplitude to about 1 ms using some artful processing, but the result is still far inferior to the performance with older systems.
+        The processor resources consumed by the daemon can be significant, ranging from about 1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC IPC. However, the overall timing accuracy is limited by the resolution and stability of the CPU clock oscillator and the interval between clock corrections, which is 64 s with this driver. This performance, while probably the best that can be achieved by the daemon itself, can be improved with assist from the PPS discipline as described elsewhere in the documentation.
         Monitor Data
         The timecode format used for debugging and data recording includes data helpful in diagnosing problems with the IRIG signal and codec connections. With debugging enabled (-d on the ntpd command line), the driver produces one line for each timecode in the following format:
         00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 3094572411.00027
@@ -81,10 +82,7 @@
             
flag4 0 | 1
             
Enable verbose clockstats recording if set.
         
-        Additional Information
-        Reference Clock Drivers

-            Reference Clock Audio Drivers
-        
+         
         
     
 
diff --git a/html/driver7.html b/html/driver7.html
index 6dcaf1fa46..24b898db93 100644
--- a/html/driver7.html
+++ b/html/driver7.html
@@ -23,7 +23,7 @@
         Description
         This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. It replaces an earlier one, built by Dennis Ferguson in 1988, which required a special line discipline to preprocessed the signal. The new driver includes more powerful algorithms implemented directly in the driver and requires no preprocessing.
         CHU transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.
-        While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described on the Pulse-per-second (PPS) Signal Interfacing page. The driver can use the modem to receive the radio signal and demodulate the data or, if available, the driver can use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone on line input port.
+        While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described on the Pulse-per-second (PPS) Signal Interfacing page. The driver can use the modem to receive the radio signal and demodulate the data or, if available, the driver can use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone or line input port.
         This driver incorporates several features in common with other audio drivers such as described in the Radio WWV/H Audio Demodulator/Decoder and the IRIG Audio Decoder pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the Reference Clock Audio Drivers page.
         Ordinarily, the driver poll interval is set to 14 (about 4.5 h), although this can be changed with configuration commands. As long as the clock is set or verified at least once during this interval, the NTP algorithms will consider the source reachable and selectable to discipline the system clock. However, if this does not happen for eight poll intervals, the algorithms will consider the source unreachable and some other source will be chosen (if available) to discipline the system clock.
         The decoding algorithms process the data using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.
@@ -43,7 +43,7 @@
         The result of the majority decoder is a nine-digit timecode representing the maximum likelihood candidate for the transmitted timecode in that minute. Note that the second and fraction within the minute are always zero and that the actual reference point to calculate timestamp offsets is backdated to the first second of the minute. At this point the timecode block is reformatted and the year, days, hours and minutes extracted along with other information from the format B burst, including DST state, DUT1 correction and leap warning. The reformatting operation checks the timecode for invalid code combinations that might have been left by the majority decoder and rejects the entire timecode if found.
         If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamp offsets accumulated over the minute. A perfect set of nine bursts could generate as many as 90 timestamps, but the maximum the interface can handle is 60. These are processed by the interface using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.
         Autotune
-        The driver includes provisions to automatically tune the radio in response to changing radio propagation conditions throughout the day and night. The radio interface is compatible with the ICOM CI-V standard, which is a bidirectional serial bus operating at TTL levels. The bus can be connected to a standard serial port using a level converter such as the CT-17. The serial port speed is presently compiled in the program, but can be changed in the icom.h header file.
+        The driver includes provisions to automatically tune the radio in response to changing radio propagation conditions throughout the day and night. The radio interface is compatible with the ICOM CI-V standard, which is a bidirectional serial bus operating at TTL levels. The bus can be connected to a standard serial port using a level converter such as the CT-17.
         Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the mode keyword of the server configuration command specifies a nonzero select code in decimal format. A table of ID select codes for the known ICOM radios is given below. Since all ICOM select codes are less than 128, the high order bit of the code is used by the driver to specify the baud rate. If this bit is not set, the rate is 9600 bps for the newer radios; if set, the rate is 1200 bps for the older radios. A missing mode keyword or a zero argument leaves the interface disabled.
         If specified, the driver will attempt to open the device /dev/icom and, if successful will tune the radio to 3.330 MHz. If after five minutes at this frequency not more than two format A bursts have been received for any minute, the driver will tune to 7.335 MHz, then to 14.670 MHz, then return to 3.330 MHz and continue in this cycle. However, the driver is liberal in what it assumes of the configuration. If the /dev/icom link is not present or the open fails or the CI-V bus or radio is inoperative, the driver quietly gives up with no harm done.
         Radio Broadcast Format
@@ -228,9 +228,6 @@
             
flag4 0 | 1
             
Enable verbose clockstats recording if set.
         
-        Additional Information
-        Reference Clock Drivers

-        Reference Clock Audio Drivers
         
         
     
diff --git a/html/exec.html b/html/exec.html
deleted file mode 100644
index e03a6b54b3..0000000000
--- a/html/exec.html
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-
-Executive Summary - Computer Network Time
-Synchronization
-
-
-Executive Summary - Computer Network Time Synchronization
-
-from Alice's Adventures in Wonderland, Lewis
-Carroll 
-
-The executive is the one on the left.

-
-
-
-Introduction
-
-The standard timescale used by most nations of the world is
-Coordinated UniversalTime (UTC), which is based on the Earth's
-rotation about its axis, and the Gregorian Calendar, which is based
-on the Earth's rotation about the Sun. The UTC timescale is
-disciplined with respect to International Atomic Time (TAI) by
-inserting leap seconds at intervals of about 18 months. UTC time is
-disseminated by various means, including radio and satellite
-navigation systems, telephone modems and portable clocks.
-
-Special purpose receivers are available for many
-time-dissemination services, including the Global Position System
-(GPS) and other services operated by various national governments.
-For reasons of cost and convenience, it is not possible to equip
-every computer with one of these receivers. However, it is possible
-to equip some number of computers acting as primary time servers to
-synchronize a much larger number of secondary servers and clients
-connected by a common network. In order to do this, a distributed
-network clock synchronization protocol is required which can read a
-server clock, transmit the reading to one or more clients and
-adjust each client clock as required. Protocols that do this
-include the Network Time Protocol (NTP), Digital Time
-Synchronization Protocol (DTSS) and others found in the literature
-(See "Further Reading" at the end of this article.)
-
-Protocol Design Issues
-
-The synchronization protocol determines the time offset of the
-server clock relative to the client clock. The various
-synchronization protocols in use today provide different means to
-do this, but they all follow the same general model. On request,
-the server sends a message including its current clock value or 
-timestamp and the client records its own timestamp upon arrival
-of the message. For the best accuracy, the client needs to measure
-the server-client propagation delay to determine its clock offset
-relative to the server. Since it is not possible to determine the
-one-way delays, unless the actual clock offset is known, the
-protocol measures the total roundtrip delay and assumes the
-propagation times are statistically equal in each direction. In
-general, this is a useful approximation; however, in the Internet
-of today, network paths and the associated delays can differ
-significantly due to the individual service providers.
-
-The community served by the synchronization protocol can be very
-large. For instance, the NTP community in the Internet of 2002 includes over 230 primary time servers, synchronized by radio,
-satellite and modem, and well over 100,000 secondary servers and
-clients. In addition, there are many thousands of private
-communities in large government, corporate and institution
-networks. Each community is organized as a tree graph or 
-subnet, with the primary servers at the root and secondary
-servers and clients at increasing hop count, or stratum level, in
-corporate, department and desktop networks. It is usually necessary
-at each stratum level to employ redundant servers and diverse
-network paths in order to protect against broken software, hardware
-and network links.
-
-Synchronization protocols work in one or more association modes,
-depending on the protocol design. Client/server mode, also called
-master/slave mode, is supported in both DTSS and NTP. In this mode,
-a client synchronizes to a stateless server as in the conventional
-RPC model. NTP also supports symmetric mode, which allows either of
-two peer servers to synchronize to the other, in order to provide
-mutual backup. DTSS and NTP support a broadcast mode which allows
-many clients to synchronize to one or a few servers, reducing
-network traffic when large numbers of clients are involved. In NTP,
-IP multicast can be used when the subnet spans multiple
-networks.
-
-Configuration management can be a serious problem in large
-subnets. Various schemes which index public databases and network
-directory services are used in DTSS and NTP to discover servers.
-Both protocols use broadcast modes to support large client
-populations; but, since listen-only clients cannot calibrate the
-delay, accuracy can suffer. In NTP, clients determine the delay at
-the time a server is first discovered by polling the server in
-client/server mode and then reverting to listen-only mode. In
-addition, NTP clients can broadcast a special "manycast" message to
-solicit responses from nearby servers and continue in client/server
-mode with the respondents.
-
-Security Issues
-
-A reliable network time service requires provisions to prevent
-accidental or malicious attacks on the servers and clients in the
-network. Reliability requires that clients can determine that
-received messages are authentic; that is, were actually sent by the
-intended server and not manufactured or modified by an intruder.
-Ubiquity requires that any client can verify the authenticity of
-any server using only public information. This is especially
-important in such ubiquitous network services as directory
-services, cryptographic key management and time
-synchronization.
-
-NTP includes provisions to cryptographically authenticate
-individual servers using symmetric-key cryptography in which
-clients authenticate servers using shared secret keys. However, the
-secret keys must be distributed in advance using secure means
-beyond the scope of the protocol. This can be awkward and fragile
-with a large population of potential clients, possibly intruding
-hackers.
-
-Modern public-key cryptography provides means to reliably bind
-the server identification credentials and related public values
-using public directory services. However, these means carry a high
-computing cost, especially when large numbers of time-critical
-clients are involved as often the case with NTP servers. In
-addition, there are problems unique to NTP in the interaction
-between the authentication and synchronization functions, since
-each requires the other for success.
-
-The recent NTP Version 4 includes a revised security model and
-authentication scheme supporting both symmetric and public-key
-cryptography. The public-key variant is specially crafted to reduce
-the risk of intrusion, minimize the consumption of processor
-resources and minimize the vulnerability to hacker attack.
-
-Computer Clock Modelling and Error Analysis
-
-Most computers include a quartz resonator-stabilized oscillator and
-hardware counter that interrupts the processor at intervals of a
-few milliseconds. At each interrupt, a quantity called tick
-is added to a system variable representing the clock time. The
-clock can be read by system and application programs and set on
-occasion to an external reference. Once set, the clock readings
-increment at a nominal rate, depending on the value of tick.
-Typical Unix system kernels provide a programmable mechanism to
-increase or decrease the value of tick by a small, fixed
-amount in order to amortize a given time adjustment smoothly over
-multiple tick intervals. 
-
-Clock errors are due to variations in network delay and
-latencies in computer hardware and software (jitter), as well as
-clock oscillator instability (wander). The time of a client
-relative to its server can be expressed
-
-T(t) = T(t₀) + 
-R(t - t₀) + 1/2 D(t -
-t₀)²,
-
-where t is the current time, T is the time offset
-at the last measurement update t₀, R is
-the frequency offset and D is the drift due to resonator
-ageing. All three terms include systematic offsets that can be
-corrected and random variations that cannot. Some protocols,
-including DTSS, estimate only the first term in this expression,
-while others, including NTP, estimate the first two terms. Errors
-due to the third term, while important to model resonator aging in
-precision applications, are neglected, since they are usually
-dominated by errors in the first two terms.
-
-The synchronization protocol estimates 
-T(t₀) (and R(t₀),
-where relevant) at regular intervals t
-and adjusts the clock to minimize T(t) in future. In
-common cases, R can have systematic offsets of several
-hundred parts-per-million (PPM) with random variations of several
-PPM due to ambient temperature changes. If not corrected, the
-resulting errors can accumulate to seconds per day. In order that
-these errors do not exceed a nominal specification, the protocol
-must periodically re-estimate T and R and compensate
-for variations by adjusting the clock at regular intervals. As a
-practical matter, for nominal accuracies of tens of milliseconds,
-this requires clients to exchange messages with servers at
-intervals in the order of tens of minutes.
-
-Analysis of quartz-resonator stabilized oscillators show that
-errors are a function of the averaging time, which in turn depends
-on the interval between corrections. At correction intervals less
-than a few hundred seconds, errors are dominated by jitter, while,
-at intervals greater than this, errors are dominated by wander. As
-explained later, the characteristics of each regime determine the
-algorithm used to discipline the clock. These errors accumulate at
-each stratum level from the root to the leaves of the subnet tree.
-It is possible to quantify these errors by statistical means, as in
-NTP. This allows real-time applications to adjust audio or video
-playout delay, for example. However, the required statistics may be
-different for various classes of applications. Some applications
-need absolute error bounds guaranteed never to exceeded, as
-provided by the following correctness principles.
-
-Correctness Principles
-
-Applications requiring reliable time synchronization such as air
-traffic control must have confidence that the local clock is
-correct within some bound relative to a given timescale such as
-UTC. There is a considerable body of literature that studies these
-issues with respect to various failure models such as fail-stop and
-Byzantine disagreement. While these models inspire much confidence
-in a theoretical setting, most require multiple message rounds for
-each measurement and would be impractical in a large computer
-network such as the Internet. However, it can be shown that the
-worst-case error in reading a remote server clock cannot exceed
-one-half the roundtrip delay measured by the client. This is a
-valuable insight, since it permits strong statements about the
-correctness of the timekeeping system.
-
-In the Probabilistic Clock Synchronization (PCS) scheme devised
-by Cristian, a maximum error tolerance is established in advance
-and time value samples associated with roundtrip delays that exceed
-twice this value are discarded. By the above argument, the
-remaining samples must represent time values within the specified
-tolerance. As the tolerance is decreased, more samples fail the
-test until a point where no samples survive. The tolerance can be
-adjusted for the best compromise between the highest accuracy
-consistent with acceptable sample survival rate.
-
-In a scheme devised by Marzullo and exploited in NTP and DTSS,
-the worst-case error determined for each server determines a
-correctness interval. If each of a number of servers are in fact
-synchronized to a common timescale, the actual time must be
-contained in the intersection of their correctness intervals. If
-some intervals do not intersect, then the clique containing the
-maximum number of intersections is assumed correct 
-truechimers and the others assumed incorrect 
-falsetickers. Only the truechimers are used to adjust the
-system clock.
-
-Data Grooming Algorithms
-
-By its very nature, clock synchronization is a continuous process,
-resulting in a sequence of measurements with each of possibly
-several servers and resulting in a clock adjustment. In some
-protocols, crafted algorithms are used to improve the time and
-frequency estimates and refine the clock adjustment. Algorithms
-described in the literature are based on trimmed-mean and median
-filter methods. The clock filter algorithm used in NTP is based on
-the above observation that the correctness interval depends on the
-roundtrip delay. The algorithm accumulates offset/delay samples in
-a window of several samples and selects the offset sample
-associated with the minimum delay. In general, larger window sizes
-provide better estimates; however, stability considerations limit
-the window size to about eight. 
-
-The same principle could be used when selecting the best subset
-of servers and combining their offsets to determine the clock
-adjustment. However, different servers often show different
-systematic offsets, so the best statistic for the central tendency
-of the server population may not be obvious. Various kinds of
-clustering algorithms have been found useful for this purpose. The
-one used in NTP sorts the offsets by a quality metric, then
-calculates the variance of all servers relative to each server
-separately. The algorithm repeatedly discards the outlyer with the
-largest variance until further discards will not improve the
-residual variance or until a minimum number of servers remain. The
-final clock adjustment is computed as a weighted average of the
-survivors.
-
-At the heart of the synchronization protocol is the algorithm
-used to adjust the system clock in accordance with the final
-adjustment determined by the above algorithms. This is called the
-clock discipline algorithm or simply the discipline. Such
-algorithms can be classed according to whether they minimize the
-time offset or frequency offset or both. For instance, the
-discipline used in DTSS minimizes only the time offset, while the
-one used in NTP minimizes both time and frequency offsets. While
-the DTSS algorithm cannot remove residual errors due to systematic
-frequency errors, the NTP algorithm is more complicated and less
-forgiving of design and implementation mistakes.
-
-All clock disciplines function as a feedback loop, with measured
-offsets used to adjust the clock oscillator phase and frequency to
-match the external synchronization source. The behavior of feedback
-loops is well understood and modelled by mathematical analysis. The
-significant design parameter is the time constant, or
-responsiveness to external or internal variations in time or
-frequency. Optimum selection of time constant depends on the
-interval between update messages. In general, the longer these
-intervals, the larger the time constant and vice versa. In practice
-and with typical network configurations the optimal poll intervals
-vary between one and twenty minutes for network paths to some
-thousands of minutes for modem paths.
-
-Further Reading
-
-
-
-Cristian, F. Probabilistic clock synchronization. In Distributed
-Computing 3, Springer Verlag, 1989, 146-158.
-
-
-
-Digital Time Service Functional Specification Version T.1.0.5.
-DigitalEquipment Corporation, 1989.
-
-
-
-Gusella, R., and S. Zatti. TEMPO - A network time controller for
-a distributed Berkeley UNIX system. IEEE Distributed Processing
-Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also
-in: Proc. Summer 1984 USENIX (Salt Lake City, June 1984).
-
-
-
-Kopetz, H., and W. Ochsenreiter. Clock synchronization in
-distributed real-time systems. IEEE Trans. Computers C-36, 8
-(August 1987), 933-939.
-
-
-
-Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
-presence of faults. JACM 32, 1 (January 1985), 52-78.
-
-
-
-Marzullo, K., and S. Owicki. Maintaining the time in a
-distributed system. ACM Operating Systems Review 19, 3 (July 1985),
-44-54.
-
-
-
-Mills, D.L. Adaptive hybrid clock discipline algorithm for the
-Network Time Protocol. IEEE/ACM Trans. Networking 6, 5
-(October 1998), 505-514.
-
-
-
-Mills, D.L. Improved algorithms for synchronizing computer
-network clocks. IEEE/ACM Trans. Networks 3, 3 (June 1995),
-245-254.
-
-
-
-Mills, D.L. Internet time synchronization: the Network Time
-Protocol. IEEE Trans. Communications COM-39, 10 (October 1991),
-1482-1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global
-States and Time in Distributed Systems, IEEE Press, Los Alamitos,
-CA, 91-102.
-
-
-
-Mills, D.L. Modelling and analysis of computer network clocks.
-Electrical Engineering Department Report 92-5-2, University of
-Delaware, May 1992, 29 pp.
-
-
-
-NIST Time and Frequency Dissemination Services. NBS Special
-Publication432 (Revised 1990), National Institute of Science and
-Technology, U.S. Department of Commerce, 1990.
-
-
-
-Schneider, F.B. A paradigm for reliable clock synchronization.
-Department of Computer Science Technical Report TR 86-735, Cornell
-University, February 1986.
-
-
-
-Srikanth, T.K., and S. Toueg. Optimal clock synchronization.
-JACM 34, 3 (July 1987), 626-645.
-
-
-
-Stein, S.R. Frequency and time - their measurement and
-characterization (Chapter 12). In: E.A. Gerber and A. Ballato
-(Eds.). Precision Frequency Control, Vol. 2, Academic Press, New
-York 1985, 191-232, 399-416. Also in: Sullivan, D.B., D.W. Allan,
-D.A. Howe and F.L. Walls (Eds.). Characterization of Clocks and
-Oscillators. National Institute of Standards and Technology
-Technical Note 1337, U.S. Government Printing Office (January,
-1990), TN61-TN119.
-
-
-
-
- 
-
-David L. Mills
-<mills@udel.edu>
-
-
-
diff --git a/html/extern.html b/html/extern.html
index 696e3d7372..49b0304673 100644
--- a/html/extern.html
+++ b/html/extern.html
@@ -10,6 +10,7 @@
 
     
         External Clock Discipline and the Local Clock Driver
+        Last update: 20:28 UTC Monday, December 02, 2002
         
         The NTPv4 implementation includes provisions for an external clock, where the system clock is implemented by some external hardware device. One implementation might take the form of a bus peripheral with a high resolution counter disciplined by a GPS receiver, for example. Another implementation might involve another synchronization protocol, such as the Digital Time Synchronization Service (DTSS), where the system time is disciplined to this protocol and NTP clients of the server obtain synchronization indirectly via the server. A third implementation might be a completely separate clock discipline algorithm and synchronization protocol, such as the Lockclock algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.
         When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon ntpd to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail and synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.
diff --git a/html/gadget.html b/html/gadget.html
deleted file mode 100644
index 155d56f8d8..0000000000
--- a/html/gadget.html
+++ /dev/null
@@ -1,51 +0,0 @@
-
-
-
-
-    
-        Gadget Box PPS Level Converter and CHU Modem
-        
-    
-
-    
-        Gadget Box PPS Level Converter and CHU Modem
-        A Gadget Box built by Chuck Hanavin
-        Related Links
-        
-            
-            

-        
-        table of Contents
-        
-            Introduction
-            
Circuit Description
-            
Files
-        
-        
-        Introduction
-        Many radio clocks used as a primary reference source for NTP servers produce a pulse-per-second (PPS) signal that can be used to improve accuracy to a high degree. However, the signals produced are usually incompatible with the modem interface signals on the serial ports used to connect the signal to the host. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional radio modem designed to decode the radio timecode signals transmitted by the Canadian time and frequency station CHU. A complete set of schematics, PCB artwork, drill templates can be obrtained via the web as the distribution gadget.tar.Z, or by anonymous FTP from ftp.udel.edu in the pub/ntp directory.
-        The gadget box is assembled in a 5"x3"x2" aluminum minibox containing the level converter and modem circuitry. It includes two subcircuits. One of these converts a TTL positive edge into a fixed-width pulse at EIA levels and is for use with a timecode receiver or oscillator including a TTL PPS output. The other converts the timecode modulation broadcast by Canadian time/frequency standard station CHU into a 300-bps serial character stream at EIA levels and is for use with the Radio CHU Audio Demodulator/Decoder driver.
-        This archive contains complete construction details for the gadget box, including schematic, parts list and artwork for a two-sided, printed-circuit board. All files are in PostScript, with the exception of this file and an information file, which are in ASCII. The artwork is in the 1:1 scale and is suitable for direct printing on photographic resist for each side of the board. While a plated-through-holes process is most convenient, it is possible to bridge the two sides using soldered wires where necessary.
-        Circuit Description
-        Following is a brief functional description of the device. See the schematic diagram gadget.s01 for reference. The audio output of a shortwave radio tuned to CHU at 3330, 7335 or 14670 kHz is connected to J2. A level of at least 30 mV peak-peak is required, such as provided by the recorder output on many receivers. The input level is adjusted by potentiometer R8 so that the timecode modulation broadcast at 31-39 seconds past the minute reliably lights green LED1, but the signals broadcast during other seconds of the minute do not.
-        Opamp U4A provides low-impedance drive for the bridged-tee bandpass filter U4B. The filter has a bandpass of about 600 Hz at the 6-dB points and a center frequency of about 2150 Hz. It is designed to avoid aliasing effects with receivers of relatively wide bandpass characteristics. The modem itself is implemented by U2 and its associated circuitry. Resistors R4 and R1 are a 40-dB pad which matches the filter output to the modem input. U2 is a TTL/EIA level converter with integral power supply for bipolar signals. The modem output is available at pin 3 (receive data) of DB25 connector J1.
-        The TTL PPS signal is connected via J3 to a retriggerable one-shot U3A, which generates a TTL pulse of width determined by potentiometer R7. The pulse width is determined by the bit rate of the attached serial port. In the common case the width is one bit-time, such as 26 us for 38.4 kbps, for example. This appears to the port as a single start bit of zero followed by eight bits of ones and a stop bit of one. The second one-shot U3B generates a 200-ms pulse suitable for driving the amber LED3 as a visual monitor. The output of U3A is converted to EIA levels by U1 and appears at pin 12 (secondary receive data) of J1.
-        If only the PPS circuit is required, U2 and U4 can be deleted and the gadget box powered from the EIA modem-control signal at pin 20 (terminal ready) of J1, assuming this signal is placed in the on (positive voltage) condition by the computer program. J1 is wired to keep most finicky UARTs and terminal-driver programs happy. If the CHU circuit is required, an external 12-volt ACtransformer or 9-12-volt DC supply connected to J4 is required. Red LED2 indicates power is supplied to the box.
-        Files
-        Following is a list of files included in this archive. All files are in PostScript, except the README and gadget.lst files, which are in ASCII. The files gadget.s01, gadget.s02 and gadget.lst were generated using the Schema schematic-capture program from Omation. The printed-circuit files *.lpr were generated using Schema-PCB, also from Omation.
-        README - helpful information

-            gadget.s01 - circuit schematic

-            gadget.s02 - minibox assembly drawing

-            gadget.lst - net list, pin list, parts list, etc.

-            gen0102.lpr - pcb x-ray diagram

-            art01.lpr - pcb artword side 1

-            art02.lpr - pcb artwork side 2

-            adt0127.lpr - pcb assembly drawing

-            dd0124.lpr - pcb drill drawing

-            sm0228.lpr - pcb solder mask (side 2)

-            sst0126.lpr - pcb silkscreen mask (side 1)
-        
-        
-    
-
-
\ No newline at end of file
diff --git a/html/genkeys.html b/html/genkeys.html
index d0d929e6db..ee200c473d 100644
--- a/html/genkeys.html
+++ b/html/genkeys.html
@@ -12,16 +12,17 @@
         ntp-keygen - generate public and private keys
         from Alice's Adventures in Wonderland, Lewis Carroll
         Alice holds the key.
+        Last update: 21:04 UTC Monday, December 09, 2002
+        

         Related Links
         
-        

         Table of Contents
         
-            Synopsis
-            
Description
+            
Introduction
             
Running the program
-            
Trusted Hosts and Groups
+            
Trusted Hosts and Groups
             
Identity Schemes
+            
Example
             
Command Line Options
             
Symmetric Key File
             
Private Key Files
@@ -32,9 +33,7 @@
             
Bugs
         
         
-        Synopsis
-        ntp-keygen
-        Description
+        Introduction
         This program generates cryptographic data files used by the NTPv4 authentication and identification schemes. It generates MD5 key files used in symmetric key cryptography. In addition, if the OpenSSL software library has been installed, it generates key, certificate and parameter files used in public key cryptography. These files are used for cookie encryption, digital signature and challenge/response identification algorithms compatible with the Internet standard security infrastructure.
         All files are in PEM-encoded printable ASCII format, so they can be embedded as MIME attachments in mail to other sites and certificate authorities. Files containing private values can be password encrypted. File names begin with the prefix ntpkey_ and end with the postfix _hostname.filestamp, where hostname is the owner name, usually the string returned by the Unix gethostname() routine, and filestamp is the NTP seconds when the file was generated, in decimal digits. This both guarantees uniqueness and simplifies maintenance procedures, since all files can be quickly removed by a rm ntpkey* command or all files generated at a specific time can be removed by a rm *filestamp command. To further reduce the risk of misconfiguration, the first two lines of a file contain the file name and generation date and time as comments.
         All files are installed by default in the keys directory /usr/local/etc, which is normally in a shared filesystem in NFS-mounted networks. The actual location of the keys directory or each file can be overridden by configuration commands, but this is not recommended. Normally, the files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.
@@ -46,22 +45,101 @@
         The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. When necessary, a different sign key can be specified and this can be either RSA or DSA type. By default, the message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified.
         Running the program as other than root and using the Unix su command to assume root may not work properly, since by default the OpenSSL library looks for the random seed file .rnd in the user home directory. However, there should be only one .rnd, most conveniently in the root directory, so it is convenient to define the $RANDFILE environment variable used by the OpenSSL library as the path to /.rnd.
         Installing the keys as root might not work in NFS-mounted shared file systems, as NFS clients may not be able to write to the shared keys directory, even as root. In this case, NFS clients can specify the files in another directory such as /etc using the keysdir command. There is no need for one client to read the keys and certificates of other clients or servers, as these data are obtained automatically by the Autokey protocol.
-        Ordinarily, cryptographic files are generated by the host that uses them, but it is possible for a trusted host to generate these files for other hosts; however, in such cases the private values should always be password-encrypted. The password is supplied as an option to the ntp-keygen command and as the pw subcommand in the ntpd cofiguration file. It is convenient to designate the owner name and trusted name as the subject and issuer fields, respectivily, of the certificate. The owner name is also used for the host and sign key files, while the trusted name is used for the identity files.
-        Trusted Hosts and Groups
+        Ordinarily, cryptographic files are generated by the host that uses them, but it is possible for a trusted agent (TA) to generate these files for other hosts; however, in such cases the private values should always be password-encrypted. The password is supplied as the -p option to the ntp-keygen program and as the pw subcommand in the ntpd configuration file. The owner name and trusted name default to the name of the host generating the files, but can be changed by command line options. It is convenient to designate the owner name and trusted name as the subject and issuer fields, respectively, of the certificate. The owner name is also used for the host and sign key files, while the trusted name is used for the identity files.
+        Trusted Hosts and Groups
         Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as explained in the Authentication Options page. The default cryptotype uses RSA encryption, MD5 message digest and default (TC) identification. First, configure a NTP subnet including a number of low-stratum time servers from which all other subnet members derive synchronization directly or indirectly. These servers are considered trusted and will have trusted certificates. All others will automatically and dynamically build authoritative certificate trails to these servers.
-        On each trusted server as root, change to the keys directory. To insure a fresh fileset, remove all ntpkey files. Then run ntp-keygen -T to generate keys and a trusted certificate. On all other hosts do the same, but leave off the -T flag to generate keys and nontrusted certificates. When complete, start the NTP daemons beginning at the lowest stratum and working up the tree. It may take some time for Autokey to instantiate the certificate trails throughout the subnet, but setting up the environment is completely automatic.
-It is important that every group be able to construct a certificate trail to one or more trusted hosts in the same group. Ordinarily, each host on the trail to a trusted host has certificates for all hosts along the trail, so a host can hike the trail by fetching each in turn until a trusted host is found. This requires all NTP configuration files to specify servers known to be in the group. If the certificate trail is broken so that no trusted host can be found, a host will loop forever (at low rate) until a path comes available.
-        
A host can be a member of more than one group if it has the necessary credentials. It might be the case, for example, that the servers in one corporation be members of the corporate group, as well as members of a national standards group from which it imports time. In such cases a host exports its home group when operating as a server and imports the group of each association separately when operating as a client. For instance, server alice exports the her own credentials to dependent clients, but  imports the credentials from the certificate trail of each client association specific to that association.
+        On each trusted server as root, change to the keys directory. To insure a fresh fileset, remove all ntpkey files. Then run ntp-keygen -T to generate keys and a trusted certificate. On all other hosts do the same, but leave off the -T flag to generate keys and nontrusted certificates. When complete, start the NTP daemons beginning at the lowest stratum and working up the tree. It may take some time for Autokey to instantiate the certificate trails throughout the subnet, but setting up the environment is completely automatic. The ntp-keygen program can be run to refresh the certificate without affecting ongoing operations; however, if the keys are refreshed, the NTP daemon should be restarted.
+        NTP groups can be used to define cryptographic compartments, as described on the Autokey Protocol page. It is important that every host in the group be able to construct a certificate trail to one or more trusted hosts in the same group. Ordinarily, each group host runs the Autokey protocol to obtain the certificates for all hosts along the trail to one or more trusted hosts. This requires the configuration file in all hosts to be engineered so that, even under anticipated failure conditions, the NTP subnet will form such that every group host can find a trail to at least one trusted host. If the trail is broken so that no trusted certificate can be found, a host will loop forever (at low rate) until a trail becomes available.
+        A host can be a member of more than one group if it has the necessary credentials. It might be the case, for example, that the servers in one corporation be members of the corporate group, as well as clients of a national standards group from which it imports time. In such cases a trusted host exports server credentials when operating as a server and imports client credentials of the group specific to each association. For instance, trusted server alice exports her server credentials to dependent clients, but imports bob client credentials for the associations where the certificate trail ends at trusted host bob in a different group.
         After setting up the environment it is advisable to update certificates from time to time, if only to extend the validity interval. Simply run ntp-keygen with the same flags as before to generate new certificates using existing keys. The next time ntpd is started, it will load the new certificate and restart the protocol. Since the keys have not changed, other dependent hosts will continue as usual until signatures are refreshed and the protocol is restarted, which occurs about once per day.
-Identity Schemes
-
-        As mentioned on the Authentication Options page, the default TC identity scheme is vulnerable to a middleman attack. However, there are more secure identity schemes available, including PC, IFF, GQ and MV. These schemes are based on a trusted agent host and a group of hosts deriving trust from that host. The trusted agent is not necessarily one of the group hosts, bout often is. Group membership is defined by private values generated by the trusted agent and distributed by secure means to all group hosts.
-        The PC scheme is set up as follows. On trusted agent alice run ntp-keygen -P -p password to generate the encrypted host key and private certificate. Do not generate keys and certificates on the other group hosts. Note that, as with all encrypted files, the ntp-keygen program prompts for the password if it reads an encrypted file and the -p option is not present.
-        Copy the host key file ntpkey_RSAkey_alice.filestamp and certificate file ntpkey_RSA-MD5_cert_alice.filestamp to all group hosts. On each host bob install a soft link from the generic name ntpkey_host_bob to the host key file and soft link ntpkey_cert_bob to the certificate file. Note the generic links are on bob, but point to files generated by alice. In this scheme it is not possible to refresh either the keys or certificates in any host without copying them to all other hosts in the group.
-        For the IFF scheme and trusted agent Alice, run the ntp-keygen program with the -I -p password options. Then proceed as in the TC scheme to generate keys and certificates for each group host. Then, copy the IFF parameters file ntpkeys_IFFpar_alice.filestamp to all hosts in the group. On each host bob install a soft link from the generic ntpkey_iff_alice to this file and a soft link from the generic ntpkey_iff_bob to the same file. As the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.
-        For the GQ scheme and trusted agent Alice, run the ntp-keygen program with the -G -p password options. Then proceed as in the TC scheme to generate keys and certificates for each group host. Then, copy the GQ parameters file ntpkeys_GQpar_alice.filestamp to all group hosts. On each host bob install a soft link from the generic ntpkey_gq_alice to this file and a soft link from the generic ntpkey_gq_bob to the same file. As the GQ scheme updates the GQ parameters file and certificate at the same time, keys and certificates can be regenerated as needed.
-        In the MV scheme the trusted agent generates server parameters, which are copied to all group hosts restricted to operate only as servers, and client parameters, which are copied to all group hosts restricted to operate only as clients. On trusted agent Alice run the ntp-keygen program with the -V n -p password options, where n is the number of revokable keys, typically 5. Then, copy the MV parameters file ntpkeys_MVpar_alice.filestamp to all group servers. On server bob install a soft link from the generic ntpkey_mv_bob to this file. Select one of the ntpkeys_MVkeyk_alice.filestamp files (except the last)where k is the key number, and copy it to all group clients, including those servers that may become clients of other servers.  On client dave install a soft link from the generic ntpkey_mvkey_alice to this file. As the MV scheme is independent of keys and certificates, these files can be refreshed as needed.
+        Identity Schemes
+        As mentioned on the Autonomous Authentication page, the default TC identity scheme is vulnerable to a middleman attack. However, there are more secure identity schemes available, including PC, IFF, GQ and MV described in the Identification Schemes page. These schemes are based on a TA and a group of hosts deriving trust from the TA. The TA is not necessarily one of the group hosts, but often is. Group membership is defined by private and public keys generated by the TA and distributed by secure means to all group hosts.
+        In some schemes there are separate keys for servers and clients. A server can also be a client of another server, but a client can never be a server for another client. In general, a trusted host or TA is always a server and never a client of the same group, so these hosts have only server keys. Note that the name of the group is the subject and issuer names in the trusted certificate; that is, the certificate is self-signed.
+        The PC scheme is set up as follows. On TA alice run ntp-keygen -P -p password to generate the host key file ntpkey_RSAkey_alice.filestamp and private certificate file ntpkey_RSA-MD5_cert_alice.filestamp. Do not generate keys and certificates on the other group hosts; however, be sure to specify pw password in the crypto command in all NTP configuration files. Note that, as with all encrypted files, the ntp-keygen program prompts for the password if it reads an encrypted file and the -p option is not present.
+        Copy the host key file and private certificate file to all group hosts. On each host bob install a soft link from the generic name ntpkey_host_bob to the host key file and soft link ntpkey_cert_bob to the private certificate file. Note the generic links are on bob, but point to files generated by alice as the trusted host. In this scheme it is not possible to refresh either the keys or certificates in any host without copying them to all other hosts in the group.
+        The IFF scheme is set up as follows. On TA alice run the ntp-keygen program with the -I -p password options to produce the server key file ntpkey_IFFpar_alice.filestamp and client key file ntpkey_IFFkey_alice.filestamp. The only difference between these files is the server has the private group key and the client does not; therefore, a client cannot masquerade as a rogue server. Proceed as in the TC scheme to generate keys and certificates for each group host. Then, copy the server key file to all group hosts that can operate as servers or clients of other servers and the client key file to group hosts that can operate only as clients. On all group servers and clients install a soft link from the generic ntpkey_iff_alice to the client key file. On each server bob install a soft link from generic ntpkey_iff_bob to the server key file. As the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.
+        The GQ scheme is set up as follows. On TA alice run the ntp-keygen program with the -G -p password options to produce the server/client key file ntpkey_GQpar_alice.filestamp. Proceed as in the TC scheme to generate keys and certificates for each group host. Then, copy the server/client key file to all group hosts. On all group servers and clients install a soft link from the generic ntpkey_gq_alice to this file. On each server bob install a soft link from generic ntpkey_gq_bob to this file. As the GQ scheme updates the GQ parameters file and certificate at the same time, keys and certificates can be regenerated as needed.
+        The MV scheme is set up as follows. On TA Alice run the ntp-keygen program with the -V n -p password options, where n is the number of revokable keys (typically 5) to produce the server key file ntpkeys_MVpar_alice.filestamp and client key files ntpkeys_MVkeyd_alice.filestamp where d is the key number (0 < d < n). Then, distribute the client key files throughout the group. It doesn't matter which client key file goes to which group host; they all work the same. But, keep in mind it is possible for a TA-server conspiracy to selectively deactivate a key in case of compromise. On each client dave install a soft link from generic ntpkey_mv_alice to the client key file. On each server bob install a soft link from generic ntpkey_mv_bob to the server key file. Note that the MV scheme is independent of host key and certificates, these files can be refreshed as needed.
         If it is necessary to use a different sign key or different digest/signature scheme than the default, run ntp-keygen with the -S option and either RSA or DSA argument as needed. The most often need to do this is when a DSA-signed certificate is used. If ntp-keygen is run again without the option, it will generate a new certificate using the existing sign key. If it is necessary to use a different certificate scheme than the default, run ntp-keygen with the -c option and selected scheme as needed. If ntp-keygen is run again without the option, it will generate a new certificate using the same scheme and existing sign key.
+        Example
+        First, generate the host key, trusted host certificate and IFF identity file for trusted host whimsy. The ntp-keygen program on whimsy produces the following typescript.
+        whimsy:/usr/local/etc# ntp-keygen -T -I -pqqsv
+Using OpenSSL version 90607f
+Random seed file /.rnd 1024 bytes
+Generating IFF parameters (512 bits)...
+IFF 0 159 188   1 49 118        2 1 2           3 1 2
+Generating IFF keys (512 bits)...
+Confirm g^(q - b) g^b = 1 mod p: yes
+Confirm g^k = g^(k + b r) g^(q - b) r: yes
+Generating new iff file and link
+ntpkey_iff_whimsy.udel.edu->ntpkey_IFFpar_whimsy.udel.edu.3248306666
+Generating RSA keys (512 bits)...
+RSA 0 16 207    1 11 142                        3 1 4
+Generating new host file and link
+ntpkey_host_whimsy.udel.edu->ntpkey_RSAkey_whimsy.udel.edu.3248306666
+Using host key as sign key
+Generating certificate RSA-MD5
+X509v3 Basic Constraints: critical,CA:TRUE
+X509v3 Key Usage: digitalSignature,keyCertSign
+X509v3 Extended Key Usage: trustRoot
+Generating new cert file and link
+ntpkey_cert_whimsy.udel.edu->ntpkey_RSA-MD5cert_whimsy.udel.edu.3248306666
+
+        The following files and links should be on whimsy:
+        ntpkey_IFFkey_whimsy.udel.edu.3248306666
+ntpkey_IFFpar_whimsy.udel.edu.3248306666
+MD5cert_whimsy.udel.edu.3248306666
+ntpkey_RSAkey_whimsy.udel.edu.3248306666
+ntpkey_cert_whimsy.udel.edu->ntpkey_RSA-MD5cert_whimsy.udel.edu.3248306666
+ntpkey_host_whimsy.udel.edu->ntpkey_RSAkey_whimsy.udel.edu.3248306666
+ntpkey_iff_whimsy.udel.edu->ntpkey_IFFpar_whimsy.udel.edu.3248306666
+
+        Next, generate the host key and nontrusted host certificate for host mort. The ntp-keygen program on mort produces the following typescript.
+        mort:/usr/local/etc# ntp-keygen 
+Using OpenSSL version 90607f
+Random seed file /.rnd 1024 bytes
+Generating RSA keys (512 bits)...
+RSA                                             3 1 2
+Generating new host file and link
+ntpkey_host_mort.udel.edu->ntpkey_RSAkey_mort.udel.edu.3248306679
+Using host key as sign key
+Generating certificate RSA-MD5
+X509v3 Basic Constraints: critical,CA:TRUE
+X509v3 Key Usage: digitalSignature,keyCertSign
+Generating new cert file and link
+ntpkey_cert_mort.udel.edu->ntpkey_RSA-MD5cert_mort.udel.edu.3248306679
+
+        On whimsy, copy the file ntpkey_IFFpar_whimsy.udel.edu.3248306666 to mort.
+        whimsy:/usr/local/etc# scp ntpkey_IFFpar_whimsy.udel.edu.3248306666 mort:/usr/local/etc/ntpkey_IFFpar_whimsy.udel.edu.3248306666
+
+        On mort, install the links
+        mort:/usr/local/etc# ln -s ntpkey_IFFpar_whimsy.udel.edu.3248306666 ntpkey_iff_whimsy.udel.edu
+mort:/usr/local/etc# ln -s ntpkey_IFFpar_whimsy.udel.edu.3248306666 ntpkey_iff_mort.udel.edu
+
+        Note the same file is linked from both hosts whimsy and mort if both are to be servers as well as clients. The following files and links should be on mort:
+        ntpkey_IFFpar_whimsy.udel.edu.3248306666
+MD5cert_mort.udel.edu.3248306679
+ntpkey_RSAkey_mort.udel.edu.3248306679
+ntpkey_cert_mort.udel.edu->ntpkey_RSA-MD5cert_mort.udel.edu.3248306679
+ntpkey_host_mort.udel.edu->ntpkey_RSAkey_mort.udel.edu.3248306679
+ntpkey_iff_whimsy.udel.edu->ntpkey_IFFpar_whimsy.udel.edu.3248306666  ntpkey_iff_mort.udel.edu->ntpkey_IFFpar_whimsy.udel.edu.3248306666
+
+        Following is edited output from the ntpq program on whimsy with the rv command. Note the self-sgned certificate subject and issuer names are whimsy and the 0x2 confirms the certificate is trusted.
+        hostname="whimsy.udel.edu", signature="md5WithRSAEncryption",
+flags=0x80021, hostkey=3248306666, refresh=3248306823,
+cert="whimsy.udel.edu whimsy.udel.edu 0x2 3248306666"
+
+        Following is edited output from the ntpq program on mort with the rv command. Note the self-sgned certificate subject and issuer names are whimsy and the 0x2 confirms the certificate is trusted. Note the Autokey protocol has fetched the trusted certificate for whimsy, confirmed whimsy identity with the IFF scheme and has its certificate signed by whimsy. The 0x3 confirms the certificates have all been validated as well.
+        hostname="mort.udel.edu", signature="md5WithRSAEncryption",
+flags=0x80001, hostkey=3248306679, refresh=3248306943,
+cert="mort.udel.edu whimsy.udel.edu 0x3 3248306679",
+cert="whimsy.udel.edu whimsy.udel.edu 0x3 3248306666",
+cert="mort.udel.edu mort.udel.edu 0x3 3248306679"
+
+        Following is edited output from the ntpq program on mort with the rv assoc command. This reveals the association host name, signature scheme, flags (showing the IFF scheme) and trusted host name.
+        hostname="whimsy.udel.edu", signature="md5WithRSAEncryption",
+flags=0x83f21, identity="whimsy.udel.edu"
+
         Command Line Options
         
             -c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]
@@ -99,15 +177,11 @@
         The ntp-keygen program generates a MD5 symmetric keys file ntpkey_MD5key_hostname.filestamp. Since the file contains private shared keys, it should be visible only to root and distributed by secure means to other subnet hosts. The NTP daemon loads the file ntp.keys, so ntp-keygen installs a soft link from this name to the generated file. Subsequently, similar soft links must be installed by manual or automated means on the other subnet hosts. While this file is not used with the Autokey Version 2 protocol, it is needed to authenticate some remote configuration commands used by the ntpq and ntpdc utilities.
         The symmetric key file contains 16 MD5 keys. Each key consists of 16 characters randomized over the ASCII 93-character printing subset. The file is read by the daemon at the location specified by the keys configuration file command. Additional keys consisting of easily remembered passwords should be added by hand for use with the ntpq and ntpdc programs. While the key identifiers for MD5 keys must be in the range 1-65,535, inclusive, the ntp-keygen program uses only the identifiers from 1 to 16. The key identifier for each association is specified as the key subcommand with the server or peer configuration command.
         Private Key Files
-        The Autokey protocol requires every host to have a private/public host key pair and an optional private/public sign key pair. The ntp-keygen program generates a private key file ntpkey_keynamekey_hostname.filestamp, where keyname is the name of the public key algorithm type, either RSA or DSA. Since the host key is used to encrypt some data, it must be RSA type; the sign key file can be a RSA or DSA type. These files contain private values, so should be encrypted or visible only to root. The NTP daemon loads the host key file ntpkey_host_hostname and the sign key file ntpkey_sign_hostname, so ntp-keygen installs soft links to direct these names to the generated files.
-        Identification Parameter Files
-        Of the four identification schemes implemented in Autokey, the IFF and GQ schemes require special parameters used as group keys, while the GQ scheme requires in addition a private/public key pair as well as a special certificate with the public key included in an X509v3 extension field. In both schemes parameter files are generated by a trusted host, then securely distributed to all other hosts in the group. These files contain private values, so should be encrypted or visible only to root. On Unix machines, a convenient way to do this might be the sdist facility often used to update the latest software within the administrative domain.
-        The ntp-keygen program with the -I flag generates an IFF parameter file ntpkey_IFFpar_hostname.filestamp and with the -G flag generates a GQ parameter file ntpkey_GQpar_hostname.filestamp. The NTP daemon loads the IFF parameter file ntpkey_IFFpar_hostname and the GQ parameter file ntpkey_GQpar_hostname, so ntp-keygen installs soft links to direct these names to the generated files. Subsequently, similar soft links must be installed by manual or automated means on the other hosts in the group.
-        When a certificate is generated for the GQ scheme, the ntp-keygen also generates a GQ key file ntpkey_GQkey_hostname.filestamp. The NTP daemon loads the GQ key file ntpkey_gq_hostname, so the program installs a soft link to direct this name to the generated file. At the same time the program generates a special certificate with the public key component saved in the "X509v3 Subject Key Identifier" extension field. It is important to note that the GQ keys and certificates are generated at the same time and that they can be regenerated from time to time without requiring new GQ parameters.
-        Certificates
+        The Autokey protocol requires every host to have a private/public host key pair and an optional private/public sign key pair. The ntp-keygen program generates a private key file ntpkey_keynamekey_hostname.filestamp, where keyname is the name of the public key algorithm type, either RSA or DSA. Since the host key is used to encrypt some data, it must be RSA type; the sign key file can be a RSA or DSA type. These files contain private values, so should be encrypted or visible only to root. The NTP daemon loads the host key file ntpkey_host_hostname and the sign key file ntpkey_sign_hostname, so ntp-keygen installs soft links to direct these names to the generated files.
+        Certificates
         The Internet security infrastructure requires every host to have a digitally signed public certificate. Security procedures require the public key and host credentials, such as host name, responsible person, mail address, etc., to be provided in the form of a X.509 certificate request to a trusted certificate authority or CA. The CA attaches a digital signature to the request and returns the certificate with signature to the requesting party. The integrity of these procedures depend on the certificate trail that ultimately must end on a self-signed certificate provided by a trusted CA. The OpenSSL software library provides routines that can automate this process.
         Normally, the ntp-keygen program generates certificates which contain only public values, so they can be transmitted and stored without cryptographic protection. With the -P option the program generates a certificate including a "X509v3 "Extended Key Usage" extension field with value private The intent when this field is present is never to disclose the certificate outside the host on which it is installed. Certificates generated without this option do not contain this field and are by default public.
-        The Autokey TC identification scheme automates the certificate trail construction and verification process with each server at stratum n operating as a CA for clients at stratum n + 1. The ntp-keygen program generates a self-signed X.509v3 public certificate ntpkey_digestnamecert_hostname.filestamp, where digestname is the name of the digest/signature scheme. The NTP daemon loads the certificate ntpkey_cert_hostname, so ntp-keygen installs soft links to direct this name to the generated file. The ntp-keygen program with the -T flag generates a trusted certificate including a "X509v3 Extended Key Usage" extension field with value trustRoot. Certificates generated without this option do not contain this field and are by default non-trusted.
+        The Autokey TC identification scheme automates the certificate trail construction and verification process with each server at stratum n operating as a CA for clients at stratum n + 1. The ntp-keygen program generates a self-signed X.509v3 public certificate ntpkey_digestnamecert_hostname.filestamp, where digestname is the name of the digest/signature scheme. The NTP daemon loads the certificate ntpkey_cert_hostname, so ntp-keygen installs soft links to direct this name to the generated file. The ntp-keygen program with the -T flag generates a trusted certificate including a "X509v3 Extended Key Usage" extension field with value trustRoot. Certificates generated without this option do not contain this field and are by default non-trusted.
         Public certificates contain only public values and can be freely transmitted and stored anywhere without further cryptographic protection, although this is rarely necessary. The Autokey protocol retrieves the server certificate and requests the server sign and return the client certificate. Where security considerations require, certificates can be transmitted to an outside trusted certificate authority (CA) and returned as a signed public certificate for use in the Autokey protocol.
         The Autokey protocol supports all digest/signature schemes available in the OpenSSL library, including those using the MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms. However, the scheme specified in the certificate must be compatible with the sign key. Certificates using any digest algorithm are compatible with RSA sign keys; however, only SHA and SHA1 certificates are compatible with DSA sign keys.
         Leapseconds Table
@@ -121,7 +195,7 @@
         where keyno is a positive integer in the range 1-65,535, type is the string MD5 defining the key format and key is the key itself, which is a printable ASCII string 16 characters or less in length. Each character is chosen from the 93 printable characters in the range 0x21 through 0x7f excluding space and the '#' character.
         Note that the keys used by the ntpq and ntpdc programs are checked against passwords requested by the programs and entered by hand, so it is generally appropriate to specify these keys in human readable ASCII format.
         Bugs
-        It can take quite a while to generate some cryptographic values, from one to several minutes with modern architectures such as UltraSPARC and up tens of minutes to an hour with older architectures such as SPARC IPC.
+        It can take quite a while to generate some cryptographic values, from one to several minutes with modern architectures such as UltraSPARC and up to tens of minutes to an hour with older architectures such as SPARC IPC.
         
         
     
diff --git a/html/hints.html b/html/hints.html
index b7ea7bcb47..cb6275b550 100644
--- a/html/hints.html
+++ b/html/hints.html
@@ -10,8 +10,9 @@
     
         Hints and Kinks
          from Alice's Adventures in Wonderland, Lewis Carroll
-        Mother in law has all the answers.

-        
+        Mother in law has all the answers.
+        Last update: 20:27 UTC Monday, December 02, 2002
+        

         
         This is an index for a set of troubleshooting notes contained in individual text files in the ./hints directory. They were supplied by various volunteers in the form of mail messages, patches or just plain word of mouth. Each note applies to a specific computer and operating system and gives information found useful in setting up the NTP distribution or site configuration. The notes are very informal and subject to errors; no attempt has been made to verify the accuracy of the information contained in them.
         Additions or corrections to this list or the information contained in the notes is solicited. The most useful submissions include the name of the computer manufacturer (and model numbers where appropriate), operating system (specific version(s) where appropriate), problem description, problem solution and submitter's name and electric address. If the submitter is willing to continue debate on the problem, please so advise. See the directory listing.
diff --git a/html/howto.html b/html/howto.html
index 092299f5bb..de92400e79 100644
--- a/html/howto.html
+++ b/html/howto.html
@@ -10,14 +10,12 @@
 
     
         How to Write a Reference Clock Driver
-        from Pogo, Walt Kelly
-        You need a little magic.
-        
+        from Pogo, Walt Kelly
+        You need a little magic.
+        Last update: 20:26 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         Table of Contents
         
             Description
@@ -33,7 +31,7 @@
         The audio drivers are designed to look like a typical external radio in that the reference oscillator is derived from the audio codec oscillator and separate from the system clock oscillator. In the WWV and IRIG drivers, the codec oscillator is disciplined in frequency to the standard timescale via radio or local sources and can be assumed to have the same reliability and accuracy as an external radio. In these cases the driver continues to provide updates to the clock filter even if the WWV or IRIG signals are lost. However, the interface is provided the last reference time when the signals were received and increases the dispersion as expected with an ordinary peer.
         The best way to understand how the clock drivers work is to study the ntp_refclock.c module and one of the drivers already implemented, such as refclock_wwvb.c. Routines refclock_transmit() and refclock_receive() maintain the peer variables in a state analogous to a network peer and pass received data on through the clock filters. Routines refclock_peer() and refclock_unpeer() initialize and terminate reference clock associations, should this ever be necessary. A set of utility routines is included to open serial devices, process sample data, edit input lines to extract embedded timestamps and to perform various debugging functions.
         The main interface used by these routines is the refclockproc structure, which contains for most drivers the decimal equivalents of the year, day, month, hour, second and nanosecond decoded from the radio timecode. Additional information includes the receive timestamp, reference timestamp, exception reports, statistics tallies, etc. The support routines are passed a pointer to the peer structure, which is used for all peer-specific processing and contains a pointer to the refclockproc structure, which in turn contains a pointer to the unit structure, if used. For legacy purposes, a table typeunit[type][unit] contains the peer structure pointer for each configured clock type and unit. This structure should not be used for new implementations.
-        The reference clock interface supports auxiliary functions to support in-stream timestamping, pulse-per-second (PPS) interfacing and precision time kernel support. In most cases the drivers do not need to be aware of them, since they are detected at autoconfigure time and loaded automatically when the device is opened. These include the tty_clk STREAMS module and ppsapi PPS interface described in the Line Disciplines and Streams Modules page. The tty_clk module reduces latency errors due to the operating system and serial port code in slower systems. The ppsapi PPS interface replaces the ppsclock STREAMS module and is expected to become the IETF standard cross-platform interface for PPS signals. In either case, the PPS signal can be connected via a level converter/pulse generator described in the Pulse-per-second (PPS) Signal Interfacing page.
+        The reference clock interface supports auxiliary functions to support in-stream timestamping, pulse-per-second (PPS) interfacing and precision time kernel support. In most cases the drivers do not need to be aware of them, since they are detected at autoconfigure time and loaded automatically when the device is opened. These include the tty_clk STREAMS module and ppsapi PPS interface described in the Line Disciplines and Streams Modules page. The tty_clk module reduces latency errors due to the operating system and serial port code in slower systems. The ppsapi PPS interface replaces the ppsclock STREAMS module and is expected to become the IETF standard cross-platform interface for PPS signals. In either case, the PPS signal can be connected via a level converter/pulse generator described in the Pulse-per-second (PPS) Signal Interfacing page.
         Radio and modem reference clocks by convention have addresses in the form 127.127.t.u, where t is the clock type and u in the range 0-3 is used to distinguish multiple instances of clocks of the same type. Most clocks require a serial or parallel port or special bus peripheral. The particular device is normally specified by adding a soft link /dev/devicedd to the particular hardware device involved, where d corresponds to the unit number.
         By convention, reference clock drivers are named in the form refclock_xxxx.c, where xxxx is a unique string. Each driver is assigned a unique type number, long-form driver name, short-form driver name and device name. The existing assignments are in the Reference Clock Drivers page and its dependencies. All drivers supported by the particular hardware and operating system are automatically detected in the autoconfigure phase and conditionally compiled. They are configured when the daemon is started according to the configuration file, as described in the Configuration Options page.
         The standard clock driver interface includes a set of common support routines some of which do such things as start and stop the device, open the serial port, and establish special functions such as PPS signal support. Other routines read and write data to the device and process time values. Most drivers need only a little customizing code to, for instance, transform idiosyncratic timecode formats to standard form, poll the device as necessary, and handle exception conditions. A standard interface is available for remote debugging and monitoring programs, such as ntpq and ntpdc, as well as the filegen facility, which can be used to record device status on a continuous basis.
diff --git a/html/index.html b/html/index.html
index eeb8977d02..d4ab0eae8e 100644
--- a/html/index.html
+++ b/html/index.html
@@ -10,13 +10,12 @@
 
     
         The Network Time Protocol (NTP) Distribution
-        P.T. Bridgeport Bear; from Pogo, Walt Kelly
+        P.T. Bridgeport Bear; from Pogo, Walt Kelly
         Pleased to meet you.
+        Last update: 20:26 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         

         Table of Contents
         
diff --git a/html/kern.html b/html/kern.html
index 5fdf6e897e..9a8a392c76 100644
--- a/html/kern.html
+++ b/html/kern.html
@@ -10,16 +10,15 @@
 
     
         Kernel Model for Precision Timekeeping
-         from Pogo, Walt Kelly
+         from Pogo, Walt Kelly
         Alice touched the kernel and it exploded.
+        Last update: 20:26 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         
         The technical report [2], which is a major revision and update of RFC-1589 [3], describes an engineering model for a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators using phase-lock loops (PLL) and frequency-lock loops (FLL) often found in the engineering literature. The model uses a hybrid PLL/FLL discipline algorithm implemented in the kernel. The algorithm, which is very similar to the algorithm implemented in the NTP daemon, provides automatic time and frequency steering with update intervals from a few seconds to tens of minutes.
-        The hybrid PLL/FLL code described in [2] is included in Solaris  and Digital/Compaq/HP Tru64. It includes two system calls ntp_gettime() and ntp_adjtime() and can discipline the system clock with microsecond resolution. However, newer hardware and kernels with the same system calls can discipline the clock with nanosecond resolution. The new code described in [1] is available for Linux, FreeBSD, SunOS and Tru64; however, only the Linux and FreeBSD implementations, which do not include licensed code, are readily available. The software and documentation, including a simulator used to verify correct behavior, but not involving licensed code, is available at nanokernel.tar.gz.
+        The hybrid PLL/FLL code described in [2] is included in Solaris and Digital/Compaq/HP Tru64. It includes two system calls ntp_gettime() and ntp_adjtime() and can discipline the system clock with microsecond resolution. However, newer hardware and kernels with the same system calls can discipline the clock with nanosecond resolution. The new code described in [1] is available for Linux, FreeBSD, SunOS and Tru64; however, only the Linux and FreeBSD implementations, which do not include licensed code, are readily available. The software and documentation, including a simulator used to verify correct behavior, but not involving licensed code, is available at nanokernel.tar.gz.
         The model also changes the way the system clock is adjusted in time and frequency relative to an external precision timing source, such as described in the Pulse-per-second (PPS) Signal Interfacing page. The NTP software daemon uses the PPS to provide synchronization limited in principle only by the accuracy and stability of the external timing source.
         References
         
diff --git a/html/kernpps.html b/html/kernpps.html
deleted file mode 100644
index f9a7a0e7de..0000000000
--- a/html/kernpps.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
-    
-        Kernel Programming Interface for Precision Time Signals
-        
-    
-
-    
-        Kernel Programming Interface for Precision Time Signals
-        Related Links
-        
-            
-            

-        
-        
-        The technical report [1] describes a proposed application programming interface (API) for external precision time signals, such as the pulse-per-second (PPS) signal generated by some radio clocks and cesium oscillators. The report argues for a generic capability in the ubiquitous Unix kernel, which could be used for a wide variety of measurement applications, including network time synchronization and experiments involving performance measurement and evaluation of computer networks and transmission systems. The hardware to do this requires only a serial port and a modem control lead, such as the data carrier detect (DCD) lead, which can be driven by an external source via a level converter/pulse generator.
-        Support for this API has been implemented in the NTP Version 4 software distribution. The /usr/include/sys/timepps.h header file defines the API interface routines and data structures. The API obsoletes previous APIs based on the tty_clock and ppsclock line disciplines and streams modules, which are no longer supported. The API used by the PPS Clock Discipline driver (type 22) to support PPS signals via either a serial port or parallel port, depending on the operating system. The API is supported in stock FreeBSD from 3.4 and with the addition of the PPSkit kernel software in Linux. Limited support for Solaris from 2.8 is available using the timepps.h.solaris header file included in this distribution. Copy this file to /usr/include/sys before configuring the distributution.
-        The API is normally used in conjunction with the precision time kernel modifications described in the Kernel Model for Precision Timekeeping page.
-        Reference
-        
-            
-            Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. ASCII
-        
-        
-        
-    
-
-
\ No newline at end of file
diff --git a/html/ldisc.html b/html/ldisc.html
index 92b58dee41..1af737ba89 100644
--- a/html/ldisc.html
+++ b/html/ldisc.html
@@ -9,17 +9,14 @@
 
     
         Line Disciplines and Streams Modules
+        Last update: 20:25 UTC Monday, December 02, 2002
         Related Links
-        
-            
-            

-        
+        
         
         Description
         Most radio and modem clocks used for a primary (stratum-1) NTP server utilize serial ports operating at speeds of 9600 baud or greater. The intrinsic delay and jitter contributed by the serial port hardware and software driver can accumulate up to a millisecond in newer Unix systems and tens of milliseconds in older ones. In order to reduce the effects of delay and jitter, a set of special line disciplines, stream modules and operating system calls (ioctls) can be configured in some Unix kernels. These routines intercept special characters or signals provided by the radio or modem clock and save a timestamp for later processing.
         The routines provide two important functions. Some insert a timestamp in the receive data stream upon occurance of a designated character or characters at the serial interface. This can be used to timestamp an on-time character produced by a radio clock, for example. Other routines support an application program interface for pulse-per-second (PPS) signals generated by some radio clocks and laboratory instruments. These routines are normally accessed through the PPSAPI application program interface described below.
         The routines can be compiled in the kernel in older BSD-derived systems, or installed as System V streams modules and either compiled in the kernel or dynamically loaded when required. In either case, they require minor changes in some kernel files and in the NTP daemon ntpd. The streams modules can be pushed and popped from the streams stack using conventional System V streams program primitives. Note that some Unix kernels do not support line disciplines and some do not support System V streams. The routines described here are known to work correctly with the Unix kernels called out in the descriptions, but have not been tested for other kernels.
-
         tty_clk Line Discipline/Streams Module
         This routine intercepts characters received from the serial port and passes unchanged all except a set of designated characters to the generic serial port discipline. For each of the exception characters, the character is inserted in the receiver buffer followed by a local timestamp in Unix timeval format. Both select() and SIGIO are supported by the routine. Support for this routine is automatically detected during the NTP build process and interface code compiled as necessary.
         There are two versions of the tty_clk routine. The tty_clk.c line discipline is designed for older BSD systems and is compiled in the kernel. The tty_clk_STREAMS.c is designed for System V streams, in which case it can be either compiled in the kernel or dynamically loaded. Since these programs are small, unobtrusive, and do nothing unless specifically enabled by an application program, it probably doesn't matter which version is chosen. Instructions on how to configure and build a kernel supporting either of these routines is in the README file in the ./kernel directory.
diff --git a/html/leap.html b/html/leap.html
deleted file mode 100644
index 97bf8d4b44..0000000000
--- a/html/leap.html
+++ /dev/null
@@ -1,250 +0,0 @@
-
-
-
-
-NTP Timescale and Leap Seconds
-
-
-NTP Timescale and Leap Seconds
-
-from Alice's Adventures in Wonderland, Lewis
-Carroll 
-
-The Mad Hatter and the March Hare are discussing whether the
-Teapot serial number should have two or four digits.

-
-
-
-Introduction
-
-In the year 2001 the Network Time Protocol (NTP) has been in use
-for over two decades and remains the longest running, continuously
-operating application protocol in the Internet. There was some
-concern, especially in government and financial institutions, that
-NTP might cause Internet applications to misbehave in terrible ways
-on the epoch of the new century, but this didn't happen. However,
-how NTP reckons the time is important when considering the
-relationship between NTP time and conventional civil time.
-
-This document presents an analysis of the NTP timescale, in
-particular the metrication relative to the conventional civil
-timescale and when the NTP timescale rolls over in 2036. These
-issues are also important with respect to the Unix timescale, but
-that rollover will not happen until 2038. This document does not
-establish a standard, nor does it present specific algorithms which
-metricate the NTP timescale with respect to other timescales.
-
-The NTP Timescale
-
-It will be helpful in understanding the issues raised in this
-document to consider the concept of a universal timescale. The
-conventional civil timescale used in most parts of the world is
-based on Coordinated Universal Time (UTC) (sic), formerly known as
-Greenwich Mean Time (GMT). UTC is based on International Atomic
-Time (TAI sic), which is derived from hundreds of cesium clocks in
-the national standards laboratories of many countries. Deviations
-of UTC from TAI are implemented in the form of leap seconds, which
-occur on average every eighteen months.
-
-For almost every computer application today, UTC represents the
-universal timescale extending into the indefinite past and
-indefinite future. We know of course that the UTC timescale did not
-exist prior to 1972, the Gregorian calendar did not exist prior to
-1582, the Julian calendar did not exist prior to 54 BC and we
-cannot predict exactly when the next leap second will occur.
-Nevertheless, most folks would prefer that, even if we can't get
-future seconds numbering right beyond the next leap second, at
-least we can get the days numbering right until the end of
-reason.
-
-The universal timescale can be implemented using a binary
-counter of indefinite width and with the unit seconds bit placed
-somewhere in the middle. The counter is synchronized to UTC such
-that it runs at the same rate (also the rate of TAI) and the units
-increment coincides with the UTC seconds tick. The NTP timescale is
-constructed from 64 bits of this counter, of which 32 bits number
-the seconds and 32 bits represent the fraction. With this design,
-the counter runs in 136-year cycles, called eras, the latest of
-which began with a counter value of zero at 0h 1 January 1900. The
-next era will begin when the seconds counter rolls over sometime in
-2036. The design assumption is that further low order bits, if
-required, are provided by local interpolation, while further high
-order bits, when required, are provided by external means.
-
-The important point to be made here is that the high order bits
-must ultimately be provided by astronomers and disseminated to the
-population by international means. Ultimately, should a need exist
-to align a particular NTP era to the current calendar, the
-operating system in which NTP is embedded must provide the
-necessary high order bits, most conveniently from the file system
-or flash memory.
-
-With respect to the recent year 2000 issue, the most important
-thing to observe about the NTP timescale is that it knows nothing
-about days, years or centuries, only the seconds since the
-beginning of the current era which began on 1 January 1900. On 1
-January 1970 when Unix life began, the NTP timescale showed
-2,208,988,800 and on 1 January 1972 when UTC life began, it showed
-2,272,060,800. On the last second of the year 1999, the NTP
-timescale showed 3,155,673,599 and one second later on the first
-second of the next century showed 3,155,673,600. Other than this
-observation, the NTP timescale has no knowledge of or provision for
-any of these eclectic seconds.
-
-Conversion to Other Timescales
-
-The NTP timescale is almost never used directly by system or
-application programs. The generic Unix kernel keeps time in seconds
-and microseconds (or nanoseconds) to provide both time of day and
-interval timer functions. In order to synchronize the Unix clock,
-NTP must convert to and from NTP representation and Unix
-representation. Unix kernels implement the time of day function
-using two 32-bit counters, one representing the signed seconds
-since Unix life began and the other the microseconds or nanoseconds
-of the second. In principle, the seconds counter will change sign
-in 2038. How the particular Unix semantics interprets the counter
-values is of concern, but is beyond the scope of discussion
-here.
-
-While incorrect NTP time values are unlikely in a properly
-configured subnet using strong cryptography, redundant sources and
-diverse network paths, hazards remain due to incorrect software
-external to NTP. These include the Unix kernel and library routines
-which convert NTP time to and from Unix time and to and from
-conventional civil time in seconds, minutes, hours, days and years.
-Although NTP uses these routines to format monitoring data
-displays, they are not used to read or set the NTP clock. They may
-in fact cause problems with certain application programs, but this
-is not an issue which concerns NTP correctness.
-
-It is possible that some external source to which NTP
-synchronizes may produce a discontinuity which could then induce a
-NTP discontinuity. The NTP primary (stratum 1) time servers, which
-are the ultimate time references for the entire NTP population,
-obtain time from various sources, including radio and satellite
-receivers and telephone modems. Not all sources provide year
-information and not all of these provide time in four-digit form.
-In point of fact, the NTP reference implementation does not use the
-year information, even if available. Instead, the year information
-is provided from the file system, which itself depends on the Unix
-clock.
-
-Most computers include a time-of-year (TOY) clock chip which
-maintains the time when the power is off. When the operating system
-is booted, the system clock is set from the chip. As the chip does
-not record the year, this value is determined from the datestamp on
-a system configuration file. For this to be correct, the filestamp must by updated at least once each year. The NTP protocol specification
-requires the apparent NTP time derived from external servers to be
-compared to the system time before the clock is set. If the
-discrepancy is over 1000 seconds, an error alarm is raised
-requiring manual intervention. This makes it very unlikely that
-even a clique of seriously corrupted NTP servers will result in
-grossly incorrect time values. When the system clock is synchronized to
-NTP, the TOY chip is corrected to system time on a regular
-basis.
-
-Timescale Resolution and the Tick Interval
-
-Modern computer clocks use a hardware counter to generate processor interrupts at tick intervals in the order of a few milliseconds. At each tick the processor increments the software system clock by the number of microseconds or nanoseconds in the tick. The software resolution of the system clock is defined as the tick interval. Most modern processors implement some kind of high resolution hardware counter that can be used to interpolate the interval between the most recent tick and the actual clock reading. The hardware resolution of the system clock is defined as the time between increments of this counter. However, the actual reading latency due to the kernel interface and interpolation code can range from a few tens of microseconds in older processors to under a microsecond in modern processors.
-
-System clock correctness principles require that clock readings must be always monotonically increasing, so that no two clock readings will be the same. As long as the reading latency exceeds the hardware resolution, this behavior is guaranteed. With reading latencies dropping below the microsecond in modern processors, the system clock in modern operating systems runs in nanoseconds, rather than the microseconds used in the original Unix kernel. With processor speeds exceeding 1 GHz, this assumption may be in jeopardy.
-
-
Leap Seconds
-
-The International Earth Rotation Service (IERS) uses
-astronomical observations provided by USNO and other observatories
-to determine UTC, which is syntonic (identical frequency) with TAI
-but offset by a integral number of seconds. Starting from apparent
-mean solar time as observed, the UT0 timescale is determined using
-corrections for Earth orbit and inclination (the Equation of Time,
-as used by sundials), the UT1 (navigator's) timescale by adding
-corrections for polar migration and the UT2 timescale by adding
-corrections for known periodicity variations. UTC is based on UT1,
-which is presently fast relative to TAI by a fraction of a second
-per year. Since the UTC timescale runs at the TAI rate, when the
-magnitude of the UT1 correction approaches 0.5 second, a leap
-second is inserted or deleted in the UTC timescale on the last day
-of June or December.
-
-For the most precise coordination and timestamping of events
-since 1972, it is necessary to know when leap seconds are
-implemented in UTC and how the seconds are numbered. The insertion
-of leap seconds into UTC is currently the responsibility of the
-IERS, which is located at the Paris Observatory. As specified in
-CCIR Report 517, a leap second is inserted following second
-23:59:59 on the last day of June or December and becomes second
-23:59:60 of that day. A leap second would be deleted by omitting
-second 23:59:59 on one of these days, although this has never
-happened. A table of historic leap seconds and the NTP time when
-each occurred is available via FTP from any NIST NTP server.
-
-The UTC timescale thus ticks in standard (atomic) seconds and
-was set to an initial offset of 10 seconds relative to TAI at 0h
-MJD 41,318.0 according to the Julian calendar or 0h on 1 January
-1972 according to the Gregorian calendar. This established the
-first tick of the UTC era and its reckoning with these calendars.
-Subsequently, the UTC timescale has marched backward relative to
-the TAI timescale exactly one second on scheduled occasions
-recorded in the institutional memory of our civilization. Note in
-passing that leap second adjustments affect the number of seconds
-per day and thus the number of seconds per year. Apparently, should
-we choose to worry about it, the UTC clock, Gregorian calendar and
-various cosmic oscillators will inexorably drift apart with time
-until rationalized by some future papal bull.
-
-Reckoning with NTP and UTC Leap seconds
-
-The NTP timescale is based on the UTC timescale, but not
-necessarily always coincident with it. At the first tick of the UTC
-Era, which began at 0h on 1 January 1972 (MJD 41,318.0) the NTP
-clock read 2,272,060,800, representing the number of standard
-seconds since the beginning of the NTP era at 0h on 1 January 1900
-(MJD 15,021.0) according to the Gregorian calendar. The insertion
-of leap seconds in UTC and subsequently into NTP does not affect
-the UTC or NTP oscillator frequency, only the conversion between
-NTP network time and UTC civil time. However, since the only
-institutional memory available to NTP are the UTC broadcast
-services, the NTP timescale is in effect reset to UTC as each
-broadcast timecode is received. Thus, when a leap second is
-inserted in UTC and subsequently in NTP, knowledge of all previous
-leap seconds is lost.
-
-Another way to describe this is to say there are as many NTP
-timescales as historic leap seconds. In effect, a new timescale is
-established after each new leap second. Thus, all previous leap
-seconds, not to mention the apparent origin of the timescale
-itself, lurch forward one second as each new timescale is
-established. If a clock synchronized to NTP in early 2001 was used
-to establish the UTC epoch of an event that occurred in early 1972
-without correction, the event would appear 22 seconds late.
-However, NTP primary time servers resolve the epoch using the
-broadcast timecode, so that the NTP clock is set to the broadcast
-value on the current timescale. As a result, for the most precise
-determination of epoch relative to the historic Gregorian calendar
-and UTC timescale, the user must subtract from the apparent NTP
-epoch the offsets derived from the NIST table. This is a feature of
-almost all present day time distribution mechanisms.
-
-The obvious question raised by this scenario is what happens
-during the leap second when NTP time stops and the clock remains
-unchanged. If the precision time kernel modifications have been
-implemented, the kernel includes a state machine that implements
-the actions required by the scenario. At the exact instant of the
-leap, the logical clock is stepped backward one second. However,
-the routine that actually reads the clock is constrained never to
-step backwards, unless the step is significantly larger than one
-second, which might occur due to explicit operator direction.
-
-In this design time stands still during the leap second, but is correct commencing with the next second. Since clock readings must be positive monotonic, the apparent time will increase by one nanosecond for each reading. At the end of the second the apparent time may be ahead of the actual time depending on how many times the clocks was read during the second. Eventually, the actual time will catch up with the apparent time and operation continues normally.
-
-
- 
-
-David L. Mills
-<mills@udel.edu>
-
-
-
diff --git a/html/manyopt.html b/html/manyopt.html
index 4a042102c3..631324473b 100644
--- a/html/manyopt.html
+++ b/html/manyopt.html
@@ -12,9 +12,10 @@
         Automatic NTP Configuration Options
         from Alice's Adventures in Wonderland, Lewis Carroll
         Make sure who your friends are.
+        Last update: 20:25 UTC Monday, December 02, 2002
+        

         Related Links
         
-        

         Table of Contents
         
             Manycasting
diff --git a/html/measure.html b/html/measure.html
index 57610d6768..c2546270ba 100644
--- a/html/measure.html
+++ b/html/measure.html
@@ -9,6 +9,7 @@
 
     
         Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation
+        Last update: 20:24 UTC Monday, December 02, 2002
         
         The technical memorandum: Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation(PostScript) describes a number of techniques for conducting experiments typical of computer network and transmission systems engineering.
         In most experiments in which time is involved, it is necessary to develop estimates of time, frequency and measurement errors from a series of time measurements between the clocks of a number of computers and ancillary devices interconnected by some kind of computer network. However, time is not a physical quantity, such as mass, nor can it be measured relative to an absolute frame of reference, such as velocity. The only way to measure time in our universe is to compare the reading of one clock, which runs according to its own timescale, with another clock, which runs according to a given timescale, at some given instant or epoch. The errors arise from the precision of time comparisons and the accuracy of frequency estimates between the timescales involved.
diff --git a/html/miscopt.html b/html/miscopt.html
index 0444d69c3c..f7056b1268 100644
--- a/html/miscopt.html
+++ b/html/miscopt.html
@@ -10,13 +10,12 @@
 
     
         Miscellaneous Options
-        from Pogo, Walt Kelly
+        from Pogo, Walt Kelly
         We have three, now looking for more.
+        Last update: 20:24 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         
         
             broadcastdelay seconds
diff --git a/html/monopt.html b/html/monopt.html
index e8b3bb4652..51154ca292 100644
--- a/html/monopt.html
+++ b/html/monopt.html
@@ -10,13 +10,12 @@
 
     
         Monitoring Options
-        from Pogo, Walt Kelly
+        from Pogo, Walt Kelly
         The pig watches the logs.
+        Last update: 20:24 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         
         ntpd includes a comprehensive monitoring facility suitable for continuous, long term recording of server and client timekeeping performance. See the statistics command below for a listing and example of each type of statistics currently supported. Statistic files are managed using file generation sets and scripts in the ./scripts directory of this distribution. Using these facilities and Unix cron jobs, the datacan be automatically summarized and archived for retrospective analysis.
         Monitoring Commands
diff --git a/html/notes.html b/html/notes.html
index 9fa986e482..96fc1db652 100644
--- a/html/notes.html
+++ b/html/notes.html
@@ -10,7 +10,10 @@
 
     
         Notes on setting up a NTP subnet
-        From NBS Special Publication 432 (out of print)

+        From NBS Special Publication 432 (out of print)
+        Last update: 20:23 UTC Monday, December 02, 2002
+        

+        
         Introduction
         This document is a collection of notes concerning the use of ntpd and related programs, and on coping with the Network Time Protocol (NTP) in general. It is a major rewrite and update of an earlier document written by Dennis Ferguson of the University of Toronto and includes many changes and additions resulting from the NTP Version 3 specification and new Version 4 implementation features. It supersedes earlier documents, which should no longer be used for new configurations.
         ntpd includes a complete implementation of the NTP Version 3 specification, as defined in:
diff --git a/html/ntpd.html b/html/ntpd.html
index ab4efb95b4..de8b29a151 100644
--- a/html/ntpd.html
+++ b/html/ntpd.html
@@ -10,26 +10,28 @@
 
     
         ntpd - Network Time Protocol (NTP) daemon
-        from Alice's Adventures in Wonderland, Lewis Carroll
+        from Alice's Adventures in Wonderland, Lewis Carroll
         The mushroom knows all the command line options.
+        Last update: 20:22 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
+        Table of Contents
+        
+            Synopsis

+            
Description

+            
How NTP Operates

+            
Frequency Discipline

+            
Operating Modes

+            
Poll Interval Control

+            
Poll Interval Control

+            
Notes

+            
Command Line Options

+            
The Configuration File

+            
Configuration Options

+            
Files
+        
         
-        Synopsis

-            Description

-            How NTP Operates

-            Frequency Discipline

-            Operating Modes

-            Poll Interval Control

-            Poll Interval Control

-            Notes

-            Command Line Options

-            The Configuration File

-            Configuration Options

-            Files
         Synopsis
         ntpd [ -aAbdgLmNPqx ] [ -c conffile ] [ -f driftfile ] [ -g ] [ -k keyfile ] [ -l logfile ] [ -N high ] [ -p pidfile ] [ -r broadcastdelay ] [ -s statsdir ] [ -t key ] [ -v variable ] [ -V variable ] [ -x ]
         Description
diff --git a/html/ntpdate.html b/html/ntpdate.html
index fecde4f721..f5226bd336 100644
--- a/html/ntpdate.html
+++ b/html/ntpdate.html
@@ -10,9 +10,10 @@
 
     
         ntpdate - set the date and time via NTP
-        from Alice's Adventures in Wonderland, Lewis Carroll
-        I told you it was eyeball and wristwatch.

-        
+        from Alice's Adventures in Wonderland, Lewis Carroll
+        I told you it was eyeball and wristwatch.
+        Last update: 20:21 UTC Monday, December 02, 2002
+        

         
         Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page. After a suitable period of mourning, the ntpdate program is to be retired from this distribution
         Synopsis
diff --git a/html/ntpdc.html b/html/ntpdc.html
index f01fbccaf3..0d55fa99ac 100644
--- a/html/ntpdc.html
+++ b/html/ntpdc.html
@@ -10,9 +10,10 @@
 
     
         ntpdc - special NTP query program
-        from Alice's Adventures in Wonderland, Lewis Carroll
-        This program is a big puppy.

-        
+        from Alice's Adventures in Wonderland, Lewis Carroll
+        This program is a big puppy.
+        Last update: 20:21 UTC Monday, December 02, 2002
+        

         
         Synopsis
         ntpdc [ -ilnps ] [ -c command ] [ host ] [ ... ]
diff --git a/html/ntpq.html b/html/ntpq.html
index 9a68201a85..87a4b5646d 100644
--- a/html/ntpq.html
+++ b/html/ntpq.html
@@ -10,9 +10,10 @@
 
     
         ntpq - standard NTP query program
-        from Pogo, Walt Kelly
-        A typical NTP monitoring packet.

-        
+        from Pogo, Walt Kelly
+        A typical NTP monitoring packet
+        Last update: 20:20 UTC Monday, December 02, 2002
+        

         
         Synopsis
         ntpq [-inp] [-c command] [host] [...]
diff --git a/html/ntptime.html b/html/ntptime.html
index a3a28ddd34..0ddd8e40bd 100644
--- a/html/ntptime.html
+++ b/html/ntptime.html
@@ -10,9 +10,10 @@
 
     
         ntptime - read kernel time variables
-        from Pogo, Walt Kelly
-        The turtle has been swimming in the kernel.

-        
+        from Pogo, Walt Kelly
+        The turtle has been swimming in the kernel.
+        Last update: 20:19 UTC Monday, December 02, 2002
+        

         
         Synopsis
         ntptime [ -chr ] [ -e est_error ] [ -f frequency ] [ -m max_error ] [ -o offset ] [ -s status ] [ -t time_constant]
diff --git a/html/ntptrace.html b/html/ntptrace.html
index 7ac273e3ec..76002bf0e7 100644
--- a/html/ntptrace.html
+++ b/html/ntptrace.html
@@ -10,9 +10,10 @@
 
     
         ntptrace - trace a chain of NTP servers back to the primary source
-        from Alice's Adventures in Wonderland, Lewis Carroll
-        The rabbit knows the way back.

-        
+        from Alice's Adventures in Wonderland, Lewis Carroll
+        The rabbit knows the way back.
+        Last update: 20:19 UTC Monday, December 02, 2002
+        

         
         Synopsis
         ntptrace [ -vdn ] [ -r retries ] [ -t timeout ] [ server ]
diff --git a/html/patches.html b/html/patches.html
index 4a7e365cd1..01823c8244 100644
--- a/html/patches.html
+++ b/html/patches.html
@@ -9,9 +9,10 @@
 
     
         Patching Procedures
-         rom Alice's Adventures in Wonderland, Lewis Carroll
-        The Mad Hatter needs patches.

-        
+         rom Alice's Adventures in Wonderland, Lewis Carroll
+        The Mad Hatter needs patches.
+        Last update: 20:18 UTC Monday, December 02, 2002
+        

         
         A distribution so widely used as this one eventually develops numerous barnacles as the result of porting to new systems, idiosyncratic new features and just plain bugs. In order to help keep order and make maintenance bearable, we ask that proposed changes to the distribution be submitted in the following form.
         
diff --git a/html/pic/sunrise1.psd b/html/pic/sunrise1.psd
deleted file mode 100644
index 0f8ec35195..0000000000
Binary files a/html/pic/sunrise1.psd and /dev/null differ
diff --git a/html/porting.html b/html/porting.html
index f3825cdf85..44db2ab289 100644
--- a/html/porting.html
+++ b/html/porting.html
@@ -9,9 +9,11 @@
 
     
         Porting Hints
-        from The Wizard of Oz, L. Frank Baum
-        Porting Dorothy in Oz.

+        from The Wizard of Oz, L. Frank Baum
+        
Porting Dorothy in Oz
         
+        Last update: 20:17 UTC Monday, December 02, 2002
+        

         
         NOTE: The following procedures have been replaced by GNU automake and autoconfigure. This page is to be updated in the next release.
         Porting to a new machine or operating system ordinarily requires updating the ./machines directory and the ./compilers directories in order to define the build environment and autoconfigure means. You will probably have to modify the ntp_machines.h file and "l_stdlib.h" files as well. The two most famous trouble spots are the I/O code in ./ntpd/ntp_io.c and the clock adjustment code in ./ntpd/ntp_unixclock.c.
diff --git a/html/pps.html b/html/pps.html
index fafbd16ed0..dc438a37cb 100644
--- a/html/pps.html
+++ b/html/pps.html
@@ -10,13 +10,12 @@
 
     
         Pulse-per-second (PPS) Signal Interfacing
-        from Alice's Adventures in Wonderland, Lewis Carroll
+        from Alice's Adventures in Wonderland, Lewis Carroll
         Alice is trying to find the PPS signal connector.
+        Last update: 20:15 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         
         Some radio clocks and related timekeeping gear have a pulse-per-second (PPS) signal that can be used to discipline the system clock to a high degree of precision, typically to the order less than 10 ms in time and 0.01 parts-per-million (PPM) in frequency. This page describes the hardware and software necessar for NTP to use this signal.
         A Gadget Box built by Chuck Hanavin

diff --git a/html/prefer.html b/html/prefer.html
index 02ab7ae991..8d6614d926 100644
--- a/html/prefer.html
+++ b/html/prefer.html
@@ -9,15 +9,13 @@
 
     
         Mitigation Rules and the prefer Keyword
-         from Alice's Adventures in Wonderland, Lewis Carroll
-        Listen carefully to what I say; it is very complicated.
-        
-         Related Links
-        
-            
-            

-        
-       Table of Contents
+         from Alice's Adventures in Wonderland, Lewis Carroll
+        Listen carefully to what I say; it is very complicated.
+        Last update: 20:15 UTC Monday, December 02, 2002
+        

+        Related Links
+        
+        Table of Contents
         
             Introduction
             
The prefer Peer
diff --git a/html/qth.html b/html/qth.html
deleted file mode 100644
index 1756edb10b..0000000000
--- a/html/qth.html
+++ /dev/null
@@ -1,76 +0,0 @@
-
-Stations, Frequencies and Geographic Coordinates
-
-Stations, Frequencies and Geographic Coordinates
-

-
-The following data were obtained from the International Frequency List
-published by the ITU and other sources.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Station Frequencies Coordinates
WWV Ft. Collins, CO 2.5/5/10/15/20 MHz 40:40:49.0N 105:02:27.0W
WWVB Ft. Collins, CO 60 kHz 40:40:28.3N 105:02:39.5W
WWVH Kauai, HI 2.5/5/10/15 MHz 21:59:26.0N 159:46:00.0W
CHU Ottawa, CA 3330/7335/14670 kHz 45:18N 75:45N
DCF77 Mainflingen, DE 77.5 kHz 50:01N 9:00E
MSF Rugby, UK 60 kHz 52:22N 1:11W
TDF Allouis, FR 162 kHz 47:10N 2:12E
JJY ( Fukushima, JAPAN ) 40 KHz 37:22 N   140:51 E
JJY ( Saga, JAPAN ) 60 KHz 33:28 N   130:11 E
-
-
 David L. Mills <mills@udel.edu>
-
diff --git a/html/quick.html b/html/quick.html
index 254e16cdb7..7ca2a78094 100644
--- a/html/quick.html
+++ b/html/quick.html
@@ -11,8 +11,9 @@
     
         Quick Start
         FAX test image for SATNET (1979).
-        The baby panda was scanned at University College London and used as a FAX test image for a demonstration of the DARPA Atlantic SATNET Program and the first transatlantic Internet connection in 1978. The computing system used for that demonstration was called the Fuzzball . As it happened, this was also the first Internet multimedia presentation and the first to use NTP in regular operation. The image was widely copied and used for testing purpose throughout much of the 1980s.

-        
+        The baby panda was scanned at University College London and used as a FAX test image for a demonstration of the DARPA Atlantic SATNET Program and the first transatlantic Internet connection in 1978. The computing system used for that demonstration was called the Fuzzball . As it happened, this was also the first Internet multimedia presentation and the first to use NTP in regular operation. The image was widely copied and used for testing purpose throughout much of the 1980s.
+        Last update: 20:13 UTC Monday, December 02, 2002
+        

         
         For the rank amateur the sheer volume of the documentation collection must be intimidating. However, it doesn't take much to fly the ntpd daemon with a simple configuration where a workstation needs to synchronize to some server elsewhere in the Internet. The first thing that needs to be done is to build the distribution for the particular workstation and install in the usual place. The Building and Installing the Distribution page describes how to do this.
         While it is possible that certain configurations do not need a configuration file, most do require one. Strictly speaking, the file need only contain one line specifying a remote server, for instance
diff --git a/html/rdebug.html b/html/rdebug.html
index 1523b05dc5..a10884868d 100644
--- a/html/rdebug.html
+++ b/html/rdebug.html
@@ -9,15 +9,12 @@
 
     
         Debugging Hints for Reference Clock Drivers
-        from The Wizard of Oz, L. Frank Baum
-        Call the girls and the'll sweep your bugs.
-        
+        from The Wizard of Oz, L. Frank Baum
+        Call the girls and the'll sweep your bugs.
+        Last update: 20:12 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
-
+        
         
         The ntpq and ntpdc utility programs can be used to debug reference clocks, either on the server itself or from another machine elsewhere in the network. The server is compiled, installed and started using the configuration file described in the ntpd page and its dependencies. If the clock appears in the ntpq utility and pe command, no errors have occured and the daemon has started, opened the devices specified and waiting for peers and radios to come up. If not, the first thing to look for are error messages on the system log. These are usually due to improper configuration, missing links or multiple instances of the daemon.
         It normally takes a minute or so for evidence to appear that the clock is running and the driver is operating correctly. The first indication is a nonzero value in the reach column in the pe billboard. If nothing appears after a few minutes, the next step is to be sure the RS232 messages, if used, are getting to and from the clock. The most reliable way to do this is with an RS232 tester and to look for data flashes as the driver polls the clock and/or as data arrive from the clock. Our experience is that the overwhelming fraction of problems occurring during installation are due to problems such as miswired connectors or improperly configured device links at this stage.
diff --git a/html/refclock.html b/html/refclock.html
index 66b86daf19..4cbc2ee9b3 100644
--- a/html/refclock.html
+++ b/html/refclock.html
@@ -10,12 +10,11 @@
 
     
         Reference Clock Drivers
-        Master Time Facility at the UDel Internet Research Laboratory
+        Master Time Facility at the UDel Internet Research Laboratory
+        Last update: 20:11 UTC Monday, December 02, 2002
+        

         Related Links
-        
-            
-            

-        
+        
         Pulse-Per-Second Interfacing Links
         
             
diff --git a/html/release.html b/html/release.html
index 76a9758097..43a16b0278 100644
--- a/html/release.html
+++ b/html/release.html
@@ -10,11 +10,11 @@
 
     
         
NTP Version 4 Release Notes
-        from Alice's Adventures in Wonderland, Lewis Carroll
-        The rabbit toots to make sure you read this.

+        from Alice's Adventures in Wonderland, Lewis Carroll
+        
The rabbit toots to make sure you read this
         
-        
-        This document was last updated 3 September 2002
+        Last update: 20:07 UTC Monday, December 02, 2002
+.
        
         NTP Version 4 Release Notes
         This release of the NTP Version 4 (NTPv4) daemon for Unix, VMS and Windows incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions, including NTPv3 and NTPv2, but not NTPv1. Support for NTPv1 has been discontinued because of certain security vulnerabilities. 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 retrofitted in the older NTPv3, although this version is not actively maintained by the NTPv4 developer corps.
         The code compiles and runs properly in all test host configurations available to the developer corps, including Sun Microsystems, Digital/Compaq, Hewlett Packard, FreeBSD and Linux. Other volunteers have verified it works in IRIX and certain versions of Windows NT and several others. We invite comments and corrections about the various architectures, operating systems and hardware complement that can't be verified by the developer corps. Of particular interest are Windows, VMS and various reference clock drivers. As always, corrections and bugfixes are warmly received, especially in the form of context diffs sent to <bugs@ntp.org>>.
diff --git a/html/scripts/footer.txt b/html/scripts/footer.txt
new file mode 100644
index 0000000000..b8726dc2eb
--- /dev/null
+++ b/html/scripts/footer.txt
@@ -0,0 +1,8 @@
+document.write("\
+\
+\
+\
+\
+Home Page \
+\
+David L. Mills <mills@udel.edu>")
\ No newline at end of file
diff --git a/html/scripts/header.txt b/html/scripts/header.txt
new file mode 100644
index 0000000000..6950e3018e
--- /dev/null
+++ b/html/scripts/header.txt
@@ -0,0 +1 @@
+document.write("Network Time Protocol Version 4")
\ No newline at end of file
diff --git a/html/scripts/links10.txt b/html/scripts/links10.txt
new file mode 100644
index 0000000000..4889527e63
--- /dev/null
+++ b/html/scripts/links10.txt
@@ -0,0 +1,6 @@
+document.write("\
+Reference Clock Drivers
\
+
Mitigation Rules and the prefer Keyword
\
+
How to Write a Reference Clock Driver
\
+
Debugging Hints for Reference Clock Drivers
\
+")
\ No newline at end of file
diff --git a/html/scripts/links11.txt b/html/scripts/links11.txt
new file mode 100644
index 0000000000..2f497f04f9
--- /dev/null
+++ b/html/scripts/links11.txt
@@ -0,0 +1,5 @@
+document.write("\
+Reference Clock Drivers
\
+
Pulse-per-second (PPS) Signal Interfacing
\
+
Line Disciplines and Streams Modules
\
+")
\ No newline at end of file
diff --git a/html/scripts/links7.txt b/html/scripts/links7.txt
new file mode 100644
index 0000000000..fa476e279c
--- /dev/null
+++ b/html/scripts/links7.txt
@@ -0,0 +1,5 @@
+document.write("\
+Server Options
\
+
Authentication Options
\
+
Monitoring Options
\
+")
\ No newline at end of file
diff --git a/html/scripts/links8.txt b/html/scripts/links8.txt
new file mode 100644
index 0000000000..51c3a38fdc
--- /dev/null
+++ b/html/scripts/links8.txt
@@ -0,0 +1,6 @@
+document.write("\
+Reference Clock Drivers
\
+
Radio CHU Audio Demodulator/Decoder
\
+
Radio WWV/H Audio Demodulator/Decoder
\
+
IRIG Audio Decoder\
+")
\ No newline at end of file
diff --git a/html/scripts/links9.txt b/html/scripts/links9.txt
new file mode 100644
index 0000000000..1cef59c3ad
--- /dev/null
+++ b/html/scripts/links9.txt
@@ -0,0 +1,7 @@
+document.write("\
+Authentication Options
\
+
Automatic NTP Configuration Options
\
+
Server Options
\
+
ntp-keygen - generate public and private keys\
+
Autonomous Authentication\
+")
\ No newline at end of file
diff --git a/html/scripts/style.css b/html/scripts/style.css
new file mode 100644
index 0000000000..9f60d5ab3f
--- /dev/null
+++ b/html/scripts/style.css
@@ -0,0 +1,64 @@
+body {background: #FDF1E1;
+      color: #006600;
+      font-family: "verdana ref","lucida bright",sans-serif;
+      text-align: justify;
+      margin-left: 5px;}
+
+p, h4, hr, li {margin-top: .6em; margin-bottom: .6em}
+li.inline {text-align: left; margin-top: 0; margin-bottom: 0}
+
+ul, dl, ol, {margin-top: .6em; margin-bottom: .6em; margin-left 5em}
+
+dt {margin-top: .6em}
+dd {margin-bottom: .6em}
+
+div.header {text-align: center;
+            font-style: italic;}
+
+div.footer {text-align: center;         
+            font-size: 60%;}
+
+img.cell {align: left;}
+
+td.sidebar {width: 40px; align: center; valign: top;}
+img.sidebar {align: center; margin-top: 5px;}
+h4.sidebar {align: center;}
+
+p.top {background: #FDF1E1;
+       color: #006600;
+       position: absolute;
+       margin-left: -90px;
+       text-align: center;}
+
+a:link.sidebar {background: transparent;
+                color: #990033;
+                font-weight: bold;}
+
+a:visited.sidebar {background: transparent;
+                   color: #990033;
+                   font-weight: bold;}
+
+a:hover.sidebar {background: #FDF1E1;
+                 color: #006600;}
+
+img {margin: 5px;}
+
+div {text-align: center;}
+
+h1 {text-align: center;
+    font-size: 250%;}
+
+caption {background: #EEEEEE;
+         color: #339999;}
+         
+tx {text-align: center;}
+
+th {background: #FFFFCC;
+    color: #006600;
+    text-align: center;
+    text-decoration: underline;
+    padding-top: 5px;}
+
+th.caption {background: #EEEEEE;
+            color: #006600;
+            text-align: center;}
\ No newline at end of file
diff --git a/html/sntp.html b/html/sntp.html
index 82b1947434..75a3985c58 100644
--- a/html/sntp.html
+++ b/html/sntp.html
@@ -9,6 +9,7 @@
 
     
         Simple Network Time Protocol (SNTP) Client
+        Last update: 20:10 UTC Monday, December 02, 2002
         
         Synopsis
         sntp [{-h --help -?}][{ -v -V -W }][{-r -a}][-P prompt][-e minerr][-E maxerr][-c count][-d delay][address(es)]
diff --git a/html/tickadj.html b/html/tickadj.html
index 7c2d9a4231..7153f7785a 100644
--- a/html/tickadj.html
+++ b/html/tickadj.html
@@ -10,6 +10,7 @@
 
     
         tickadj - set time-related kernel variables
+        Last update: 20:11 UTC Monday, December 02, 2002
         
         Synopsis
         tickadj [ -Aqs ] [ -a tickadj ] [ -t tick ]

Station	Frequencies	Coordinates
WWV Ft. Collins, CO	2.5/5/10/15/20 MHz	40:40:49.0N 105:02:27.0W
WWVB Ft. Collins, CO	60 kHz	40:40:28.3N 105:02:39.5W
WWVH Kauai, HI	2.5/5/10/15 MHz	21:59:26.0N 159:46:00.0W
CHU Ottawa, CA	3330/7335/14670 kHz	45:18N 75:45N
DCF77 Mainflingen, DE	77.5 kHz	50:01N 9:00E
MSF Rugby, UK	60 kHz	52:22N 1:11W
TDF Allouis, FR	162 kHz	47:10N 2:12E
JJY ( Fukushima, JAPAN )	40 KHz	37:22 N 140:51 E
JJY ( Saga, JAPAN )	60 KHz	33:28 N 130:11 E

Access Control Options

Related Links

Table of Contents

Association Management

Related Links

Table of Contents

Association Modes

Client/Server Mode

Symmetric Active/Passive Mode

Manycasting

Burst Modes

Reference Clock Audio Drivers

Related Links

Table of Contents

Sound Card Drivers

Setup and Debugging Aids

Authentication Options

Related Links

Table of Contents

Public Key Cryptography

Autokey Dances

-Protocol Conformance Statement -

Building and Installing the Distribution

Related Links

Table of Contents

Reference Clock Options

Related Links

Table of Contents

Configuration Options

Table of Contents

Basic Configuration Options - the configure utility

Basic Configuration Options - the configure utility

Options

Options

Directory and File Names

Directory and File Names

Host Type

Host Type

Optional Packages

Optional Packages

Optional Features

Optional Features

Radio Clocks

Radio Clocks

PARSE Clocks

PARSE Clocks

Server Options

Related Links

Table of Contents

Copyright Notice

NTP Debugging Techniques

Initial Startup

Additional Information

Performance

Monitor Data

Additional Information

Description

Autotune

Radio Broadcast Format

Additional Information

Executive Summary - Computer Network Time Synchronization

Introduction

Protocol Design Issues

Security Issues

Computer Clock Modelling and Error Analysis

Correctness Principles

Data Grooming Algorithms

Further Reading

External Clock Discipline and the Local Clock Driver

Gadget Box PPS Level Converter and CHU Modem

Related Links

table of Contents

Introduction

Circuit Description

Files

ntp-keygen - generate public and private keys

Related Links

Table of Contents

Synopsis

Description

Basic Configuration Options - the `configure` utility

Basic Configuration Options - the `configure` utility

`ntp-keygen` - generate public and private keys

`tty_clk` Line Discipline/Streams Module

`ntpd` - Network Time Protocol (NTP) daemon

`ntpdate` - set the date and time via NTP

`ntpdc` - special NTP query program

`ntpq` - standard NTP query program

`ntptime` - read kernel time variables

`ntptrace` - trace a chain of NTP servers back to the primary source

Mitigation Rules and the `prefer` Keyword