<body>
<h3>Access Control Options</h3>
- <img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The skunk watches for intruders and sprays.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:34</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#acx">Access Control Support</a>
<body>
<h3>Association Management</h3>
- <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:34</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#modes">Association Modes</a>
<hr>
<h4 id="#modes">Association Modes</h4>
<p>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 <a href="confopt.html">Configuration Options</a> and <a href="authopt.html">Authentication Options</a> pages and in the papers, reports, memoranda and briefings at <a href="http://www.ntp.org">www.ntp.org</a>.</p>
- <p>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.</p>
+ <p>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.</p>
<p>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 <a href="authopt.html">Authentication Options</a> 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 <i>provenance</i> 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.</p>
- <p>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.</p>
+ <p>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.</p>
<h4 id="#client">Client/Server Mode</h4>
<p>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 <tt>server</tt> (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.</p>
<h4 id="#symact">Symmetric Active/Passive Mode</h4>
<p>A multicast client is configured using the <tt>broadcast</tt> 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 <tt>broadcast</tt> 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.</p>
<p>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 <tt>broadcast</tt> 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.</p>
<h4 id="#many">Manycasting</h4>
- <p>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 <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
+ <p>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 <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
<h4 id="#burst">Burst Modes</h4>
<p>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 <tt>burst</tt> mode sends a burst when the server is reachable, while the <tt>iburst</tt> mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. The <tt>calldelay</tt> 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.</p>
<p>The <tt>iburst</tt> 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.</p>
<body>
<h3>Reference Clock Audio Drivers</h3>
- <img src="pic/radio2.jpg" alt="jpg" align="left">
+ <img src="pic/radio2.jpg" alt="jpg" align="left">ICOM R-72 shortwave receiver and Sure audio mixer
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:34</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links8.txt"></script>
- <br clear="left">
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#sound">Sound Card Drivers</a>
</ul>
<hr>
<h4 id="#sound">Sound Card Drivers</h4>
- <p>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.</p>
+ <p>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.</p>
<p>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.</p>
- <p>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.</p>
+ <p>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.</p>
<p>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 <tt>ntpq</tt> program.</p>
<p>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.</p>
<p>The drivers include provisions to select the input port and to monitor the input signal. The <tt>fudge flag 2</tt> 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 <tt>fudge flag 3</tt> 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 <tt>ntpdc</tt> utility program.</p>
<p>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.</p>
<h4 id="#setup">Setup and Debugging Aids</h4>
<p>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 <tt>clockstats</tt> file for later analysis. Of particular help in verifying signal connections and compatibility is a provision to monitor the signal via headphones or speaker.</p>
- <p>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 <tt>fudge flag2</tt> 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.</p>
- <p>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.</p>
- <p>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.</p>
- <p>The drivers use <tt>fudge flag2</tt> 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.</p>
+ <p>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.</p>
+ <p>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 <tt>fudge flag2</tt> 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.</p>
<p>The drivers write a synthesized timecode to the <tt>clockstats</tt> 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.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<body>
<h3>Authentication Options</h3>
- <img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:35</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear=left>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
- <br clear="left">
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#auth">Authentication Support</a>
The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.
<p>When <tt>ntpd</tt> is first started, it reads the key file specified in the <tt>keys</tt> configuration command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trusted</tt> command before use. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using <tt>ntpdc</tt>. This also provides a revocation capability that can be used if a key becomes compromised. The <tt>requestkey</tt> command selects the key used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key used as the password for the <tt>ntpq</tt> utility.</p>
<h4 id="#pub">Public Key Cryptography</h4>
- <p>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.</p>
+ <p>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 <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Protocol</a> 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.</p>
<p>The cryptographic means necessary for all Autokey operations provided by the OpenSSL software library. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the interface routines required.</p>
<p>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 <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
<p>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 <tt>md5WithRSAEncryption</tt>, 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 <a href="genkeys.html"><tt>ntp-keygen</tt></a> page.</p>
<p>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.</p>
<h4 id="#auto">Autokey Dances</h4>
- <p>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.</p>
+ <p>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 <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Protoco</a>l 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.</p>
<p>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:</p>
<ol>
<li>Each group member holds a private group key generated by a trusted authority.
+++ /dev/null
-<html><head><title>
-Protocol Conformance Statement
-</title></head><body><h3>
-Protocol Conformance Statement
-</h3>
-
-<img align=left src=pic/flatheads.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>From <i>The
-Wizard of Oz</i>, L. Frank Baum</a>
-
-<p>Say it three times and it must be right.
-<br clear=left>
-<hr>
-
-<p>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.
-
-<p>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 <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page, while issues related to the NTP timescale and pending century are discussed in the <a href=y2k.htm> Network Time Protocol Year 2000 Conformance Statement</a> 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 <a href=http://www.eecis.udel.edu/~mills>David L. Mills</a> web page. A historical perspective is available in
-
-<ul>
-
-<p><li>Mills, D.L. A brief history of NTP time: confessions of an Internet timekeeper. Submitted for publication; please do not cite or redistribute. <a href=database/papers/history.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/history.pdf>PDF</a>
-
-</ul>
-
-<p>The NTP architecture, protocol and algorithm models are described in
-
-<ul>
-
-<p><li>Mills, D.L. Internet time synchronization: the Network Time Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991), 1482-1493. <a href=http://www.eecis.udel.edu/~mills/database/papers/trans.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf> PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States and Time in Distributed Systems</I>. IEEE Computer Society Press, Los Alamitos, CA, 1994, 91-102.
-
-</ul>
-
-<p>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
-<ul>
-
-<p><li>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: <a
-href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps> PostScript)</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps> PostScript)</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf> PDF</a>, Appendices: <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf> PDF</a>.
-
-</ul>
-
-<p>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:
-
-<ol>
-
-<p><li>Support for precision-time kernel modifications, as described in
-
-<p>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf>PDF</a>, Slides: <a href=database/brief/nano/nano.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ppt>PowerPoint</a>
-
-<p>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: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf> PDF</a>. Major revision and update of: Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</a>
-
-<p><li>Support for IP Multicasting, as described the <a href=assoc.htm>Association Management</a> page and in
-
-<p>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: <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf> PDF</a>
-
-<p><li>A new hybrid phase/frequency-lock clock discipline, which
-replaces the RFC-1305 local clock algorithm, as described in</li>
-
-<p>Mills, D.L. Improved algorithms for synchronizing computer network clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <a href=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>PDF</a>
-
-<p>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: <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>PDF</a>
-
-<p><li>Simple Network Monitoring Protocol (SNMP) monitoring tools, as described in</li>
-
-<p>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. <a href=http://www.eecis.udel.edu/~mills/database/reports/ntp-mib-tr.ps>PostScript</a> | <a href=database/reports/ntp-mib-tr.pdf>PDF</a>
-
-<p><li>Engineered refinements to radio clock drivers and interface code, as described in in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a> page and</li>
-
-<p>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. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2783.txt>ASCII</a>
-
-<p>Mills, D.L. Precision synchronization of computer network clocks. <I>ACM Computer Communication Review 24, 2</I> (April 1994). 28-43. <a href=http://www.eecis.udel.edu/~mills/database/papers/fine.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf>PDF</a>
-
-<p><li>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 <a href=refclock.htm>Reference Clock Drivers</a> page.</li>
-
-<p><li>A new security model and authentication scheme based on public-key cryptography called <I>Autokey</I>, as described in the <a href=authopt.htm>Authentication Options</a> page and in</li>
-
-<p>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. <a href=http://www.eecis.udel.edu/~mills/database/memos/draft-ietf-stime-ntpauth-00.txt>ASCII</a>
-
-<p>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: <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeya.ps>PostScript</a> | <a href=database/reports/pkey/pkeya.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeyb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeyb.pdf>PDF</a>
-
-<p>Mills, D.L. Authentication scheme for distributed, ubiquitous, real-time protocols. <I>Proc. Advanced Telecommunications/Information Distribution Research Program (ATIRP) Conference</I> (College Park MD, January 1997), 293-298. <a href=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf>PDF</a>
-
-<p>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: <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf>PDF</a>
-
-<p><li> Support for the MD5 cryptographic hash algorithm, in addition to the DES-CBC algorithm described in RFC-1305, as described in the <a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon </a>page.</li>
-
-<p><li>The prefer-peer scheme, as described in the <a href=prefer.htm>Mitigation Rules and the <tt>prefer</tt> Keyword </a>page.</li>
-
-<p><li>Specification for the Simple Network Time Protocol (SNTP), as described in</li>
-
-<p>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. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt>ASCII</a>. Obsoletes RFC-1769 and RFC-1361.
-
-<p><li>Support for International Atomic Time (TAI), as described in</li>
-
-<p>Levine, J., and D. Mills. Using the Network Time Protocol to transmit International Atomic Time (TAI). <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/tai.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/tai.pdf>PDF</a>
-
-<p><li>Performance surveys for NTP Version 4 can be found in</li>
-
-<p>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet timekeeping around the globe. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Long Beach CA, December 1997), 365-371. Paper: <a
-href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>PowerPoint</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>PDF</a>
-
-<p>Mills, D.L. The network computer as precision timekeeper. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>PowerPoint</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>PDF</a>
-
-</ol>
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
<body>
<h3>Building and Installing the Distribution</h3>
- <img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>For putting out compiler fires.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:36</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#build">Building and Installing the Distribution</a>
<body>
<h3>Reference Clock Options</h3>
- <img src="pic/stack1a.jpg" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/stack1a.jpg" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>See the radios, all in a row.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:36</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#ref">Reference Clock Support</a>
<body>
<h3>Configuration Options</h3>
- <img src="pic/pogo3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
- <p>Gnu autoconfigure tools are in the backpack.<br clear="left">
- </p>
+ <img src="pic/pogo3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>Gnu autoconfigure tools are in the backpack.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:36</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Table of Contents</h4>
<ul>
- <li class=inline><a href=#basic>Basic Configuration Options - the <tt>configure</tt> utility</a>
- <li class=inline><a href=#opt>Options</a>
- <li class=inline><a href=#dir>Directory and File Names</a>
- <li class=inline><a href=#host>Host Type</a>
- <li class=inline><a href=#pkg>Optional Packages</a>
- <li class=inline><a href=#feat>Optional Features</a>
- <li class=inline><a href=#radio>Radio Clocks</a>
- <li class=inline><a href=#parse>PARSE Clocks</a>
-
-
+ <li class="inline"><a href="#basic">Basic Configuration Options - the <tt>configure</tt> utility</a>
+ <li class="inline"><a href="#opt">Options</a>
+ <li class="inline"><a href="#dir">Directory and File Names</a>
+ <li class="inline"><a href="#host">Host Type</a>
+ <li class="inline"><a href="#pkg">Optional Packages</a>
+ <li class="inline"><a href="#feat">Optional Features</a>
+ <li class="inline"><a href="#radio">Radio Clocks</a>
+ <li class="inline"><a href="#parse">PARSE Clocks</a>
</ul>
<hr>
- <h4 id=#basic>Basic Configuration Options - the <tt>configure</tt> utility</h4>
+ <h4 id="#basic">Basic Configuration Options - the <tt>configure</tt> utility</h4>
<p>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.</p>
<p>Configuration options are specified as arguments to the <tt>configure</tt> script. Following is a summary of the current options, as of the 4.0.99m version:</p>
<p>Usage: <tt>configure [options] [host]</tt><br>
- <h4 id=#opt>Options</h4>
- <p><tt>[defaults in brackets after descriptions]</tt> Configuration:</p>
+ </p>
+ <h4 id="#opt">Options</h4>
+ <p><tt>[defaults in brackets after descriptions]</tt> Configuration:</p>
<pre>
--cache-file=FILE cache test results in FILE
--help print this message
--version print the version of autoconf that created
configure
</pre>
- <h4 id=#dir>Directory and File Names</h4>
+ <h4 id="#dir">Directory and File Names</h4>
<pre>
--prefix=PREFIX install architecture-independent files in PREFIX [/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [same as prefix]
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM run sed PROGRAM on installed program names
</pre>
- <h4 id=#host>Host Type</h4>
+ <h4 id="#host">Host Type</h4>
<pre>
--build=BUILD configure for building on BUILD [BUILD=HOST]
--host=HOST configure for HOST [guessed]
--target=TARGET configure for TARGET [TARGET=HOST]
</pre>
- <h4 id=#pkg>Optional Packages</h4>
+ <h4 id="#pkg">Optional Packages</h4>
<pre>
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
crypto=rsaref Use the RSAREF library
electricfence Compile with ElectricFence malloc debugger
</pre>
- <h4 id=#feat>Optional Features</h4>
+ <h4 id="#feat">Optional Features</h4>
<pre>
--disable-FEATURE do not include FEATURE (same as
--enable-FEATURE=no)
tickadj=VALUE Force a value for 'tickadj'
udp-wildcard Use UDP wildcard delivery
</pre>
- <h4 id=#radio>Radio Clocks</h4>
- <p>(these are ordinarily enabled, if supported by the machine and operating system):
+ <h4 id="#radio">Radio Clocks</h4>
+ <p>(these are ordinarily enabled, if supported by the machine and operating system):</p>
<pre>
all-clocks Include drivers for all suitable non-PARSE clocks [enable]
ACTS NIST dialup clock
USNO US Naval Observatory dialup clock
WWV WWV audio receiver
</pre>
- <h4 id=#parse>PARSE Clocks</h4>
+ <h4 id="#parse">PARSE Clocks</h4>
<pre>
parse-clocks Include drivers for all suitable PARSE clocks [enable]
COMPUTIME Diem Computime Radio Clock
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
-</html>
+</html>
\ No newline at end of file
<body>
<h3>Server Options</h3>
- <img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The chicken is getting configuration advice.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:36</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#cfg">Configuration Commands</a>
<body>
<h3>Copyright Notice</h3>
- <img src="pic/sheepb.jpg" alt="jpg" align="left">"Clone me," says Dolly sheepishly<br clear="left">
+ <img src="pic/sheepb.jpg" alt="jpg" align="left"> "Clone me," says Dolly sheepishly
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:31</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>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.<br>
</p>
<body>
<h3>NTP Debugging Techniques</h3>
- <img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
- <p>We make house calls and bring our own bugs.<br clear="left">
- </p>
+ <img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>We make house calls and bring our own bugs.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:28</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>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 <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.</p>
<h4>Initial Startup</h4>
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
- <h4>Additional Information</h4>
- <p><a href="refclock.html">Reference Clock Drivers</a><br>
- <a href="audio.html">Reference Clock Audio Drivers</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
Other devices set these elements to zero.
<h4>Performance</h4>
<p>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.</p>
- <p>The accuracy of the system clock synchronized to the IRIG-B source with this driver and the <tt>ntpd</tt> daemon is 10-20 <font face="symbol">m</font>s 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.</p>
+ <p>The accuracy of the system clock synchronized to the IRIG-B source with this driver and the <tt>ntpd</tt> daemon is 10-20 <font face="symbol">m</font>s 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.</p>
+ <p>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.</p>
<h4>Monitor Data</h4>
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:
<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 3094572411.00027</tt></p>
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
- <h4>Additional Information</h4>
- <p><a href="refclock.html">Reference Clock Drivers</a><br>
- <a href="audio.html">Reference Clock Audio Drivers</a></p>
- <hr>
+ <hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<h4>Description</h4>
<p>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.</p>
<p>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.</p>
- <p>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 <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> 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.</p>
+ <p>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 <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> 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.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> 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 <a href="audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h4>Autotune</h4>
- <p>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 <tt>icom.h</tt> header file.</p>
+ <p>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.</p>
<p>Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the <tt>mode</tt> keyword of the <tt>server</tt> 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 <tt>mode</tt> keyword or a zero argument leaves the interface disabled.</p>
<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> 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 <tt>/dev/icom</tt> 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.</p>
<h4>Radio Broadcast Format</h4>
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
- <h4>Additional Information</h4>
- <a href="refclock.html">Reference Clock Drivers</a><br>
- <a href="audio.html">Reference Clock Audio Drivers</a>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" &amp;lt;html>
-<html>
-<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Executive Summary - Computer Network Time
-Synchronization</title>
-</head>
-<body>
-<h3>Executive Summary - Computer Network Time Synchronization</h3>
-
-<img align="left" src="pic/alice12.gif" alt="gif"><a href=
-"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
-Carroll</a>
-
-<p>The executive is the one on the left.<br clear="left">
-</p>
-
-<hr>
-<h4>Introduction</h4>
-
-<p>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.</p>
-
-<p>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.)</p>
-
-<h4>Protocol Design Issues</h4>
-
-<p>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 <i>
-timestamp</i> 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.</p>
-
-<p>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 <i>
-subnet</i>, 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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>Security Issues</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>Computer Clock Modelling and Error Analysis</h4>
-
-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 <i>tick</i>
-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 <i>tick</i>.
-Typical Unix system kernels provide a programmable mechanism to
-increase or decrease the value of <i>tick</i> by a small, fixed
-amount in order to amortize a given time adjustment smoothly over
-multiple <i>tick</i> intervals.
-
-<p>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</p>
-
-<center><i>T</i>(<i>t</i>) = <i>T</i>(<i>t</i><sub>0</sub>) + <i>
-R</i>(<i>t - t</i><sub>0</sub>) + 1/2 <i>D</i>(<i>t -
-t</i><sub>0</sub>)<sup>2</sup>,</center>
-
-<p>where <i>t</i> is the current time, <i>T</i> is the time offset
-at the last measurement update <i>t</i><sub>0</sub>, <i>R</i> is
-the frequency offset and <i>D</i> 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.</p>
-
-<p>The synchronization protocol estimates <i>
-T</i>(<i>t</i><sub>0</sub>) (and <i>R</i>(<i>t</i><sub>0</sub>),
-where relevant) at regular intervals <font face="symbol">t</font>
-and adjusts the clock to minimize <i>T</i>(<i>t</i>) in future. In
-common cases, <i>R</i> 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 <i>T</i> and <i>R</i> 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.</p>
-
-<p>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.</p>
-
-<h4>Correctness Principles</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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 <i>
-truechimers</i> and the others assumed incorrect <i>
-falsetickers</i>. Only the truechimers are used to adjust the
-system clock.</p>
-
-<h4>Data Grooming Algorithms</h4>
-
-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.
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>Further Reading</h4>
-
-<ol>
-<li>
-<p>Cristian, F. Probabilistic clock synchronization. In Distributed
-Computing 3, Springer Verlag, 1989, 146-158.</p>
-</li>
-
-<li>
-<p>Digital Time Service Functional Specification Version T.1.0.5.
-DigitalEquipment Corporation, 1989.</p>
-</li>
-
-<li>
-<p>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).</p>
-</li>
-
-<li>
-<p>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
-distributed real-time systems. IEEE Trans. Computers C-36, 8
-(August 1987), 933-939.</p>
-</li>
-
-<li>
-<p>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
-presence of faults. JACM 32, 1 (January 1985), 52-78.</p>
-</li>
-
-<li>
-<p>Marzullo, K., and S. Owicki. Maintaining the time in a
-distributed system. ACM Operating Systems Review 19, 3 (July 1985),
-44-54.</p>
-</li>
-
-<li>
-<p>Mills, D.L. Adaptive hybrid clock discipline algorithm for the
-Network Time Protocol. <i>IEEE/ACM Trans. Networking 6, 5</i>
-(October 1998), 505-514.</p>
-</li>
-
-<li>
-<p>Mills, D.L. Improved algorithms for synchronizing computer
-network clocks. <i>IEEE/ACM Trans. Networks 3, 3</i> (June 1995),
-245-254.</p>
-</li>
-
-<li>
-<p>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.</p>
-</li>
-
-<li>
-<p>Mills, D.L. Modelling and analysis of computer network clocks.
-Electrical Engineering Department Report 92-5-2, University of
-Delaware, May 1992, 29 pp.</p>
-</li>
-
-<li>
-<p>NIST Time and Frequency Dissemination Services. NBS Special
-Publication432 (Revised 1990), National Institute of Science and
-Technology, U.S. Department of Commerce, 1990.</p>
-</li>
-
-<li>
-<p>Schneider, F.B. A paradigm for reliable clock synchronization.
-Department of Computer Science Technical Report TR 86-735, Cornell
-University, February 1986.</p>
-</li>
-
-<li>
-<p>Srikanth, T.K., and S. Toueg. Optimal clock synchronization.
-JACM 34, 3 (July 1987), 626-645.</p>
-</li>
-
-<li>
-<p>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.</p>
-</li>
-</ol>
-
-<hr>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"home"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-<mills@udel.edu></a></address>
-</body>
-</html>
-
<body>
<h3>External Clock Discipline and the Local Clock Driver</h3>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:28</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
<hr>
<p>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.</p>
<p>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> 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.</p>
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <title>Gadget Box PPS Level Converter and CHU Modem</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Gadget Box PPS Level Converter and CHU Modem</h3>
- <img src="pic/gadget.jpg" alt="gif" align="left">A Gadget Box built by Chuck Hanavin
- <h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
- <br clear="left">
- </p>
- <h4>table of Contents</h4>
- <ul>
- <li class="inline"><a href="#intro">Introduction</a>
- <li class="inline"><a href="#ckt">Circuit Description</a>
- <li class="inline"><a href="#file">Files</a>
- </ul>
- <hr>
- <h4 id="#intro">Introduction</h4>
- <p>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 <a href="http://www.eecis.udel.edu/%7emills/ntp/ntp">gadget.tar.Z</a>, or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp</tt> directory.</p>
- <p>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 <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> driver.</p>
- <p>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.</p>
- <h4 id="#ckt">Circuit Description</h4>
- <p>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.</p>
- <p>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.</p>
- <p>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.</p>
- <p>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.</p>
- <h4 id="#file">Files</h4>
- <p>Following is a list of files included in this archive. All files are in PostScript, except the <tt>README</tt> and <tt>gadget.lst</tt> files, which are in ASCII. The files <tt>gadget.s01, gadget.s02</tt> and <tt>gadget.lst</tt> were generated using the Schema schematic-capture program from Omation. The printed-circuit files <tt>*.lpr</tt> were generated using Schema-PCB, also from Omation.</p>
- <p><tt>README</tt> - helpful information<br>
- <tt>gadget.s01</tt> - circuit schematic<br>
- <tt>gadget.s02</tt> - minibox assembly drawing<br>
- <tt>gadget.lst</tt> - net list, pin list, parts list, etc.<br>
- <tt>gen0102.lpr</tt> - pcb x-ray diagram<br>
- <tt>art01.lpr</tt> - pcb artword side 1<br>
- <tt>art02.lpr</tt> - pcb artwork side 2<br>
- <tt>adt0127.lpr</tt> - pcb assembly drawing<br>
- <tt>dd0124.lpr</tt> - pcb drill drawing<br>
- <tt>sm0228.lpr</tt> - pcb solder mask (side 2)<br>
- <tt>sst0126.lpr</tt> - pcb silkscreen mask (side 1)</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
<h3><tt>ntp-keygen</tt> - generate public and private keys</h3>
<img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Alice holds the key.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">21:04</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 09, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
- <br clear="left">
<h4>Table of Contents</h4>
<ul>
- <li class="inline"><a href="#synop">Synopsis</a>
- <li class="inline"><a href="#desc">Description</a>
+ <li class="inline"><a href="#intro">Introduction</a>
<li class="inline"><a href="#run">Running the program</a>
- <li class="inline"><a href="#exam">Trusted Hosts and Groups</a>
+ <li class="inline"><a href="#trust">Trusted Hosts and Groups</a>
<li class="inline"><a href="#idexp">Identity Schemes</a>
+ <li class="inline"><a href="#exam">Example</a>
<li class="inline"><a href="#cmd">Command Line Options</a>
<li class="inline"><a href="#symkey">Symmetric Key File</a>
<li class="inline"><a href="#priv">Private Key Files</a>
<li class="inline"><a href="#bug">Bugs</a>
</ul>
<hr>
- <h4 id="#synop">Synopsis</h4>
- <tt>ntp-keygen</tt>
- <h4 id="#desc">Description</h4>
+ <h4 id="#intro">Introduction</h4>
<p>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.</p>
<p>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 <tt>ntpkey_</tt> and end with the postfix <tt><i>_hostname.filestamp</i></tt>, where <tt><i>hostname</i></tt> is the owner name, usually the string returned by the Unix <tt>gethostname()</tt> routine, and <tt><i>filestamp</i></tt> 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 <tt>rm ntpkey*</tt> command or all files generated at a specific time can be removed by a <tt>rm *<i>filestamp</i></tt> 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.</p>
<p>All files are installed by default in the keys directory <tt>/usr/local/etc</tt>, 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.</p>
<p>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.</p>
<p>Running the program as other than root and using the Unix <tt>su</tt> command to assume root may not work properly, since by default the OpenSSL library looks for the random seed file <tt>.rnd</tt> in the user home directory. However, there should be only one <tt>.rnd</tt>, most conveniently in the root directory, so it is convenient to define the <tt>$RANDFILE</tt> environment variable used by the OpenSSL library as the path to <tt>/.rnd</tt>.</p>
<p>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 <tt>/etc</tt> using the <tt>keysdir</tt> 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.</p>
- <p>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 <tt>ntp-keygen</tt> command and as the <tt>pw</tt> subcommand in the <tt>ntpd</tt> 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.</p>
- <h4 id="#exam">Trusted Hosts and Groups</h4>
+ <p>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 <tt>-p</tt> option to the <tt>ntp-keygen</tt> program and as the <tt>pw</tt> subcommand in the <tt>ntpd</tt> 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.</p>
+ <h4 id="#trust">Trusted Hosts and Groups</h4>
<p>Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as explained in the <a href="authopt.html">Authentication Options</a> 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.</p>
- <p>On each trusted server as root, change to the keys directory. To insure a fresh fileset, remove all <tt>ntpkey</tt> files. Then run <tt>ntp-keygen -T</tt> to generate keys and a trusted certificate. On all other hosts do the same, but leave off the <tt>-T</tt> 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.</p>
-<p>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.
- <p>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.</p>
+ <p>On each trusted server as root, change to the keys directory. To insure a fresh fileset, remove all <tt>ntpkey</tt> files. Then run <tt>ntp-keygen -T</tt> to generate keys and a trusted certificate. On all other hosts do the same, but leave off the <tt>-T</tt> 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 <tt>ntp-keygen</tt> program can be run to refresh the certificate without affecting ongoing operations; however, if the keys are refreshed, the NTP daemon should be restarted.</p>
+ <p>NTP groups can be used to define cryptographic compartments, as described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Protocol</a> 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.</p>
+ <p>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 <i>alice</i> exports her server credentials to dependent clients, but imports <i>bob</i> client credentials for the associations where the certificate trail ends at trusted host <i>bob </i>in a different group<i>.</i></p>
<p>After setting up the environment it is advisable to update certificates from time to time, if only to extend the validity interval. Simply run <tt>ntp-keygen</tt> with the same flags as before to generate new certificates using existing keys. The next time <tt>ntpd</tt> 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.</p>
-<h4 id="#idexp">Identity Schemes</h4>
-
- <p>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.</p>
- <p>The PC scheme is set up as follows. On trusted agent <i>alice</i> run <tt>ntp-keygen -P -p <i>password</i></tt> 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 <tt>ntp-keygen</tt> program prompts for the password if it reads an encrypted file and the <tt>-p</tt> option is not present.</p>
- <p>Copy the host key file <tt>ntpkey_RSAkey_<i>alice.filestamp</i></tt> and certificate file <tt>ntpkey_RSA-MD5_cert_<i>alice.filestamp</i></tt> to all group hosts. On each host <i>bob</i> install a soft link from the generic name <tt>ntpkey_host_bob</tt> to the host key file and soft link <tt>ntpkey_cert_bob</tt> to the certificate file. Note the generic links are on <i>bob</i>, but point to files generated by <i>alice</i>. 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.</p>
- <p>For the IFF scheme and trusted agent <i>Alice</i>, run the <tt>ntp-keygen</tt> program with the <tt>-I -p <i>password</i></tt> options. Then proceed as in the TC scheme to generate keys and certificates for each group host. Then, copy the IFF parameters file <tt>ntpkeys_IFFpar_<i>alice.filestamp</i></tt> to all hosts in the group. On each host <i>bob</i> install a soft link from the generic <tt>ntpkey_iff_<i>alice</i></tt> to this file and a soft link from the generic <tt>ntpkey_iff_<i>bob</i></tt> to the same file. As the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
- <p>For the GQ scheme and trusted agent <i>Alice</i>, run the <tt>ntp-keygen</tt> program with the <tt>-G -p <i>password</i></tt> options. Then proceed as in the TC scheme to generate keys and certificates for each group host. Then, copy the GQ parameters file <tt>ntpkeys_GQpar_<i>alice.filestamp</i></tt> to all group hosts. On each host <i>bob</i> install a soft link from the generic <tt>ntpkey_gq_<i>alice</i></tt> to this file and a soft link from the generic <tt>ntpkey_gq_<i>bob</i></tt> 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.</p>
- <p>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 <i>Alice</i> run the <tt>ntp-keygen</tt> program with the <tt>-V <i>n</i> -p <i>password</i></tt> options, where <i>n</i> is the number of revokable keys, typically 5. Then, copy the MV parameters file <tt>ntpkeys_MVpar_<i>alice.filestamp</i></tt> to all group servers. On server <i>bob</i> install a soft link from the generic <tt>ntpkey_mv_<i>bob</i></tt> to this file. Select one of the <tt>ntpkeys_MVkey<i>k</i>_<i>alice.filestamp</i></tt> files (except the last)where <i><tt>k</tt></i> is the key number, and copy it to all group clients, including those servers that may become clients of other servers. On client <i>dave</i> install a soft link from the generic <tt>ntpkey_mvkey_<i>alice</i></tt> to this file. As the MV scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
+ <h4 id="#idexp">Identity Schemes</h4>
+ <p>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 <a href="http://www.eecis.udel.edu/~mills/keygen.html">Identification Schemes</a> 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.</p>
+ <p>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.</p>
+ <p>The PC scheme is set up as follows. On TA <i>alice</i> run <tt>ntp-keygen -P -p <i>password</i></tt> to generate the host key file <tt>ntpkey_RSAkey_<i>alice.filestamp</i></tt> and private certificate file <tt>ntpkey_RSA-MD5_cert_<i>alice.filestamp</i></tt>. Do not generate keys and certificates on the other group hosts; however, be sure to specify <tt>pw <i>password</i></tt> in the <tt>crypto</tt> command in all NTP configuration files. Note that, as with all encrypted files, the <tt>ntp-keygen</tt> program prompts for the password if it reads an encrypted file and the <tt>-p</tt> option is not present.</p>
+ <p>Copy the host key file and private certificate file to all group hosts. On each host <i>bob</i> install a soft link from the generic name <tt>ntpkey_host_<i>bob</i></tt> to the host key file and soft link <tt>ntpkey_cert_<i>bob</i></tt> to the private certificate file. Note the generic links are on <i>bob</i>, but point to files generated by <i>alice</i> 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.</p>
+ <p>The IFF scheme is set up as follows. On TA <i>alice</i> run the <tt>ntp-keygen</tt> program with the <tt>-I -p <i>password</i></tt> options to produce the server key file <tt>ntpkey_IFFpar_<i>alice.filestamp</i></tt> and client key file <tt>ntpkey_IFFkey_<i>alice.filestamp</i></tt>. 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 <tt>ntpkey_iff_<i>alice</i></tt> to the client key file. On each server <i>bob</i> install a soft link from generic <tt>ntpkey_iff_<i>bob</i></tt> to the server key file. As the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
+ <p>The GQ scheme is set up as follows. On TA <i>alice</i> run the <tt>ntp-keygen</tt> program with the <tt>-G -p <i>password</i></tt> options to produce the server/client key file <tt>ntpkey_GQpar_<i>alice.filestamp</i></tt>. 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 <tt>ntpkey_gq_<i>alice</i></tt> to this file. On each server <i>bob</i> install a soft link from generic <tt>ntpkey_gq_<i>bob</i></tt> 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.</p>
+ <p>The MV scheme is set up as follows. On TA <i>Alice</i> run the <tt>ntp-keygen</tt> program with the <tt>-V <i>n</i> -p <i>password</i></tt> options, where <i>n</i> is the number of revokable keys (typically 5) to produce the server key file <tt>ntpkeys_MVpar_<i>alice.filestamp </i></tt>and client key files <tt>ntpkeys_MVkey<i>d</i>_<i>alice.filestamp</i></tt> where <i><tt>d</tt></i> is the key number (0 < <i><tt>d</tt></i> < <i>n</i>). 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 <i>dave</i> install a soft link from generic <tt>ntpkey_mv_<i>alice </i></tt>to the client key file. On each server <i>bob</i> install a soft link from generic <tt>ntpkey_mv_<i>bob</i></tt> to the server key file. Note that the MV scheme is independent of host key and certificates, these files can be refreshed as needed.</p>
<p>If it is necessary to use a different sign key or different digest/signature scheme than the default, run <tt>ntp-keygen</tt> with the <tt>-S</tt> option and either <tt>RSA</tt> or <tt>DSA</tt> argument as needed. The most often need to do this is when a DSA-signed certificate is used. If <tt>ntp-keygen</tt> 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 <tt>ntp-keygen</tt> with the <tt>-c</tt> option and selected scheme as needed. If <tt>ntp-keygen</tt> is run again without the option, it will generate a new certificate using the same scheme and existing sign key.</p>
+ <h4 id="#exam">Example</h4>
+ <p>First, generate the host key, trusted host certificate and IFF identity file for trusted host <i>whimsy</i>. The <tt>ntp-keygen</tt> program on <i>whimsy</i> produces the following typescript.</p>
+ <pre>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
+</pre>
+ <p>The following files and links should be on <i>whimsy</i>:</p>
+ <pre>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
+</pre>
+ <p>Next, generate the host key and nontrusted host certificate for host <i>mort</i>. The <tt>ntp-keygen</tt> program on <i>mort</i> produces the following typescript.</p>
+ <pre>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
+</pre>
+ <p>On <i>whimsy</i>, copy the file <tt>ntpkey_IFFpar_whimsy.udel.edu.3248306666</tt> to <i>mort</i>.</p>
+ <pre>whimsy:/usr/local/etc# scp ntpkey_IFFpar_whimsy.udel.edu.3248306666 mort:/usr/local/etc/ntpkey_IFFpar_whimsy.udel.edu.3248306666
+</pre>
+ <p>On <i>mort</i>, install the links</p>
+ <pre>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
+</pre>
+ <p>Note the same file is linked from both hosts <i>whimsy</i> and <i>mort</i> if both are to be servers as well as clients. The following files and links should be on <i>mort</i>:</p>
+ <pre>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
+</pre>
+ <p>Following is edited output from the <tt>ntpq</tt> program on <i>whimsy</i> with the <tt>rv</tt> command. Note the self-sgned certificate subject and issuer names are <i>whimsy</i> and the <tt>0x2</tt> confirms the certificate is trusted.</p>
+ <pre>hostname="whimsy.udel.edu", signature="md5WithRSAEncryption",
+flags=0x80021, hostkey=3248306666, refresh=3248306823,
+cert="whimsy.udel.edu whimsy.udel.edu 0x2 3248306666"
+</pre>
+ <p>Following is edited output from the <tt>ntpq</tt> program on <i>mort</i> with the <tt>rv</tt> command. Note the self-sgned certificate subject and issuer names are <i>whimsy</i> and the <tt>0x2</tt> confirms the certificate is trusted. Note the Autokey protocol has fetched the trusted certificate for <i>whimsy</i>, confirmed <i>whimsy</i> identity with the IFF scheme and has its certificate signed by <i>whimsy</i>. The <tt>0x3</tt> confirms the certificates have all been validated as well.</p>
+ <pre>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"
+</pre>
+ <p>Following is edited output from the <tt>ntpq</tt> program on <i>mort</i> with the <tt>rv <i>assoc</i></tt> command. This reveals the association host name, signature scheme, flags (showing the IFF scheme) and trusted host name.</p>
+ <pre>hostname="whimsy.udel.edu", signature="md5WithRSAEncryption",
+flags=0x83f21, identity="whimsy.udel.edu"
+</pre>
<h4 id="#cmd">Command Line Options</h4>
<dl>
<dt><tt>-c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]</tt>
<p>The <tt>ntp-keygen</tt> program generates a MD5 symmetric keys file <tt>ntpkey_MD5key_<i>hostname.filestamp</i></tt>. 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 <tt>ntp.keys</tt>, so <tt>ntp-keygen</tt> 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 <a href="ntpdc.html"><tt>ntpq</tt></a> and <a href="ntpq.html"><tt>ntpdc</tt></a> utilities.</p>
<p>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 <tt>keys</tt> configuration file command. Additional keys consisting of easily remembered passwords should be added by hand for use with the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. While the key identifiers for MD5 keys must be in the range 1-65,535, inclusive, the <tt>ntp-keygen</tt> program uses only the identifiers from 1 to 16. The key identifier for each association is specified as the <tt>key</tt> subcommand with the <tt>server</tt> or <tt>peer</tt> configuration command.</p>
<h4 id="#priv">Private Key Files</h4>
- <p>The Autokey protocol requires every host to have a private/public host key pair and an optional private/public sign key pair. The <tt>ntp-keygen</tt> program generates a private key file <tt>ntpkey_<i>keyname</i>key_<i>hostname.filestamp</i></tt>, where <i>keyname</i> is the name of the public key algorithm type, either <tt>RSA</tt> or <tt>DSA</tt>. 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 <tt>ntpkey_host_<i>hostname</i></tt> and the sign key file <tt>ntpkey_sign_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct these names to the generated files.</p>
- <h4 id="#ident">Identification Parameter Files</h4>
- <p>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 <tt>sdist</tt> facility often used to update the latest software within the administrative domain.</p>
- <p>The <tt>ntp-keygen</tt> program with the <tt>-I</tt> flag generates an IFF parameter file <tt>ntpkey_IFFpar_<i>hostname.filestamp</i></tt> and with the <tt>-G</tt> flag generates a GQ parameter file <tt>ntpkey_GQpar_<i>hostname.filestamp</i></tt>. The NTP daemon loads the IFF parameter file <tt>ntpkey_IFFpar_<i>hostname</i></tt> and the GQ parameter file <tt>ntpkey_GQpar_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> 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.</p>
- <p>When a certificate is generated for the GQ scheme, the <tt>ntp-keygen</tt> also generates a GQ key file <tt>ntpkey_GQkey_<i>hostname.filestamp</i></tt>. The NTP daemon loads the GQ key file <tt>ntpkey_gq_<i>hostname</i></tt>, 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.</p>
- <h4 id="#cert">Certificates</h4>
+ <p>The Autokey protocol requires every host to have a private/public host key pair and an optional private/public sign key pair. The <tt>ntp-keygen</tt> program generates a private key file <tt>ntpkey_<i>keyname</i>key_<i>hostname.filestamp</i></tt>, where <i><tt>keyname</tt></i> is the name of the public key algorithm type, either <tt>RSA</tt> or <tt>DSA</tt>. 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 <tt>ntpkey_host_<i>hostname</i></tt> and the sign key file <tt>ntpkey_sign_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct these names to the generated files.</p>
+ <h4 id="#ident">Certificates</h4>
<p>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.</p>
<p>Normally, the <tt>ntp-keygen</tt> program generates certificates which contain only public values, so they can be transmitted and stored without cryptographic protection. With the <tt>-P</tt> option the program generates a certificate including a "X509v3 "Extended Key Usage" extension field with value <tt>private</tt> 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.</p>
- <p>The Autokey TC identification scheme automates the certificate trail construction and verification process with each server at stratum <i>n</i> operating as a CA for clients at stratum <i>n</i> + 1. The <tt>ntp-keygen</tt> program generates a self-signed X.509v3 public certificate <tt>ntpkey_<i>digestname</i>cert_<i>hostname.filestamp</i></tt>, where <i>digestname</i> is the name of the digest/signature scheme. The NTP daemon loads the certificate <tt>ntpkey_cert_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct this name to the generated file. The <tt>ntp-keygen</tt> program with the <tt>-T</tt> flag generates a trusted certificate including a "X509v3 Extended Key Usage" extension field with value <tt>trustRoot</tt>. Certificates generated without this option do not contain this field and are by default non-trusted.</p>
+ <p>The Autokey TC identification scheme automates the certificate trail construction and verification process with each server at stratum <i>n</i> operating as a CA for clients at stratum <i>n</i> + 1. The <tt>ntp-keygen</tt> program generates a self-signed X.509v3 public certificate <tt>ntpkey_<i>digestname</i>cert_<i>hostname.filestamp</i></tt>, where <i><tt>digestname</tt></i> is the name of the digest/signature scheme. The NTP daemon loads the certificate <tt>ntpkey_cert_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct this name to the generated file. The <tt>ntp-keygen</tt> program with the <tt>-T</tt> flag generates a trusted certificate including a "X509v3 Extended Key Usage" extension field with value <tt>trustRoot</tt>. Certificates generated without this option do not contain this field and are by default non-trusted.</p>
<p>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.</p>
<p>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.</p>
<h4 id="#leap">Leapseconds Table</h4>
<p>where <i><tt>keyno</tt></i> is a positive integer in the range 1-65,535, <i><tt>type</tt></i> is the string <tt>MD5</tt> defining the key format and <i><tt>key</tt></i> 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.</p>
<p>Note that the keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt> 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.</p>
<h4 id="#bug">Bugs</h4>
- <p>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.</p>
+ <p>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.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>Hints and Kinks</h3>
<img src="pic/alice35.gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>Mother in law has all the answers.<br clear="left">
- </p>
+ <p>Mother in law has all the answers.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:27</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>This is an index for a set of troubleshooting notes contained in individual text files in the <tt>./hints</tt> 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.</p>
<p>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 <a href="hints/">directory listing</a>.</p>
<body>
<h3>How to Write a Reference Clock Driver</h3>
- <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
- <p>You need a little magic.
- </p>
+ <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>You need a little magic.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:26</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#desc">Description</a>
<p>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.</p>
<p>The best way to understand how the clock drivers work is to study the <tt>ntp_refclock.c</tt> module and one of the drivers already implemented, such as <tt>refclock_wwvb.c</tt>. Routines <tt>refclock_transmit()</tt> and <tt>refclock_receive()</tt> maintain the peer variables in a state analogous to a network peer and pass received data on through the clock filters. Routines <tt>refclock_peer()</tt> and <tt>refclock_unpeer()</tt> 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.</p>
<p>The main interface used by these routines is the <tt>refclockproc</tt> 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 <tt>peer</tt> structure, which is used for all peer-specific processing and contains a pointer to the <tt>refclockproc</tt> structure, which in turn contains a pointer to the unit structure, if used. For legacy purposes, a table <tt>typeunit[type][unit]</tt> contains the peer structure pointer for each configured clock type and unit. This structure should not be used for new implementations.</p>
- <p>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 <tt>tty_clk</tt> STREAMS module and <tt>ppsapi</tt> PPS interface described in the <a href="ldisc.html">Line Disciplines and Streams Modules</a> page. The <tt>tty_clk</tt> module reduces latency errors due to the operating system and serial port code in slower systems. The <tt>ppsapi</tt> PPS interface replaces the <tt>ppsclock</tt> 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 <a href=pps.html>Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
+ <p>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 <tt>tty_clk</tt> STREAMS module and <tt>ppsapi</tt> PPS interface described in the <a href="ldisc.html">Line Disciplines and Streams Modules</a> page. The <tt>tty_clk</tt> module reduces latency errors due to the operating system and serial port code in slower systems. The <tt>ppsapi</tt> PPS interface replaces the <tt>ppsclock</tt> 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 <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
<p>Radio and modem reference clocks by convention have addresses in the form <tt>127.127.<i>t</i>.<i>u</i></tt>, where <i>t</i> is the clock type and <i>u</i> 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 <tt>/dev/device<i>d</i>d</tt> to the particular hardware device involved, where <tt><i>d</i></tt> corresponds to the unit number.</p>
<p>By convention, reference clock drivers are named in the form <tt>refclock_<i>xxxx</i>.c</tt>, where <i>xxxx</i> 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 <a href="refclock.html">Reference Clock Drivers</a> 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 <a href="config.html">Configuration Options</a> page.</p>
<p>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 <tt>ntpq</tt> and <tt>ntpdc</tt>, as well as the <tt>filegen</tt> facility, which can be used to record device status on a continuous basis.</p>
<body>
<h3>The Network Time Protocol (NTP) Distribution</h3>
- <img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:26</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<br clear="left">
<h4>Table of Contents</h4>
<ul>
<body>
<h3>Kernel Model for Precision Timekeeping</h3>
- <p><img src="pic/alice61.gif" alt="gif" align="left"> <a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a></p>
+ <p><img src="pic/alice61.gif" alt="gif" align="left"> <a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a></p>
<p>Alice touched the kernel and it exploded.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:26</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
<hr>
<p>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.</p>
- <p>The hybrid PLL/FLL code described in [2] is included in Solaris and Digital/Compaq/HP Tru64. It includes two system calls <tt>ntp_gettime()</tt> and <tt>ntp_adjtime()</tt> 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 <a href=ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz>nanokernel.tar.gz</a>.</p>
+ <p>The hybrid PLL/FLL code described in [2] is included in Solaris and Digital/Compaq/HP Tru64. It includes two system calls <tt>ntp_gettime()</tt> and <tt>ntp_adjtime()</tt> 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 <a href="ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz">nanokernel.tar.gz</a>.</p>
<p>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 <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> 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.</p>
<h4>References</h4>
<ol>
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <title>Kernel Programming Interface for Precision Time Signals</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Kernel Programming Interface for Precision Time Signals</h3>
- <h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
- <br clear="left">
- </p>
- <hr>
- <p>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.</p>
- <p>Support for this API has been implemented in the NTP Version 4 software distribution. The <tt>/usr/include/sys/timepps.h</tt> header file defines the API interface routines and data structures. The API obsoletes previous APIs based on the <tt>tty_clock</tt> and <tt>ppsclock</tt> line disciplines and streams modules, which are no longer supported. The API used by the <a href="driver22.html">PPS Clock Discipline</a> 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 <tt>PPSkit</tt> kernel software in Linux. Limited support for Solaris from 2.8 is available using the <tt>timepps.h.solaris</tt> header file included in this distribution. Copy this file to <tt>/usr/include/sys</tt> before configuring the distributution.</p>
- <p>The API is normally used in conjunction with the precision time kernel modifications described in the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page.</p>
- <h4>Reference</h4>
- <ol>
- <p></p>
- <li>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. <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc2783.txt">ASCII</a>
- </ol>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
<body>
<h3>Line Disciplines and Streams Modules</h3>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:25</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
<hr>
<h4>Description</h4>
<p>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 (<tt>ioctls</tt>) 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.</p>
<p>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.</p>
<p>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 <tt>ntpd</tt>. 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.</p>
-
<h4><tt>tty_clk</tt> Line Discipline/Streams Module</h4>
<p>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 <tt>timeval</tt> format. Both <tt>select()</tt> and <tt>SIGIO</tt> are supported by the routine. Support for this routine is automatically detected during the NTP build process and interface code compiled as necessary.</p>
<p>There are two versions of the <tt>tty_clk</tt> routine. The <tt>tty_clk.c</tt> line discipline is designed for older BSD systems and is compiled in the kernel. The <tt>tty_clk_STREAMS.c</tt> 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 <tt>README</tt> file in the <tt>./kernel</tt> directory.</p>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html>
-<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>NTP Timescale and Leap Seconds</title>
-</head>
-<body>
-<h3>NTP Timescale and Leap Seconds</h3>
-
-<img align="left" src="pic/alice15.gif" alt="gif"><a href=
-"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
-Carroll</a>
-
-<p>The Mad Hatter and the March Hare are discussing whether the
-Teapot serial number should have two or four digits.<br clear=
-"left">
-</p>
-
-<hr>
-<h4>Introduction</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>The NTP Timescale</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>Conversion to Other Timescales</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>Timescale Resolution and the Tick Interval</h4>
-
-<p>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.</p>
-
-<p>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.
-
-<h4>Leap Seconds</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h4>Reckoning with NTP and UTC Leap seconds</h4>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<hr>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"gif"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-<mills@udel.edu></a></address>
-</body>
-</html>
-
<h3>Automatic NTP Configuration Options</h3>
<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:25</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
- <br clear="left">
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#many">Manycasting</a>
<body>
<h3>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</h3>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:24</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
<hr>
<p>The technical memorandum: <cite>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</cite><a href="http://www.eecis.udel.edu/%7emills/database/memos/memo96a.ps">(PostScript) </a>describes a number of techniques for conducting experiments typical of computer network and transmission systems engineering.</p>
<p>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.</p>
<body>
<h3>Miscellaneous Options</h3>
- <img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We have three, now looking for more.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:24</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<hr>
<dl>
<dt><tt>broadcastdelay <i>seconds</i></tt>
<body>
<h3>Monitoring Options</h3>
- <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The pig watches the logs.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:24</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<hr>
<tt>ntpd</tt> includes a comprehensive monitoring facility suitable for continuous, long term recording of server and client timekeeping performance. See the <tt>statistics</tt> 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 <tt>cron</tt> jobs, the datacan be automatically summarized and archived for retrospective analysis.
<h4>Monitoring Commands</h4>
<body>
<h3>Notes on setting up a NTP subnet</h3>
- <img src="pic/tonea.gif" alt="gif" align="left">From NBS Special Publication 432 (out of print)<br clear="left">
+ <img src="pic/tonea.gif" alt="gif" align="left">From NBS Special Publication 432 (out of print)
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:23</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
+ <hr>
<h4>Introduction</h4>
<p>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.</p>
<p><tt>ntpd</tt> includes a complete implementation of the NTP Version 3 specification, as defined in:</p>
<body>
<h3><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</h3>
- <img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The mushroom knows all the command line options.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:22</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#synop">Synopsis</a><br>
+ <li class="inline"><a href="#descr">Description</a><br>
+ <li class="inline"><a href="#op">How NTP Operates</a><br>
+ <li class="inline"><a href="#freq">Frequency Discipline</a><br>
+ <li class="inline"><a href="#modes">Operating Modes</a><br>
+ <li class="inline"><a href="#poll">Poll Interval Control</a><br>
+ <li class="inline"><a href="#poll">Poll Interval Control</a><br>
+ <li class="inline"><a href="#notes">Notes</a><br>
+ <li class="inline"><a href="#cmd">Command Line Options</a><br>
+ <li class="inline"><a href="#cfg">The Configuration File</a><br>
+ <li class="inline"><a href="#opt">Configuration Options</a><br>
+ <li class="inline"><a href="#files">Files</a>
+ </ul>
<hr>
- <p><a href="#synop">Synopsis</a><br>
- <a href="#descr">Description</a><br>
- <a href="#op">How NTP Operates</a><br>
- <a href="#freq">Frequency Discipline</a><br>
- <a href="#modes">Operating Modes</a><br>
- <a href="#poll">Poll Interval Control</a><br>
- <a href="#poll">Poll Interval Control</a><br>
- <a href="#notes">Notes</a><br>
- <a href="#cmd">Command Line Options</a><br>
- <a href="#cfg">The Configuration File</a><br>
- <a href="#opt">Configuration Options</a><br>
- <a href="#files">Files</a></p>
<h4 id="#synop">Synopsis</h4>
<tt>ntpd [ -aAbdgLmNPqx ] [ -c <i>conffile</i> ] [ -f <i>driftfile</i> ] [ -g ] [ -k <i>keyfile</i> ] [ -l <i>logfile</i> ] [ -N high ] [ -p <i>pidfile</i> ] [ -r <i>broadcastdelay</i> ] [ -s <i>statsdir</i> ] [ -t <i>key</i> ] [ -v <i>variable</i> ] [ -V <i>variable</i> ] [ -x ]</tt>
<h4 id="#descr">Description</h4>
<body>
<h3><tt>ntpdate</tt> - set the date and time via NTP</h3>
- <img src="pic/rabbit.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>I told you it was eyeball and wristwatch.<br clear="left">
- </p>
+ <img src="pic/rabbit.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>I told you it was eyeball and wristwatch.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:21</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>Disclaimer: The functionality of this program is now available in the <tt>ntpd</tt> program. See the <tt>-q</tt> command line option in the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page. After a suitable period of mourning, the <tt>ntpdate</tt> program is to be retired from this distribution</p>
<h4>Synopsis</h4>
<body>
<h3><tt>ntpdc</tt> - special NTP query program</h3>
- <img src="pic/alice31.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>This program is a big puppy.<br clear="left">
- </p>
+ <img src="pic/alice31.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>This program is a big puppy.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:21</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<h4>Synopsis</h4>
<tt>ntpdc [ -ilnps ] [ -c <i>command</i> ] [ <i>host</i> ] [ ... ]</tt>
<body>
<h3><tt>ntpq</tt> - standard NTP query program</h3>
- <img src="pic/bustardfly.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
- <p>A typical NTP monitoring packet.<br clear="left">
- </p>
+ <img src="pic/bustardfly.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>A typical NTP monitoring packet</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:20</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<h4>Synopsis</h4>
<tt>ntpq [-inp] [-c <i>command</i>] [<i>host</i>] [...]</tt>
<body>
<h3><tt>ntptime</tt> - read kernel time variables</h3>
- <img src="pic/pogo5.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
- <p>The turtle has been swimming in the kernel.<br clear="left">
- </p>
+ <img src="pic/pogo5.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>The turtle has been swimming in the kernel.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:19</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<h4>Synopsis</h4>
<tt>ntptime [ -chr ] [ -e <i>est_error</i> ] [ -f <i>frequency</i> ] [ -m <i>max_error</i> ] [ -o <i>offset</i> ] [ -s <i>status</i> ] [ -t <i>time_constant</i>]</tt>
<body>
<h3><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</h3>
- <img src="pic/alice13.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>The rabbit knows the way back.<br clear="left">
- </p>
+ <img src="pic/alice13.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>The rabbit knows the way back.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:19</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<h4>Synopsis</h4>
<tt>ntptrace [ -vdn ] [ -r <i>retries</i> ] [ -t <i>timeout</i> ] [ <i>server</i> ]</tt>
<body>
<h3>Patching Procedures</h3>
- <img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> rom <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>The Mad Hatter needs patches.<br clear="left">
- </p>
+ <img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html"> rom <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>The Mad Hatter needs patches.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:18</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>A distribution so widely used as this one eventually develops numerous barnacles as the result of <a href="porting.html">porting</a> 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.</p>
<ol>
<body>
<h3>Porting Hints</h3>
- <img src="pic/wingdorothy.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
- <p>Porting Dorothy in Oz.<br clear="left">
+ <img src="pic/wingdorothy.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
+ <p>Porting Dorothy in Oz
</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:17</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>NOTE: The following procedures have been replaced by GNU <tt>automake</tt> and <tt>autoconfigure</tt>. This page is to be updated in the next release.</p>
<p>Porting to a new machine or operating system ordinarily requires updating the <tt>./machines</tt> directory and the <tt>./compilers</tt> directories in order to define the build environment and autoconfigure means. You will probably have to modify the <tt>ntp_machines.h</tt> file and <tt>"l_stdlib.h"</tt> files as well. The two most famous trouble spots are the I/O code in <tt>./ntpd/ntp_io.c</tt> and the clock adjustment code in <tt>./ntpd/ntp_unixclock.c</tt>.</p>
<body>
<h3>Pulse-per-second (PPS) Signal Interfacing</h3>
- <img src="pic/alice32.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice32.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Alice is trying to find the PPS signal connector.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:15</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
<hr>
<p>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 <font face="Symbol">m</font>s 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.</p>
<img src="pic/gadget.jpg" alt="gif" align="left">A Gadget Box built by Chuck Hanavin<br clear="left">
<body>
<h3>Mitigation Rules and the <tt>prefer</tt> Keyword</h3>
- <img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>Listen carefully to what I say; it is very complicated.
- </p>
- <h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
- <br clear="left">
- </p>
- <h4>Table of Contents</h4>
+ <img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>Listen carefully to what I say; it is very complicated.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:15</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
+ <h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a>
<li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a>
+++ /dev/null
-<html><head><title>
-Stations, Frequencies and Geographic Coordinates
-</title></head><body><h3>
-Stations, Frequencies and Geographic Coordinates
-</h3><hr>
-
-The following data were obtained from the International Frequency List
-published by the ITU and other sources.
-
-<p><table cols=3 width=100%>
-
-<tr>
-<td>Station</td>
-<td>Frequencies</td>
-<td>Coordinates</td>
-</tr>
-
-<tr>
-<td>WWV Ft. Collins, CO</td>
-<td>2.5/5/10/15/20 MHz</td>
-<td>40:40:49.0N 105:02:27.0W</td>
-</tr>
-
-<tr>
-<td>WWVB Ft. Collins, CO</td>
-<td>60 kHz</td>
-<td>40:40:28.3N 105:02:39.5W</td>
-</tr>
-
-<tr>
-<td>WWVH Kauai, HI</td>
-<td>2.5/5/10/15 MHz</td>
-<td>21:59:26.0N 159:46:00.0W</td>
-</tr>
-
-<tr>
-<td>CHU Ottawa, CA</td>
-<td>3330/7335/14670 kHz</td>
-<td>45:18N 75:45N</td>
-</tr>
-
-<tr>
-<td>DCF77 Mainflingen, DE</td>
-<td>77.5 kHz</td>
-<td>50:01N 9:00E</td>
-</tr>
-
-<tr>
-<td>MSF Rugby, UK</td>
-<td>60 kHz</td>
-<td>52:22N 1:11W</td>
-</tr>
-
-<tr>
-<td>TDF Allouis, FR</td>
-<td>162 kHz</td>
-<td>47:10N 2:12E</td>
-</tr>
-
-<tr>
-<td><a class="StationInfo" href="http://jjy.crl.go.jp/">JJY</a> ( Fukushima, JAPAN )</td>
-<td>40 KHz</td>
-<td>37:22 N 140:51 E</td>
-</tr>
-
-<tr>
-<td><a class="StationInfo" href="http://jjy.crl.go.jp/">JJY</a> ( Saga, JAPAN )</td>
-<td>60 KHz</td>
-<td>33:28 N 130:11 E</td>
-</tr>
-
-</table>
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
<body>
<h3>Quick Start</h3>
<img src="pic/panda.gif" alt="gif" align="left">FAX test image for SATNET (1979).
- <p>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 <a href="http://www.eecis.udel.edu/%7emills/database/papers/fuzz.ps">Fuzzball</a> . 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.<br clear="left">
- </p>
+ <p>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 <a href="http://www.eecis.udel.edu/%7emills/database/papers/fuzz.ps">Fuzzball</a> . 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.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:13</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<hr>
<p>For the rank amateur the sheer volume of the documentation collection must be intimidating. However, it doesn't take much to fly the <tt>ntpd</tt> 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 <a href="build.html">Building and Installing the Distribution</a> page describes how to do this.</p>
<p>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</p>
<body>
<h3>Debugging Hints for Reference Clock Drivers</h3>
- <img src="pic/oz2.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
- <p>Call the girls and the'll sweep your bugs.
- </p>
+ <img src="pic/oz2.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
+ <p>Call the girls and the'll sweep your bugs.</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:12</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
- <br clear="left">
- </p>
-
+ <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
<hr>
<p>The <a href="ntpq.html"><tt>ntpq</tt></a> and <a href="ntpdc.html"><tt>ntpdc</tt></a> 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 <a href="ntpd.html"><tt>ntpd</tt></a> page and its dependencies. If the clock appears in the <tt>ntpq</tt> utility and <tt>pe</tt> 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.</p>
<p>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 <tt>reach</tt> column in the <tt>pe</tt> 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.</p>
<body>
<h3>Reference Clock Drivers</h3>
- <img src="pic/stack1a.jpg" alt="gif" align="left">Master Time Facility at the <a href="http://www.eecis.udel.edu/%7emills/lab.html">UDel Internet Research Laboratory</a>
+ <img src="pic/stack1a.jpg" alt="gif" align="left">Master Time Facility at the <a href="http://www.eecis.udel.edu/~mills/lab.html">UDel Internet Research Laboratory</a>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:11</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+ <br clear="left">
<h4>Related Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
- <br clear="left">
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
<h4>Pulse-Per-Second Interfacing Links</h4>
<p>
<script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
<body>
<h3>NTP Version 4 Release Notes</h3>
- <img src="pic/hornraba.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>The rabbit toots to make sure you read this.<br clear="left">
+ <img src="pic/hornraba.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>The rabbit toots to make sure you read this
</p>
- <hr>
- <p>This document was last updated 3 September 2002</p>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:07</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
+.<br clear="left"> <hr>
<h4>NTP Version 4 Release Notes</h4>
<p>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.</p>
<p>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 <a href="mailto:bugs@ntp.org"><bugs@ntp.org>></a>.</p>
--- /dev/null
+document.write("\\r
+<table><tr>\\r
+<td width='50%' ><img src='icons/home.gif' align='middle' alt='gif'>\\r
+<a href='index.html'>Home Page</a></td>\\r
+<td width='50%' ><img src='icons/mail2.gif' align='middle' alt='gif'>\\r
+<a href='http://www.eecis.udel.edu/~mills/spam.html'>\\r
+<i>David L. Mills <mills@udel.edu></a></i></td>\\r
+</tr></table>")
\ No newline at end of file
--- /dev/null
+document.write("<div class='footer'><a href='index.html'><img src='pic/alautun4b.gif' alt='gif' align='right'><h2>Network Time Protocol Version 4</h2></a></div>")
\ No newline at end of file
--- /dev/null
+document.write("<ul>\\r
+<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\\r
+<li class='inline'><a href='prefer.html'>Mitigation Rules and the <tt>prefer</tt> Keyword</a><br>\\r
+<li class='inline'><a href='howto.html'>How to Write a Reference Clock Driver</a><br>\\r
+<li class='inline'><a href='rdebug.html'>Debugging Hints for Reference Clock Drivers</a><br>\\r
+</ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul>\\r
+<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\\r
+<li class='inline'><a href='pps.html'>Pulse-per-second (PPS) Signal Interfacing</a><br>\\r
+<li class='inline'><a href='ldisc.html'>Line Disciplines and Streams Modules</a><br>\\r
+</ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul>\\r
+<li class='inline'><a href='confopt.html'>Server Options</a><br>\\r
+<li class='inline'><a href='authopt.html'>Authentication Options</a><br>\\r
+<li class='inline'><a href='monopt.html'>Monitoring Options</a><br>\\r
+</ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul>\\r
+<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\\r
+<li class='inline'><a href='driver7.html'>Radio CHU Audio Demodulator/Decoder</a><br>\\r
+<li class='inline'><a href='driver36.html'>Radio WWV/H Audio Demodulator/Decoder</a><br>\\r
+<li class='inline'><a href='driver6.html'>IRIG Audio Decoder</a>\\r
+</ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul>\\r
+<li class='inline'><a href='authopt.html'>Authentication Options</a><br>\\r
+<li class='inline'><a href='manyopt.html'>Automatic NTP Configuration Options</a><br>\\r
+<li class='inline'><a href='confopt.html'>Server Options</a><br>\\r
+<li class='inline'><a href='genkeys.html'><tt>ntp-keygen</tt> - generate public and private keys</a>\\r
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autokey.html'>Autonomous Authentication</a>\\r
+</ul>")
\ No newline at end of file
--- /dev/null
+body {background: #FDF1E1;\r
+ color: #006600;\r
+ font-family: "verdana ref","lucida bright",sans-serif;\r
+ text-align: justify;\r
+ margin-left: 5px;}\r
+\r
+p, h4, hr, li {margin-top: .6em; margin-bottom: .6em}\r
+li.inline {text-align: left; margin-top: 0; margin-bottom: 0}\r
+\r
+ul, dl, ol, {margin-top: .6em; margin-bottom: .6em; margin-left 5em}\r
+\r
+dt {margin-top: .6em}\r
+dd {margin-bottom: .6em}\r
+\r
+div.header {text-align: center;\r
+ font-style: italic;}\r
+\r
+div.footer {text-align: center; \r
+ font-size: 60%;}\r
+\r
+img.cell {align: left;}\r
+\r
+td.sidebar {width: 40px; align: center; valign: top;}\r
+img.sidebar {align: center; margin-top: 5px;}\r
+h4.sidebar {align: center;}\r
+\r
+p.top {background: #FDF1E1;\r
+ color: #006600;\r
+ position: absolute;\r
+ margin-left: -90px;\r
+ text-align: center;}\r
+\r
+a:link.sidebar {background: transparent;\r
+ color: #990033;\r
+ font-weight: bold;}\r
+\r
+a:visited.sidebar {background: transparent;\r
+ color: #990033;\r
+ font-weight: bold;}\r
+\r
+a:hover.sidebar {background: #FDF1E1;\r
+ color: #006600;}\r
+\r
+img {margin: 5px;}\r
+\r
+div {text-align: center;}\r
+\r
+h1 {text-align: center;\r
+ font-size: 250%;}\r
+\r
+caption {background: #EEEEEE;\r
+ color: #339999;}\r
+ \r
+tx {text-align: center;}\r
+\r
+th {background: #FFFFCC;\r
+ color: #006600;\r
+ text-align: center;\r
+ text-decoration: underline;\r
+ padding-top: 5px;}\r
+\r
+th.caption {background: #EEEEEE;\r
+ color: #006600;\r
+ text-align: center;}
\ No newline at end of file
<body>
<h3>Simple Network Time Protocol (SNTP) Client</h3>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:10</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
<hr>
<h4>Synopsis</h4>
<tt>sntp [{-h --help -?}][{ -v -V -W }][{-r -a}][-P <i>prompt</i>][-e <i>minerr</i>][-E <i>maxerr</i>][-c <i>count</i>][-d <i>delay</i>][address(es)]</tt>
<body>
<h3><tt>tickadj</tt> - set time-related kernel variables</h3>
+ <p>Last update: <csobj format="ShortTime" h="24" locale="00000409" region="0" t="DateTime" w="50">20:11</csobj> UTC <csobj format="LongDate" h="24" locale="00000409" region="0" t="DateTime" w="257">Monday, December 02, 2002</csobj></p>
<hr>
<h4>Synopsis</h4>
<tt>tickadj [ -Aqs ] [ -a <i>tickadj</i> ] [ -t <i>tick</i> ]</tt>
projects / thirdparty / ntp.git / commitdiff
