+* Documentation cleanup from Dave Mills.
* [Bug 918] Only use a native md5.h if MD5Init() is available.
* [Bug 979] Provide ntptimeval if it is not otherwise present.
* [Bug 634] Re-instantiate syslog() and logfiles after the daemon fork.
<h3>Access Control Options</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">18:35</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">15:56</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#acx">Access Control Support</a>
</ul>
<hr>
<h4 id="acx">Access Control Support</h4>
- The<tt> ntpd</tt> daemon implements a general purpose address/mask based restriction list. The list contains address/match entries sorted first by increasing address values and and then by increasing mask values. A match occurs when the bitwise AND of the mask and the packet source address is equal to the bitwise AND of the mask and address in the list. The list is searched in order with the last match found defining the restriction flags associated with the entry. Additional information and examples can be found in the <a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a> page.
+ The<tt> ntpd</tt> daemon implements a general purpose address/mask based restriction list. The list contains address/match entries sorted first by increasing address values and and then by increasing mask values. A match occurs when the bitwise AND of the mask and the packet source address is equal to the bitwise AND of the mask and address in the list. The list is searched in order with the last match found defining the restriction flags associated with the entry.
<p>The restriction facility was implemented in conformance with the access policies for the original NSFnet backbone time servers. Later the facility was expanded to deflect cryptographic and clogging attacks. While this facility may be useful for keeping unwanted or broken or malicious clients from congesting innocent servers, it should not be considered an alternative to the NTP authentication facilities. Source address based restrictions are easily circumvented by a determined cracker.</p>
<p>Clients can be denied service because they are explicitly included in the restrict list created by the <tt>restrict</tt> command or implicitly as the result of cryptographic or rate limit violations. Cryptographic violations include certificate or identity verification failure; rate limit violations generally result from defective NTP implementations that send packets at abusive rates. Some violations cause denied service only for the offending packet, others cause denied service for a timed period and others cause the denied service for an indefinate period. When a client or network is denied access for an indefinate period, the only way at present to remove the restrictions is by restarting the server.</p>
<h4 id="kiss">The Kiss-of-Death Packet</h4>
<h3>Association Management</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">20:56</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="309">Thursday, November 22, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:56</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="277">Friday, December 28, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#modes">Association Modes</a>
</ul>
<hr>
<h4 id="modes">Association Modes</h4>
- <p>This page describes the various modes of operation provided in NTPv4.
Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the automatic server discovery schemes are described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.</p>
- <p>There are three types of associations in NTP: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>prempt</tt> option and are demobilized by timeout or error or when displaced by a "better" server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.</p>
+ <p>This page describes the various modes of operation provided in NTPv4.
Details about the configuration commands and options are given on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are given on the <a href="authopt.html">Authentication Options</a> page. Details about the automatic server discovery schemes are described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.</p>
+ <p>There are three types of associations in NTP: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>prempt</tt> option and are demobilized by a "better" server or by timeout, but only if the number of survivors exceeds the threshold set by the <tt>tos maxclock</tt> configuration command. Ephemeral associations are mobilized upon arrival of designated messages and demobilized by timeout.</p>
<p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described in the <a href="authopt.html">Authentication Options</a> page.</p>
<p>There are three principal modes of operation in NTP: client/server, symmetric active/passive and broadcast/multicast. There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and pool described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. In addition, the orphan mode and burst options described on this page can be used in appropriate cases.</p>
<p>Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
<h4 id="client">Client/Server Mode</h4>
<p>Client/server mode is the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers and stateful clients. In this mode a host sends a client (mode 3) request to the specified server and expects a server (mode 4) reply at some future time. In some contexts this would be described as a "pull" operation, in that the host pulls the time and related values from the server.</p>
- <p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for use by clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
+ <p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
<p>Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The <tt>minpoll</tt> and <tt>maxpoll</tt> options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.</p>
<h4 id="symact">Symmetric Active/Passive Mode</h4>
<p>Symmetric active/passive mode is intended for configurations were a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a radio clock, or a set of secondary (stratu, 2) servers known to be reliable and authentic. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and related values can flow from the surviving peers to all hosts in the subnet. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.</p>
- <p>A peer with a configured symmetric active association sends a symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.</p>
+ <p>In symmetric active mode a peer symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.</p>
<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or IPv4 or IPv6 address. The <tt>burst</tt> and <tt>iburst</tt> options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.</p>
<p>As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the <tt>minpoll</tt> and <tt>maxpoll</tt> options.</p>
<h4 id="broad">Broadcast/Multicast Modes</h4>
<p>NTP broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode can be used with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast packets do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
<h4 id="many">Manycast Mode</h4>
- <p>Manycast mode 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>Manycast mode 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
ephemeral 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>
<h4 id="orphan">Orphan Mode</h4>
<p>Sometimes an NTP subnet becomes isolated from all UTC sources such as local reference clocks or Internet time servers. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC timescale. Previously, this function was provided by the local clock driver to simulate a UTC source. A server with this driver could be used to synchronize other hosts in the subnet directly or indirectly.</p>
<p>There are many disadvantages using the local clock driver, primarily that the subnet is vulnerable to single-point failures and multiple server redundancy is not possible. Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC source with multiple servers and provides seamless switching as servers fail and recover.</p>
<p>For broadcast networks each core server is configured in both broadcast server and broadcast client modes as shown above. Orphan children operate as broadcast clients of all core servers. As in peer networks, the core servers back up each other and only they and the orphan children need to be enabled for orphan mode.</p>
<p>In normal operation subnet hosts operate below stratum 5, so the subnet is automatically configured as described in the NTP specification. If all UTC sources are lost, all core servers become orphans and the orphan children will select the same root server to become the orphan parent.</p>
<h4 id="burst">Burst Options</h4>
- <p>There are two burst options where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal one packet. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands and not with reference clock drivers. The <tt>burst</tt> option sends a burst when the server is reachable, while the <tt>iburst</tt> option sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. In either mode the client sends one packet, waits for the reply, then sends the remaining packets in the burst. This may be useful to allow a modem to complete a call.</p>
+ <p>There are two burst options where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal one packet. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands, but not with reference clock drivers nor symmetric peers. The <tt>burst</tt> option sends a burst when the server is reachable, while the <tt>iburst</tt> option sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. In either mode the client sends one packet, waits for the reply, then sends the remaining packets in the burst. This may be useful to allow a modem to complete a call.</p>
<p>In both modes 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 adjusts the system clock as if only a single packet exchange had occurred.</p>
<p>The <tt>iburst</tt> option is useful where the system clock must be set quickly or when the network attachment requires an initial calling or training sequence. The burst is initiated only when the server first becomes reachable. This improves accuracy with intermittent connections typical of PPP and ISDN services. Outliers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first received packet.</p>
- <p>The <tt>burst</tt> option can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training sequence. The burst is initiated at each poll interval when the server is reachable. The number of packets in the burst is determined by the poll interval so that the average interval between packets is no less than 16.. At a poll interval of 16 s, only one packet is sent in the burst; at 32 s, two packets are sent and so forth until at 128 s and above eight packets are sent. =</p>
+ <p>The <tt>burst</tt> option can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training sequence. The burst is initiated at each poll interval when the server is reachable. The number of packets in the burst is determined by the poll interval so that the average interval between packets is no less than 16.. At a poll interval of 16 s, only one packet is sent in the burst; at 32 s, two packets are sent and so forth until at 128 s and above eight packets are sent.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>Reference Clock Audio Drivers</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">19:40</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="223">Friday, April 13, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">00:48</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links8.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#sound">Sound Card Drivers</a>
<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>
<p>Our resident cryptographer; now you see him, now you don't.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:21</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="306">Tuesday, September 25, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">15:56</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#auth">Authentication Support</a>
<li class="inline"><a href="#symm">Symmetric Key Cryptography</a>
<li class="inline"><a href="#pub">Public Key Cryptography</a>
<li class="inline"><a href="#group">NTP Secure Groups</a>
- <li class="inline"><a href="#name">Naming Conventions</a>
+ <li class="inline"><a href="#ident">Identity Schemes and Cryptotypes</a>
<li class="inline"><a href="#cfg">Configuration</a>
- <li class="inline"><a href="#inter">Operation</a>
<li class="inline"><a href="#exam">Examples</a>
<li class="inline"><a href="#cmd">Authentication Commands</a>
<li class="inline"><a href="#err">Error Codes</a>
</ul>
<hr>
<h4 id="auth">Authentication Support</h4>
- <p>Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. The NTPv3 specification RFC-1305 defines a scheme which provides cryptographic authentication of received NTP packets. Originally, this was done using the Data Encryption Standard (DES) algorithm operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was replaced by the RSA Message Digest 5 (MD5) algorithm using a private key, commonly called keyed-MD5. Either algorithm computes a message digest, or one-way hash, which can be used to verify the server has the correct private key and key identifier.</p>
- <p>NTPv4 retains the NTPv3 scheme, properly described as symmetric key cryptography and, in addition, provides a new Autokey scheme based on public key cryptography. Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. With the exception of the group keys described later, all key distribution and management functions involve only public values, which considerably simplifies key distribution and storage. Public key management is based on X.509 certificates, which can be provided by commercial services or produced by utility programs in the OpenSSL software library or the <a href="keygen.html"><tt>ntp-keygen</tt></a> program in the NTP distribution.</p>
- <p>While the algorithms for symmetric key cryptography are included in the NTPv4 distribution, public key cryptography requires the OpenSSL software library to be installed before building the NTP distribution. 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/build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the library routines required.</p>
- <p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> subcommand on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> configuration commands as described in the <a href="confopt.html">Configuration Options</a> page. The authentication options described below specify the locations of the key files, which symmetric keys are trusted and other details needed by the optional Autokey protocol. The <a href="keygen.html">ntp-keygen</a> program is used to generate the various key files, certificate files and identity files described below.</p>
- <p>Authentication is always enabled, although ineffective if not configured as described below. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and the message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key. Furthermore, the Autokey scheme requires a preliminary protocol exchange to obtain the server certificate, verify its credentials and initialize the protocol.</p>
- <p>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running on another machine. If this flag is enabled, which is the default, new broadcast/manycast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric key or public key cryptography. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating with the <tt>auth</tt> flag disabled invites a significant vulnerability where a rogue hacker can masquerade as a legitimate server and seriously disrupt system timekeeping. It is important to note that this flag has no purpose other than to allow or disallow a new association in response to new broadcast and symmetric active messages and remote configuration commands and, in particular, the flag has no effect on the authentication process itself.</p>
- <p>The security model and protocol schemes for both symmetric key and public key cryptography are summarized below; further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
- <h4 id="symm">Symmetric Key Cryptography</h4>The original RFC-1305 specification allows any one of possibly 65,534 keys (excluding zero), 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 means 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. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed by hand.<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>trustedkey</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>
+ <p>Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. The NTPv3 specification RFC-1305 defines a scheme using the Data Encryption Standard (DES) algorithm, commonly called DES-CBC. Subsequently, this scheme was replaced by the RSA Message Digest 5 (MD5) algorithm, commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same key as the server.</p>
+ <p>NTPv4 includes the NTPv3 scheme, properly described as symmetric key cryptography and, in addition a new scheme based on public key cryptography and called Autokey. Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library or a utility program in the NTP software distribution.</p>
+ <p>While the algorithms for symmetric key cryptography are included in the NTPv4 software distribution, Autokey cryptography requires the OpenSSL software library to be installed before building the NTP distribution. 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 library routines required.</p>
+ <p>Authentication is configured separately for each association separately using the <tt>key</tt> or <tt>autokey</tt> option on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> or <tt>manycastclient</tt> configuration commands, as described in the <a href="confopt.html">Server Options</a> page, and the options described on this page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
+ <h4 id="symm">Symmetric Key Cryptography</h4>
+ The original RFC-1305 specification allows any one of possibly 65,534 keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key and key ID to authenticate NTP packets. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key.
+ <p>Keys and related information are specified in a keys file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure means 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. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed using an ordinary text editor.</p>
+ <p>When <tt>ntpd</tt> is first started, it reads the key file specified by the <tt>keys</tt> configuration command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
<h4 id="pub">Public Key Cryptography</h4>
- <p>NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/
%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page are based on cryptographic challenge/response exchanges. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks. 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/%7emills/autokey.html">Autonomous Authentication</a> page.</p>
+ <p>NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/
~mills/proto.html">Autokey Protocol</a> page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. Using these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks. 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/%7emills/autokey.html">Autonomous Authentication</a> page.</p>
<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers are operated outside firewall perimeters.</p>
- <p>The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links generated by the <a href="keygen.html"><tt>ntp-keygen</tt></a> program. These define the required host key, required host certificate and optional sign key and identity keys. The certificate defines the Autokey host name and the selected cryptographic algorithms.</p>
<h4 id="group">NTP Secure Groups</h4>
- <p>NTP secure groups are used to define cryptographic compartments and security hierarchies. All hosts belonging to a named secure group share a secret group key which can be encrypted with individual passwords. Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The other hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts, to one or more trusted hosts.</p>
- <p>When a host starts up, it recursively retrieves the certificates along the trail in order to verify group membership and avoid masquerade and middleman attacks. The trail concludes with the trusted certificate of a TH. The subject name on the trusted certificate defines the group name and name of the identity file used to confirm group membership.</p>
- <p>Secure groups can be configured as hierarchies where the THs of one group can be clients of one or more other groups operating at a lower stratum. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. The THs for each group have encrypted identity keys for that group as well as nonencrypted identity parameters for each of the lower stratum groups. The parameters can be obtained from the trusted agent (TA), usually one of the THs of the lower stratum group. There are many other scenarios, but all must be configured to include only acyclic certificate trails.</p>
- <p>In the IFF and GQ identity schemes the TA generates an encrypted keys file including private keys and public parameters needed to verify identity to a dependent client. The parameters file is a copy of this file with the private keys obscured. A client without the private keys can confirm identity with respect to a server but cannot prove identity to a dependent client.</p>
- <h4 id="name">Naming Conventions</h4>
- <p>It is important to note that Autokey does not use DNS to resolve names or addresses, since DNS can't be completely trusted until the name servers have synchronized clocks. The Autokey names for hosts and groups are used only to verify group membership and create group hierarchies.</p>
- <p>All THs share the same host name, which is also the group name. The host and group name is specified by the <tt>host</tt> and <tt>ident</tt> subcommands, respectively, of the <tt>crypto</tt> configuration command. All other hosts in the group have the same group name, but different host names. If the host name is not specified, the default host name is the string returned by the Unix <tt>gethostname()</tt> system call. If the group name is not specified, it defaults to the host name, in which case the group is nameless and, while certificate trails are used, identity schemes are not.</p>
- <p>File and link names are in the form <tt>ntpkey_<i>key</i>_<i>name</i>.<i>fstamp</i></tt>, where <tt><i>key</i></tt> is the key or parameter type, <tt><i>name</i></tt> is the host or group name and <tt><i>fstamp</i></tt> is the filestamp (NTP seconds) when the file was created). By convention, key fields in generated file names include both upper and lower case alphanumeric characters, while key fields in generated link names include only lower case characters. The filestamp is not used in generated link names.</p>
- <p>The key type is a string defining the cryptographic function. Key types include public/private keys <tt>host </tt>and <tt>sign</tt>, certificate <tt>cert</tt> and several challenge/response key types. By convention, files used for challenges have a <tt>par</tt> subtype, as in the IFF challenge <tt>IFFpar</tt>, while files for responses have a <tt>key</tt> subtype, as in the GQ response <tt>GQkey</tt>.</p>
+ <p>NTP secure groups are used to define cryptographic compartments and security hierarchies. All hosts belonging to a secure group have the same group name but different host names. The string specified in the <tt>host</tt> option of the <tt>crypto</tt> command is the name of the host and in the name of the host key, sign key and certificate files. The string specified in the <tt>ident</tt> option of the <tt>crypto</tt> comand is the group name of all group hosts and in the name of the identity files. The file naming conventions are described on the <a href="keygen.html">ntp-keygen</a> page.</p>
+ <p>Each group includes one or more trusted hosts (THs) operating at the root, or lowest stratum in the group. The group name is used in the subject and issuer fields of the TH trusted certificate. The host name is used in these fields for hosts other than THs.</p>
+ <p>All group hosts are configured to provide an unbroken path, called a certificate trail, from each host, possibly via intermediate hosts and ending at a TH. When a host starts up, it recursively retrieves the certificates along the trail in order to verify group membership and avoid masquerade and middleman attacks.</p>
+ <p>Secure groups can be configured as hierarchies where a TH of one group can be a client of one or more other groups operating at a lower stratum. In one scenario, groups RED and GREEN can be cryptographically distinct, but both be clients of group BLUE operating at a lower stratum. In another scenario, group CYAN can be a client of multiple groups YELLOW and MAGENTA, both operating at a lower stratum. There are many other scenarios, but all must be configured to include only acyclic certificate trails.</p>
+ <h4 id="ident">Identity Schemes and Cryptotypes</h4>
+ <p>All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page.</p>
+ <p>A specific combination of authentication and identity schemes is called a cryptotype, which applies to clients and servers separately. A group can be configured using more than one cryptotype combination, although not all combinations are interoperable. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice. The server and client cryptotypes are defined by the the following codes.</p>
+ <dl>
+ <dt>NONE
+ <dd>A client or server is type NONE if authentication is not available or not configured. Packets exchanged between client and server have no MAC.
+ <dt>AUTH
+ <dd>A client or server is type AUTH if the <tt>key</tt> option is specified with the <tt>server</tt> configuration command and the client and server keys are compatible. Packets exchanged between clients and servers have a MAC.<dt>PC
+ <dd>A client or server is type PC if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key and private certificate files are present. Packets exchanged between clients and servers have a MAC.<dt>TC
+ <dd>A client or server is type TC if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key and public certificate files are present. Packets exchanged between clients and servers have a MAC.<dt>IDENT
+ <dd>A client or server is type IDENT if the <tt>autokey</tt> option is specified with the <tt>server</tt> configuration command and compatible host key, public certificate and identity scheme files are present. Packets exchanged between clients and servers have a MAC.</dl>
+ <p>The compatible cryptotypes for clients and servers are listed in the following table.</p>
+ <table width="100%" border="1" cellpadding="4">
+ <tr>
+ <td rowspan="2" align="center">Client</td>
+ <td colspan="5" align="center">Server</td>
+ </tr>
+ <tr>
+ <td align="center">NONE</td>
+ <td align="center">AUTH</td>
+ <td align="center">PC</td>
+ <td align="center">TC</td>
+ <td align="center">IDENT</td>
+ </tr>
+ <tr>
+ <td align="center">NONE</td>
+ <td align="center">yes</td>
+ <td align="center">yes*</td>
+ <td align="center">yes*</td>
+ <td align="center">yes*</td>
+ <td align="center">yes*</td>
+ </tr>
+ <tr>
+ <td align="center">AUTH</td>
+ <td align="center">no</td>
+ <td align="center">yes</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ </tr>
+ <tr>
+ <td align="center">PC</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">yes</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ </tr>
+ <tr>
+ <td align="center">TC</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">yes</td>
+ <td align="center">yes</td>
+ </tr>
+ <tr>
+ <td align="center">IDENT</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">no</td>
+ <td align="center">yes</td>
+ </tr>
+ </table>
+ <p>* These combinations are not valid if the restriction list includes the <tt>notrust</tt> option.</p>
<h4 id="cfg">Configuration</h4>
- <p>Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. The simplest scenario consists of a secure group with one or more THs at the same low stratum. On behalf of the group a designated TH operating as a trusted agent (TA) generates private host keys, a trusted, self-signed public certificate and private identity keys. These media are copied intact to all THs, most conveniently using a tar archive. This insures all certificate trails end with the same credentials.</p>
- <p>All other hosts generate private host keys and a nontrusted, self-signed public certificate. In the intended model, a host sends a mail message to the TA, provides password and out-of-band credentials, and requests the group identity media. For those hosts acting as severs with dependent clients, identity keys encrypted with the password are provided; for those hosts without dependent clients, only an unencrypted subset, called the identity parameters, are provided. Hosts with only the parameters can confirm identity with servers but cannot prove identity to dependent clients. Received files are installed in the keys directory named as the first line in the file, but all in lower case and without the filestamp field.</p>
- <p>All hosts in the group specify the group name by the <tt>ident</tt> subcommand of the <tt>crypto</tt> configuration command. Trusted hosts in addition specify the same host name in the <tt>host</tt> subcommand. Optionally, nontrusted hosts can specify other host names, but all must be distinct.</p>
- <h4>Operation</h4>
- <p>A specific combination of authentication scheme (none, symmetric key, public key) and identity scheme is called a cryptotype, although not all combinations are compatible. There may be management configurations where the clients, servers and peers may not all support the same cryptotypes. A secure NTPv4 subnet can be configured in many ways while keeping in mind the principles explained above and in this section. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice.</p>
- <p>The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when an NTP packet of appropriate cryptotype arrives. When mobilized by a <tt>server</tt> or <tt>peer</tt> configuration command and no <tt>key</tt> or <tt>autokey</tt> subcommands are present, the association is not authenticated. If the <tt>key</tt> subcommand is present, the association is authenticated using the symmetric key ID specified. If the <tt>autokey</tt> subcommand is present, the association is authenticated using Autokey.</p>
- <p>With Autokey, the cryptotype of the association is determined by the set of files generated by the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program. All configurations include a public/private host key pair and matching certificate. Absent identity parameters, this is a Trusted Certificate (TC) scheme. There are three identity schemes, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/%7emills/ident.html">Identity Schemes</a> page. Each is characterized by a set of private parameters that are distributed to each group host by secure means.</p>
- <p>A group can operate where the cryptotype can be different for each client. One client can elect to use no authentication at all, another with the TC scheme and others with IFF, GQ and/or MV. However, a host cannot prove identity to a dependent client unless it has the corresponding identity parameters.</p>
+ <p>Autokey has an intimidating number of configuration options, most of which are not necessary in typical scenarios. The simplest scenario consists of a secure group with one TH at the lowest stratum. For the simplest identity scheme TC, the TH generates host key and trusted certificate files using the <tt>ntp-keygen -T</tt> command, while the remaining group hosts use the same command with no options. All hosts use the <tt>crypto</tt> configuration command with no options. Configuration with passwords is described in the <a href="keygen.html">ntp-keygen</a> page</p>
+ <p>When an identity scheme is included, for example IFF, the TH generates host key, trusted certificate and private identity keys files using the <tt>ntp-keygen -T -I -i <i>group</i> </tt>command, where <tt><i>group</i></tt> is the group name. The remaining group hosts use the same command with no options. All hosts use the <tt>crypto ident <i>group</i></tt> configuration command.</p>
+ <p>Hosts with no dependent clients can retrieve public identity parameters from an archive or web page. The <tt>ntp-keygen</tt> can export these data using the <tt>-e</tt> option. Hosts with dependent clients other than the TH must retrieve copies of the TH private identity keys using secure means. The <tt>ntp-keygen</tt> can export these data using the <tt>-q</tt> option. In either case the data are installed as a file and then renamed using the name given as the first line in the file, but without the filestamp.</p>
<h4 id="exam">Examples</h4>
- <p>Consider a scenario involving three secure groups with names red, green and blue. Groups red and blue may be typical of national laboratories providing certified time. These groups run symmetric modes so each can monitor or backup the other should the ions grow dim. Group green may be typical of a large university providing time to the campus population. Green is dependent on both red and blue and, for the sake of this example, shares an Ethernet with red and blue. Blue uses the IFF scheme, while both red and green us the GQ scheme, but with different keys.</p>
- <p>Blue and red include the following commands in the configuration file</p>
- <p><tt>crypto pw <i>passwd</i> host <i>group</i> ident <i>group<br>
- </i></tt><tt>peer<i> IPaddr </i>autokey<i><br>
- </i></tt><tt>broadcast<i> IPbroadcastaddr </i>autokey</tt></p>
- <p>where <tt><i>passwd</i></tt> is the password for files encrypted by <tt>ntp-keygen</tt>, <tt><i>group</i></tt> is the group name and <tt><i>IPaddr</i></tt> is the DNS name or IP address of the peer. Blue generates cryptographic media using <tt>ntp-keygen</tt> and the commands</p>
- <p><tt>ntp-keygen -q <i>passwd</i> -s blue -T -I<br>
- ntp-keygen -q <i>passwd</i> -s blue -e >ntpkey_iffpar_blue<br>
- ntp-keygen -q <i>passwd</i> -s blue<i> -</i>q<i> host >ID</i>_iffkey_blue</tt></p>
- <p>The first line generates the host keys, trusted certificate and IFF keys files. The second generates the IFF parameters file, which can be saved in the same keys directory without name collision. This file is not encrypted and can be moved to a public place. The third line generates a copy of the IFF keys file encrypted with the password <tt><i>host</i></tt> supplied by the requesting host. Note the <tt><i>ID</i></tt> is chosen to avoid name collision should the file be saved in the same keys directory. Ordinarily the file contents are piped to a mail application which returns it to the requesting host. Red and green use a similar procedure, but substitute their group name and use <tt>-G</tt> in place of <tt>-I</tt>. </p>
- <p>To set up the network, the identity parameters file for blue is copied to both red and green, while the identity parameters file for red is copied to blue and green.</p>
- <p>Now consider host cyan whose server is green and host magenta whose server is cyan. These are not trusted hosts, so cyan generates cryptographic media using the first two commands above, but omitting the <tt>-G</tt> and <tt>-T </tt>options. However, since magenta is a client of cyan, cyan needs the identity keys file for green, which is generated by the third line in green's <tt>ntp-keygen</tt> script. While in principle the identity encrypted keys file includes the parameters, the unencrypted parameters file is maintained separately, cyan needs both files</p>
+ <p>Consider a scenario involving three secure groups RED, GREEN and BLUE. RED and BLUE are typical of national laboratories providing certified time to the Internet at large. TH mort of RED and TH macabre of BLUE run NTP symmetric mode with each other for monitoring or backup. GREEN is typical of a large university providing certified time to the campus community. TH howland of GREEN is a client of both RED and BLUE. BLUE uses the IFF scheme, while both RED and GREEN use the GQ scheme, but with different keys.</p>
+ <p>BLUE TH macabre uses configuration commands</p>
+ <p><tt>crypto pw qqsv ident blue<br>
+ peer mort autokey</tt></p>
+ <p>where <tt>qqsv</tt> is the password for macabre files. It generates BLUE files using the commands</p>
+ <p><tt>ntp-keygen -p qqsv -T -G -i blue<br>
+ ntp-keygen -p qqsv -e >ntpkey_gqpar_blue</tt></p>
+ <p>The first line generates the host, trusted certificate and private GQ server files. The second generates the public GQ client file, which can have any nonconflicting mnemonic name.</p>
+ <p>RED TH mort uses configuration commands</p>
+ <p><tt>crypto pw xxx ident red<br>
+ peer macabre autokey</tt></p>
+ <p>where <tt>xxx</tt> is the password for mort files. It generates RED files using the commands</p>
+ <p><tt>ntp-keygen -p xxx -T -I -i red<br>
+ ntp-keygen -p xxx -e >ntpkey_iffpar_red</tt></p>
+ <p>GREEN TH howland uses configuration commands</p>
+ <p><tt>crypto pw yyy ident green<br>
+ </tt><tt>server mort autokey<br>
+ </tt><tt>server macabre autokey</tt></p>
+ <p>where <tt>yyy</tt> is the password for mort files. It generates GREEN files using the commands</p>
+ <p><tt>ntp-keygen -p yyy -T -G -i green<br>
+ ntp-keygen -p yyy -e >ntpkey_gqpar_green<br>
+ </tt><tt>ntp-keygen -p yyy -v zzz >zzz_ntpkey_gqkey_green</tt></p>
+ <p>The first two lines serve the same purpose as the preceeding examples. The third line generats a copy of the private GREEN server file for use on another server in the same group, but encrypted with the <tt>zzz</tt> pasword.</p>
+ <p>Each TH in a group acting as a client of another group retrieves the public client file for that group from a public archive or web page using nonsecure means. In addition, each server in a group retrieves the private server file from the TH of that group, but it is encrypted and so can be sent using nonsecured means. The files are installed in the keys directory with name taken from the first line in the file, but without the filestamp</p>
<h4 id="cmd">Authentication Commands</h4>
<dl>
<dt><tt>autokey [<i>logsec</i>]</tt>
<dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol. Note that the size of the key list for each association depends on this interval and the current poll interval. The default value is 12 (4096 s or about 1.1 hours). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.
<dt><tt>controlkey <i>key</i></tt>
- <dd>Specifies the key identifier to use with the <a href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the standard protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
- <dt><tt>crypto [randfile <i>file</i>] [host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>]</tt>
- <dd>This command requires the OpenSSL library. It activates public key cryptography and loads the required public/private encryption and sign kyes and public certificat. If one or more files are left unspecified, the default names are used as described below. Unless the complete path and name of the file are specified, the location of a file is relative to the keys directory specified in the <tt>keysdir</tt> command or default <tt>/usr/local/etc</tt>. Following are the subcommands.<dl>
+ <dd>Specifies the key ID to use with the <a href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the standard protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the key ID for a trusted key, where the value can be in the range 1 to 65,534, inclusive.<dt><tt>crypto [randfile <i>file</i>] [host <i>name</i>] [ident <i>name</i>] [pw <i>password</i>]</tt>
+ <dd>This command requires the OpenSSL library. It activates public key cryptography and loads the required host key and public certificat. If one or more files are left unspecified, the default names are used as described below. Unless the complete path and name of the file are specified, the location of a file is relative to the keys directory specified in the <tt>keysdir</tt> configuration command or default <tt>/usr/local/etc</tt>. Following are the options.
+ <dl>
<dt><tt>host <i>name</i></tt>
- <dd>Specifies the host name used in the host key link <tt>ntpkey_host_<i>name</i></tt>, sign key link <tt>ntpkey_sign_<i>name</i></tt> and certificate link <tt>ntpkey_cert_<i>name</i></tt>. The <tt>ntp-keygen</tt> program automatically installs these links to the most recently generated files.<dt><tt>ident <i>name</i></tt>
- <dd>Specifies the group name used in the identity key link <tt>ntpkey_<i>key</i>_<i>name</i></tt>, where <tt><i>key</i></tt> identifies the key type described on the <tt>ntp-keygen</tt> page. The <tt>ntp-keygen</tt> program automatically installs these links to the most recently generated files.<dt><tt>pw <i>password</i></tt>
- <dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program.<dt><tt>randfile <i>file</i></tt>
+ <dd>Specifies the string used when constructing the names for the host, sign and certificate files generated by the <tt>ntp-keygen</tt> program with the <tt>-s <i>name</i></tt> option.
+ <dt><tt>ident <i>name</i></tt>
+ <dd>Specifies the string used in constructing the identity files generated by the <tt>ntp-keygen </tt>program with the <tt>-i <i>name</i></tt> option.<dt><tt>pw <i>password</i></tt>
+ <dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program with the <tt>-p</tt> option.
+ <dt><tt>randfile <i>file</i></tt>
<dd>Specifies the location of the random seed file used by the OpenSSL library. The defaults are described on the <a href="keygen.html"><tt>ntp-keygen</tt></a> page.
</dl>
<dt><tt>keys <i>keyfile</i></tt>
- <dd>Specifies the complete path to the MD5 key file containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option.
+ <dd>Specifies the complete path to the MD5 key file containing the keys and key IDs used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating with symmetric key cryptography. This is the same operation as the <tt>-k </tt>command line option.
<dt><tt>keysdir <i>path</i></tt>
<dd>This command specifies the default directory path for cryptographic keys, parameters and certificates. The default is <tt>/usr/local/etc/</tt>.
<dt><tt>requestkey <i>key</i></tt>
- <dd>Specifies the key identifier to use with the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which uses a proprietary protocol specific to this implementation of <tt>ntpd</tt>. The <tt><i>key</i></tt> argument is a key identifier for the trusted key, where the value can be in the range 1 to 65,534, inclusive.
- <dt><tt>revoke [<i>logsec</i>]</tt>
+ <dd>Specifies the key ID to use with the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program, which uses a proprietary protocol specific to this implementation of <tt>ntpd</tt>. The <tt><i>key</i></tt> argument is a key ID for the trusted key, where the value can be in the range 1 to 65,534, inclusive.<dt><tt>revoke [<i>logsec</i>]</tt>
<dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. These values need to be updated frequently in order to deflect brute-force attacks on the algorithms; however, updating some values is a relatively expensive operation. The default interval is 16 (65,536 s or about 18 hours). For poll intervals above the specified interval, the values will be updated for every message sent.<dt><tt>trustedkey <i>key</i> [...]</tt>
- <dd>Specifies the key identifiers which are trusted for the purposes of authenticating peers with symmetric key cryptography, as well as keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. The authentication procedures require that both the local and remote servers share the same key and key identifier for this purpose, although different keys can be used with different servers. The <tt><i>key</i></tt> arguments are 32-bit unsigned integers with values from 1 to 65,534.
- </dl>
+ <dd>Specifies the key ID which are trusted for the purposes of authenticating peers with symmetric key cryptography, as well as keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. The authentication procedures require that both the local and remote servers share the same key and key ID for this purpose, although different keys can be used with different servers.</dl>
<h4 id="err">Error Codes</h4>
<p>Errors can occur due to mismatched configurations, unexpected restarts, expired certificates and unfriendly people. In most cases the protocol state machine recovers automatically by retransmission, timeout and restart, where necessary. Some errors are due to mismatched keys, digest schemes or identity schemes and must be corrected by installing the correct media and/or correcting the configuration file. One of the most common errors is expired certificates, which must be regenerated and signed at least once per year using the <tt><a href="keygen.html">ntp-keygen</a></tt> program.</p>
<p>The following error codes are reported via the NTP control and monitoring protocol trap mechanism.</p>
<dd>The leapseconds table is missing, corrupted or bogus.
<dt>113 (bad or missing certificate)
<dd>The certificate is missing, corrupted or bogus.
- <dt>114 (bad or missing group key)<dd>The identity key is missing, corrupt or bogus.
-
+ <dt>114 (bad or missing group key)
+ <dd>The identity key is missing, corrupt or bogus.
<dt>115 (protocol error)
<dd>The protocol state machine has wedged due to unexpected restart
<dt>116 (server certificate expired)
<dd>The old server certificate has expired.
</dl>
<h4 id="file">Files</h4>
- <p>See the <a href="keygen.html"><tt>ntp-keygen</tt></a> page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.</p>
+ <p>See the <a href="keygen.html"><tt>ntp-keygen</tt></a> page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>NTP Version 4 Bug Reporting Procedures</title>
+ <title>NTP Bug Reporting Procedures</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
- <h3>NTP Version 4 Bug Reporting Procedure</h3>
+ <h3>NTP Bug Reporting Procedures</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</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">13:20</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="307">Wednesday, October 31, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:36</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="292">Monday, December 31, 2007</csobj></p>
.<br clear="left">
<hr>
- <h4>NTP Version 4 Security Bug Reporting Procedure</h4>
- <p>Please do not contact developers directly.</p>
- <p>IF YOU THINK YOU HAVE FOUND A SECURITY RELATED NTP BUG please send your report to <a href="mailto:security@ntp.org">security@ntp.org</a>.</p>
- <h4>Reporting non-Security Bugs</h4>
- <p>THE BEST WAY TO REPORT NON-SECURITY RELATED NTP BUGS is to use the NTP Public Service Project Bug Tracking System (Bugzilla) located at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a>. Bugs reported this way are immediately forwarded to the developers.</p>
- <p>IF YOU WISH TO REPORT NON-SECURITY RELATED BUGS VIA E-MAIL you may do so. But please remember that your report will be held until one of our volunteers enters it in to our Bug Tracking System. The email address for these reports is <a href="mailto:bugs@ntp.org">bugs@ntp.org</a>. You will need to register at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a> so that you may participate directly in any e-mail discussion regarding your report.</p>
- <p>Please do not contact developers directly.</p>
+ <h4> Security Bug Reporting Procedures</h4>
+ <p>IF YOU THINK YOU HAVE FOUND A SECURITY RELATED NTP BUG please send your report to <a href="mailto:security@ntp.org">security@ntp.org</a>. Please do not contact developers directly.</p>
+ <h4> Non-Security Bug Reporting Proceduress</h4>
+ <p>The best way to report a non-security bug is to use the NTP Public Service Project Bug Tracking System (Bugzilla) located at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a>. Bugs reported this way are immediately forwarded to the developers. Please do not contact the developers directly.</p>
+ <p>If you wish to report a non-security bug via electronic mail, you may do so, but please remember that your report will be held until one of our volunteers enters it in Bugzilla. The email address for these reports is <a href="mailto:bugs@ntp.org">bugs@ntp.org</a>. You will need to register at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a> so that you may participate directly in any e-mail discussion regarding your report.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=windows-1252">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Building and Installing the Distribution</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <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>
+ <p>For putting out compiler fires.</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:11</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="285">Saturday, January 19, 2008</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#build">Building and Installing the Distribution</a>
+ <li class="inline"><a href="#unix">Building and Installing for Unix</a>
+ <li class="inline"><a href="#win">Building and Installing for Windows</a>
+ <li class="inline"><a href="#conf">Configuration</a>
+ <li class="inline"><a href="#prob">If You Have Problems</a>
+ <li class="inline"><a href="#make">Additional <tt>make</tt> Commands</a>
+</a>
+ </ul>
+ <hr>
+ <h4 id="build">Building and Installing the Distribution</h4>
+ <p>It is not possible in a software distribution such as this to support every individual computer and operating system with a common executable, even with the same system but different versions. Therefore, it is necessary to configure, build and install for each system and version. In almost all cases, these procedures are completely automatic, The user types <tt>./configure</tt>, <tt>make</tt> and <tt>install</tt> in that order and the autoconfigure system does the rest. There are some exceptions, as noted below and on the <a href="hints.html">Hints and Kinks</a> pages.</p>
+ <p>If available, the OpenSSL library from <a href="http://www.openssl.org">http://www.openssl.org</a> is used to support public key cryptography. The library must be built and installed prior to building NTPv4. The procedures for doing that are included in the OpenSSL documentation. The library is found during the normal NTPv4 configure phase and the interface routines compiled automatically. Only the <tt>libcrypto.a</tt> library file and <tt>openssl</tt> header files are needed. If the library is not available or disabled, this step is not required.</p>
+ <p>The <a href="config.html">Configuration Options</a> page describes a number of options that determine whether debug support is included, whether and which reference clock drivers are included and the locations of the executables and library files, if not the default. By default debugging options and all reference clock drivers are included.</p>
+ <h4 id="unix">Building and Installing for Unix</h4>
+ <p>This distribution uses common compilers and tools that come with most Unix distributions. Not all of these tools exist in the standard distribution of modern Unix versions (compilers are likely to be an add-on product). If this is the case, consider using the GNU tools and <tt>gcc</tt> compiler included as freeware in some products. For a successful build, all of these tools should be accessible via the current path.</p>
+ <p>The first thing to do is uncompress the distribution and extract the source tree. In the distribution base directory use the <tt>./configure</tt> command to perform an automatic configuration procedure. This command inspects the hardware and software environment and configures the build process accordingly. Use the <tt>make</tt> command to compile and link the distribution and the <tt>install</tt> command to install the executables by default in <tt>/usr/local/bin</tt>.</p>
+ <p>If your site supports multiple architectures and uses NFS to share files, you can use a single source tree to build executables for multiple architectures. While running on a particular architecture, change to the base directory and create a subdirectory using a command like <tt>mkdir A.machine</tt> which will create an architecture-specific directory, then change to this directory and mumble <tt>../configure</tt>. The remaining steps are the same whether building in the base directory or in the subdirectory.</p>
+ <h4 id="win">Building and Installing for Windows</h4>
+ <p>NTP supports Windows Vista, XP, NT4 and 2000 systems. See <tt><a href="hints/winnt.html">hints/winnt.htm</a></tt> for directions to compile the sources and install the executables. A precompiled executable is available.</p>
+ <h4 id="conf">Configuration</h4>
+ <p>You are now ready to configure the daemon. You will need to create a NTP configuration file by default in <tt>n/etc/ntp.conf.</tt> Newbies should see the <a href="quick.html">Quick Start</a> page for orientation. Seasoned veterans can start with the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page and move on to the specific configuration option pages from there.</p>
+ <h4 id="prob">If You Have Problems</h4>
+ <p>If you have problems with your hardware and software environment (e.g. operating system-specific issues), browse the <a href="hints.html">Hints and Kinks</a> pages. For other problems a tutorial on debugging technique is in the <a href="debug.html">NTP Debugging Technique</a> page. A list of important system log messages is on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page.</p>
+ <p>The first line of general assistance is the NTP web site <a href="http://www.ntp.org">www.ntp.org</a> and the helpful documents resident there. Requests for assistance of a general nature and of interest to other timekeepers should be sent to the NTP newsgroup comp.protocols.time.ntp.</p>
+ <p>Users are invited to report bugs and offer suggestions via the <a href="bugs.html">NTPáBug Reporting Procedures</a> page.</p>
+ <h4 id="make">Additional <tt>make</tt> commands</h4>
+ <dl>
+ <dt><tt>make clean</tt>
+ <dd>Cleans out object files, programs and temporary files.
+ <dt><tt>make distclean</tt>
+ <dd>Does the work of <tt>clean</tt>, but cleans out all directories in preparation for a new distribution release.
+ <dt><tt>make dist</tt>
+ <dd>Does the work of <tt>make distclean</tt>, but constructs compressed tar files for distribution. You must have GNU automake to perform this function.
+ </dl>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>Building and Installing the Distribution</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <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>
- <p>For putting out compiler fires.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">03:06 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 13, 2003</csobj></p>
- <br clear="left">
- <h4>Related Links</h4>
- <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>
- <li class="inline"><a href="#unix">Building and Installing under Unix</a>
- <li class="inline"><a href="#comp">Compilation</a>
- <li class="inline"><a href="#install">Installation</a>
- <li class="inline"><a href="#config">Configuration</a>
- <li class="inline"><a href="#prob">If You Have Problems</a>
- <li class="inline"><a href="#win">Building and Installing under Windows NT</a>
- </ul>
- <hr>
- <h4 id="build">Building and Installing the Distribution</h4>
- <p>As a practical matter, every computer architecture and operating system version seems to be different than any other. The device drivers may be different, the input/output system may be idiosyncratic and the libraries may have different semantics. It is not possible in a software distribution such as this one to support every individual system with a common set of binaries, even with the same system but different versions. Therefore, it is necessary to individually configure the software build for each system and version, both at compile time and at run time. In almost all cases, these procedures are completely automatic and all the newbie user need do is type "configure", "make" and "install" in that order and the autoconfigure system does the rest. There are some exceptions, as noted below and on the <a href="hints.html">Hints and Kinks</a> page.</p>
- <p>If available, the OpenSSL library from <a href="http://www.openssl.org">http://www.openssl.org</a> is used to support public key cryptography. The library must be built and installed prior to building NTPv4. The procedures for doing that are included in the OpenSSL documentation. The library is found during the normal NTPv4 configure phase and the interface routines compiled automatically. Only the <tt>libcrypto.a</tt> library and associated header files are used. If the library is not available or disabled, this step is not required.</p>
- <h4 id="unix">Building and Installing under Unix</h4>
- <p>Make sure that you have all necessary tools for building executables. These tools include <tt>cc/gcc, make, awk, sed, tr, sh, grep, egrep</tt> and a few others. Not all of these tools exist in the standard distribution of modern Unix versions (compilers are likely to be an add-on product). If this is the case, consider using the GNU tools and <tt>gcc</tt> compiler. For a successful build, all of these tools should be accessible via the current path.</p>
- <p>The first thing to do is uncompress the distribution and extract the source tree. In the distribution base directory use the <tt>./configure</tt> command to perform an automatic configuration procedure. This command inspects the hardware and software environment and tests for the presence of system header files and the contents of these files to determine if certain features are present. When one or more of these features are present, the code is compiled to use them; if not, no special code is compiled. However, even if the code is compiled to use these features, the code does a special test at run time to see if one or more are actually present and avoids using them if not present. In such cases a warning message is sent to the system log, but the daemon should still work properly.</p>
- <p>The default build normally includes the debugging code, which can be useful in diagnosing problems found in initial test, and all reference clock drivers known to work with each machine and operating system. Unless memory space is at a premium, this is a sensible strategy and greatly simplifies debugging and support. If you need to delete either the debugging code or one or all reference clock drivers to save space, see the <a href="config.html">Configuration Options</a> page.</p>
- <p>If your site supports multiple architectures and uses NFS to share files, you can use a single source tree to compile executables for all architectures. While running on a target architecture machine and in the distribution base directory create a subdirectory using a command like <tt>mkdir A.`config.guess`</tt>, which will create an architecture-specific directory with name peculiar to the architecture and operating system. Then change to this directory and emit a <tt>../configure</tt> command. The remaining steps are the same whether building in the base directory or in the subdirectory.</p>
- <h4 id="comp">Compilation</h4>
- <p>Use the <tt>make</tt> command to compile all source modules, construct the libraries and link the distribution. Expect few or no warnings using <tt>cc</tt> and a moderate level of warnings using <tt>gcc</tt>. Note: On some Unix platforms <tt>gcc</tt> may show quite a few complaints about system header files and type inconsistencies, especially with pointer variables. This is usually the case when the system header files are not up to ANSI standards or <tt>gcc </tt>expectations, when <tt>gcc</tt> is not installed properly, or when operating system updates and patches are applied and <tt>gcc</tt> is not reinstalled. While the autoconfigure process is quite thorough, the Unix programming cultures of the various workstation makers still remain idiosyncratic.</p>
- <h4 id="install">Installation</h4>
- <p>As root, use the <tt>make install</tt> command to install the binaries in the destination directory. Most commonly, these programs are installed in <tt>/usr/local/bin</tt>, but this can be overridden during configuration. You must of course have write permission on the install in the destination directory. This includes the following programs:</p>
- <ul>
- <li><a href="../ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>
- <li><a href="../ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>
- <li><a href="../ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>
- <li><a href="../ntpdate.html"><tt>ntpdate</tt> - set the date and time via NTP</a>
- <li><a href="../ntptrace.html"><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a>
- </ul>
- <p>If the precision time kernel modifications are present, the following program is installed:</p>
- <ul>
- <li><a href="../ntptime.html"><tt>ntptime</tt> - read kernel time variables</a>
- </ul>
- <p>If the public key authentication functions are present, the following program is installed:</p>
- <ul>
- <li><a href="../keygen.html"><tt>ntp-keygen</tt> - generate public and private keys</a>
- </ul>
- <p>In some systems that include the capability to edit kernel variables, the following program is installed:</p>
- <ul>
- <li><a href="../tickadj.html"><tt>tickadj</tt> - set time-related kernel variables</a>
- </ul>
- <p>Cryptographic support, both symmetric and public key, requires one or more key files, commonly installed in <tt>/usr/local/etc</tt>. Public key cryptography requires a random seed file, usually called <tt>.rnd</tt>, installed in a dark place such as the root directory or <tt>/etc</tt>. Directions for generating keys is on the <a href="../authopt.html">Authentication Options</a> page.</p>
- <h4 id="config">Configuration</h4>
- <p>You are now ready to configure the daemon and start it. You will need to create a NTP configuration file <tt>ntp.conf</tt> and a cryptographic key file <tt>ntp.keys</tt>. The latter file is necessary only for remote configuration support, if needed. Newbies should see the <a href="quick.html">Quick Start</a> page for orientation. Seasoned veterans can start with the <a href="../ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page and move on to the specific configuration option pages from there. A tutorial on NTP subnet design and configuration options is in the <a href="../notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a> page.</p>
- <h4 id="prob">If You Have Problems</h4>
- <p>If you have problems peculiar to the particular hardware and software environment (e.g. operating system-specific issues), browse the <a href="hints.html">Hints and Kinks</a> page. For other problems a tutorial on debugging technique is in the <a href="../debug.html">NTP Debugging Technique</a> page. As always, the first line of general assistance is the NTP web site <a href="http://www.ntp.org">www.ntp.org</a> and the FAQ resident there. Requests for assistance of a general nature and of interest to other timekeepers should be sent to the NTP newsgroup comp.protocols.time.ntp. Bug reports of a specific nature should be sent to <a href="mailto:bugs@mail.ntp.org">bugs@ntp.org</a>. Bug reports of a specific nature on features implemented by the programmer corps mentioned in the <a href="../copyright.html">Copyright</a> page should be sent directly to the implementor listed in that page, with copy to bugs@ntp.org.</p>
- <p>Please include the version of the source distribution (e.g., ntp-4.0.70a) in your bug report, as well as billboards from the relevant utility programs and debug trace, if available. Please include the output of <tt>config.guess</tt> in your bug report. It will look something like:</p>
- <p><tt>pdp11-dec-fuzzos3.4</tt></p>
- <h4>Additional <tt>make</tt> commands</h4>
- <dl>
- <dt><tt>make clean</tt>
- <dd>Cleans out object files, programs and temporary files.
- <dt><tt>make distclean</tt>
- <dd>Does the work of <tt>clean</tt>, but cleans out all directories in preparation for a new distribution release.
- <dt><tt>make dist</tt>
- <dd>Does the work of <tt>make distclean</tt>, but constructs compressed tar files for distribution. You must have GNU automake to perform this function.
- </dl>
- <h4 id="win">Building and Installing under Windows NT</h4>
- <p>See <tt><a href="hints/winnt.html">hints/winnt.htm</a></tt> for directions to compile the sources and install the executables.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <title>Hints and Kinks</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Hints and Kinks</h3>
- <img src="../pic/alice35.gif" align="left" alt="gif"><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.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">12:56 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="266">Saturday, March 20, 2004</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>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
+++ /dev/null
-Starting with NetBSD-1.6, it is possible to delegate the system clock
-control to a non root user. This enable running ntpd in a chroot
-jail under a non privilegied UID/GID, using ntpd -i and -u flags.
-
-The delegation is done through the clockctl(4) pseudodevice driver.
-This driver makes privilegied system calls such as ntp_adjtime(2)
-available through ioctl(2) on the /dev/clockctl device. If a user
-is able to write to /dev/clockctl, then (s)he can control the system
-clock.
-
-In order to use this feature, make sure that:
-
-1) Your kernel is compiled with the following option:
-pseudo-device clockctl
-This is true for GENERIC kernels on most ports. Please check
-http://wwW.netbsd.org/Documentation/kernel/
-if you need information about building a kernel.
-
-2) You have a ntpd user on your system. Here is the /etc/master.passwd
-entry for ntpd user on NetBSD-1.6:
-ntpd:*:15:15::0:0:& pseudo-user:/var/chroot/ntpd:/sbin/nologin
-And here is the /etc/group entry for group 15:
-ntpd:*:15:
-
-3) /dev/clockctl exists and is writtable by user ntpd. Default
-NetBSD-1.6 setting is:
-crw-rw---- 1 root ntpd 61, 0 Apr 1 2002 /dev/clockctl
-Major device number and date is likely to be different on your system.
-If you need to create the device, issue the following command:
-cd /dev && ./MAKEDEV clockctl
-
-Here is an example of how to run ntpd chrooted in /var/chroot/ntpd,
-running with ntpd UID and ntpd GID:
-ntpd -i /var/chroot/ntpd -u ntpd:ntpd
-Note that -i and -u options are enabled at configure time if your
-system supports system clock control by an unprivilegied user. If this
-is not the case, then the -i and -u options will not be available.
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <title>vxWorks Port of NTP</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body link="#00008B" vlink="#8B0000">
- <h1>VxWorks port of NTP</h1>
- <p>Creating a port for vxWorks posed some problems. This port may help as a starting point for similar ports to real-time OS's and other embeddable kernels, particularly where main() is not allowed, and where the configure scripts need to be altered.</p>
- <h1><b>Configuration issues</b></h1>
- <p>I decided to do as little invasive surgery as possible on the NTP code, so I brought the vxWorks header tree in line with the standard unix tree. The following changes were needed, as a side effect these changes will allow for easy porting of other autoconfigure enabled code.</p>
- <p>Where I have 386 you will need to put in your target type. The vxWorks tree entry point is /usr/wind. If these are the same for your system, you should be able to cut and paste the changes.</p>
- <p><blink>WARNING: Check you are not overwriting files, before entering the following: there should be no conflict, but check first... </blink></p>
- <p>export CC="cc386 -nostdlib -m486 -DCPU=I80486 -I/usr/wind/target/h"<br>
- export RANLIB=ranlib386<br>
- export AR=ar386<br>
- export VX_KERNEL=/usr/wind/target/config/ims_std_bsp/vxWorks<br>
- cd /usr/wind/target/sys<br>
- ln -s ../signal.h<br>
- ln -s ../time.h<br>
- ln -s socket.h sockio.h<br>
- ln -s ../selectLib.h select.h<br>
- ln -s ../timers.h<br>
- touch file.h param.h resource.h utsname.h var.h ../netdb.h ../a.out.h ../termios.h<br>
- echo " ******ADD #include \"sys/times.h\" to sys/time.h "</p>
- <p>The configure script must be changed in the following way to get the linking tests to work, once in the correct directory issue the following commands:<br>
- sed -e 's%main.*()%vxmain()%' configure > configure.vxnew<br>
- mv configure.vxnew configure<br>
- chmod 755 configure</p>
- <p>The new version 4 of NTP requires some maths functions so it links in the maths library (-lm) in the ntpd <a href="../../ntpd/Makefile.am">Makefile.am</a> change the line "ntpd_LDADD = $(LDADD) -lm" by removing the "-lm".<br>
- You are now ready to compile</p>
- <p><br>
- The <a href="../../configure.in">configure.in </a>file needed to be altered to allow for a host-target configuration to take place.</p>
- <ul>
- <li>The define SYS_VXWORKS was added to the compilation flags.
- <li>Little endianess is set if the target is of type iX86.
- <li>The size of char, integer, long values are all set. If Wind River ever changes these values they will need to be updated.
- <li>clock_settime() is defined to be used for setting the clock.
- <li>The Linking flags have -r added to allow for relinking into the vxWorks kernel
- </ul>
- <p>Unfortunately I have had to make use of the <a href="../../include/ntp_machine.h">ntp_machine.h </a>file to add in the checks that would have been checked at linking stage by autoconf, a better method should be devised.</p>
- <ul>
- <li>There is now a NO_MAIN_ALLOWED define that simulates command line args, this allows the use of the normal startup sysntax.
- <li>POSIX timers have been added.
- <li>Structures normally found in netdb.h have been added with, the corresponding code is in <a href="../../libntp/machines.c">machines.c </a>. Where possible the defines for these have been kept non-vxWorks specific.
- </ul>
- <p>Unfortunately there are still quite a few SYS_VXWORKS type defines in the source, but I have eliminated as many as possible. You have the choice of using the usrtime.a library avaliable from the vxworks archives or forgoing adjtime() and using the clock_[get|set]time().The <a href="../../include/ntp_machine.h">ntp_machine.h </a>file clearly marks how to do this.</p>
- <h1><b>Compilation issues</b></h1>
- <p>You will need autoconf and automake ... available free from the gnu archives worldwide.</p>
- <p>The variable arch is the target architecture (e.g. i486)</p>
- <p>mkdir A.vxworks (or whatever....)<br>
- cd A.vxworks<br>
- ../configure --target=arch-wrs-vxworks [any other options]<br>
- make</p>
- <p>Options I normally use are the --disable-all-clocks --enable-LOCAL-CLOCK flags. The program should proceed to compile without problem. The daemon ntpd, ntpdate, ntptrace, ntpdc, ntpq programs and of course the libraries are all fully ported. The other utilities are not, but they should be easy to port.</p>
- <h1>Running the software</h1>
- <p>Load in the various files, call them in the normal vxWorks function type manner. Here are some examples. Refer to the man pages for further information.</p>
- <p>ld < ntpdate/ntpdate<br>
- ld < ntpd/ntpd<br>
- ld < ntptrace/ntptrace<br>
- ld < ntpq/ntpq<br>
- ld < ntpdc/ntpdc<br>
- ntpdate ("-b", "192.168.0.245")<br>
- sp(ntpd, "-c", "/export/home/casey/ntp/ntp.conf")<br>
- ntpdc("-c", "monlist", "192.168.0.244")<br>
- ntpq("-c", "peers", "192.168.0.244")<br>
- ntptrace("192.168.0.244")<br>
- </p>
- <h1>Bugs and such</h1>
- <p>Should you happen across any bugs, please let me know, or better yet fix them and submit a patch. Remember to make you patch general for Vxworks, not just for your particular architecture. <a href="http://www.ccii.co.za">CCII Systems (Pty) Ltd</a>, my ex employers, sponsored the time to this port. Please let me know how it goes, I would be most interested in offsets and configurations.</p>
- <p><br>
- </p>
- <p>Casey Crellin<br>
- <a href="mailto:casey@csc.co.za">casey@csc.co.za</a></p>
- <p><br>
- </p>
- </body>
-
-</html>
\ No newline at end of file
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <title>NTP on Windows NT</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h1>NTP 4.x for Windows NT</h1>
-
- <h2>Introduction</h2>
- The NTP 4 distribution runs as service on Windows NT 4.0, Windows 2000, Windows XP,
- Windows .NET Server 2003. It will NOT run on Windows 95, 98, ME, etc.
- The binaries work on multi-processor systems. This port has not been tested
- on the Alpha platform. This release now uses OpenSSL for authentication.
- IPv6 is not implemented yet for Win32 platforms.
- <h2>Authentication Keys</h2>
- With this release ntp-keygen is supported. See the <a href="../../keygen.html">
- ntp keygen documentation</a> for details on how to use ntp-keygen.
- <p>
- ntpd can now use the generated keys in the same way as on Unix platforms. Please
- refer to the <a href="../../authopt.html">Authentication Options</a> for details
- on how to use these.
- <p><B>NOTE:</B> ntpd and ntp-keygen both use OpenSSL which requires a random
- character file called .rnd by default. Both of these programs will automatically
- generate this file if they are not found. The programs will look for an
- environmental variable called RANDFILE and use that for the name of the
- random character file if the variable exists. If it does not exist it will look for an environmental
- variable called HOME and use that directory to search for a filed called .rnd
- in that directory. Finally, if neither RANDFILE nor HOME exists it will look
- in C:\ for a .rnd file. In each case it will search for and create the file
- if the environmental variable exists or in the C:\ directory if it doesn't.
- Note that ntpd normally runs as a service so that the only way that it will
- have either RANDFILE or HOME defined is if it is a System environmental
- variable or if the service is run under a specific account name and that
- account has one of those variables defined. Otherwise it will use the file
- "c:\.rnd". This was done so that OpenSSL will work normally on Win32 systems.
- This obviates the need to ship the OpenSSL.exe file and explain how to
- generate the .rnd file. A future version may change this behavior.
-
- <p>Refer to <a href="#Compiling">Compiling Requirements</a> and Instructions for how to compile the program.</p>
- <h2>Reference Clocks</h2>
- Reference clock support under Windows NT is tricky because the IO functions are
- so much different. Some of the clock types have been built into the ntpd executable
- and should work but have not been tested by the ntp project. If you have a clock
- that runs on Win32 and the driver is there but not implemented on Win32 you will have
- make the required configuration changes in config.h and then build ntpd from source
- and test it. The following reference clocks are known to work and are supported
- by Windows NT:
- <p><a href="../../driver1.html">Type 1</a> Undisciplined Local Clock (LOCAL)<br>
- <a href="../../driver29.html">Type 29</a> Trimble Navigation Palisade GPS (GPS_PALISADE)</p>
- <h2>Functions Supported</h2>
- All NTP functions are supported with some constraints. See the <a href="#ToDo">TODO list</a> below.
- Note that the ntptrace executable is not supported and you should use the PERL script
- version instead.
- <h2>Accuracy</h2>
- Greg Brackley has implemented a fantastic interpolation scheme that improves the precision of the NTP clock
- using a realtime thread (is that poetic or what!) which captures a tick count from the 8253 counter after each
- OS tick. The count is used to interpolate the time between operating system ticks.
- <p>On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds and synchronizes the clock
- to +/-500 microseconds using the <a href="http://www.trimble.com/products/ntp">Trimble Palisade</a> as UTC reference.
- This allows distributed applications to use the 10 milliseconds ticks available to them with high confidence.</p>
- <h2>Binaries</h2>
- Recent InstallShield based executable versions of NTP for Windows NT (intel) are available from:
- <ul>
- <li><a href="http://www.trimble.com/oem/ntp">http://www.trimble.com/oem/ntp</a>
- <li><a href="http://www.five-ten-sg.com/">http://www.five-ten-sg.com/</a>
- <li><a href="http://www.meinberg.de/english/sw/ntp.htm">http://www.meinberg.de/english/sw/ntp.htm</a>
- </ul>
- <a name="ToDo"><h2>ToDo</h2></a>
- These tasks are in no particular order of priority.
- <ul>
- <li>Create a proper install/uninstall program
- <li>Add sntp to the list of supported programs
- <li>Add support for Visual C++ 7.0 or later (.NET)
- <li>Add IPv6 support
- <li>See if precision can be improved by using CPU cycle counter for tick interpolation.
- <li>Make precision time available to applications using NTP_GETTIME API
- </ul>
- <h2>Compiling Requirements</h2>
- <ul>
- <li>Windows NT 4.0 Windows 2000, Windows XP, or Windows.NET Server 2003
- <li>Microsoft Visual C++ 6.0. <B>NOTE:</B> VC++ 7.0 (aka .NET) is not yet supported
- but will probably work fine.
- <li>Some way of uncompressing and untarring the gzipped tar file.
- <li>OpenSSL must be built on the box before building NTP. Additional steps would
- be required to not use OpenSSL.
- </ul>
- <a name="Compiling"><h2>Compiling Instructions</h2></a>
- <ol>
- <li>Unpack and build OpenSSL according to the OpenSSL instructions for building on
- Windows. An environment variable named OPENSSL must be set up to specify the base path
- of the OpenSSL directory to be used to build the NTP package
- (e.g. <code>OPENSSL=C:\openssl-0.9.8b</code>).
- <li>Unpack the ntp-*.tar.gz archive using utilities such as WinZip.
- <li>Open the .\ports\winnt\ntp.dsw Visual C workspace
- <li>Batch build all projects
- <li>The built binaries can be found in the port\winnt\bin\Release subdirectory
- <li>In addition you will need to install the OpenSSL libeay32.dll
- <li>If you are shipping binaries in a kit it is strongly recommended that you
- ship this file (winnt.html) along with the binaries.
- </ol>
- <h2>Configuration File</h2>
- The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\. </tt>(%SystemRoot%
- is an environmental variable that can be determined by typing "set" at the "Command Prompt"
- or from the "System" icon in the "Control Panel").<br>
- Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt> file in the directory
- corresponding to your system installation.<br>
- <tt>The older <WINDIR>\ntp.conf </tt>is still supported but you will get a log entry reporting that
- the first file wasn't found.
- <h2>Installation Instructions</h2>
- The <tt>instsrv</tt> program in the instsrv subdirectory of the distribution can be used to install 'ntpd' as
- a service and start automatically at boot time. Instsrv is automatically compiled with the rest of the distribution
- if you followed the steps above.
- <ol>
- <li>Start a command prompt and enter "instsrv.exe <pathname_for_ntpd.exe>"
- <li>Clicking on the "Services" icon in the "Control Panel" will display the list of
- currently installed services in a dialog box. The NetworkTimeProtocol service should show up in this list.
- Select it in the list and hit the "Start" button in the dialog box. The NTP service should start.
- <li>You can also stop and start the service by typing net start|stop NetworkTimeProtocol at the DOS prompt.
- <li>View the event log by clicking on the "Event Viewer" icon in the "Administrative Tools"
- group, there should be several successful startup messages from NTP. NTP will keep running and restart
- automatically when the machine is rebooted.
- </ol>
- You can change the start mode (automatic/manual) and other startup parameters corresponding to the NTP service
- in the "Services" dialog box if you wish.
- <h2>Removing NTP</h2>
- You can also use <tt>instsrv</tt> to delete the NTP service by entering: "instsrv.exe remove"
- <h2>Command Line Parameters and Registry Entries</h2>
- Unlike the Unix environment, there is no clean way to run 'ntpdate' and reset the clock before starting 'ntpd' at boot time.<br>
- NTP will step the clock up to 1000 seconds by default. While there is no reason that the system clock should be that much off
- during bootup if 'ntpd' was running before, you may wish to override this default and/or pass other command line directives.
- <p>Use the registry editor to edit the value for the ntpd executable under LocalMachine\System\CurrentControlSet\Services\NTP.</p>
- <p>Add the -g option to the ImagePath key, behind "%INSTALLDIR>\ntpd.exe". This will force NTP to accept
- large time errors (including 1.1.1980 00:00)</p>
- <h2>Bug Reports</h2>
- Send questions to <a href="news://comp.protocols.time.ntp">news://comp.protocols.time.ntp</a>
- and bug reports should be entered in <a href="http://bugzilla.ntp.org/">Bugzilla</a> on the
- NTP Web site.
- <h2>Change Log</h2>
- <h3>Last revision 2 July 2003 Version 4.2.0</h3>
- <b>by Danny Mayer (mayer@ntp.org>)</b>
- <h3>Significant Changes:</h3>
- This latest release of NTP constitutes a major upgrade to its ability to build and
- run on Windows platforms and should now build and run cleanly. More importantly it
- is now able to support all authentication in the same way as Unix boxes. This does
- require the usage of OpenSSL which is now a prerequisite for build on Windows.
- ntp-keygen is now supported and builds on Win32 platforms.
-
- <h3>Last revision 16 February 1999 Version 4.0.99e.</h3>
- <b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
- <p><b>Significant Changes:</b></p>
- <ul>
- <li>Perl 5 is no longer needed to compile NTP. The configuration script which creates version.c
- with the current date and time was modified by Frederick Czajka [w2k@austin.rr.com] so that Perl
- is no longer required.
- </ul>
- <h3>Last revision 15 November 1999 Version 4.0.98f.</h3>
- <b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
- <p><b>Significant Changes:</b></p>
- <ul>
- <li>Fixed I/O problem delaying packet responses which resulted in no-replys to NTPQ and others.
- <li>The default configuration file path is <tt><WINDIR>\system32\drivers\etc\ntp.conf.
- The old <WINDIR>\ntp.conf </tt>is still supported but you will get a log entry reporting
- that the first file wasn't found. The NTP 3.x legacy <tt>ntp.ini</tt> file is no longer supported.
- </ul>
- <b>Known Problems / TODO:</b>
- <ul>
- <li>MD5 and name resolution do not yet get along. If you define MD5, you cannot use DNS names, only IP numbers.
- </ul>
- <h3>Last revision 27 July 1999 Version 4.0.95.</h3>
- This version compiles under WINNT with Visual C 6.0.
- <p>Greg Brackley and Sven Dietrich</p>
- <p>Significant changes:<br>
- -Visual Studio v6.0 support<br>
- -Winsock 2.0 support<br>
- -Use of I/O completion ports for sockets and comm port I/O<br>
- -Removed the use of multimedia timers (from ntpd, others need removing)<br>
- -Use of waitable timers (with user mode APC) and performance counters to fake getting a better time<br>
- -Trimble Palisade NTP Reference Clock support<br>
- -General cleanup, prototyping of functions<br>
- -Moved receiver buffer code to a separate module (removed unused members from the recvbuff struct)<br>
- -Moved io signal code to a separate module</p>
- <h3>Last revision: 20-Oct-1996</h3>
- This version corrects problems with building the XNTP<br>
- version 3.5-86 distribution under Windows NT.
- <p>The following files were modified:<br>
- blddbg.bat<br>
- bldrel.bat<br>
- include\ntp_machine.h<br>
- xntpd\ntp_unixclock.c<br>
- xntpd\ntp_refclock.c<br>
- scripts\wininstall\build.bat<br>
- scripts\wininstall\setup.rul<br>
- scripts\wininstall\readme.nt<br>
- scripts\wininstall\distrib\ntpog.wri<br>
- html\hints\winnt (this file)</p>
- <p>In order to build the entire Windows NT distribution you<br>
- need to modify the file scripts\wininstall\build.bat<br>
- with the installation directory of the InstallShield<br>
- software. Then, simply type "bldrel" for non-debug<br>
- or "blddbg" for debug executables.</p>
- <p>Greg Schueman<br>
- <schueman@acm.org></p>
- <h3>Last revision: 07-May-1996</h3>
- This set of changes fixes all known bugs, and it includes<br>
- several major enhancements.
- <p>Many changes have been made both to the build environment as<br>
- well as the code. There is no longer an ntp.mak file, instead<br>
- there is a buildntall.bat file that will build the entire<br>
- release in one shot. The batch file requires Perl. Perl<br>
- is easily available from the NT Resource Kit or on the Net.</p>
- <p>The multiple interface support was adapted from Larry Kahn's<br>
- work on the BIND NT port. I have not been able to test it<br>
- adequately as I only have NT servers with one network<br>
- interfaces on which to test.</p>
- <p>Enhancements:<br>
- * Event Logging now works correctly.<br>
- * Version numbers now work (requires Perl during build)<br>
- * Support for multiple network interface cards (untested)<br>
- * NTP.CONF now default, but supports ntp.ini if not found<br>
- * Installation procedure automated.<br>
- * All paths now allow environment variables such as %windir%</p>
- <p>Bug fixes:<br>
- * INSTSRV replaced, works correctly<br>
- * Cleaned up many warnings<br>
- * Corrected use of an uninitialized variable in XNTPD<br>
- * Fixed ntpdate -b option<br>
- * Fixed ntpdate to accept names as well as IP addresses<br>
- (Winsock WSAStartup was called after a gethostbyname())<br>
- * Fixed problem with "longjmp" in xntpdc/ntpdc.c that<br>
- caused a software exception on doing a Control-C in xntpdc.<br>
- A Cntrl-C now terminates the program.</p>
- <p>See below for more detail:</p>
- <p> Note: SIGINT is not supported for any Win32 application including<br>
- Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32<br>
- operating systems generate a new thread to specifically handle that<br>
- interrupt. This can cause a single-thread application such as UNIX,<br>
- to become multithreaded, resulting in unexpected behavior.<br>
- </p>
- <p>Possible enhancements and things left to do:<br>
- * Reference clock drivers for NT (at least Local Clock support)<br>
- * Control Panel Applet<br>
- * InstallShield based installation, like NT BIND has<br>
- * Integration with NT Performance Monitor<br>
- * SNMP integration<br>
- * Fully test multiple interface support<br>
- </p>
- <p>Known problems:<br>
- * bug in ntptrace - if no Stratum 1 servers are available,<br>
- such as on an
- IntraNet, the application crashes.</p>
- <h3>Last revision: 12-Apr-1995</h3>
- This NTPv3 distribution includes a sample configuration file and the project<br>
- makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0 compiler.<br>
- Also included is a small routine to install the NTP daemon as a "service"<br>
- on a WindowsNT box. Besides xntpd, the utilities that have been ported are<br>
- ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using a Bancomm<br>
- TimeServe2000 GPS receiver clock that acts as a strata 1 NTP server with no<br>
- authentication (it has not been tested with any refclock drivers compiled in).<br>
- Following are the known flaws in this port:<br>
- 1) currently, I do not know of a way in NT to get information about multiple<br>
- network interface cards. The current port uses just one socket bound to<br>
- INADDR_ANY address. Therefore when dealing with a multihomed NT time server,<br>
- clients should point to the default address on the server (otherwise the<br>
- reply is not guaranteed to come from the same interface to which the<br>
- request was sent). Working with Microsoft to get this resolved.<br>
- 2) There is some problem with "longjmp" in xntpdc/ntpdc.c that causes a<br>
- software exception on doing a Control-C in xntpdc. Be patient!<br>
- 3) The error messages logged by xntpd currently contain only the numerical<br>
- error code. Corresponding error message string has to be looked up in<br>
- "Books Online" on Visual C++ 2.0 under the topic "Numerical List of Error<br>
- Codes".
- <p>Last HTML Update: November 17, 1999<br>
- <a href="mailto://sven_dietrich@trimble.com">Sven_Dietrich@Trimble.COM</a></p>
- </body>
-
-</html>
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <title>Patching Procedures</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <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.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">12:56 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="266">Saturday, March 20, 2004</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>
- <li>Please submit patches to <a href="mailto:bugs@mail.ntp.org">bugs@mail.ntp.org</a> in the form of either unified-diffs (<tt>diff -u</tt>) or context-diffs (<tt>diff -c</tt>).
- <li>Please include the <strong>output</strong> from <tt>config.guess</tt> in the description of your patch. If <tt>config.guess</tt> does not produce any output for your machine, please fix that, too!
- <li>Please base the patch on the root directory of the distribution. The preferred procedure here is to copy your patch to the root directory and mumble
- <p><tt>patch -p <your_patch></tt></p>
- <li>Please avoid patching the RCS subdirectories; better yet, clean them out before submitting patches.
- <li>If you have whole new files, as well as patches, wrap the files and patches in a shell script. If you need to compress it, use either GNU <tt>gzip</tt> or the stock Unix <tt>compress</tt> utility.
- <li>Don't forget the documentation that may be affected by the patch. Send us patches for the <tt>./htm</tt> files as well.
- <li>We would be glad to include your name, electric address and descriptive phrase in the <a href="../copyright.html">Copyright</a> page, if you wish.
- </ol>
- <p>Prior to ntp3-5.83 (releases up to and including ntp3.5f) a complete patch history back to the dark ages was kept in the <tt>./patches</tt> directory, which might have been helpful to see if the same problem occurred in another port, etc. Patches were saved in that directory with file name in the form <tt>patch.<i>nnn</i></tt>, where <i>nnn</i> was approaching 200. All patches in that directory have been made; so, if yours was there, it was in the distribution.</p>
- <p>Since we have been getting multple patches for some bugs, plus many changes are implemented locally, no two maintainers here use the same tools, and since we're not using any bug-tracking software or even source code control, there is currently no tracking of specific changes.</p>
- <p>The best way to see what's changed between two distributions is to run a <tt>diff</tt> against them.</p>
- <p>Thanks for your contribution and happy chime.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <title>Porting Hints</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <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
- </p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">12:56 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="266">Saturday, March 20, 2004</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>
- <p>These are the rules so that older bsd systems and the POSIX standard system can coexist together.</p>
- <ol>
- <li>If you use <tt>select</tt> then include <tt>"ntp_select.h"</tt>. <tt>select</tt> is not standard, since it is very system dependent as to where it is defined. The logic to include the right system dependent include file is in <tt>"ntp_select.h"</tt>.
- <li>Always use POSIX definition of strings. Include <tt>"ntp_string.h"</tt> instead of <tt><string.h></tt>.
- <li>Always include <tt>"ntp_malloc.h"</tt> if you use <tt>malloc</tt>.
- <li>Always include <tt>"ntp_io.h"</tt> instead of <tt><sys/file.h></tt> or <tt><fnctl.h></tt> to get <tt>O_*</tt> flags.
- <li>Always include <tt>"ntp_if.h"</tt> instead of <tt><net/if.h></tt>.
- <li>Always include <tt>"ntp_stdlib.h"</tt> instead of <tt><stdlib.h></tt>.
- <li>Define any special defines needed for a system in <tt>./include/ntp_machine.h</tt> based on system identifier. This file is included by the <tt>"ntp_types.h"</tt> file and should always be placed first after the <tt><></tt> defines.
- <li>Define any special library prototypes left over from the system library and include files in the <tt>"l_stdlib.h"</tt> file. This file is included by the <tt>"ntp_stdlib.h"</tt> file and should ordinarily be placed last in the includes list.
- <li>Don't define a include file by the same name as a system include file.
- </ol>
- <p><tt>"l_stdlib.h"</tt> can contain any extra definitions that are needed so that <tt>gcc</tt> will shut up. They should be controlled by a system identifier and there should be a separate section for each system. Really this will make it easier to maintain.</p>
- <p>See <tt>include/ntp_machines.h</tt> for the various compile time options.</p>
- <p>When you are satisfied the port works and that other ports are not adversely affected, please send <a href="patches.html">patches</a> for the system files you have changed, as well as any documentation that should be updated, including the advice herein.</p>
- <p>Good luck.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>Quick Start</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <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.pdf">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="25" locale="00000409" region="0" t="DateTime" w="99">01:01 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="266">Saturday, March 20, 2004</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. The file, called by default <tt>/etc/ntp.conf</tt>, need only contain one line specifying a remote server, for instance</p>
- <p><tt>server foo.bar.com</tt></p>
- <p>Choosing an appropriate remote server is somewhat of a black art, but a suboptimal choice is seldom a problem. There are about two dozen public time servers operated by National Institutes of Science and Technology (NIST), US Naval Observatory (USNO), Canadian Metrology Centre (CMC) and many others available on the Internet. Lists of public primary and secondary NTP servers maintained on the <a href="http://www.eecis.udel.edu/%7emills/ntp/servers.html">Public NTP TIme Servers</a> page, which is updated frequently.The lists are sorted by country and, in the case of the US, by state. Usually, the best choice is the nearest in geographical terms, but the terms of engagement specified in each list entry should be carefully respected.</p>
- <p>During operation <tt>ntpd</tt> measures and corrects for incidental clock frequency error and writes the current value to a file called by default <tt>/etc/ntp.drift</tt>. If <tt>ntpd</tt> is stopped and restarted, it initializes the frequency from this file. In this way the potentially lengthy interval to relearn the frequency error is avoided.</p>
- <p>That's all there is to it, unless some problem in network connectivity or local operating system configuration occurs. The most common problem is some firewall between the workstation and server. System administrators should understand NTP uses UDP port 123 as both the source and destination port and that NTP does not involve any operating system interaction other than to set the system clock. While almost all modern Unix systems have included NTP and UDP port 123 defined in the services file, this should be checked if <tt>ntpd</tt> fails to come up at all.</p>
- <p>The best way to confirm NTP is working is using the <a href="../ntpq.html"><tt>ntpq</tt></a> utility, although the <a href="../ntpdc.html"><tt>ntpdc</tt></a> utility may be useful in extreme cases. See the documentation pages for further information. In the most extreme cases the <tt>-d</tt> option on the <tt>ntpd</tt> command line results in a blow-by-blow trace of the daemon operations. While the trace output can be cryptic, to say the least, it gives a general idea of what the program is doing and, in particular, details the arriving and departing packets and detected errors, if present.</p>
- <p>Sometimes the <tt>ntpd</tt>. behavior may seem to violate the Principle of Least Astonishment, but there are good reasons for this. See the <a href="../ntpd.html">Network Time Protocol (NTP) daemon</a> page for revealing insights. See this page and its dependencies for additional configuration and control options. The <a href="../notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a> page contains an extended discussion of these options.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
+++ /dev/null
-document.write("\
-<table><tr>\
-<td width='50%' ><img src='../icons/home.gif' align='middle' alt='gif'>\
-<a href='../index.html'>Home Page</a></td>\
-<td width='50%' ><img src='../icons/mail2.gif' align='middle' alt='gif'>\
-<a href='http://www.ntp.org/contact.html'>Contacts</a></i></td>\
-</tr></table>")
\ No newline at end of file
+++ /dev/null
-document.write("<ul>\
-<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\
-<li class='inline'><a href='prefer.html'>Mitigation Rules and the <tt>prefer</tt> Keyword</a><br>\
-<li class='inline'><a href='howto.html'>How to Write a Reference Clock Driver</a><br>\
-</ul>")
\ No newline at end of file
+++ /dev/null
-document.write("<ul>\
-<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\
-<li class='inline'><a href='pps.html'>Pulse-per-second (PPS) Signal Interfacing</a><br>\
-<li class='inline'><a href='ldisc.html'>Line Disciplines and Streams Modules</a><br>\
-</ul>")
\ No newline at end of file
+++ /dev/null
-document.write("<ul>\
-<li class='inline'><a href='debug.html'>NTP Debugging Techniques</a><br>\
-<li class='inline'><a href='rdebug.html'>Debugging Reference Clock Drivers</a><br>\
-<li class='inline'><a href='msyslog.html'><tt>ntpd</tt> System Log Messages</a><br>\
-</ul>")
\ No newline at end of file
+++ /dev/null
-document.write("<ul>\
-<li class='inline'><a href='../confopt.html'>Server Options</a><br>\
-<li class='inline'><a href='../authopt.html'>Authentication Options</a><br>\
-<li class='inline'><a href='../monopt.html'>Monitoring Options</a><br>\
-</ul>")
\ No newline at end of file
+++ /dev/null
-document.write("<ul>\
-<li class='inline'><a href='authopt.html'>Authentication Options</a><br>\
-<li class='inline'><a href='manyopt.html'>Automatic NTP Configuration Options</a><br>\
-<li class='inline'><a href='confopt.html'>Server Options</a><br>\
-<li class='inline'><a href='keygen.html'><tt>ntp-keygen</tt> - generate public and private keys</a>\
-<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autokey.html'>Autonomous Authentication</a>\
-</ul>")
\ No newline at end of file
+++ /dev/null
-body {background: #FDF1E1;
- color: #006600;
- font-family: "verdana", sans-serif;
- text-align: justify;
- margin-left: 5px;}
-
-p, h4, hr, li {margin-top: .6em; margin-bottom: .6em}
-li.inline {text-align: left; margin-top: 0; margin-bottom: 0}
-
-ul, dl, ol, {margin-top: .6em; margin-bottom: .6em; margin-left 5em}
-
-dt {margin-top: .6em}
-dd {margin-bottom: .6em}
-
-div.header {text-align: center;
- font-style: italic;}
-
-div.footer {text-align: center;
- font-size: 60%;}
-
-img.cell {align: left;}
-
-td.sidebar {width: 40px; align: center; valign: top;}
-img.sidebar {align: center; margin-top: 5px;}
-h4.sidebar {align: center;}
-
-p.top {background: #FDF1E1;
- color: #006600;
- position: absolute;
- margin-left: -90px;
- text-align: center;}
-
-a:link.sidebar {background: transparent;
- color: #990033;
- font-weight: bold;}
-
-a:visited.sidebar {background: transparent;
- color: #990033;
- font-weight: bold;}
-
-a:hover.sidebar {background: #FDF1E1;
- color: #006600;}
-
-img {margin: 5px;}
-
-div {text-align: center;}
-
-h1 {text-align: center;
- font-size: 250%;}
-
-caption {background: #EEEEEE;
- color: #339999;}
-
-tx {text-align: center;}
-
-th {background: #FFFFCC;
- color: #006600;
- text-align: center;
- text-decoration: underline;
- padding-top: 5px;}
-
-th.caption {background: #EEEEEE;
- color: #006600;
- text-align: center;}
\ No newline at end of file
<h3>Reference Clock Options</h3>
<img src="pic/stack1a.jpg" alt="gif" align="left">
<p>See the radios, all in a row.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:37</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">16:01</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#ref">Reference Clock Support</a>
</ul>
<hr>
<h4 id="ref">Reference Clock Support</h4>
- <p>The NTP Version 4 daemon supports some three dozen different radio, satellite and modem reference clocks plus a special pseudo-clock used for backup or when no other clock source is available. Detailed descriptions of individual device drivers and options can be found in the <a href="refclock.html">Reference Clock Drivers</a> page. Additional information can be found in the pages linked there, including the <a href="rdebug.html">Debugging Hints for Reference Clock Drivers</a> and <a href="howto.html">How To Write a Reference Clock Driver</a> pages. In addition, support for a PPS signal is available as described in <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. Many drivers support special line discipline/streams modules which can significantly improve the accuracy using the driver. These are described in the <a href="ldisc.html">Line Disciplines and Streams Drivers</a> page.</p>
+ <p>The NTP Version 4 daemon supports some three dozen different radio, satellite and modem reference clocks plus a special pseudo-clock used for backup or when no other clock source is available. Detailed descriptions of individual device drivers and options can be found in the <a href="refclock.html">Reference Clock Drivers</a> page. Additional information can be found in the pages linked there, including the <a href="rdebug.html">Debugging Hints for Reference Clock Drivers</a> and <a href="howto.html">How To Write a Reference Clock Driver</a> pages. In addition, support for a PPS signal is available as described in <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
<p>A reference clock will generally (though not always) be a radio timecode receiver which is synchronized to a source of standard time such as the services offered by the NRC in Canada and NIST and USNO in the US. The interface between the computer and the timecode receiver is device dependent, but is usually a serial port. A device driver specific to each reference clock must be selected and compiled in the distribution; however, most common radio, satellite and modem clocks are included by default. Note that an attempt to configure a reference clock when the driver has not been compiled or the hardware port has not been appropriately configured results in a scalding remark to the system log file, but is otherwise non hazardous.</p>
<p>For the purposes of configuration, <tt>ntpd</tt> treats reference clocks in a manner analogous to normal NTP peers as much as possible. Reference clocks are identified by a syntactically correct but invalid IP address, in order to distinguish them from normal NTP peers. Reference clock addresses are of the form <tt>127.127.<i>t.u</i></tt>, where <i><tt>t</tt></i> is an integer denoting the clock type and <i><tt>u</tt></i> indicates the unit number in the range 0-3. While it may seem overkill, it is in fact sometimes useful to configure multiple reference clocks of the same type, in which case the unit numbers must be unique.</p>
<p>The <tt>server</tt> command is used to configure a reference clock, where the <i><tt>address</tt></i> argument in that command is the clock address. The <tt>key</tt>, <tt>version</tt> and <tt>ttl</tt> options are not used for reference clock support. The <tt>mode</tt> option is added for reference clock support, as described below. The <tt>prefer</tt> option can be useful to persuade the server to cherish a reference clock with somewhat more enthusiasm than other reference clocks or peers. Further information on this option can be found in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. The <tt>minpoll</tt> and <tt>maxpoll</tt> options have meaning only for selected clock drivers. See the individual clock driver document pages for additional information.</p>
<html>
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>Configuration Options</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=windows-1252">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Configuration Options</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <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.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">12:56 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="266">Saturday, March 20, 2004</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>
- </ul>
- <hr>
- <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>
- </p>
- <h4 id="opt">Options</h4>
- <p><tt>[defaults in brackets after descriptions]</tt> Configuration:</p>
- <pre>
+ <body>
+ <h3>Configuration Options</h3>
+ <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="25" locale="00000409" region="0" t="DateTime" w="99">03:07 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 13, 2003</csobj></p>
+ <br clear="left">
+ <h4>Table of Contents</h4>
+
<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>
+
<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>
+ </p>
+ <h4 id="opt">Options</h4>
+
<p><tt>[defaults in brackets after descriptions]</tt> Configuration:</p>
--cache-file=FILE cache test results in FILE
--help print this message
--no-create do not create output files
--version print the version of autoconf that created
configure
</pre>
- <h4 id="dir">Directory and File Names</h4>
- <pre>
+ <h4 id="dir">Directory and File Names</h4>
--prefix=PREFIX install architecture-independent files in PREFIX [/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [same as prefix]
--bindir=DIR user executables in DIR [EPREFIX/bin]
--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>
- <pre>
+ <h4 id="host">Host Type</h4>
--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>
- <pre>
+ <h4 id="pkg">Optional Packages</h4>
--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>
- <pre>
+ <h4 id="feat">Optional Features</h4>
--disable-FEATURE do not include FEATURE (same as
--enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
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):</p>
- <pre>
+ <h4 id="radio">Radio Clocks</h4>
+
<p>(these are ordinarily enabled, if supported by the machine and operating system):</p>
all-clocks Include drivers for all suitable non-PARSE clocks [enable]
ACTS NIST dialup clock
ARBITER Arbiter 1088A/B GPS receiver
USNO US Naval Observatory dialup clock
WWV WWV audio receiver
</pre>
- <h4 id="parse">PARSE Clocks</h4>
- <pre>
+ <h4 id="parse">PARSE Clocks</h4>
parse-clocks Include drivers for all suitable PARSE clocks [enable]
COMPUTIME Diem Computime Radio Clock
DCF7000 ELV/DCF7000 Clock
VARITEXT VARITEXT clock
WHARTON Wharton 400A Series clock
</pre>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<h3>Server Options</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">20:19</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 15, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">00:57</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<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
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:31</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="285">Saturday, January 06, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:32</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="292">Monday, December 31, 2007</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>
+ <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.</p>
<pre>
***********************************************************************
* *
-* Copyright (c) David L. Mills 1992-2007 *
+* Copyright (c) David L. Mills 1992-2008 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *
<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.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:38</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">00:58</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>More Help</h4>
- <script type="text/javascript" language="javascript" src="scripts/links12.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<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>
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <title>Austron 2200A/2201A GPS Receivers</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <title>Austron 2200A/2201A GPS Receivers</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>Austron 2200A/2201A GPS Receivers</h3>
- <hr>
- <h4>Synopsis</h4>
- <p>Address: 127.127.10.<i>u</i><br>
- Reference ID: <tt>GPS</tt><br>
- Driver ID: <tt>GPS_AS2201</tt><br>
- Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
- Features: <tt>tty_clk</tt></p>
- <h4>Description</h4>
- <p>This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Buffered Serial Interface module for communication with the driver. For operation with multiple computers, it requires the <tt>ppsclock</tt> streams module described in the <a href="../ldisc.html">Line Disciplines and Streams Modules</a> page. The streams module requires a gadget box and 1-PPS level converter, such as described in the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
- <p>For use with a single computer, the receiver can be connected directly to the receiver. For use with multiple computers, one of them is connected directly to the receiver and generates the polling messages. The other computers just listen to the receiver output directly or through a buffer amplifier. For computers that just listen, <tt>fudge flag2</tt> must be set and the <tt>ppsclock </tt>streams module configured on each of them.</p>
- <p>This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory</p>
- of the ntp3 distribution.
- <h4>Monitor Data</h4>
- <p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
- <h4>Fudge Factors</h4>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
- <dt><tt>time2 <i>time</i></tt>
- <dd>Not used by this driver.
- <dt><tt>stratum <i>number</i></tt>
- <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
- <dt><tt>refid <i>string</i></tt>
- <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
- <dt><tt>flag1 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag2 0 | 1</tt>
- <dd>Set for computers that listen-only.
- <dt><tt>flag3 0 | 1</tt>
- <dd>Not used by this driver.
- <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></p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ <body>
+ <h3>Austron 2200A/2201A GPS Receivers</h3>
+ <hr>
+ <h4>Synopsis</h4>
+
<p>Address: 127.127.10.<i>u</i><br>
+ Reference ID: <tt>GPS</tt><br>
+ Driver ID: <tt>GPS_AS2201</tt><br>
+ Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
+ Features: <tt>tty_clk</tt></p>
+ <h4>Description</h4>
+ <p>This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Buffered Serial Interface module for communication with the driver.</p>
+
<p>For use with a single computer, the receiver can be connected directly to the receiver. For use with multiple computers, one of them is connected directly to the receiver and generates the polling messages. The other computers just listen to the receiver output directly or through a buffer amplifier. For computers that just listen, <tt>fudge flag2</tt> must be set and the <tt>ppsclock </tt>streams module configured on each of them.</p>
+
<p>This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory</p>
+ of the ntp3 distribution.
+ <h4>Monitor Data</h4>
+
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
+ <h4>Fudge Factors</h4>
+ <dt><tt>time1 <i>time</i></tt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
+ <dt><tt>time2 <i>time</i></tt>
+ <dd>Not used by this driver.
+ <dt><tt>stratum <i>number</i></tt>
+ <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+ <dt><tt>refid <i>string</i></tt>
+ <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
+ <dt><tt>flag1 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag2 0 | 1</tt>
+ <dd>Set for computers that listen-only.
+ <dt><tt>flag3 0 | 1</tt>
+ <dd>Not used by this driver.
+ <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></p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <title>Arbiter 1088A/B GPS Receiver</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <title>Arbiter 1088A/B GPS Receiver</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>Arbiter 1088A/B GPS Receiver</h3>
- <hr>
- <h4>Synopsis</h4>
- <p>Address: 127.127.11.<i>u</i><br>
- Reference ID: <tt>GPS</tt><br>
- Driver ID: <tt>GPS_ARBITER</tt><br>
- Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
- Features: <tt>tty_clk</tt></p>
- <h4>
- <p>Description</p>
- </h4>
- <p>This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The claimed accuracy of this clock is 100 ns relative to the PPS output when receiving four or more satellites.</p>
- <p>The receiver should be configured before starting the NTP daemon, in order to establish reliable position and operating conditions. It does not initiate surveying or hold mode. For use with NTP, the daylight savings time feature should be disables (<tt>D0</tt> command) and the broadcast mode set to operate in UTC (<tt>BU</tt> command).</p>
- <p>The timecode format supported by this driver is selected by the poll sequence <tt>B5</tt>, which initiates a line in the following format to be repeated once per second until turned off by the <tt>B0</tt> command.</p>
- <p>Format <tt>B5</tt> (24 ASCII printing characters):</p>
- <pre><cr><lf>i yy ddd hh:mm:ss.000bbb
+ <body>
+ <h3>Arbiter 1088A/B GPS Receiver</h3>
+ <hr>
+ <h4>Synopsis</h4>
+ <p>Address: 127.127.11.<i>u</i><br>
+ Reference ID: <tt>GPS</tt><br>
+ Driver ID: <tt>GPS_ARBITER</tt><br>
+ Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
+ Features: <tt>tty_clk</tt></p>
+ <h4>Description</h4>
+ <p>This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The claimed accuracy of this clock is 100 ns relative to the PPS output when receiving four or more satellites.</p>
+ <p>The receiver should be configured before starting the NTP daemon, in order to establish reliable position and operating conditions. It does not initiate surveying or hold mode. For use with NTP, the daylight savings time feature should be disables (<tt>D0</tt> command) and the broadcast mode set to operate in UTC (<tt>BU</tt> command).</p>
+ <p>The timecode format supported by this driver is selected by the poll sequence <tt>B5</tt>, which initiates a line in the following format to be repeated once per second until turned off by the <tt>B0</tt> command.</p>
+ <p>Format <tt>B5</tt> (24 ASCII printing characters):</p>
+ <pre><cr><lf>i yy ddd hh:mm:ss.000bbb
on-time = <cr>
i = synchronization flag (' ' = locked, '?' = unlocked)
hh:mm:ss = hours, minutes, seconds
.000 = fraction of second (not used)
bbb = tailing spaces for fill</pre>
- <p>The alarm condition is indicated by a '?' at i, which indicates the receiver is not synchronized. In normal operation, a line consisting of the timecode followed by the time quality character (TQ) followed by the receiver status string (SR) is written to the clockstats file.</p>
- <p>The time quality character is encoded in IEEE P1344 standard:</p>
- <p>Format <tt>TQ</tt> (IEEE P1344 estimated worst-case time quality)</p>
- <pre>0 clock locked, maximum accuracy
+
<p>The alarm condition is indicated by a '?' at i, which indicates the receiver is not synchronized. In normal operation, a line consisting of the timecode followed by the time quality character (TQ) followed by the receiver status string (SR) is written to the clockstats file.</p>
+
<p>The time quality character is encoded in IEEE P1344 standard:</p>
+
<p>Format <tt>TQ</tt> (IEEE P1344 estimated worst-case time quality)</p>
+
<pre>0 clock locked, maximum accuracy
F clock failure, time not reliable
4 clock unlocked, accuracy < 1 us
5 clock unlocked, accuracy < 10 us
9 clock unlocked, accuracy < 100 ms
A clock unlocked, accuracy < 1 s
B clock unlocked, accuracy < 10 s</pre>
- <p>The status string is encoded as follows:</p>
- <p>Format <tt>SR</tt> (25 ASCII printing characters)</p>
- <pre>V=vv S=ss T=t P=pdop E=ee
+
<p>The status string is encoded as follows:</p>
+
<p>Format <tt>SR</tt> (25 ASCII printing characters)</p>
+
<pre>V=vv S=ss T=t P=pdop E=ee
vv = satellites visible
ss = relative signal strength
t = satellites tracked
pdop = position dilution of precision (meters)
ee = hardware errors</pre>
- <p>A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself.</p>
- <h4>Monitor Data</h4>
- <p>When enabled by the <tt>flag4</tt> fudge flag, an additional line containing the latitude, longitude, elevation and optional deviation data is written to the <tt>clockstats</tt> file. The deviation data operates with an external pulse-per-second (PPS) input, such as a cesium oscillator or another radio clock. The PPS input should be connected to the B event channel and the radio initialized for deviation data on that channel. The deviation data consists of the mean offset and standard deviation of the external PPS signal relative the GPS signal, both in microseconds over the last 16 seconds.</p>
- <h4>Fudge Factors</h4>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
- <dt><tt>time2 <i>time</i></tt>
- <dd>Not used by this driver.
- <dt><tt>stratum <i>number</i></tt>
- <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
- <dt><tt>refid <i>string</i></tt>
- <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
- <dt><tt>flag1 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag2 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag3 0 | 1</tt>
- <dd>Not used by this driver.
- <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></p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+
<p>A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself.</p>
+ <h4>Monitor Data</h4>
+
<p>When enabled by the <tt>flag4</tt> fudge flag, an additional line containing the latitude, longitude, elevation and optional deviation data is written to the <tt>clockstats</tt> file. The deviation data operates with an external pulse-per-second (PPS) input, such as a cesium oscillator or another radio clock. The PPS input should be connected to the B event channel and the radio initialized for deviation data on that channel. The deviation data consists of the mean offset and standard deviation of the external PPS signal relative the GPS signal, both in microseconds over the last 16 seconds.</p>
+ <h4>Fudge Factors</h4>
+ <dt><tt>time1 <i>time</i></tt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
+ <dt><tt>time2 <i>time</i></tt>
+ <dd>Not used by this driver.
+ <dt><tt>stratum <i>number</i></tt>
+ <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+ <dt><tt>refid <i>string</i></tt>
+ <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
+ <dt><tt>flag1 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag2 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag3 0 | 1</tt>
+ <dd>Not used by this driver.
+ <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></p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <title>NIST Modem Time Service</title>
+ <title>NIST/USNO/PTB Modem Time Services</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
- <h3>Automated Computer Time Service (ACTS)</h3>
+ <h3>NIST/USNO/PTB Modem Time Services</h3>
<hr>
<h4>Synopsis</h4>
<p>Address: 127.127.18.<i>u</i><br>
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <title>Heath WWV/WWVH Receiver</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <title>Heath WWV/WWVH Receiver</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>Heath WWV/WWVH Receiver</h3>
- <hr>
- <h4>Synopsis</h4>
- <p>Address: 127.127.19.<i>u</i><br>
- Reference ID: <tt>WWV</tt><br>
- Driver ID: <tt>WWV_HEATH</tt><br>
- Serial Port: <tt>/dev/heath<i>u</i></tt>; 1200 baud, 8-bits, no parity<br>
- Features: <tt>tty_clk</tt><br>
- Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control</p>
- <h4>Description</h4>
- <p>This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less robust than other supported receivers. Its claimed accuracy is 100 ms when actually synchronized to the broadcast signal, but this doesn't happen even most of the time, due to propagation conditions, ambient noise sources, etc. When not synchronized, the accuracy is at the whim of the internal clock oscillator, which can wander into the sunset without warning. Since the indicated precision is 100 ms, expect a host synchronized only to this thing to wander to and fro, occasionally being rudely stepped when the offset exceeds the default CLOCK_MAX of 128 ms.</p>
- <p>The internal DIPswitches should be set to operate at 1200 baud in MANUAL mode and the current year. The external DIPswitches should be set to GMT and 24-hour format. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year.</p>
- <p>In MANUAL mode the clock responds to a rising edge of the request to send (RTS) modem control line by sending the timecode. Therefore, it is necessary that the operating system implement the <tt>TIOCMBIC</tt> and <tt>TIOCMBIS</tt> ioctl system calls and <tt>TIOCM_RTS</tt> control bit. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well.</p>
- <p>The clock message consists of 23 ASCII printing characters in the following format:</p>
- <pre>hh:mm:ss.f dd/mm/yr<cr>
+ <body>
+ <h3>Heath WWV/WWVH Receiver</h3>
+ <hr>
+ <h4>Synopsis</h4>
+
<p>Address: 127.127.19.<i>u</i><br>
+ Reference ID: <tt>WWV</tt><br>
+ Driver ID: <tt>WWV_HEATH</tt><br>
+ Serial Port: <tt>/dev/heath<i>u</i></tt>; 1200 baud, 8-bits, no parity<br>
+ Features: <tt>tty_clk</tt><br>
+ Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control</p>
+ <h4>Description</h4>
+ <p>This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less robust than other supported receivers. It's claimed accuracy is 100 ms when actually synchronized to the broadcast signal, but this doesn't happen even most of the time, due to propagation conditions, ambient noise sources, etc. When not synchronized, the accuracy is at the whim of the internal clock oscillator, which can wander into the sunset without warning. Since the indicated precision is 100 ms, expect a host synchronized only to this thing to wander to and fro, occasionally being rudely stepped when the offset exceeds the default CLOCK_MAX of 128 ms.</p>
+
<p>The internal DIPswitches should be set to operate at 1200 baud in MANUAL mode and the current year. The external DIPswitches should be set to GMT and 24-hour format. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year.</p>
+
<p>In MANUAL mode the clock responds to a rising edge of the request to send (RTS) modem control line by sending the timecode. Therefore, it is necessary that the operating system implement the <tt>TIOCMBIC</tt> and <tt>TIOCMBIS</tt> ioctl system calls and <tt>TIOCM_RTS</tt> control bit. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well.</p>
+
<p>The clock message consists of 23 ASCII printing characters in the following format:</p>
+
<pre>hh:mm:ss.f dd/mm/yr<cr>
hh:mm:ss.f = hours, minutes, seconds
f = deciseconds ('?' when out of spec)
dd/mm/yr = day, month, year</pre>
- <p>The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day.</p>
- <p>A fudge time1 value of .07 s appears to center the clock offset residuals.</p>
- <h4>Fudge Factors</h4>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
- <dt><tt>time2 <i>time</i></tt>
- <dd>Not used by this driver.
- <dt><tt>stratum <i>number</i></tt>
- <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
- <dt><tt>refid <i>string</i></tt>
- <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>.
- <dt><tt>flag1 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag2 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag3 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag4 0 | 1</tt>
- <dd>Not used by this driver
- </dl>
- Additional Information
- <p><a href="../refclock.html">Reference Clock Drivers</a> </p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+
<p>The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day.</p>
+
<p>A fudge time1 value of .07 s appears to center the clock offset residuals.</p>
+ <h4>Fudge Factors</h4>
+ <dt><tt>time1 <i>time</i></tt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
+ <dt><tt>time2 <i>time</i></tt>
+ <dd>Not used by this driver.
+ <dt><tt>stratum <i>number</i></tt>
+ <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+ <dt><tt>refid <i>string</i></tt>
+ <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>.
+ <dt><tt>flag1 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag2 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag3 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag4 0 | 1</tt>
+ <dd>Not used by this driver
+ </dl>
+ Additional Information
+
<p><a href="../refclock.html">Reference Clock Drivers</a> </p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<dl>
<dt><tt>g</tt> CR
<dd>Request for signal quality. Answer only valid during (late part of) resync to MSF signal. The response consists of two characters as follows:
- <ol>
<dl compact>
<dt>bit 7
<dd>parity
<dt>bit 2--0
<dd>reception signal quality in the range 0--5 (very poor to very good); if in the range 0--2 no successful reception is to be expected. The reported value drops to zero when not resyncing, ie when first returned byte is not `3'.
</dl>
- </ol>
<dt><tt>h</tt> CR
<dd>Request to resync to signal. Can take up from about 30s to 360s. Drains batteries so should not be used excessively. After this the clock time and date should be correct and the phase within 20ms of time as transmitted from the source signal (remember to allow for propagation time). By default the clock resyncs once per day in the late evening/early morning (presumably to catch transitions to/from daylight saving time quickly). This driver code, by default, resyncs at least once per hour to minimise clock wander.
<dt><tt>o</tt> CR
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>Ultralink Clock</title>
- <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
- <link <link href="scripts/style.css" type="text/css" rel="stylesheet"> </HEAD> <BODY> <H3> Ultralink Clock</H3>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>Ultralink Clock</h3>
<hr>
<h4>Synopsis</h4>
- Address: 127.127.34.<i>u</i><br>
- Reference ID: <tt>WWVB</tt><br>
- Driver ID: <tt>ULINK</tt><br>
- Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 bps, 8-bits, no parity<br>
- <br>
- Features: <tt>(none)</tt>
+ <p>Address: 127.127.34.<i>u</i><br>
+ Reference ID: <tt>WWVB</tt><br>
+ Driver ID: <tt>ULINK</tt><br>
+ Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 bps, 8-bits, no parity<br>
+ Features: <tt>(none)</tt></p>
<h4>Description</h4>
- <p>This driver supports the Ultralink Model 325 (replacement for Model 320) RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.ulio.com/">http://www.ulio.com/</a>. This driver also supports the Model 320, 330,331,332 decoders in both polled or continous time code mode.<br>
- Leap second and quality are supported.</p>
- <p>Most of this code is originally from refclock_wwvb.c with thanks. Any mistakes are mine. Any improvements are welcome.</p>
- <hr>
- <pre> The Model 325 timecode format is:
-
- <cr><lf>RQ_1C00LYYYY+DDDUTCS_HH:MM:SSL+5
-
- where:
-
- R = Signal readability indicator, ranging from R1 to R5
- Q R1 is unreadable, R5 is best reception
- _ = Space
- 1 = prev. received data bit, values: 0, 1 ,M or ? unknown
- C = Signal reception from (C)olorado or (H)awaii
- 0 = Hours since last WWVB time and flag code update, values
- 0 00 to 99 (hopefully always 00)
- L = HEX A5 if receiver is locked to WWVB, Space if not
- YYYY = Year from 2000 to 2099
- + = '+' if current year is a leap year, else ' '
- DDD = current day in the year from 1 to 365/366
- UTC = timezone (always UTC)
- S = Daylight savings indicator, (S)TD, (D)ST, (O) transition
- into DST, (I) transition out of DST
- _ = Space
- HH = UTC hour 0 to 23
- : = Time delimiter, ':' if synced, Space if not
- MM = Minutes of current hour from 0 to 59
- : = Time delimiter, ':' if synced, Space if not
- SS = Seconds of current minute from 0 to 59
- mm = 10's milliseconds of the current second from 00 to 99
- L = Leap second pending at end of month, (I)nsert, (D)elete
- or Space
- +5 = UT1 correction, +/- .1 sec increments
- </pre>
+ <p>This driver supports the Ultralink Model 325 (replacement for Model 320) RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.ulio.com/">http://www.ulio.com/</a>. This driver also supports the Model 320, 330,331,332 decoders in both polled or continous time code mode.Leap second and quality are supported. Most of this code is originally from refclock_wwvb.c with thanks. Any mistakes are mine. Any improvements are welcome.</p>
+ <h4>Model 325 timecode format</h4>
+ <p><tt><cr><lf>RQ_1C00LYYYY+DDDUTCS_HH:MM:SSL+5</tt></p>
+ <p>R = Signal readability indicator, ranging from R1 to R5 Q R1 is unreadable, R5 is best reception<br>
+ _ = Space<br>
+ 1 = prev. received data bit, values: 0, 1 ,M or ? unknown
+ C = Signal reception from (C)olorado or (H)awaii 0 = Hours since last WWVB time and flag code update, values 0 00 to 99 (hopefully always 00)<br>
+ L = HEX A5 if receiver is locked to WWVB, Space if not<br>
+ YYYY = Year from 2000 to 2099<br>
+ + = '+' if current year is a leap year, else ' '<br>
+ DDD = current day in the year from 1 to 365/366<br>
+ UTC = timezone (always UTC)<br>
+ S = Daylight savings indicator, (S)TD, (D)ST, (O) transition into DST, (I) transition out of DST<br>
+ _ = Space<br>
+ HH = UTC hour 0 to 23<br>
+ : = Time delimiter, ':' if synced, Space if not<br>
+ MM = Minutes of current hour from 0 to 59<br>
+ : = Time delimiter, ':' if synced, Space if not<br>
+ SS = Seconds of current minute from 0 to 59<br>
+ mm = 10's milliseconds of the current second from 00 to 99<br>
+ L = Leap second pending at end of month, (I)nsert, (D)elete or Space<br>
+ +5 = UT1 correction, +/- .1 sec increments</p>
<p>Note that Model 325 reports a very similar output like Model 33X series. The driver for this clock is similar to Model 33X behavior. On a unmodified new ULM325 clock, the polling flag (flag1 =1) needs to be set.</p>
- <hr>
- <pre> The Model 320 timecode format is:
-
- <cr><lf>SQRYYYYDDD+HH:MM:SS.mmLT<cr>
-
- where:
-
- S = 'S' -- sync'd in last hour, '0'-'9' - hours x 10 since last update, else '?'
- Q = Number of correlating time-frames, from 0 to 5
- R = 'R' -- reception in progress, 'N' -- Noisy reception, ' ' -- standby mode
- YYYY = year from 1990 to 2089
- DDD = current day from 1 to 366
- + = '+' if current year is a leap year, else ' '
- HH = UTC hour 0 to 23
- MM = Minutes of current hour from 0 to 59
- SS = Seconds of current minute from 0 to 59
- mm = 10's milliseconds of the current second from 00 to 99
- L = Leap second pending at end of month -- 'I' = inset, 'D'=delete
- T = DST <-> STD transition indicators
- </pre>
- <p>Note that this driver does not do anything with the T flag.</p>
- <p>The M320 also has a 'U' command which returns UT1 correction information. It is not used in this driver.</p>
- <hr>
- <pre> The Model 33x timecode format is:
-
- S9+D 00 YYYY+DDDUTCS HH:MM:SSl+5
-
- Where:
-
- S = sync indicator S insync N not in sync
- the sync flag is WWVB decoder sync
- nothing to do with time being correct
- 9+ = signal level 0 thru 9+ If over 9 indicated as 9+
- D = data bit ( fun to watch but useless ;-)
- space
- 00 = hours since last GOOD WWVB frame sync
- space
- YYYY = current year
- + = leap year indicator
- DDD = day of year
- UTC = timezone (always UTC)
- S = daylight savings indicator
- space
- HH = hours
- : = This is the REAL in sync indicator (: = insync)
- MM = minutes
- : = : = in sync ? = NOT in sync
- SS = seconds
- L = leap second flag
- +5 = UT1 correction (sign + digit ))
- </pre>
- <p>This driver ignores UT1 correction,DST indicator,Leap year and signal level.</p>
- <hr>
+ <h4>Model 320 timecode format</h4>
+ <p><tt><cr><lf>SQRYYYYDDD+HH:MM:SS.mmLT<cr></tt></p>
+ <p>S = 'S' -- sync'd in last hour, '0'-'9' - hours x 10 since last update, else '?'<br>
+ Q = Number of correlating time-frames, from 0 to 5<br>
+ R = 'R' -- reception in progress,'N' -- Noisy reception, ' ' -- standby mode<br>
+ YYYY = year from 1990 to 2089<br>
+ DDD = current day from 1 to 366 + = '+' if current year is a leap year, else ' '<br>
+ HH = UTC hour 0 to 23<br>
+ MM = Minutes of current hour from 0 to 59<br>
+ SS = Seconds of current minute from 0 to 59<br>
+ mm = 10's milliseconds of the current second from 00 to 99<br>
+ L = Leap second pending at end of month -- 'I' = insert, 'D'=delete<br>
+ T = DST <-> STD transition indicators</p>
+ <p>Note that this driver does not do anything with the T flag. The M320 also has a 'U' command which returns UT1 correction information. It is not used in this driver.</p>
+ <h4>Model 33x timecode format</h4>
+ <p><tt>S9+D 00 YYYY+DDDUTCS HH:MM:SSl+5</tt></p>
+ <p>S = sync indicator S insync N not in sync the sync flag is WWVB decoder sync nothing to do with time being correct </p>
+ <p>9+ = signal level 0 thru 9+ If over 9 indicated as 9<br>
+ D = data bit (fun to watch but useless ;-) space<br>
+ 00 = hours since last GOOD WWVB frame sync space<br>
+ YYYY = current year + = leap year indicator<br>
+ DDD = day of year<br>
+ UTC = timezone (always UTC)<br>
+ S = daylight savings indicator space<br>
+ HH = hours : = This is the REAL in sync indicator (: = insync)<br>
+ MM = minutes : = : = in sync ? = NOT in sync<br>
+ SS = seconds<br>
+ L = leap second flag<br>
+ +5 = UT1 correction (sign + digit ))</p>
+ <p>This driver ignores UT1 correction, DST indicator,Leap year and signal level.</p>
<h4>Fudge factors</h4>
<p>flag1 polling enable (1=poll 0=no poll)</p>
<hr>
- <address><a href="mailto:frank.migge@oracle.com">mail</a></address>
- <!-- hhmts start -->Last modified: Mon Mar 8 10:12:08 PST 2004<!-- hhmts end -->
- <hr>
- <script type="text/javascript" language="javascript" src="Ultralink Clock_files/footer.txt"></script>
- </BODY>
- </head>
-
-</html>
\ No newline at end of file
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+</html>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
- <title>Spectracom 8170 and Netclock/2 WWVB Receivers</title>
+ <title> WWVB/GPS Receivers</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
- <h3>Spectracom 8170 and Netclock/2 WWVB Receivers</h3>
+ <h3>WWVB/GPS Receivers</h3>
<hr>
<h4>Synopsis</h4>
Address: 127.127.4.<i>u</i><br>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
<hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
-
</html>
\ No newline at end of file
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <title>Magnavox MX4200 GPS Receiver</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <title>Magnavox MX4200 GPS Receiver</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>Magnavox MX4200 GPS Receiver</h3>
- <hr>
- <h4>Synopsis</h4>
- Address: 127.127.9.<i>u</i><br>
- Reference ID: <tt>GPS</tt><br>
- Driver ID: <tt>GPS_MX4200</tt><br>
- Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 baud, 8-bits, no parity<br>
- Features: <tt>ppsclock</tt> (required)
- <h4>Description</h4>
- <p>This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. It requires the <tt>ppsclock</tt> line discipline or streams module described in the <a href="../ldisc.html">Line Disciplines and Streams Modules</a> page. It also requires a level converter such as described in the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
- <p>This driver supports all compatible receivers such as the 6-channel MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.</p>
- <p><a href="http://www.leica-gps.com/"><img src="../pic/9400n.jpg" alt="Leica MX9400N Navigator" height="143" width="180" align="left"></a> <a href="http://www.leica-gps.com/">Leica Geosystems</a> acquired the Magnavox commercial GPS technology business in February of 1994. They now market and support former Magnavox GPS products such as the MX4200 and its successors.</p>
- <br clear="LEFT">
- <p>Leica MX9400N Navigator.</p>
- <h4>Operating Modes</h4>
- <p>This driver supports two modes of operation, static and mobile, controlled by clock flag 2.</p>
- <p>In static mode (the default) the driver assumes that the GPS antenna is in a fixed location. The receiver is initially placed in a "Static, 3D Nav" mode, where latitude, longitude, elevation and time are calculated for a fixed station. An average position is calculated from this data. After 24 hours, the receiver is placed into a "Known Position" mode, initialized with the calculated position, and then solves only for time.</p>
- <p>In mobile mode, the driver assumes the GPS antenna is mounted on a moving platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic, 3D Nav" mode and solves for position, altitude and time while moving. No position averaging is performed.</p>
- <h4>Monitor Data</h4>
- <p>The driver writes each timecode as received to the <tt>clockstats</tt> file. Documentation for the <cite>NMEA-0183</cite> proprietary sentences produced by the MX4200 can be found in <a href="../mx4200data.html">MX4200 Receiver Data Format</a>.</p>
- <h4>Fudge Factors</h4>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
- <dt><tt>time2 <i>time</i></tt>
- <dd>Not used by this driver.
- <dt><tt>stratum <i>number</i></tt>
- <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
- <dt><tt>refid <i>string</i></tt>
- <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
- <dt><tt>flag1 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag2 0 | 1</tt>
- <dd>Assume GPS receiver is on a mobile platform if set.
- <dt><tt>flag3 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag4 0 | 1</tt>
- <dd>Not used by this driver.
- </dl>
- <h4>Additional Information</h4>
- <p><a href="../refclock.html">Reference Clock Drivers</a> </p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ <body>
+ <h3>Magnavox MX4200 GPS Receiver</h3>
+ <hr>
+ <h4>Synopsis</h4>
+ Address: 127.127.9.<i>u</i><br>
+ Reference ID: <tt>GPS</tt><br>
+ Driver ID: <tt>GPS_MX4200</tt><br>
+ Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 baud, 8-bits, no parity<br>
+ Features: <tt>ppsclock</tt> (required)
+ <h4>Description</h4>
+ <p>This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. This driver supports all compatible receivers such as the 6-channel MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.</p>
+ <p><a href="http://www.leica-gps.com/"><img src="../pic/9400n.jpg" alt="Leica MX9400N Navigator" height="143" width="180" align="left"></a> <a href="http://www.leica-gps.com/">Leica Geosystems</a> acquired the Magnavox commercial GPS technology business in February of 1994. They now market and support former Magnavox GPS products such as the MX4200 and its successors.</p>
+ <br clear="LEFT">
+ <p>Leica MX9400N Navigator.</p>
+ <h4>Operating Modes</h4>
+ <p>This driver supports two modes of operation, static and mobile, controlled by clock flag 2.</p>
+ <p>In static mode (the default) the driver assumes that the GPS antenna is in a fixed location. The receiver is initially placed in a "Static, 3D Nav" mode, where latitude, longitude, elevation and time are calculated for a fixed station. An average position is calculated from this data. After 24 hours, the receiver is placed into a "Known Position" mode, initialized with the calculated position, and then solves only for time.</p>
+ <p>In mobile mode, the driver assumes the GPS antenna is mounted on a moving platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic, 3D Nav" mode and solves for position, altitude and time while moving. No position averaging is performed.</p>
+ <h4>Monitor Data</h4>
+ <p>The driver writes each timecode as received to the <tt>clockstats</tt> file. Documentation for the <cite>NMEA-0183</cite> proprietary sentences produced by the MX4200 can be found in <a href="mx4200data.html">MX4200 Receiver Data Format</a>.</p>
+ <h4>Fudge Factors</h4>
+ <dl>
+ <dt><tt>time1 <i>time</i></tt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
+ <dt><tt>time2 <i>time</i></tt>
+ <dd>Not used by this driver.
+ <dt><tt>stratum <i>number</i></tt>
+ <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+ <dt><tt>refid <i>string</i></tt>
+ <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
+ <dt><tt>flag1 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag2 0 | 1</tt>
+ <dd>Assume GPS receiver is on a mobile platform if set.
+ <dt><tt>flag3 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag4 0 | 1</tt>
+ <dd>Not used by this driver.
+ </dl>
+ <h4>Additional Information</h4>
+ <p><a href="../refclock.html">Reference Clock Drivers</a> </p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<title>MX4200 Receiver Data Format</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ <link href="../scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
Example:<br>
<code>$PMVXG,830,T,1998,10,12,15:30:46,U,S,000298,00003,000000,01*02</code>
<hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ <script type="text/javascript" language="javascript" src="../scripts/footer.txt"></script>
</body>
</html>
\ No newline at end of file
<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
+ <br clear="left">
<h4>Related Links</h4>
<p>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
<br clear="left">
</p>
<h4>table of Contents</h4>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>ntp-keygen - Generate Public and Private Keys Files</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3><tt>ntp-keygen</tt> - Generate Public and Private Keys Files</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="25" locale="00000409" region="0" t="DateTime" w="61">20:57</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="306">Saturday, December 22, 2007</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#intro">Introduction</a>
+ <li class="inline"><a href="#host">Host and Sign Key Files</a>
+ <li class="inline"><a href="#cert">Certificate Files</a>
+ <li class="inline"><a href="#ident">Identity Scheme Files</a>
+ <li class="inline"><a href="#key">Symmetric Keys Files</a>
+ <li class="inline"><a href="#run">Running the Program</a>
+ <li class="inline"><a href="#cmd">Command Line Options</a>
+ <li class="inline"><a href="#fmt">File Formats</a>
+ <li class="inline"><a href="#bug">Bugs</a>
+ </ul>
+ <hr>
+ <h4 id="intro">Introduction</h4>
+ <p>Note: In order to support the MV identity scheme and provide for a trusted-agent function, the <tt>-p</tt>, and <tt>-q</tt> options have been changed in minor ways from previous versions. See the command line options for details.</p>
+ <p>This program generates cryptographic data files used by the NTPv4 authentication schemes. It generates MD5 key files used in symmetric key cryptography and, if the OpenSSL software library has been installed, generates files used in Autokey public key cryptography. All files are in printable ASCII format and can be embedded as attachments in mail to other sites and certificate authorities.</p>
+ <p>File names begin with the prefix <tt>ntpkey_</tt> and end with the postfix <tt><i>_name.filestamp</i></tt>, where <tt><i>name</i></tt> is the host or group name and <tt><i>filestamp</i></tt> is the NTP decimal seconds when the file was generated. This both guarantees uniqueness and simplifies maintenance procedures.</p>
+ <p>The host name for the host, sign and certificate files is specified by the <tt>-s</tt> option and must agree with the <tt>host</tt> option of the <tt>crypto</tt> configuration command. If this option is not specified, the string returned by the Unix <tt>gethostname()</tt> function is used. The group name for the identity files and certificate subject and issuer fields is specified by the <tt>-i</tt> option and must agree with the <tt>ident</tt> option of the <tt>crypto</tt> configuration command. If this option is not specified, the host name is used.</p>
+ <p>Files containing private data are encrypted with DES-CBC and the password specified by the <tt>-p</tt> option and must agree with the <tt>pw</tt> option of the <tt>crypto</tt> configuration command. If the <tt>-p</tt> option is not specified, the string returned by the Unix <tt>gethostname()</tt> function is used. However, private data files can be encrypted with the password specified by the <tt>-q</tt> option and redirected via the standard output stream to a file or another program. In a similar way the public data files can be redirected using the <tt>-e</tt> option.</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 can be changed by the <tt>keysdir</tt> configuration command.</p>
+ <h4 id="host">Host and Sign Key Files</h4>
+ <p>With the <tt>-H</tt> option the <tt>ntp-keygen</tt> program generates a new private host key file <tt>ntpkey_RSAkey_<i>hostname.filestamp </i></tt> and link <tt>ntpkey_host_<i>hostname</i></tt>. With the <tt>-S</tt> option the program generates a new private sign key file <tt>ntpkey_<i>keyname</i>sign_<i>hostname.filestamp</i></tt> and soft link <tt>ntpkey_sign_<i>hostname</i></tt>, where <i><tt>keyname</tt></i> is the name of the digest/signature scheme specified by the <tt>-S</tt> option, either <tt>RSA</tt> or <tt>DSA</tt>. If this option is not specified, the host key is used as the sign key.</p>
+ <h4 id="cert">Certificate Files</h4>
+ <p>The <tt>ntp-keygen</tt> program automatically generates a new self-signed X.509v3 public certificate <tt>ntpkey_<i>digest</i>cert_<i>hostname.filestamp</i></tt>, and soft link <tt>ntpkey_cert_<i>hostname</i></tt>, where <i><tt>digest</tt></i> is the name of the digest/signature scheme. All digest/signature schemes in the OpenSSL library are available; however, the scheme specified in the certificate must be compatible with the sign key.</p>
+ <p>With the <tt>-P</tt> option the program generates a private certificate including an X509v3 Extended Key Usage extension field with value <tt>private</tt>. Certificates generated without this option do not contain this field and are by default public.</p>
+ <p>With the <tt>-T</tt> option the program generates a trusted certificate including an 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 nontrusted.</p>
+ <h4 id="ident">Identity Scheme Files</h4>
+ <p>There are several optional identity schemes available with Autokey, including TC, PC, IFF, GQ and MV described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page. The IFF, GQ and MV schemes are based on a challenge-response exchange where the challenger uses public client parameters and the responder uses private server keys. For the IFF and GQ schemes the <tt>ntp-keygen</tt> program generates the server file <tt>ntpkey_<i>SCHEME</i>key_<i>groupname.filestamp</i></tt> and soft link <tt>ntpkey_<i>scheme</i>key_<i>groupname</i></tt>, where <tt><i>scheme</i></tt> is <tt>iff</tt> or <tt>gq</tt> with the <tt>-I </tt> or <tt>-G</tt> options, respectively. In these schemes the client file is not stored locally and must be redirected using the <tt>-e</tt> option.</p>
+ <p>In the MV scheme the keys are generated by a trusted agent (TA) which for security purposes is neither a server nor a client. With the <tt>-V</tt> option the program generates the TA keys file <tt>ntpkey_MVta_<i>hostname.filestamp</i></tt> and soft link <tt>ntpkey_mvta_<i>hostname</i></tt>. In this scheme the server and client files are not stored locally and must be redirected using the <tt>-q</tt> and <tt>-e</tt> options, respectively.</p>
+ <h4 id="key">Symmetric Keys Files</h4>
+ <p>With the <tt>-M</tt> option the <tt>ntp-keygen</tt> program generates a symmetric keys file <tt>ntpkey_MD5key_<i>hostname.filestamp</i></tt> and soft link <tt>ntpkey_md5key_<i>hostname</i></tt>. The file contains a list of 16 printable, semi-random MD5 keys compatible with previous NTP versions. It is in plaini text format, so additional keys can be added by hand. Since it is not encrypted, it should be visible only to root and distributed by secure means to other 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>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> option with the <tt>server</tt> or <tt>peer</tt> configuration command.</p>
+ <h4 id="run">Running the Program</h4>
+ <p>The safest way to run the <tt>ntp-keygen</tt> program is logged in directly as root. The recommended procedure is change to the keys directory, usually <tt>/ust/local/etc</tt>, then run the program. When run without options for the first time, or if all <tt>ntpkey</tt> files have been removed, the program generates an RSA host keys file and matching RSA-MD5 certificate file, which is all that is necessary in many cases. Additional information and examples are on the <a href="authopt.html">Authentication Options</a> page.</p>
+ <p>If run again, the program uses the same host, sign and identity files, but generates a new certificate file and link using the fields of the original certificate, but updating the issue and expire dates.</p>
+ <p>If the <tt>-M</tt> option is specified, all other options are ignored. The <tt>-I</tt>, <tt>-G</tt> and <tt>-V</tt> options work only with the <tt>-T</tt> option; a warning message is displayed otherwise. The <tt>-q</tt> and <tt>-e</tt> options work only if an identity scheme has been previously specified and in either case a new certificate is not generated. The recommended procedure is to specify all except these options in one invocation of the program and one of these options in a subsequent invocation.</p>
+ <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>
+ <dd>Specify the certificate digest/signature scheme. Note that RSA schemes must be used with a RSA sign key and DSA schemes must be used with a DSA sign key. If not specified, the scheme is <tt>RSA-MD5</tt>.
+ <dt><tt>-d</tt>
+ <dd>Enable debugging. This option displays cryptographic data produced in eye-friendly billboards.
+ <dt><tt>-e</tt>
+ <dd>Redirect the public client parameters to the standard output stream.<dt><tt>-G</tt>
+ <dd>Generate a new private server keys file for the GQ identity scheme.<dt><tt>-H</tt>
+ <dd>Generate a new private RSA host keys file.<dt><tt>-I</tt>
+ <dd>Generate a new private server keys file for the IFF identity scheme.<dt><tt>-i <i>name</i></tt>
+ <dd>Specify the group name for the identity file and certificate subject and issuer fields. If not specified, the host name is used as the group name.<dt><tt>-m <i>mod</i></tt>
+ <dd>Set the modulus for cryptographic keys to <tt><i>mod</i></tt> in the range 256-2048. If not specified, the modulus is 512. Caution: some schemes may not work with values other than 512 and some with larger values may produce unacceptably large network packets and may require unacceptably long times to compute.
+ <dt><tt>-M</tt>
+ <dd>Generate a new public keys file containing 16 MD5 semi-random keys.<dt><tt>-P</tt>
+ <dd>Generate a new private certificate file. If not specified, the program generates a public certificate file.<dt><tt>-p <i>password</i></tt>
+ <dd>Specify the read and write password for locally generated files to <tt><i>password</i></tt>. If not specified the host name is used as the password.<dt><tt>-q <i>password</i></tt>
+ <dd>Redirect the server keys file to the standard output stream encrypted using <tt><i>password</i></tt>.
+ <dt><tt>-S [ RSA | DSA ]</tt>
+ <dd>Generate a new sign keys file of the designated type. If not specified, the host key is used as the sign key.<dt><tt>-s <i>name</i></tt>
+ <dd>Specify the host name for the host, sign and certificate files. If not specified, the host name is the string returned by the Unix <tt>gethostname()</tt> function.
+ <dt><tt>-T</tt>
+ <dd>Generate a new trusted certificate file. By default, the program generates a nontrusted certificate file.<dt><tt>-V <i>nkeys</i></tt>
+ <dd>Generate a new private trusted-agent file for the Mu-Varadharajan (MV) identity scheme containing <tt><i>nkeys</i></tt> activation keys.
+ </dl>
+ <h4 id="fmt">File Formats</h4>
+ <p>All file formats begin with two lines. The first contains the file name, including the host/group name and filestamp, while the second contains the datestamp in conventional Unix <tt>date</tt> format. Empty lines and lines beginning with <tt>#</tt> are ignored. For all except the symmetric keys file, the cryptographic values are encoded first using ASN.1 encoding rules and then in PEM-encoded printable ASCII format preceded and followed by MIME content identifier lines.</p>
+ <p>Private/public key files and certificates are compatible with other OpenSSL applications and very likely other libraries as well. Certificates or certificate requests derived from them should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity files, although encoded as the other files, are probably not compatible with anything other than Autokey.</p>
+ <p>The format of the symmetric keys file is different than the other files for backward compatibility with the NTPv3 format and can be further customized using an ordinary text editor. The lines following the header contain 16 MD5 keys, one key per line. Since DES-CBC is deprecated in NTPv4, the only key format of interest is MD5 alphanumeric strings. Keys are entered one per line in the format</p>
+ <p><i><tt>keyno </tt></i><tt>MD5</tt><i><tt> key</tt></i></p>
+ <p>where <i><tt>keyno</tt></i> is an integer in the range 1-65,535 and <i><tt>key</tt></i> is the key itself, which is a string containing 16 characters or less. Each character is chosen from the 93 printable ASCII 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 program 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 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>
+
+</html>
\ No newline at end of file
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
- <meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>Trusted Hosts and Groups</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Trusted Hosts and Groups</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="25" locale="00000409" region="0" t="DateTime" w="61">00:12</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="299">Tuesday, November 08, 2005</csobj></p>
- <br clear="left">
- <h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
- <h4>Table of Contents</h4>
- <ul>
- <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="#rand">Random Seed File</a>
- <li class="inline"><a href="#fmt">Cryptographic Data Files</a>
- <li class="inline"><a href="#bug">Bugs</a>
- </ul>
- <hr>
- <h4 id="synop">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 TC identification. First, configure a NTP subnet including one or more low-stratum trusted hosts from which all other hosts derive synchronization directly or indirectly. Trusted hosts have trusted certificates; all other hosts have nontrusted certificates. These hosts will automatically and dynamically build authoritative certificate trails to one or more trusted hosts. A trusted group is the set of all hosts that have, directly or indirectly, a certificate trail ending at a trusted host. The trail is defined by static configuration file entries or dynamic means described on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
- <p>On each trusted host 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>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><i><tt> type</tt></i> option, where <i><tt>type</tt></i> is either <tt>RSA</tt> or <tt>DSA</tt>. The most often need to do this is when a DSA-signed certificate is used. If it is necessary to use a different certificate scheme than the default, run <tt>ntp-keygen</tt> with the <tt>-c <i>scheme</i></tt> option and selected <i><tt>scheme</tt></i> as needed. If <tt>ntp-keygen</tt> is run again without these options, it generates a new certificate using the same scheme and sign key.</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. However, if the host or sign key is changed, <tt>ntpd</tt> should be restarted. When ntpd is restarted, it loads any new files and restarts the protocol. Other dependent hosts will continue as usual until signatures are refreshed, at which time the protocol is restarted.</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 on the <a href="http://www.eecis.udel.edu/%7emills/keygen.html">Identification Schemes</a> page. These schemes are based on a TA, one or more trusted hosts and some number of nontrusted hosts. Trusted hosts prove identity using values provided by the TA, while the remaining hosts prove identity using values provided by a trusted host and certificate trails that end on that host. The name of a trusted host is also the name of its sugroup and also the subject and issuer name on its trusted certificate. The TA is not necessarily a trusted host in this sense, but often is.</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, trusted hosts and nontrusted hosts that operate as both server and client have parameter files that contain both server and client keys. Hosts that operate only as clients have key files that contain only client keys.</p>
- <p>The PC scheme supports only one trusted host in the group. On trusted host <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 trusted private certificate file <tt>ntpkey_RSA-MD5_cert_<i>alice.filestamp</i></tt>. Copy both files to all group hosts; they replace the files which would be generated in other schemes. 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 trusted host <i>alice</i>. In this scheme it is not possible to refresh either the keys or certificates without copying them to all other hosts in the group.</p>
- <p>For the IFF scheme proceed as in the TC scheme to generate keys and certificates for all group hosts, then for every trusted host in the group, generate the IFF parameter file. On trusted host <i>alice</i> run <tt>ntp-keygen -T </tt><tt>-I -p <i>password</i></tt> to produce her parameter file <tt>ntpkey_IFFpar_<i>alice.filestamp</i></tt>, which includes both server and client keys. Copy this file to all group hosts that operate as both servers and clients and install a soft link from the generic <tt>ntpkey_iff_<i>alice</i></tt> to this file. If there are no hosts restricted to operate only as clients, there is nothing further to do. As the IFF scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
- <p>If a rogue client has the parameter file, it could masquerade as a legitimate server and present a middleman threat. To eliminate this threat, the client keys can be extracted from the parameter file and distributed to all restricted clients. After generating the parameter file, on <i>alice</i> run <tt>ntp-keygen</tt> <tt>-e</tt> and pipe the output to a file or mail program. Copy or mail this file to all restricted clients. On these clients install a soft link from the generic <tt>ntpkey_iff_<i>alice</i></tt> to this file. To further protect the integrity of the keys, each file can be encrypted with a secret password.</p>
- <p>For the GQ scheme proceed as in the TC scheme to generate keys and certificates for all group hosts, then for every trusted host in the group, generate the IFF parameter file. On trusted host <i>alice</i> run <tt>ntp-keygen -T </tt><tt>-G -p <i>password</i></tt> to produce her parameter file <tt>ntpkey_GQpar_<i>alice.filestamp</i></tt>, which includes both server and client keys. Copy this file to all group hosts and install a soft link from the generic <tt>ntpkey_gq_<i>alice</i></tt> to this file. In addition, on each host <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>For the MV scheme, proceed as in the TC scheme to generate keys and certificates for all group hosts. For illustration assume <i>trish</i> is the TA, <i>alice</i> one of several trusted hosts and <i>bob</i> one of her clients. On TA <i>trish</i> run <tt>ntp-keygen </tt><tt>-V <i>n</i> -p <i>password</i></tt>, where <i>n</i> is the number of revokable keys (typically 5) to produce the parameter file <tt>ntpkeys_MVpar_<i>trish.filestamp </i></tt>and client key files <tt>ntpkeys_MVkey<i>d</i>_<i>trish.filestamp</i></tt> where <i><tt>d</tt></i> is the key number (0 < <i><tt>d</tt></i> < <i>n</i>). Copy the parameter file to <i>alice</i> and install a soft link from the generic <tt>ntpkey_mv_<i>alice</i></tt> to this file. Copy one of the client key files to <i>alice</i> for later distribution to her clients. It doesn't matter which client key file goes to <i>alice</i>, since they all work the same way. <i>Alice</i> copies the client key file to all of her cliens. On client <i>bob</i> install a soft link from generic <tt>ntpkey_mvkey_<i>bob </i></tt>to the client key file. As the MV scheme is independent of keys and certificates, these files can be refreshed as needed.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=windows-1252">
+ <title>Hints and Kinks</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <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.</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>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
- Trimble SV6 GPS receiver
If you want to add new clock types please check
- with kardel <AT> informatik.uni-erlangen.de. These files
+ with kardel@informatik.uni-erlangen.de. These files
implement the conversion of RS232 data streams into
timing information used by refclock_parse.c which is
mostly generic except for NTP configuration constants.
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
- <meta http-equiv="content-type" content="text/html;charset=windows-1252">
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
<title>SCO Unix hints</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ <link href="../scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
- <h1>SCO Unix hints</h1>
- <h2>Older SCO Unix versions</h2>
+ <h3>SCO Unix hints</h3>
+ <h4>Older SCO Unix versions</h4>
<p>NTP 4.0.x does not run on SCO Unix prior to version 3.2.5.0.0. If you need NTP on an older SCO Unix system and don't mind to modify your kernel, use 3.5.91 which has patches for SCO Unix 3.2.4.x. Apply the kernel modifications as described in <a href="http://www.echelon.nl/en/ntp/sco3-recipe.html">XNTP on SCO 3.2.4.2</a>.</p>
- <h2>Compiling NTP</h2>
+ <h4>Compiling NTP</h4>
<p>Delete the old SCO supplied NTP programs using the "custom" utility. Run the NTP configure program with CFLAGS="-b elf -K <i>processor-type</i>" for best results.</p>
- <h2>Running NTP</h2>
+ <h4>Running NTP</h4>
<p>Run "tickadj -As" after every reboot to set the variables "clock_drift" and "track_rtc" to the right values.</p>
<p>Run "ntpd" with a high negative nice-value, i.e. "nice --19 ntpd" for best results.</p>
- <h2>More information</h2>
+ <h4>More information</h4>
<p>More information on the way SCO Unix and NTP interact can be found in <a href="http://www.echelon.nl/en/ntp/ntp-on-sco.html">NTP on SCO Unix</a>, which includes links to precompiled versions of NTP.</p>
- <p><a href="mailto:kees@echelon.nl">Kees Hendrikse</a>, January 1999</p>
+ <p>Kees Hendrikse, January 1999</p>
</body>
</html>
\ No newline at end of file
<BODY BGCOLOR="#FFFFFF" LINK="#666699" ALINK="#FFFFFF">
-<TABLE WIDTH="623" BORDER="0">
+<TABLE WIDTH="623" BORDER="0" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD COLSPAN="2" VALIGN="TOP" WIDTH="623">
<IMG BORDER="0" SRC="/images/homebuy.gif" WIDTH="149" HEIGHT="32" ALT="Home * Buy * My Sun(sm)" USEMAP="#lefttop"><IMG BORDER="0" SRC="/images/globalnavbar.gif" WIDTH="474" HEIGHT="32" ALT="sun.com Global Sections" USEMAP="#topnav"></TD>
<!-- TITLEBAR IMAGE: INSERT CUSTOMIZED TITLEBAR IMAGE BELOW -->
- <A HREF="http://www.sun.com/"><IMG BORDER="0" SRC="/images/sunlogo.gif" WIDTH="149" HEIGHT="72" ALT="Sun Microsystems"></A><IMG BORDER="0" SRC="/images/titlebar/doc.title.gif" alt="gif" WIDTH="474" HEIGHT="72"></TD>
+ <A HREF="http://www.sun.com/"><IMG BORDER="0" SRC="/images/sunlogo.gif" WIDTH="149" HEIGHT="72" ALT="Sun Microsystems"></A><IMG BORDER="0" SRC="/images/titlebar/doc.title.gif" WIDTH="474" HEIGHT="72"></TD>
</TR>
<!-- Begin Search Elements -->
<TR VALIGN="top">
<TD BGCOLOR="#666699">
- <TABLE>
+ <TABLE BORDER="0" WIDTH="157" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD BGCOLOR="#666699" COLSPAN="2" WIDTH="157" VALIGN="TOP"><IMG BORDER="0" SRC="/images/search/contract/search1.gif" WIDTH="157" HEIGHT="16" ALT="Search SunSolve"></TD>
</TR>
<!-- End Search Elements -->
<!-- Begin User Personalization (Must limit to 10 Characters)-->
<TR>
- <TD COLSPAN="2"><TABLE><TR><TD COLSPAN="3" ALIGN="right"><IMG SRC="/images/home_con/welcom_1.gif" ALT="" WIDTH="156" HEIGHT="4" BORDER="0"></TD></TR>
+ <TD COLSPAN="2"><TABLE
BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="157"><TR><TD COLSPAN="3" ALIGN="right"><IMG SRC="/images/home_con/welcom_1.gif" ALT="" WIDTH="156" HEIGHT="4" BORDER="0"></TD></TR>
<TR><TD BGCOLOR="#333366"><IMG SRC="/images/home_con/welcom_2.gif" ALT="" WIDTH="17" HEIGHT="19" BORDER="0"></TD><TD BGCOLOR="#333366" VALIGN="middle"><NOBR><FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" COLOR="#99CC33" SIZE="-2">sopko</FONT></NOBR></TD><TD BGCOLOR="#333366" ALIGN="right"><A HREF="edit-user-form.pl?viewmode=contractuser"><IMG SRC="/images/home_con/welcom_3.gif" ALT="Edit" WIDTH="45" HEIGHT="19" BORDER="0"></A></TD></TR>
</TABLE>
</TD>
<IMG BORDER="0" SRC="/images/nav/p3.gif" WIDTH="157" HEIGHT="19" ALT="Y2K Central"></A><BR>
<A HREF="show.pl?target=security/sec" onmouseover="window.status='Security Information'; return true" onmouseout="window.status=''; return true">
<IMG BORDER="0" SRC="/images/nav/p2.gif" WIDTH="157" HEIGHT="19" ALT="Security Information"></A><BR>
-<br><table width="157">
+<br><table cellpadding="0" cellspacing="0" border="0" width="157">
<tr><td width="8"> </td><td width="149">
-<table>
+<table cellpadding="0" cellspacing="0" border="0">
<BR><tr><td><BR><img src="/images/line.gif" alt="------" width="140" height="11" border="0"><br>
<A HREF="mark.pl"
onmouseover="window.status='Marked Docs.';return true"
-<table width=100%>
+<table width=100% cellpadding=16 cellspacing=0 border=0>
<tr>
<td width=100% valign=top>
<CENTER><FONT FACE="Geneva, Helvetica, Arial, SunSans-Regular" SIZE="2">
<option value="#SRDB-ID">SRDB ID</option>
<option value="#OS">OS</option>
</select></div></form>
-<table width=100%>
+<table width=100% cellpadding=2 cellspacing=0 border=0>
<tr bgcolor=#666699><td><font size=2 color=#ffffff><b>SRDB ID</b></font></td>
<td bgcolor=#ffffff><font size=2> </font></td>
<td><font size=2 color=#ffffff><b>Synopsis</b></font></td>
<td><font size=2><b>4 Sep 1999</b></font></td>
</tr>
</table><br clear>
-<table width=100%><tr bgcolor=#999999>
+<table width=100% cellpadding=2 cellspacing=0 border=0><tr bgcolor=#999999>
<td><font size=2 color=#ffffff><b><a name=Problem-Description>Problem Description</a></b></font></td>
<td align=right><b><a href="#top"><font size=2 color=#ffffff>Top</font></a></b></td></tr></table>
<pre>Ever since upgrading to Solaris 2.6, the system clock has been drifting and
file. The system either was previously working fine with the freeware
xntpd or the configuration was copied from another system that was
using the freeware version.
--- 23-Apr-99 08:22 US/Eastern --</pre><table width=100%><tr bgcolor=#999999>
+-- 23-Apr-99 08:22 US/Eastern --</pre><table width=100% cellpadding=2 cellspacing=0 border=0><tr bgcolor=#999999>
<td><font size=2 color=#ffffff><b><a name=Problem-Solution>Problem Solution</a></b></font></td>
<td align=right><b><a href="#top"><font size=2 color=#ffffff>Top</font></a></b></td></tr></table>
<pre>The common lore for setting up xntpd on Solaris using
defaulkt behavior, having exactly the opposite effect
as that intended.
-Do not set <font color=red>dosynctodr</font> to 0.</pre><table width=100%>
+Do not set <font color=red>dosynctodr</font> to 0.</pre><table width=100% cellpadding=2 cellspacing=0 border=0>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Product-Area>Product Area</a></b></font></td>
<td bgcolor=#cccccc valign=top width=75%><font size=2>Bundled Network</font></td></tr>
<tr><td bgcolor=#999999 valign=top width=25%><font color=#ffffff size=2><b><a name=Product>Product</a></b></font></td>
<P>
Instead of the <I>tick</I> kernel variable, which many operating
systems use to control microseconds added to the system time every
-clock tick (c.f. <A HREF="../../notes.html#frequency_tolerance">Dealing
+clock tick (c.f. <A HREF="../notes.html#frequency_tolerance">Dealing
with Frequency Tolerance Violations</A>), Solaris has the variables
<I>nsec_per_tick</I> and <I>usec_per_tick</I>.
<P>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>vxWorks Port of NTP</title>
+ <link href="../scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+ <body link="#00008B" vlink="#8B0000">
+ <h4>VxWorks port of NTP</h4>
+ <p>Creating a port for vxWorks posed some problems. This port may help as a starting point for similar ports to real-time OS's and other embeddable kernels, particularly where <tt>main()</tt> is not allowed, and where the configure scripts need to be altered.</p>
+ <h4>Configuration issues</h4>
+ <p>I decided to do as little invasive surgery as possible on the NTP code, so I brought the vxWorks header tree in line with the standard Unix tree. The following changes were needed, as a side effect these changes will allow for easy porting of other autoconfigure enabled code.</p>
+ <p>Where I have 386 you will need to put in your target type. The vxWorks tree entry point is <tt>/usr/wind</tt>. If these are the same for your system, you should be able to cut and paste the changes.</p>
+ <p><blink>WARNING: Check you are not overwriting files, before entering the following: there should be no conflict, but check first...</blink></p>
+ <pre>
+ export CC="cc386 -nostdlib -m486 -DCPU=I80486 -I/usr/wind/target/h"
+ export RANLIB=ranlib386
+ export AR=ar386
+ export VX_KERNEL=/usr/wind/target/config/ims_std_bsp/vxWorks<br>
+
+ cd /usr/wind/target/sys
+ ln -s ../signal.h
+ ln -s ../time.h
+ ln -s socket.h sockio.h
+ ln -s ../selectLib.h select.h
+ ln -s ../timers.h
+ touch file.h param.h resource.h utsname.h var.h ../netdb.h ../a.out.h ../termios.h
+ echo " ******ADD #include \"sys/times.h\" to sys/time.h "
+ </pre>
+ The configure script must be changed in the following way to get the linking tests to work, once in the correct directory issue the following commands:
+
+ <pre> sed -e 's%main.*()%vxmain()%' configure > configure.vxnew
+ mv configure.vxnew configure
+ chmod 755 configure
+ </pre>
+ <p></p>The new version 4 of NTP requires some maths functions so it links in the maths library (-lm) in the <tt>./ntpd/Makefile.am</tt> file change the line <tt>ntpd_LDADD = $(LDADD) -lm</tt> by removing the "-lm".</p>
+ <p>>You are now ready to compile
+ <p>The ./configure.in file needed to be altered to allow for a host-target configuration to take place.</p>
+ <ul>
+ <li>The define SYS_VXWORKS was added to the compilation flags.
+ <li>Little endianess is set if the target is of type iX86.
+ <li>The size of char, integer, long values are all set. If Wind River ever changes these values they will need to be updated.
+ <li>clock_settime() is defined to be used for setting the clock.
+ <li>The Linking flags have -r added to allow for relinking into the vxWorks kernel
+ </ul>
+ <p>Unfortunately I have had to make use of the <tt>./include/ntp_machine.h</tt> file to add in the checks that would have been checked at linking stage by <tt>autoconf</tt>, a better method should be devised.</p>
+ <ul>
+ <li>There is now a <tt>NO_MAIN_ALLOWED</tt> define that simulates command line args, this allows the use of the normal startup sysntax.
+ <li>POSIX timers have been added.
+ <li>Structures normally found in <tt>netdb.h</tt> have been added with, the corresponding code is in <tt>./libntp/machines.c</tt>. Where possible the defines for these have been kept non-vxWorks specific.
+ </ul>
+ <p>Unfortunately there are still quite a few <tt>SYS_VXWORKS</tt> type defines in the source, but I have eliminated as many as possible. You have the choice of using the <tt>usrtime.a</tt> library avaliable from the vxworks archives or forgoing <tt>adjtime()</tt> and using the <tt>clock_[get|set]time()</tt>. The <tt>./include/ntp_machine.h</tt> file clearly marks how to do this.</p>
+ <h4>Compilation issues</h4>
+ <p>You will need autoconf and automake ... available free from the gnu archives worldwide.</p>
+ <p>The variable <tt>arch</tt> is the target architecture (e.g. i486)</p>
+ <pre>
+ mkdir A.vxworks)
+ cd A.vxworks
+ ../configure --target=arch-wrs-vxworks
+ make
+ </pre>
+ <p>Options I normally use are the <tt>--disable-all-clocks --enable-LOCAL-CLOCK</tt> flags. The program should proceed to compile without problem. The daemon ntpd, ntpdate, ntptrace, ntpdc, ntpq programs and of course the libraries are all fully ported. The other utilities are not, but they should be easy to port.</p>
+ <h4>Running the software</h4>
+ <p>Load in the various files, call them in the normal vxWorks function type manner. Here are some examples. Refer to the man pages for further information.</p>
+ <pre>
+ ld < ntpdate/ntpdate
+ ld < ntpd/ntpd
+ ld < ntptrace/ntptrace
+ ld < ntpq/ntpq
+ ld < ntpdc/ntpdc
+ ntpdate ("-b", "192.168.0.245")
+ sp(ntpd, "-c", "/export/home/casey/ntp/ntp.conf")
+ ntpdc("-c", "monlist", "192.168.0.244")
+ ntpq("-c", "peers", "192.168.0.244")
+ ntptrace("192.168.0.244")
+ </pre>
+ <p>Casey Crellin, casey@csc.co.za</p>
+ </body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>NTP on Windows NT</title>
+ <link href="../scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+ <body>
+ <h3>NTP 4.x for Windows NT</h3>
+
+ <h4>Introduction</h4>
+ <p>The NTP 4 distribution runs as service on Windows Vista, Windows NT 4.0, Windows 2000, Windows XP, Windows .NET Server 2003. It will NOT run on Windows 95, 98, ME, etc. The binaries work on multi-processor systems. This port has not been tested on the Alpha platform. This release now uses OpenSSL for authentication. IPv6 is not implemented yet for Win32 platforms. A ready-to-run install distribution is available from Meinberg at <a href="http://www.meinberg.de/english/sw/ntp.htm">http://www.meinberg.de/english/sw/ntp.htm</a></p>
+ <h4>Authentication Keys</h4>
+ <p>With this release ntp-keygen is supported. See the <a href="../keygen.html"> ntp keygen documentation</a> for details on how to use ntp-keygen.</p>
+ <p><tt>ntpd</tt> can now use the generated keys in the same way as on Unix platforms. Please refer to the <a href="../authopt.html">Authentication Options</a> for details on how to use these.</p>
+ <p><B>NOTE:</B> ntpd and <tt>ntp-keygen</tt> both use OpenSSL which requires a random
+ character file called <tt>.rnd</tt> by default. Both of these programs will automatically generate this file if they are not found. The programs will look for an environmental variable called RANDFILE and use that for the name of the random character file if the variable exists. If it does not exist it will look for an environmental variable called HOME and use that directory to search for a file called <tt>.rnd</tt> in that directory. Finally, if neither RANDFILE nor HOME exists it will look in <tt>C:\</tt> for a .rnd file. In each case it will search for and create the file if the environmental variable exists or in the C:\ directory if it doesn't.</p>
+ <p>Note that ntpd normally runs as a service so that the only way that it will have either RANDFILE or HOME defined is if it is a System environmental variable or if the service is run under a specific account name and that account has one of those variables defined. Otherwise it will use the file <tt>c:\.rnd</tt>. This was done so that OpenSSL will work normally on Win32 systems. This obviates the need to ship the OpenSSL.exe file and explain how to generate the .rnd file. A future version may change this behavior.</p>
+ <p>Refer to <a href="#Compiling">Compiling Requirements</a> and Instructions for how to compile the program.</p>
+ <h4>Reference Clocks</h4>
+ <p>Reference clock support under Windows NT is tricky because the IO functions are so much different. Some of the clock types have been built into the ntpd executable and should work but have not been tested by the ntp project. If you have a clock that runs on Win32 and the driver is there but not implemented on Win32 you will have make the required configuration changes in config.h and then build ntpd from source and test it. The following reference clock is known to work and is supported by Windows NT: <a href="../drivers/driver1.html">Type 1</a> Undisciplined Local Clock (LOCAL)</p>
+ <h4>Functions Supported</h4>
+ <p>All NTP functions are supported with some constraints. See the <a href="#ToDo">TODO list</a> below. Note that the ntptrace executable is not supported and you should use the PERL script version instead.</p>
+ <h4>Accuracy</h4>
+ <p>Greg Brackley has implemented a fantastic interpolation scheme that improves the precision of the NTP clock using a realtime thread (is that poetic or what!) which captures a tick count from the 8253 counter after each OS tick. The count is used to interpolate the time between operating system ticks.</p>
+ <p>On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds and synchronizes the clock to +/-500 microseconds using the <a href="http://www.trimble.com/products/ntp">Trimble Palisade</a> as UTC reference. This allows distributed applications to use the 10 milliseconds ticks available to them with high confidence.</p>
+ <h4>Binaries</h4>
+ <p>Recent InstallShield based executable versions of NTP for Windows NT (intel) are available from:</p>
+ <ul>
+ <li><a href="http://www.five-ten-sg.com/">http://www.five-ten-sg.com/</a>
+ </ul>
+ <h4 id="ToDo">ToDo</h4>
+ <p>These tasks are in no particular order of priority.</p>
+ <ul>
+ <li>Create a proper install/uninstall program
+ <li>Add sntp to the list of supported programs
+ <li>Add support for Visual C++ 7.0 or later (.NET)
+ <li>Add IPv6 support
+ <li>See if precision can be improved by using CPU cycle counter for tick interpolation.
+ <li>Make precision time available to applications using NTP_GETTIME API
+ </ul>
+ <h4>Compiling Requirements</h4>
+ <ul>
+ <li>Windows NT 4.0 Windows 2000, Windows XP, or Windows.NET Server 2003
+ <li>Microsoft Visual C++ 6.0. <B>NOTE</B>VC++ 7.0 (aka .NET) is not yet supported
+ but will probably work fine.
+ <li>Some way of uncompressing and untarring the gzipped tar file.
+ <li>OpenSSL must be built on the box before building NTP. Additional steps would
+ be required to not use OpenSSL.
+ </ul>
+ <a name="Compiling">Compiling Instructions</a>
+ <ol>
+ <li>Unpack and build OpenSSL according to the OpenSSL instructions for building on Windows. Currently the NTP build requires OpenSSL 0.9.7b as it looks for the path to that build for the include and libeay32.lib files. If you have a different version you will need to adjust both the preprocessor path and the link path to point to the correct locations of the include files and the lib file respectively.
+ <li>Unpack the NTP-4.x.tar.gz using utilities such as WinZip.
+ <li>Open the .\ports\winnt\ntp.dsw Visual C workspace
+ <li>Batch build all projects
+ <li>The built binaries can be found in the port\winnt\bin\Release subdirectory
+ <li>In addition you will need to install the OpenSSL libeay32.dll
+ <li>If you are shipping binaries in a kit it is strongly recommended that you ship this file (winnt.html) along with the binaries.
+ </ol>
+ <h4>Configuration File</h4>
+ <p>The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\. </tt>(%SystemRoot% is an environmental variable that can be determined by typing "set" at the "Command Prompt" or from the "System" icon in the "Control Panel").</p>
+ <p>Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt> file in the directory corresponding to your system installation. The older <tt><WINDIR>\ntp.conf</tt> is still supported but you will get a log entry reporting that the first file wasn't found.
+ <h4>Installation Instructions</h4>
+ <p>The <tt>instsrv</tt> program in the instsrv subdirectory of the distribution can be used to install 'ntpd' as a service and start automatically at boot time. Instsrv is automatically compiled with the rest of the distribution if you followed the steps above.</p>
+ <ol>
+ <li>Start a command prompt and enter "instsrv.exe <pathname_for_ntpd.exe>"
+ <li>Clicking on the "Services" icon in the "Control Panel" will display the list of currently installed services in a dialog box. The NetworkTimeProtocol service should show up in this list. Select it in the list and hit the "Start" button in the dialog box. The NTP service should start.
+ <li>You can also stop and start the service by typing net start|stop NetworkTimeProtocol at the DOS prompt.
+ <li>View the event log by clicking on the "Event Viewer" icon in the "Administrative Tools" group, there should be several successful startup messages from NTP. NTP will keep running and restart automatically when the machine is rebooted.
+ </ol>
+ <p>You can change the start mode (automatic/manual) and other startup parameters corresponding to the NTP service in the "Services" dialog box if you wish.</p>
+ <h4>Removing NTP</h4>
+ <p>You can also use <tt>instsrv</tt> to delete the NTP service by entering: <tt>>"instsrv.exe remove"</tt>
+ <h4>Command Line Parameters and Registry Entries</h4>
+ <p>Unlike the Unix environment, there is no clean way to run 'ntpdate' and reset the clock before starting 'ntpd' at boot time. NTP will step the clock up to 1000 seconds by default. While there is no reason that the system clock should be that much off during bootup if <tt>ntpd</tt> was running before, you may wish to override this default and/or pass other command line directives.
+ <p>Use the registry editor to edit the value for the ntpd executable under LocalMachine\System\CurrentControlSet\Services\NTP.</p>
+ <p>Add the -g option to the ImagePath key, behind "%INSTALLDIR>\ntpd.exe". This will force NTP to accept large time errors (including 1.1.1980 00:00)</p>
+ <h4>Bug Reports</h4>
+ <p>Send questions and bug reports to <a href="../bugs.html">NTP Bug Reporting Procedures</a>.</p>
+ <h4>Change Log</h4>
+ <h3>Last revision 2 July 2003 Version 4.2.0</h3>
+ <p>by Danny Mayer (mayer@ntp.org>)</p>
+ <h4>Significant Changes:</h4>
+ <p>This latest release of NTP constitutes a major upgrade to its ability to build and run on Windows platforms and should now build and run cleanly. More importantly it is now able to support all authentication in the same way as Unix boxes. This does require the usage of OpenSSL which is now a prerequisite for build on Windows. <tt>ntp-keygen</tt> is now supported and builds on Win32 platforms.
+ <h4>Last revision 16 February 1999 Version 4.0.99e.</h4>
+ <p>by Sven Dietrich (sven_dietrich@trimble.com)</p>
+ <p>pSignificant Changes:</p>
+ <ul>
+ <li>Perl 5 is no longer needed to compile NTP. The configuration script which creates version.c with the current date and time was modified by Frederick Czajka [w2k@austin.rr.com] so that Perl is no longer required.
+ </ul>
+ <h4>Last revision 15 November 1999 Version 4.0.98f.</h4>
+ <p>by Sven Dietrich (sven_dietrich@trimble.com)</b>
+ <p>ignificant Changes:</p>
+ <ul>
+ <li>Fixed I/O problem delaying packet responses which resulted in no-replys to NTPQ and others.
+ <li>The default configuration file path is <tt><WINDIR>\system32\drivers\etc\ntp.conf. The old <WINDIR>\ntp.conf </tt>is still supported but you will get a log entry reporting that the first file wasn't found. The NTP 3.x legacy <tt>ntp.ini</tt> file is no longer supported.
+ </ul>
+ <h4>Known Problems / TODO:</h4>
+ <ul>
+ <li>MD5 and name resolution do not yet get along. If you define MD5, you cannot use DNS names, only IP numbers.
+ </ul>
+ <h4>Last revision 27 July 1999 Version 4.0.95.</h4>
+ <p>This version compiled under WINNT with Visual C 6.0 by Greg Brackley and Sven Dietrich. Significant changes:</p>
+ <ul>
+ <li>Visual Studio v6.0 support
+ <li>Winsock 2.0 support
+ <li>Use of I/O completion ports for sockets and comm port I/O
+ <li>Removed the use of multimedia timers (from ntpd, others need removing)
+ <li>Use of waitable timers (with user mode APC) and performance counters to fake getting a better time
+ <li>Trimble Palisade NTP Reference Clock support
+ <li>General cleanup, prototyping of functions
+ <li>Moved receiver buffer code to a separate module (removed unused members from the recvbuff struct)
+ <li>Moved io signal code to a separate module
+ </ul>
+ <h4>Last revision: 20-Oct-1996</h4>
+ <p>This version corrects problems with building the XNTPversion 3.5-86 distribution under Windows NT. The following files were modified:</p>
+ <ul>
+ <li><tt>blddbg.bat</tt>
+ <li><tt>bldrel.bat</tt>
+ <li><tt>include\ntp_machine.h</tt>
+ <li><tt>xntpd\ntp_unixclock.c</tt>
+ <li><tt>xntpd\ntp_refclock.c</tt>
+ <li><tt>scripts\wininstall\build.bat</tt>
+ <li><tt>scripts\wininstall\setup.rul</tt>
+ <li><tt>scripts\wininstall\readme.nt</tt>
+ <li><tt>scripts\wininstall\distrib\ntpog.wri</tt>
+ <li><tt>html\hints\winnt</tt> (this file)
+ </ul>
+ <p>In order to build the entire Windows NT distribution you need to modify the file scripts\wininstall\build.bat with the installation directory of the InstallShield software. Then, simply type "bldrel" for non-debug or "blddbg" for debug executables.</p>
+ <p>Greg Schueman,
+ schueman@acm.org></p>
+ <h4>Last revision: 07-May-1996</h4>
+ <p>This set of changes fixes all known bugs, and it includes<br>
+ several major enhancements. Many changes have been made both to the build environment as well as the code. There is no longer an ntp.mak file, instead there is a buildntall.bat file that will build the entire release in one shot. The batch file requires Perl. Perl is easily available from the NT Resource Kit or on the Net.</p>
+ <p>The multiple interface support was adapted from Larry Kahn's work on the BIND NT port. I have not been able to test it, adequately as I only have NT servers with one network interfaces on which to test.</p>
+ <p>Enhancements:</p>
+ <ul>
+ <li>Event Logging now works correctly.
+ <li>Version numbers now work (requires Perl during build)
+ <li>Support for multiple network interface cards (untested)
+ <li>NTP.CONF now default, but supports ntp.ini if not found
+ <li>Installation procedure automated.
+ <li>All paths now allow environment variables such as %windir%
+ </ul>
+ <p>Bug fixes</p>
+ <ul>
+ <li>INSTSRV replaced, works correctly
+ <li>Cleaned up many warnings
+ <li>Corrected use of an uninitialized variable in XNTPD
+ <li>Fixed ntpdate -b option
+ <li>Fixed ntpdate to accept names as well as IP addresses
+ (Winsock WSAStartup was called after a gethostbyname())
+ <li>Fixed problem with "longjmp" in xntpdc/ntpdc.c that caused a software exception on doing a Control-C in xntpdc. A Cntrl-C now terminates the program.
+ </ul>
+ <p>See below for more detail</p>
+ <p>Note: SIGINT is not supported for any Win32 application including; Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior.</p>
+ <p>Possible enhancements and things left to do:</p>
+ <ul>
+ <li>Reference clock drivers for NT (at least Local Clock support)
+ <li>Control Panel Applet
+ <li>InstallShield based installation, like NT BIND has
+ <li>Integration with NT Performance Monitor
+ <li>SNMP integration
+ <li>Fully test multiple interface support
+ </ul>
+ <h4>Known problems:</h4>
+ <ul>
+ <li>bug in ntptrace - if no Stratum 1 servers are available, such as on an IntraNet, the application crashes.
+ </ul>
+ <h4>Last revision: 12-Apr-1995</h4>
+ <p>This NTPv3 distribution includes a sample configuration file and the project makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0 compiler. Also included is a small routine to install the NTP daemon as a "service" on a WindowsNT box. Besides xntpd, the utilities that have been ported are ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using a Bancomm TimeServe2000 GPS receiver clock that acts as a stratum 1 NTP server with no authentication (it has not been tested with any refclock drivers compiled in).
+ <p>Following are the known flaws in this port</p>
+ <ul>
+ <li>Currently, I do not know of a way in NT to get information about multiple network interface cards. The current port uses just one socket bound to INADDR_ANY address. Therefore when dealing with a multihomed NT time server, clients should point to the default address on the server (otherwise the reply is not guaranteed to come from the same interface to which the request was sent). Working with Microsoft to get this resolved.
+ <li>There is some problem with "longjmp" in xntpdc/ntpdc.c that causes a software exception on doing a Control-C in xntpdc. Be patient!> 3) The error messages logged by xntpd currently contain only the numerical error code. Corresponding error message string has to be looked up in "Books Online" on Visual C++ 2.0 under the topic "Numerical List of Error Codes".</ul>
+ <h4>Last HTML Update: November 17, 1999</h4>
+ <p>by Sven_Dietrich@Trimble.COM</p>
+ </body>
+
+</html>
<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>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:39</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">16:02</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#desc">Description</a>
</ul>
<hr>
<h4 id="desc">Description</h4>
- <p>NTP reference clock support maintains the fiction that the clock is actually an ordinary peer in the NTP tradition, but operating at a synthetic stratum of zero. The entire suite of algorithms used to filter the received data, select the best clocks or peers and combine them to produce a system clock correction operate just like ordinary NTP peers. In this way, defective clocks can be detected and removed from the peer population. As no packets are exchanged with a reference clock; however, the transmit, receive and packet procedures are replaced with separate code to simulate them.</p>
- <p>It is important to understand how the NTP clock driver interface works. The driver assumes three timescales: standard time maintained by a distant laboratory such as USNO or NIST, reference time maintained by the external radio and the system time maintained by NTP. The radio synchronizes reference time and frequency to standard time via radio, satellite or modem. As the transmission means may not always be reliable, most radios continue to provide clock updates for some time after signal loss using an internal reference oscillator. In such cases the radio may or may not reveal the time since last synchronized and/or the estimated time error.</p>
- <p>All three timescales run <i>only</i> in Coordinated Universal Time (UTC), 24-hour format, and are not adjusted for local timezone or standard/daylight time. The local timezone, standard/daylight indicator and year, if provided, are ignored. However, it is important to determine whether a leap second is to be inserted in the UTC timescale in the near future so NTP can insert it in the system timescale at the appropriate epoch.</p>
- <p>The NTP clock driver synchronizes the system time and frequency to the radio via serial or parallel port, PPS signal or other means. The driver routinely checks the radio timecode string or status indicators to determine whether it is operating correctly or not. If it is, the driver decodes the radio timecode in days, hours, minutes, seconds and nanoseconds and provides these data with the NTP receive timestamp corresponding to the on-time epoch of the timecode. The driver interface computes the difference between the timecode time and NTP timestamp and saves the difference in a circular buffer for later processing. Once each poll interval, usually 64 s, the driver provides ancillary data including leap bits and last reference time to the interface. The interface processes the circular buffer using a median/trimmed mean algorithm to extract the best estimate and provides this and the ancillary data to the clock filter as with ordinary NTP peers.</p>
- <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>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="build/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>
- <p>The general organization of a typical clock driver includes a receive-interrupt routine to read a timecode from the I/O buffer and convert to internal format, generally in days, hours, minutes, seconds and fraction. Some timecode formats include provisions for leap-second warning and determine the clock hardware and software health. The interrupt routine then calls <tt>refclock_process()</tt> with these data and the timestamp captured at the on-time character of the timecode. This routine saves each sample as received in a circular buffer, which can store from a few up to 60 samples, in cases where the timecodes arrive one per second.</p>
- <p>The <tt>refclock_transmit()</tt> routine in the interface is called by the system at intervals defined by the poll interval in the peer structure, generally 64 s. This routine in turn calls the transmit poll routine in the driver. In the intended design, the driver calls the <tt>refclock_receive()</tt> to process the offset samples that have accumulated since the last poll and produce the final offset and variance. The samples are processed by recursively discarding median outlyers until about 60 percent of samples remain, then averaging the surviving samples. When a reference clock must be explicitly polled to produce a timecode, the driver can reset the poll interval so that the poll routine is called a specified number of times at 1-s intervals.</p>
- <p>The interface code and this documentation have been developed over some time and required not a little hard work converting old drivers, etc. Should you find success writing a driver for a new radio or modem service, please consider contributing it to the common good. Send the driver file itself and patches for the other files to Dave Mills (mills@udel.edu).</p>
+ <p>NTP reference clock support maintains the fiction that the clock is actually an ordinary server in the NTP tradition, but operating at a synthetic stratum of zero. The entire suite of algorithms filter the received data and select the best sources to correct the system clock. No packets are exchanged with a reference clock; however, the transmit, receive and packet procedures are replaced with code to simulate them.</p>
+ <p>The driver assumes three timescales: standard time maintained by a distant laboratory such as USNO or NIST, reference time maintained by the external radio and the system time maintained by NTP. The radio synchronizes reference time via radio, satellite or modem. As the transmission means may not always be reliable, most radios continue to provide clock updates for some time after signal loss using an internal reference oscillator. In such cases the radio may or may not reveal the time since last synchronized or the estimated time error.</p>
+ <p>All three timescales run only in Coordinated Universal Time (UTC) and are not adjusted for local timezone or standard/daylight time. The local timezone, standard/daylight indicator and year, if provided, are ignored. However, it is important to determine whether a leap second is to be inserted in the UTC timescale in the near future so NTP can insert it in the system timescale at the appropriate epoch.</p>
+ <p>The interface routines in the <tt>ntp_refclock.c</tt> source file call the following driver routines via a transfer vector:</p>
+ <dl>
+ <dt><tt>startup</tt>
+ <dd>The association has just been mobilized. The driver may open the device(s) required.
+ <dt><tt>shutdown</tt>
+ <dd>The association is about to be demobilized. The driver should close all device(s) and free all structures.
+ <dt><tt>receive</tt>
+ <dd>A timecode string is ready for retrieval using the <tt>refclock_gtlin()</tt> or <tt>refclock_gtraw()</tt> routines.
+ <dt><tt>poll</tt>
+ <dd>Called at poll timeout, by default 64 s.
+ <dt><tt>timer</tt>
+ <dd>Called once per second.</dl>
+ <p>The receive routine retrieves a timecode string via serial or parallel port, PPS signal or other means. It decodes the timecode in days, hours, minutes, seconds and nanoseconds and checks for errors. It provides these data along with the on-time timestamp to the interface routine <tt>refclock_process()</tt>, which saves the computed offset in a 60-sample circular buffer. On occasion, either by timeout, sample count or call to the poll routine, the driver routine calls <tt>refclock_receive() </tt>to average the samples and update the system clock.</p>
+ <p>The best way to understand how the clock drivers work is to study one of the drivers already implemented, such as <tt>refclock_wwvb.c</tt>. The main interface is the <tt>refclockproc</tt> structure, which contains for most drivers the decoded timecode, on0time timestamp, reference timestamp, exception reports, statistics tallies, etc. The support routines are passed a pointer to the <tt>peer</tt> structure, which 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>Radio and modem reference clocks by convention have addresses of 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>u</i></tt> to the particular hardware device.</p>
+ <p>By convention, reference clock drivers are named in the form <tt>refclock_<i>xxxx</i>.c</tt>, where <tt><i>xxxx</i></tt> 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.</p>
<h4>Conventions, Fudge Factors and Flags</h4>
- <p>Most drivers support manual or automatic calibration for systematic offset bias using values encoded in the <tt>fudge</tt> configuration command. By convention, the <tt>time1</tt> value defines the calibration offset in seconds. For those drivers that support statistics collection using the <tt>filegen</tt> utility and the <tt>clockstats</tt> file, the <tt>flag4</tt> switch enables the utility. When a PPS signal is available, a special automatic calibration facility is provided. If the <tt>flag1</tt> switch is set and the PPS signal is actively disciplining the system time, the calibration value is automatically adjusted to maintain a residual offset of zero. Should the PPS signal or the prefer peer fail, the adjustment is frozen and the remaining drivers continue to discipline the system clock with a minimum of residual error.</p>
+ <p>Most drivers support manual or automatic calibration for systematic offset bias using values encoded in the <tt>fudge</tt> configuration command. By convention, the <tt>time1</tt> value defines the calibration offset in seconds. For those drivers that support statistics collection using the <tt>filegen</tt> utility and the <tt>clockstats</tt> file, the <tt>flag4</tt> switch enables the utility.</p>
+ <p>If the calibration feature has been enabled, the <tt>flag1</tt> switch is set and the PPS signal is actively disciplining the system time, the <tt>time1</tt> value is automatically adjusted to maintain a residual offset of zero. Once the its value has stabilized, the value can be inserted in the configuration file and the calibration feature disabled.</p>
<h4 id="file">Files Which Need to be Changed</h4>
- <p>A new reference clock implementation needs to supply, in addition to the driver itself, several changes to existing files.</p>
+ <p>When a new reference clock driver is installed, the following files need to be edited. Note that changes are also necessary to properly integrate the driver in the configuration and makefile scripts, but these are decidedly beyond the scope of this page.</p>
<dl>
<dt><tt>./include/ntp.h</tt>
<dd>The reference clock type defines are used in many places. Each driver is assigned a unique type number. Unused numbers are clearly marked in the list. A unique <tt>REFCLK_<i>xxxx</i></tt> identification code should be recorded in the list opposite its assigned type number.
<dd>The <tt>clocktypes</tt> array is used for certain control message displays functions. It should be initialized with the reference clock class assigned to the driver, as per the NTP specification RFC-1305. See the <tt>./include/ntp_control.h</tt> header file for the assigned classes.
<dt><tt>./ntpd/refclock_conf.c</tt>
<dd>This file contains a list of external structure definitions which are conditionally defined. A new set of entries should be installed similar to those already in the table. The <tt>refclock_conf</tt> array is a set of pointers to transfer vectors in the individual drivers. The external name of the transfer vector should be initialized in correspondence with the type number.
- <dt><tt>./configure.in</tt>
- <dd>This is a configuration file used by the autoconfigure scheme. Add lines similar to the following:
- <pre>
- AC_MSG_CHECKING(FOO clock_description)
- AC_ARG_ENABLE(FOO,
- AC_HELP_STRING([--enable-FOO], [x clock_description]),
- [ntp_ok=$enableval], [ntp_ok=$ntp_eac])
- if test "$ntp_ok" = "yes"; then
- ntp_refclock=yes
- AC_DEFINE(CLOCK_FOO, 1, [Foo clock?])
- fi
- AC_MSG_RESULT($ntp_ok)
-</pre>
- <dd>(Note that <tt>$ntp_eac</tt> is the value from <tt>--{dis,en}able-all-clocks</tt> for non-PARSE clocks and <tt>$ntp_eacp</tt> is the value from <tt>--{dis,en}able-parse-clocks</tt> for PARSE clocks. See the documentation on the autoconf and automake tools from the GNU distributions.)
- <dt><tt>./ntpd/Makefile.am</tt>
- <dd>This is the makefile prototype used by the autoconfigure scheme. Add the driver file name to the entries already in the <tt>ntpd_SOURCES</tt> list.
- <dd>Do the following sequence of commands:
- <pre>
- autoreconf
- configure
-</pre>
- <dd>or simply run <tt>make</tt>, which will do this command sequence automatically.
+
</dl>
<h4 id="intf">Interface Routine Overview</h4>
<dl>
<dd>This routine is used to shut down a clock and return its resources to the system.
<dt><tt>refclock_transmit</tt> - simulate the transmit procedure
<dd>This routine implements the NTP transmit procedure for a reference clock. This provides a mechanism to call the driver at the NTP poll interval, as well as provides a reachability mechanism to detect a broken radio or other madness.
- <dt><tt>refclock_sample</tt> - process a pile of samples from the clock
- <dd>This routine converts the timecode in the form days, hours, minutes, seconds, milliseconds/microseconds to internal timestamp format. It then calculates the difference from the receive timestamp and assembles the samples in a shift register. It implements a recursive median filter to suppress spikes in the data, as well as determine a rough dispersion estimate. A configuration constant time adjustment <tt>fudgetime1</tt> can be added to the final offset to compensate for various systematic errors. The routine returns one if success and zero if failure due to invalid timecode data or very noisy offsets.
- <dd>Note that no provision is included for the year, as provided by some (but not all) radio clocks. Ordinarily, the year is implicit in the Unix file system and hardware/software clock support, so this is ordinarily not a problem. Nevertheless, the absence of the year should be considered more a bug than a feature and may be supported in future.
+ <dt><tt>refclock_process</tt> - insert a sample in the circular buffer
+ <dd>This routine saves the offset computed from the on-time timestamp and the days, hours, minutes, seconds and nanoseconds in the circular buffer. Note that no provision is included for the year, as provided by some (but not all) radio clocks. Ordinarily, the year is implicit in the Unix file system and hardware/software clock support, so this is ordinarily not a problem.
<dt><tt>refclock_receive</tt> - simulate the receive and packet procedures
+
<dd>This routine simulates the NTP receive and packet procedures for a reference clock. This provides a mechanism in which the ordinary NTP filter, selection and combining algorithms can be used to suppress misbehaving radios and to mitigate between them when more than one is available for backup.
- <dt><tt>refclock_gtlin</tt> - groom next input line and extract timestamp
- <dd>This routine processes the timecode received from the clock and removes the parity bit and control characters. If a timestamp is present in the timecode, as produced by the <tt>tty_clk</tt> line discipline/streams module, it returns that as the timestamp; otherwise, it returns the buffer timestamp. The routine return code is the number of characters in the line.
- <dt><tt>refclock_open</tt> - open serial port for reference clock
- <dd>This routine opens a serial port for I/O and sets default options. It returns the file descriptor if success and zero if failure.
+ <dt><tt>refclock_gtraw</tt>, <tt>refclock_gtlin</tt> - read the buffer and on-time<dd>These routines return the data received from the clock and the on-time timestamp. The <tt>refclock_gtraw</tt> routine returns a batch of one or more characters returned by the Unix terminal routines in raw mode. The <tt>refclock_gtlin</tt> routine removes the parity bit and control characters and returns all the characters up to and including the line terminator. Either routine returns the number of characters delivered.<dt><tt>refclock_open</tt> - open a serial port for reference clock<dd>This routine opens a serial port for I/O and sets default options. It returns the file descriptor if success and zero if failure.
<dt><tt>refclock_ioctl</tt> - set serial port control functions
- <dd>This routine attempts to hide the internal, system-specific details of serial ports. It can handle POSIX (<tt>termios</tt>), SYSV (<tt>termio</tt>) and BSD (<tt>sgtty</tt>) interfaces with varying degrees of success. The routine sets up the <tt>tty_clk, chu_clk</tt> and <tt>ppsclock</tt> streams module/line discipline, if compiled in the daemon and requested in the call. The routine returns one if success and zero if failure.
- <dt><tt>refclock_control</tt> - set and/or return clock values
- <dd>This routine is used mainly for debugging. It returns designated values from the interface structure that can be displayed using ntpdc and the clockstat command. It can also be used to initialize configuration variables, such as <tt>fudgetimes, fudgevalues,</tt> reference ID and stratum.
- <dt><tt>refclock_buginfo</tt> - return debugging info
- <dd>This routine is used mainly for debugging. It returns designated values from the interface structure that can be displayed using <tt>ntpdc</tt> and the <tt>clkbug</tt> command.
+
+ <dd>This routine attempts to hide the internal, system-specific details of serial ports. It can handle POSIX (<tt>termios</tt>), SYSV (<tt>termio</tt>) and BSD (<tt>sgtty</tt>) interfaces with varying degrees of success. The routine returns one if success and zero if failure.
</dl>
<hr>
<center>
<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>
<p>Pleased to meet you.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">14:06</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="307">Wednesday, October 31, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:11</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="285">Saturday, January 19, 2008</csobj></p>
+ <p>Note: These pages are being updated and may appear a little scruffy for awhile.</p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
- <br clear="left">
+ <ul>A list of all links is on the <a href="sitemap.html">Site Map</a> page.
+ </ul>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a>
<li class="inline"><a href="#build">Building and Installing NTP</a>
<li class="inline"><a href="#conf">Configuring Clients and Servers</a>
- <li class="inline"><a href="#prog">Program Manual Pages</a>
- <li class="inline"><a href="#docs">Supporting Documentation</a>
- <li class="inline"><a href="#back">Background Information</a>
- <li class="inline"><a href="#app">Application Notes</a>
- </ul>
+ <li class="inline"><a href="#opt">Features and Options</a>
+ <li class="inline"><a href="#prob">Resolving Problems</a>
+ <li class="inline"><a href="#info">Further Information</a>
+ </ul>
<hr>
<h4 id="intro">Introduction</h4>
- <p>Note: The software contained in this distribution is available without charge under the conditions set forth in the <a href="copyright.html">Copyright Notice</a>.</p>
- <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 less than a millisecond on LANs and up to a few milliseconds on WANs relative to 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.</p>
- <p>This software release implements NTP Version 4 (NTPv4), but is in general backwards compatible with previous versions except NTP Version 1, support for which is no longer viable. NTPv4 includes support for both symmetric key and public key cryptography to prevent accidental or malicious protocol attacks, as well as automatic server discovery using IP multicast means. This release includes full support for the IPv6 address family, where the operating system supports it, as well as the IPv4 address family. Either or both families can be used at the same time on the same machine.</p>
- <p>Background information on computer network time synchronization can be found on the <a href="http://www.eecis.udel.edu/%7emills/exec.html">Executive Summary - Computer Network Time Synchronization</a> page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found on the <a href="release.html">NTP Version 4 Release Notes</a> page. Discussion on how NTP reckons the time can be found on the <a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a> page. Background information, bibliography and briefing slides suitable for presentations can be found on the <a href="http://www.eecis.udel.edu/%7emills/ntp.html">Network Time Synchronization Project</a> page. Additional information can be found at the NTP web site <a href="http://www.ntp.org">www.ntp.org</a>. Bugs can be reported <a href="bugs.html">here</a>.</p>
+ <p>Note: The NTP Version 4 software contained in this distribution is available without charge under the conditions set forth in the <a href="copyright.html">Copyright Notice</a>.</p>
+ <dl>
+ <dd>It is very important that readers understand that the NTP document collection began 25 years ago and remains today a work in progress. It has evolved as new features were invented and old features retired. It has been widely copied, cached and morphed to other formats, including man pages, with varying loss of fidelity. However, these HTML pages are the ONLY authoritative and definitive reference. Readers should always use the collection that comes with the distribution they use. A copy of the online collection at <a href="http://www.ntp.org">www.ntp.org</a> is normally included in the most recent snapshot, but might not agree with an earlier snapshot or release version.</dl>
+ <p>The Network Time Protocol (NTP) is widely used to synchronize a computer to Internet time servers or other sources, such as a radio or satellite receiver or telephone modem service. It provides accuracies typically less than a millisecond on LANs and up to a few milliseconds on WANs. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.</p>
+ <p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in early 2008 includes several thousand servers in most countries and on every continent of the globe, including Antarctica. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
+ <p>The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice. </p>
+ <p>Background information on computer network time synchronization is on the <a href="http://www.eecis.udel.edu/%7emills/exec.html">Executive Summary - Computer Network Time Synchronization</a> page. Discussion on new features and interoperability with previous NTP versions is on the <a href="release.html">NTP Version 4 Release Notes</a> page. Background information, bibliography and briefing slides suitable for presentations are on the <a href="http://www.eecis.udel.edu/%7emills/ntp.html">Network Time Synchronization Research Project</a> page. Additional information is at the NTP web site <a href="http://www.ntp.org">www.ntp.org</a>.</p>
<h4 id="build">Building and Installing NTP</h4>
- <p>NTP supports Unix and Windows (XP, NT4 and 2000) systems. The <a href="build/build.html">Building and Installing the Distribution</a> page presents an overview of the procedures for compiling the distribution and installing it on a typical client or server. The build procedures inspect the system hardware and software environment and automatically select the appropriate options for that environment. While these procedures work with most computers and operating systems marketed today, exceptions requiring manual intervention do exist, as documented on the <a href="build/config.html">Configuration Options</a> and <a href="release.html">Release Notes</a> pages.</p>
- <p>Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for over 40 radio and satellite receivers and modem services in both the US and Europe. A list of supported drivers is given on the <a href="refclock.html">Reference Clock Drivers</a> page. It is also possible to use an otherwise undisciplined machine as a primary or backup server, as described on the <a href="drivers/driver1.html">Undisciplined Local Clock</a> page. For most popular workstations marketed by Sun, Silicon Graphics and Hewlett Packard, as well as widely available Unix clones such as FreeBSD and Linux, the automatic build procedures select all drivers that run on the target machine. While this increases the size of the executable binary somewhat, individual drivers can be included or excluded using the configure utility documented in the Configuration Options page.</p>
- <p>Some programs included in this distribution use cryptographic algorithms to verify authenticity and credentials. Where local security policy permits relatively weak symmetric key cryptography, the required software is included in this distribution. However, where local policy requires stronger public key cryptography, additional software not in this distribution is required. This distribution uses the OpenSSL library available from <a href="http://www.openssl.org">http://www.openssl.org</a>. This library is also used by the Secure Shell facility, so is often already installed on Unix workstations and servers. It includes support for most message digest and digital signature algorithms used in the industry, as well as X.509 certificate generation, signing and verification.</p>
- <p>While public key cryptography is optional but highly recommended for all NTP operations, it is required for the NTPv4 Autokey protocol described on the <a href="http://www.eecis.udel.edu/%7emills/autokey.html">Autonomous Authentication</a> page and is an integral component of the generic automatic configuration scheme described on the <a href="http://www.eecis.udel.edu/%7emills/autocfg.html">Autonomous Configuration</a> page. In addition, access can be restricted in various ways described on the <a href="accopt.html">Access Control Options</a> page.</p>
+ <p>NTP supports Unix, VMS and Windows (Vista, XP, NT4 and 2000) systems. The <a href="build.html">Building and Installing the Distribution</a> page details the procedures for building and installing on a typical system. This distribution includes drivers for 44 radio and satellite receivers and telephone modem services in the US, Canada and Europe. A list of supported drivers is on the <a href="refclock.html">Reference Clock Drivers</a> page. The default build includes the debugging options and all drivers that run on the target machine; however, options and drivers can be included or excluded using options on the <a href="config.html">Configuration Options</a> page.</p>
<h4 id="conf">Configuring Clients and Servers</h4>
- <p>NTP is by its very nature a complex distributed network application and can be configured and used for a great many widely divergent timekeeping scenarios. The documentation presented on these pages attempts to cover the entire suite of configuration, operation and maintenance facilities which this distribution supports. However, most applications will need only a few of these facilities. If this is the case, the <a href="build/quick.html">Quick Start</a> page may be useful to get a simple workstation on the air with an existing server.</p>
- <p>However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called <tt>ntp.conf</tt>, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the <a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a> page. However, in many common cases involving simple network topologies and workstations, the configuration data can be specified entirely on the command line for the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>.</p>
- <p>The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. A discussion on the available modes is on the <a href="assoc.html">Association Management</a> page. NTP support for one or more computers is normally engineered as part of the existing public NTP synchronization subnet. The public subnet consists of a multiply redundant hierarchy of servers and clients, with each level in the hierarchy identified by stratum number. Primary servers operate at stratum one and provide synchronization to secondary servers operating at stratum two and so on to higher strata. In this hierarchy, clients are simply servers that have no dependents.</p>
- <p>Configuring a corporate or campus NTP subnet can be an engineering challenge. NTP contains many features designed to survive system and network failures, software bugs, clock errors and hacker attacks. Surviving these hazards requires intricate design of the timekeeping network using good principles of server redundancy and path diversity. The Manycast mode, new to NTPv4, is designed to track the current server and network states and adjust the client/server configuration for the best available accuracy and reliability. More information on the Manycast mode is on the <a href="authopt.html">Athentication Options</a> and <a href="manyopt.html">Automatic NTP Configuration Options</a> pages.</p>
- <p>The NTP subnet in 2007 includes several hundred public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, including Antarctica. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are several hundred public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total population estimated at over 25 million clients and servers in the public Internet. The current lists are maintained on the <a href="http://www.eecis.udel.edu/%7emills/ntp/index.html">Information on Time and Frequency Services</a> page, which is updated frequently. There are thousands upon thousands of private primary and secondary servers not normally available to the public, many hiding behind firewalls. Clients are strongly discouraged to use these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and unwanted traffic can bring up expensive ISDN lines, causing much grief and frustration. There are defensive means described on the Access Control Options page, including the Kiss-of-Death packet.</p>
+ <p>NTP is by its very nature a complex distributed network application and can be configured for widely divergent timekeeping scenarios. The documentation on these pages attempts to cover the entire suite of configuration, operation and maintenance features which this distribution supports. However, most applications will need only a few of these features. The <a href="quick.html">Quick Start</a> page may be useful to get a simple workstation on the air with existing servers.</p>
+ <p>The most important factor in providing accurate, reliable time is the selection of modes and servers in the configuration file. A discussion on the available modes is on the <a href="assoc.html">Association Management</a> page. The current public server list is maintained at the <a href="http://www.ntp.org">www.ntp.org</a> web site. In many cases the configuration can be automated using the schemes described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page.</p>
+ <h4 id="opt">Features and Options</h4>
+ <p>This distribution includes a statistics data recording facility which can record performance statistics and events of various types for retrospective analysis. These include time and frequency statistics, significant events and usage statistics described on the <a href="monopt.html">Monitoring Options</a> page.</p>
+ <p>Some programs included in this distribution use cryptographic algorithms to verify server authenticity. Where local security policy permits relatively weak symmetric key cryptography, the required software is included in this distribution. Where local policy requires stronger public key cryptography, the OpenSSL library available from <a href="http://www.openssl.org">http://www.openssl.org</a> is required. This library is also used by the Secure Shell facility, so is often already installed. NTP public key cryptography is described on the <a href="authopt.html">Authentication Options</a> page.</p>
+ <p>This distribution includes features that can restrict access in various ways as described on the <a href="accopt.html">Access Control Options</a> page. This can be used to deny service if not authenticated, deny service requiring persistent resources or deny service altogether.</p>
+ <p>This distribution includes a simulation framework in which substantially all the runtime NTP operations and most features can be tested and evaluated. This has been very useful in exploring invitro response to unusal circumstances or over time periods impractical invivo. Details are on the <a href="ntpdsim.html">Network Time Protocol (NTP) Simulator</a> page.</p>
<h4 id="prob">Resolving Problems</h4>
- <p>Like other things Internet, the NTP synchronization subnets tend to be large and devilishly intricate, with many opportunities for misconfiguration and network problems. The NTP engineering model is specifically designed to help isolate and repair such problems using an integrated management protocol, together with a suite of monitoring and debugging tools. There is an optional statistics data recording facility which can be used to record normal and aberrant operation, log problems to the system log facility, and retain records of client access. The <a href="debug.html">NTP Debugging Techniques</a> and <a href="build/hints.html">Hints and Kinks</a> pages contain useful information for identifying problems and devising solutions. In extreme cases, problems can be detected through the use of the <a href="ntpdsim.html"><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a> included in this software distribution.</p>
- <p>Users are requested to report bugs, offer suggestions and contribute additions to this distribution. The <a href="build/patches.html">Patching Procedures</a> page suggests procedures which greatly simplify distribution updates, while the <a href="build/porting.html">Porting Hints</a> page suggest ways to make porting this code to new hardware and operating systems easier. Additional information on reference clock driver construction and debugging can be found in the <a href="rdebug.html">Debugging Hints for Reference Clock Drivers</a> page.</p>
- <h4 id="prog">Program Manual Pages</h4>
- <ul>
- <li class="inline"><a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>
- <li class="inline"><a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>
- <li class="inline"><a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>
- <li class="inline"><a href="ntpdate.html"><tt>ntpdate</tt> - set the date and time via NTP</a>
- <li class="inline"><a href="ntptrace.html"><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a>
- <li class="inline"><a href="tickadj.html"><tt>tickadj</tt> - set time-related kernel variables</a>
- <li class="inline"><a href="ntptime.html"><tt>ntptime</tt> - read kernel time variables</a>
- <li class="inline"><a href="keygen.html"><tt>ntp-keygen</tt> - generate public and private keys</a>
- <li class="inline"><a href="ntpdsim_new.html"><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a>
- </ul>
- <h4 id="docs">Supporting Documentation</h4>
- <ul>
- <li class="inline"><a href="copyright.html">Copyright Notice</a>
- <li class="inline"><a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a>
- <li class="inline"><a href="release.html">NTP Version 4 Release Notes</a>
- <li class="inline"><a href="build/build.html">Building and Installing the Distribution</a>
- <li class="inline"><a href="build/config.html">Configuration Options</a>
- <li class="inline"><a href="refclock.html">Reference Clock Drivers</a>
- <li class="inline"><a href="debug.html">NTP Debugging Techniques</a>
- <li class="inline"><a href="rdebug.html">Debugging Reference Clock Drivers</a>
- <li class="inline"><a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a>
- <li class="inline"><a href="build/patches.html">Patching Procedures</a>
- <li class="inline"><a href="build/hints.html">Hints and Kinks</a>
- <li class="inline"><a href="build/porting.html">Porting Hints</a>
- </ul>
- <h4 id="back">Background Information</h4>
- <ul>
- <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/ntp.html">NTP Project and Reference Library</a>
- <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/exec.html">Executive Summary - Computer Network Time Synchronization</a>
- <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/y2k.html">The Network Time Protocol Timescale and Era Numbering</a>
- <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a>
- <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/biblio.html">Protocol Conformance Statement</a>
- </ul>
- <h4 id="app">Application Notes</h4>
- <ul>
- <li class="inline"><a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a>
- <li class="inline"><a href="assoc.html">Association Management</a>
- <li class="inline"><a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a>
- <li class="inline"><a href="measure.html">Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</a>
- <li class="inline"><a href="kern.html">Kernel Model for Precision Timekeeping</a>
- </ul>
+ <p>Like other things in modern Internet life, NTP problems can be devilishly intricate. This distribution includes a number of utilities designed to identify and repair problems using an integrated management protocol supported by the <a href="ntpq.html"><tt>ntpq</tt></a> utility program In addition, the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program can be useful in some cases.</p>
+ <p>The <a href="debug.html">NTP Debugging Techniques</a> and <a href="hints.html">Hints and Kinks</a> pages contain useful information for identifying problems and devising solutions. Additional information on reference clock driver construction and debugging is in the <a href="rdebug.html">Debugging Hints for Reference Clock Drivers</a> page.</p>
+ <p>Users are invited to report bugs and offer suggestions via the <a href="bugs.html">NTP Bug Reporting Procedures</a> page.</p>
+ <h4 id="info">Further Information</h4>
+ <p>The <a href="sitemap.html">Site Map</a> page contains a list of document collections arranged by topic. The Program Manual Pages collection may be the best place to start, followed by the Configuration Commands and Options collection. A great wealth of additional information is available via the External Links collection, including a book and numerous background papers and briefing presentations.</p>
<hr>
<div align="center">
<img src="pic/pogo1a.gif" alt="gif"></div>
<h3>Kernel Model for Precision Timekeeping</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">18:40</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:25</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="276">Tuesday, January 01, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/misc.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 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>
+ <p>The technical report [2], which is a revision and update of an earlier report [3], describes an engineering model for a precision clock discipline function for a generic operating system. The model is the same hybrid phase/frequecy-lock feedback loop used by <tt>ntpd</tt>, but implemented in the kernel. The code described in [2] is included in Solaris and Digital/Compaq/HP Tru64. It provides 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 in FreeBSD and is an option for Linux, SunOS and Tru64; however, of the options, only the Linux implementation, which does not include licensed code, is readily available. The software and documentation, including a simulator used to verify correct behavior, but not involving licensed code, is available from <a href="ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz">nanokernel.tar.gz</a>.</p>
+ <p>The kernel model also provides support for an external precision timing source, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The new system calls are used by the <a href="kernpps.html">PPSAPI interface</a> and in turn by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver (type 22) to provide synchronization limited in principle only by the accuracy and stability of the external timing source.</p>
<h4>References</h4>
<ol>
<li>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/%7emills/database/papers/nano/nano2.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.pdf">PDF</a>, Slides: <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.html">HTML</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ppt">PowerPoint</a>
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <title>PPSAPI Interface for Precision Time Signals</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>PPSAPI Interface for Precision Time Signals</h3>
+ <h4>Related Links</h4>
+ <p>
+ <script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
+ <br clear="left">
+ </p>
+ <hr>
+ <h4>Introduction</h4>
+ <p>RFC-2783 describes the PPSAPI application programming interface for external precision time signals, such as the pulse-per-second (PPS) signal generated by some radio clocks and cesium oscillators. The PPSAPI provides a generic capability in the ubiquitous Unix kernel which can be used for a wide variety of measurement applications, including network time synchronization and related experiments. 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 such as described on the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. In some systems a parallel port can be used for the same purpose.</p>
+ <p>The PPSAPI interface defined in RFC-2783 is the only PPS interface supported in NTP Version 4. The PPSAPI is supported in stock FreeBSD and, with the addition of the <tt>PPSkit</tt> kernel module, in Linux.</p>
+ <p>The special header file <tt>/usr/include/sys/timepps.h</tt> implements the PPSAPI using whatever primitives are available in each archeticture and operating system. It obsoletes previous APIs based on the <tt>tty_clock</tt> and <tt>ppsclock</tt> line disciplines and streams modules, which are no longer supported.</p>
+ <p>The <a href="drivers/driver22.html">PPS Clock Discipline</a> driver (type 22) uses the PPSAPI in conjunction with a local radio clock or remote NTP server as a reference clock. The driver can also use the PPSAPI as an interface directly to the kernel PPS facility as described on the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page.</p>
+ <h4>PPSAPI Application Program Interface</h4>
+ <p>The PPSAPI interface provides the following functions:</p>
+ <dl>
+ <dt><tt>time_pps_create</tt>
+ <dd>Creates a PPS interface instance and returns a handle to it.
+ <dt><tt>time_pps_destroy</tt>
+ <dd>Destroys a PPS interface and returns the resources used.
+ <dt><tt>time_pps_setparams</tt>
+ <dd>Sets the parameters associated with a PPS interface instance, including offsets to be automatically added to captured timestamps.
+ <dt><tt>time_pps_getparams</tt>
+ <dd>Returns the parameters associated with a PPS interface instance.
+ <dt><tt>time_pps_getcap</tt>
+ <dd>Returns the capabilities of the current interface and kernel implementation.
+ <dt><tt>time_pps_fetch</tt>
+ <dd>Returns the current timestamps associated with a PPS interface instance in either nanoseconds and nanoseconds (Unix <tt>timespec</tt>) or seconds and fraction (NTP) format.
+ <dt><tt>time_pps_kcbind</tt>
+ <dd>If kernel PPS processing is supported, this binds the support to the associated PPS interface instance.
+ </dl>
+ <p>The entire PPS interface functionality is currently provided by inline code in the <tt>timepps.h</tt> header file. While not all implementations support the full PPSAPI specification, they do support all the functions required for the PPS driver described next. The FreeBSD, Linux and Solaris implementations can be used with the stock kernels provided with those systems; however, the Tru64 and SunOS kernels require additional functions not provided in the stock kernels. Solaris users are cautioned that these functions operate improperly in Solaris versions prior to 2.8 with patch Generic_108528-02. Header files for other systems can be found via the web at <a href="ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz">nanokernel.tar.gz</a>.</p>
+<hr> <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="25" locale="00000409" region="0" t="DateTime" w="61">17:16</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="301">Monday, September 17, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">02:47</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="269">Sunday, January 20, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#synop">Synopsis</a>
<h4 id="synop">Synopsis</h4>
<p id="intro"><tt>ntp-keygen [ -cdeMPT ] [ -c [RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ] ] [ -H } [ -i <i>issuername</i> ] [ -p <i>passwd2</i> ] [ -q <i>passwd1</i> ] [ -S [ RSA | DSA ] ] [ -s <i>subjectame</i> ] [ -V <i>nkeys</i> ]</tt></p>
<h4 id="descrip">Description</h4>
- <p>This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It generates MD5 keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it generates encryption keys, certificates and identity keys used in the Autokey public key cryptography. 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.</p>
- <p>Generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates or certificate requests generated by this or other programs should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys files are probably not compatible with anything other than Autokey.</p>
- <p>Most files written by this program are encrypted using a private password. The <tt>-p <i>passwd2</i></tt> option specifies the write password and the <tt>-q <i>passwd2</i></tt> option the read password for previously encrypted files. If no read password is specified, the host name returned by the Unix <tt>gethostname()</tt> function is used. If no write password is specified, the read password is used as the write password.</p>
- <p>The <tt>ntpd</tt> configuration command <tt>crypto pw <i>passwd</i></tt> specifies the read password for previously encrypted files. This must match the write password used by this program. For convenience, if the <tt>ntpd</tt> password is not specified, the host name returned by the Unix <tt>gethostname()</tt> function is used. Thus, if files are generated by this program without password, they can be read back by <tt>ntpd</tt> without password, but only on the same host.</p>
+ <p>This program generates cryptographic data files used by the NTPv4 authentication and identity schemes. It generates MD5 keys used in symmetric key cryptography and, if the OpenSSL software library has been installed, it generates host keys, certificates and identity keys used in the Autokey public key cryptography. 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.</p>
+ <p>Generated files are compatible with other OpenSSL applications and other Public Key Infrastructure (PKI) resources. Certificates generated by this program should be compatible with extant industry practice, although some users might find the interpretation of X509v3 extension fields somewhat liberal. However, the identity keys are probably not compatible with anything other than Autokey.</p>
+ <p>Most files used by this program are encrypted using a private password. The <tt>-p</tt> option specifies the password for local files and the <tt>-q</tt> option the password for files to be sent to remote sites. If no local password is specified, the string returned by the Unix <tt>gethostname()</tt> function is used. If no remote password is specified, the local password is used.</p>
+ <p>The <tt>ntpd</tt> command <tt>crypto pw</tt> specifies the read password for previously encrypted files. This must match the local password used by this program. If not specified, the host name is used. Thus, if files are generated by this program without password, they can be read back by <tt>ntpd</tt> without password, but only on the same host.</p>
<p>All files and links 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 location of the keys directory can be changed by the <tt>keysdir</tt> configuration command. Normally, encrypted 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>This program directs commentary and error messages to the standard error stream <tt>stderr</tt> and
some files to the standard output stream <tt>stdout</tt> where they can be piped to other aplications or redirected to a file. The names used for generated files and links all begin with the string <tt>ntpkey</tt> and include the file type, generating host and filestamp, as described in the <a href="#fmt">Cryptographic Data Files</a> section below</p>
+ <p>This program directs commentary and error messages to the standard error stream <tt>stderr</tt> and
remote files to the standard output stream <tt>stdout</tt> where they can be piped to other aplications or redirected to a file. The names used for generated files and links all begin with the string <tt>ntpkey</tt> and include the file type, generating host and filestamp, as described in the <a href="#fmt">Cryptographic Data Files</a> section below</p>
<h4 id="run">Running the Program</h4>
- <p>The safest way to run this program is log in as root and change to the keys directory, usually <tt>/usr/local/etc. </tt>When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key file and matching RSA-MD5 certificate file. The file names and password default to the host name as described above. If run again with the same command line, the program uses the same host key file, but generates a new certificate file.</p>
- <p>Run the command on as many hosts as necessary. Designate one of them as the trusted host (TH) using the <tt>-T</tt> option on the command line and configure it to synchronize via reliable paths. THs have trusted, self-signed certificates; all other hosts have nontrusted, self-signed certificates. Then configure the nontrusted hosts to synchronize to the TH directly or indirectly. A certificate trail is created by asking the immediately ascendant host towards the root to sign its certificate, which is then provided to the immediately descendant host on request. All group hosts should have acyclic certificate trails ending on the TH.</p>
- <p>By default the name used in the subject and issuer fields in the certificate is the host name. A different name can be assigned using the <tt>-s <i>host</i></tt> option on the command line, but the name must match the host name specified by the <tt>crypto</tt> configuration command.</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. A different sign key file name can be assigned using the <tt>-S</tt> option 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>To test and gain experience with Autokey concepts, log in as root and change to the keys directory, usually <tt>/usr/local/etc. </tt>When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key and matching RSA-MD5 certificate with expiration date one year hence. If run again, the program uses the same host key, but generates a new certificate with new expiration date one year hence.</p>
+ <p>Run the command on as many hosts as necessary. Designate one of them as the trusted host (TH) using <tt>ntp-keygen</tt> with the <tt>-T</tt> option and configure it to synchronize from reliable Internet servers. Then configure the other hosts to synchronize to the TH directly or indirectly. A certificate trail is created when Autokey asks the immediately ascendant host towards the root to sign its certificate, which is then provided to the immediately descendant host on request. All group hosts should have acyclic certificate trails ending on the TH.</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. A different sign key can be assigned using the <tt>-S</tt> option 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 using the <tt>-c</tt> option.</p>
<h4 id="trust">Trusted Hosts and Secure Groups</h4>
- <p>As described on the <a href="authopt.html">Authentication Options</a> page, an NTP secure group consists of one or more low-stratum THs as the root from which all other group hosts derive synchronization directly or indirectly. For authentication purposes all THs in a group must have the same host and gtoup name; all other hosts have the same group name, but different host names. The host name and group name must match the names specified by the <tt>crypto</tt> configuratrion command. Host and group names are used only for authentication purposes and have nothing to do with DNS names.</p>
- <p>It is convenient to nominate a single TH acting as a trusted authority (TA) to generate a set of files and links that are then copied intact to all other THs in the group, most conveniently as a tar archive. This means that it doesn't matter which certificate trail ends at which TH, since the cryptographic media are the same.</p>
- <p>To generate and install cryptographic media files, The TA uses the</p>
- <p><tt>ntp-keygen -q <i>passwd</i> -s <i>host -</i>T</tt></p>
- <p>command to specify the password, host/group name and trusted certificate. For THs the host and group names are the same and must match the host and group names specified on the <tt>crypto</tt> configuration command. If run again with the same command line, the program uses the same host key file, but generates a new trusted certificate file. Group hosts other than the THs use the same command line, but with a different host name and without the <tt><i>-</i>T</tt> option. On these hosts if the <tt>-s <i>host</i></tt> option is missing, the host name is the default described above.</p>
+ <p>As described on the <a href="authopt.html">Authentication Options</a> page, an NTP secure group consists of one or more low-stratum THs as the root from which all other group hosts derive synchronization directly or indirectly. For authentication purposes all hosts in a group must have the same group name specified by the <tt>-i</tt> option and matching the <tt>crypto ident</tt> command option. The group name is used in the subject and issuer fields of trusted certificates and when constructing the file names for identity keys. All hosts must have different host names specified by the <tt>-s</tt> option and matching the <tt>crypto host</tt> command option. Host names are used in the subject and issuer fields of nontrusted certificates and when constructing the file names for host and sign keys and certificats. Host and group names are used only for authentication purposes and have nothing to do with DNS names.</p>
<h4 id="ident">Identity Schemes</h4>
- <p>As described on the <a href="authopt.html">Authentication Options</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require files specific to each scheme and group. There are two files for each scheme, an encrypted keys file and a nonencrypted parameters file. THs need only the keys file; all the others need the parameters file. Other hosts expecting to support a client population also need the keys file; hosts acting only as clients need only the parameters file. Both files are generated by the TA on behalf of all servers and clients in the group.</p>
- <p>The parameters files are public; they can be stored in a public place and sent in the clear. The keys files are encrypted with the host read password. To retrieve the keys file, a host sends a mail request to the TA including its private read password. The TA encrypts the keys file with this password and returns it as an attachment. The attachment is then copied intact to the keys directory with name given in the first line of the file, but all in lower case and with the filestamp deleted..</p>
- <p>The TA can generate GQ keys, certificate and identity files for all THs using the command</p>
- <p><tt>ntp-keygen -q <i>passwd</i> -s <i>host </i>-T -G -e ><i>parameters_file</i></tt></p>
- <p>where the the redirected <tt><i>parameters_file</i></tt> can be piped to a mail application or stored locally and renamed as above for later distribution. The procedure for IFF files is similar with <tt>-G</tt> replaced by <tt>-I</tt>.</p>
- <p>The TA can generate an encrypted GQ keys file copy using the command</p>
- <p><tt>ntp-keygen -q <i>passwd1</i> -p <i>passwd2 </i>-s <i>host </i>><i>keys_file</i></tt></p>
- <p>where <tt><i>passwd1</i></tt> is the read password for the TA, <tt><i>passwd2</i></tt> is the read password for the requesting host and <tt><i>keys_file</i></tt> is sent or stored as above. The program uses the keys and parameters of whatever scheme generated the keys file.</p>
+ <p>As described on the <a href="authopt.html">Authentication Options</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity keys specific to each scheme. There are two files for each scheme, an encrypted keys file and a nonencrypted parameters file. In general, servers use the keys file and clients use the parameters file. In general, servers expecting to support a client population ned the keys file while others need only the parameters file. Both files are generated by the TA on behalf of all servers and clients in the group.</p>
+ <p>The parameters files are public; they can be stored in a public place and sent in the clear. The keys files are encrypted with the local password. To retrieve the keys file, a host sends a mail request to the TA including its local password. The TA encrypts the keys file with this password and returns it as an attachment. The attachment is then copied intact to the keys directory with name given in the first line of the file, but all in lower case and with the filestamp deleted..</p>
+ <p>For example, the TA can generate IFF keys, trusted certificate and parameter using the command</p>
+ <p><tt>ntp-keygen -p <i>local_passwd</i><i> </i>-T -I -e ><i>parameters_file</i></tt></p>
+ <p>where the -e option redirects the <tt><i>parameters_file</i></tt> to the standard output stream for a mail application or stored locally for later distribution. </p>
<p><tt><i> </i></tt></p>
<h4 id="cmd">Command Line Options</h4>
<dl>
<dd>Select certificate and message digest/signature encryption scheme. Note that RSA schemes must be used with a RSA sign key and DSA schemes must be used with a DSA sign key. The default without this option is <tt>RSA-MD5</tt>.
<dt><tt>-d</tt>
<dd>Enable debugging. This option displays the cryptographic data produced for eye-friendly billboards.<dt><tt>-e</tt>
- <dd>Generate unencrypted IFF or GQ parameters file from existing key file <tt>IFFkey</tt>. or <tt>GQkey</tt> file, respectively. The file contents are sent to the standard output stream <tt>stdout</tt>..<dt><tt>-G</tt>
+ <dd>Generate unencrypted IFF or GQ parameters file from existing key file <tt>IFFkey</tt>. or <tt>GQkey</tt> file, respectively. The file contents are sent to the standard output stream <tt>stdout</tt>. Note: Unencrypted Q parameter files should be used with caution, as a host in possesion of this file can masquerade as a group member. Use the GQ encrypted keys fiie instead.<dt><tt>-G</tt>
<dd>Generate GQ key file <tt>GQkey </tt>and link <tt>gqkey </tt>for the Guillou-Quisquater (GQ) identity scheme.
<dt><tt>-H</tt>
<dd>Generate a new public/private host keys <tt>RSAkey</tt>, and link <tt>host</tt>.
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
- <title>Line Disciplines and Streams Modules</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Line Disciplines and Streams Modules</h3>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:40</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
- <h4>Related Links</h4>
- <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>
- <p>The <tt>tty_clk</tt> routine defines a new ioctl <tt>CLK_SETSTR</tt>, which takes a pointer to a string of no more than 32 characters. Until the first <tt>CLK_SETSTR</tt> is performed, the routine will simply pass through characters. Once it is passed a string by <tt>CLK_SETSTR</tt>, any character in that string will be immediately followed by a timestamp in Unix <tt>timeval</tt> format. You can change the string whenever you want by doing another <tt>CLK_SETSTR</tt>. The character must be an exact, 8 bit match. The character '\000' cannot, be used, as it is the string terminator. Passing an empty string to <tt>CLK_SETSTR</tt> turns off timestamping. Passing <tt>NULL</tt> may produce surprising results.</p>
- <h4><tt>TIOCDCDTIMESTAMP</tt> ioctl in FreeBSD</h4>
- <p>This ioctl is included in FreeBSD 2.2 and later. It causes a timestamp to be inserted in the serial port receive data stream when the data carrier detect (DCD) signal is asserted. This is useful for those radio clocks that indicate the on-time epoch by means of a modem control signal. It is not recommended that this be used for PPS timestamps, as this function is available using the PPS application program interface included in FreeBSD 3.4 and later.</p>
- <p>The <tt>TIOCDCDTIMESTAMP</tt> ioctl() is detected and compiled automatically on FreeBSD systems if available. With FreeBSD 2.2 the measured delay between activation of the DCD signal and the time the timestamp is captured on a 66MHz 486DX2 is 19 <font face="Symbol">m</font>s and on a 100MHz Pentium is 6 <font face="Symbol">m</font>s.</p>
- <h4><tt>ppsclock</tt>Streams Module (depredated)</h4>
- <p>This routine is a streams module which causes a timestamp to be captured when the DCD signal is asserted. It is normally used in connection with a PPS signal generated by some radio clocks. However, it is normally used only by the PPSAPI interface and SunOS 4.1.3 and should be avoided in other contexts. 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>
- <p>The ppsclock streams module implements the <tt>CIOGETEV</tt> ioctl, which takes a pointer to the structure</p>
- <pre>
-struct ppsclockev {
- struct timeval tv;
- u_int serial;
-};
-</pre>
- <p>The <tt>ppsclock</tt> module is pushed on the streams stack of the serial port connected to the DCD line. At each positive-going edge of the PPS signal, the routine latches the current local timestamp and increments a counter. At each <tt>CIOGETEV</tt> ioctl call, the current values of the timestamp and counter are returned in the <tt>ppsclockev</tt> structure.</p>
- <h4><tt>TIOCSPPS</tt> and <tt>TIOCGETPPSEV</tt> ioctls in Solaris</h4>
- <p>These ioctls are included in Solaris 2.4 and later. They implement the same function as the <tt>ppsclock</tt> streams module, but are implemented as integrated system calls independent of the streams facility. They are normally used in connection with a pulse-per-second (PPS) signal generated by some radio clocks. However, these ioctls are normally used only by the PPSAPI interface and should be avoided in other contexts. See the Sun documentation for the calling sequence and return values.</p>
- <p>Users are cautioned that these ioctls function improperly in Solaris versions prior to 2.8 with patch Generic_108528-02.</p>
- <h4><tt>tty_chu</tt> Line Discipline/Streams Module (depredated)</h4>
- <p>This routine is a special purpose line discipline for receiving a special timecode broadcast by Canadian time and frequency standard station CHU. It has been removed from the distribution since its function has been replaced by the <a href="drivers/driver7.html">Radio CHU Audio Demodulator/Decoder (type 7)</a> clock driver.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
<h3>Automatic Server Discovery Schemes</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="25" locale="00000409" region="0" t="DateTime" w="61">21:27</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="275">Tuesday, October 23, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:48</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="277">Friday, December 28, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#bcst">Broadcast/Multicast Scheme</a>
</ul>
<hr>
<h4 id="modes">Introduction</h4>
- <p>This page describes the automatic server discovery schemes provided in NTPv4. Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the other modes not directly involved in these schemes are described on the <a href="assocopt.html">Association Management</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">NTP Project</a> page.</p>
- <p>There are three types of associations in NTP: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>prempt</tt> option and are demobilized by timeout or error or when displaced by a "better" server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.</p>
- <p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described in the <a href="authopt.html">Authentication Options</a> page.</p>
- <p>There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and server pool described on this page. The broadcast/multicast and manycast schemes utilize the ubiquitous broadcast or one-to-many paradigm native to IPv4 and IPv6. The server pool scheme uses DNS to resolve multiple addresses of volunteer servers scattered throughout the world. </p>
- <p>Following is a summary of the operations of each scheme. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
+ <p>This page describes the automatic server discovery schemes provided in NTPv4. Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the other modes not directly involved in these schemes are described on the <a href="assoc.html">Association Management</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/%7emills/ntp.html">NTP Project</a> page.</p>
+ <p>There are three automatic server discovery schemes: broadcast/multicast, manycast and server pool described on this page. The broadcast/multicast and manycast schemes utilize the ubiquitous broadcast or one-to-many paradigm native to IPv4 and IPv6. The server pool scheme uses DNS to resolve addresses of multiple volunteer servers scattered throughout the world. All three schemes work in much the same way and might be described as <i>grab-n'-drop</i>. Through one means or another they grab at least the number of potential servers specified by the <tt>tos maxclock</tt> configuration command, order them from best to worst using the NTP algorithms, then cast off from the end of the list until no more than the number of survivors specified in the <tt>tos minclock</tt> command remain.</p>
+ <p>This process is handled using a set of counters, one for each preemptible association. Once each poll interval the counter is increased by one. It the counter reaches a cutoff value of 10, it is preempted and demobilized. However, the counters for the survivors at the beginning of the list are set to zero.</p>
+ <p>Any of the schemes can use a stratum filter to select just those servers with stratum considered useful. This can avoid large numbers of clients ganging up on a small number of low-stratum servers and avoid servers above a certain stratum level. The range of acceptable strata range from the number specified by the <tt>tos floor</tt> command, inclusive, to the number specified by the <tt>tos ceiling</tt> command, exclusive. Potential servers operating at the same stratum as the client will be avoided unless the <tt>tos cohort</tt> command is present.</p>
+ <p></p>
+ <p>Since an intruder can impersonate a broadcast or multicast server and inject false time values, broadcast mode should always be cryptographically authenticated.</p>
+ <p>Following is a summary of each scheme. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
<h4 id="bcst">Broadcast/Multicast Scheme</h4>
- <p>In operation a broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overriden by the <tt>minpoll</tt> and <tt>ttl</tt> options, respectively. Not all kernels support the <tt>ttl</tt> command.</p>
- <p>A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. The client then polls the server in client/server and iburst modes in order to quickly authenticate the server, set the host clock and calibrate the broadcast message propagation delay. This normally results in a volley of eight client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.</p>
- <p>Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to client messages, the client will time out and continue in listen-only mode with a default propagation delay.</p>
- <p>A server is configured in broadcast mode using the <tt>broadcast</tt> command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a <tt>broadcast</tt> command is needed for each address. This provides a way to limit exposure in a firewall, for example.</p>
- <p>A broadcast client is configured using the <tt>broadcastclient</tt> command. While a broadcast message can be received on any interface, the <tt>restrict</tt> command described on the Access Control Options can be used to filter out unwanted addresses. Since an intruder can impersonate a broadcast or multicast server and inject false time values, broadcast mode should always be cryptographically authenticated.</p>
- <h4 id="mult">Multicast Mode</h4>
- <p>NTP multicast mode can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa.</p>
- <p>The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
+ <p>A broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overriden by the <tt>minpoll</tt> and <tt>ttl</tt> options, respectively. Not all kernels support the <tt>ttl</tt> command. A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. It then polls the server in client/server mode and using the iburst opion in order to quickly authenticate the server, set the host clock and calibrate the broadcast message propagation delay. This normally results in a volley of six client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.</p>
+ <p>Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to these messages, the client will cease transmission and continue in listen-only mode with a default propagation delay. The volley can be avoided by using the <tt>authdelay</tt> configuration command with nonzero argument.</p>
+ <p>A server is configured in broadcast mode using the <tt>broadcast</tt> command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a <tt>broadcast</tt> command is needed for each address. This provides a way to limit exposure in a firewall, for example. A broadcast client is configured using the <tt>broadcastclient</tt> command. </p>
+ <p>NTP multicast mode can be used to extend the scope of a timekeeping using IPv4 multicast or IPv6 broadcast with defined span. The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
<p>A multicast server is configured using the <tt>broadcast</tt> command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the <tt>multicastclient</tt> command specifying a list of one or more multicast addresses. Note that there is a subtle distinction between the IPv4 and IPv6 address families. The IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For IPv6 the same distinction can be made using the link-local prefix FF02 for each interface and site-local prefix FF05 for all interfacesl.</p>
- <p>By design, multicast messages travel from the sender via a shortest-path or shared spanning tree to the receivers, which may require these messages emit from one or more local interfaces. It is possible to configure multiple multicast groups using multiple <tt>broadcast</tt> or <tt>multicastclient</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>
- <p>Broadcasting is the simplest way to provide automatic server discovery. It uses the multi-destination paradigm, where the subnet spanning tree is constructed automatically, either by the switches in an Ethernet LAN or the DVMRP or PIM protocols when spanning multiple networks.</p>
- <p>A broadcast or multicast server is mobilized by the broadcast configuration command. The addresses can be either from the IPv4 broadcast/mulitcast address family or the IPv6 address family. Multiple broadcast server associations can be specified for a single host.</p>
- <p>A host is enabled for broadcast reception using the <tt>broadcastclient</tt> configuration command, with or without the <tt>novolley</tt> option. Upon receiving the first message from a broadcast server, the client mobilizes an ephemeral client association and exchanges a volley of client/server messages in order to quickly authenticate the source, set the clock and measure the propagation delay, then reverts to listen-only mode. A multicast client is mobilized in the same way using the <tt>multicastclient</tt> configuration command and specified multicast group address.</p>
- <p>Broadcasting can be used with either symmetric key or public key cryptography. Public key cryptography offers the best protection against compromised keys and is generally considered stronger. By default, either of these two means is required, but this can be overridden by the <tt>disable auth</tt> command.</p>
- <p>In both broadcast and multicast client operations the client association is demobilized in case of error or timeout due to loss of server or connectivity. </p>
+ <p>In both broadcast and multicast versions the client association is demobilized in case of timeout.</p>
<h4 id="mcst">Manycast Scheme</h4>
- <p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating 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 client mobilizes associations with a given number of the "best" nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail.</p>
- <p>Note that the manycast paradigm does not coincide with the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p>
- <p>Manycasting can be used with either symmetric key or public key cryptography. Public key cryptography offers the best protection against compromised keys and is generally considered stronger. By default, either of these two means is required, but this can be overridden by the <tt>disable auth</tt> command.</p>
- <p>A manycast client association is configured using the <tt>manycastclient</tt> configuration command, which is similar to the <tt>server</tt> configuration command, but with a broadcast or multicast address. Depending on address family. The manycast client sends ordinary client mode messages, but with a broadcast address rather than a unicast address. It sends only if less than a given threshold of servers have been found and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. There can be as many manycast client associations as different broadcast addresses, each one serving as a template for a future unicast client/server association.</p>
- <p>Manycast servers configured with the <tt>manycastserver</tt> command listen on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies to the manycast client message with an ordinary unicast server message.</p>
- <p>The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. The client runs the NTP mitigation algorithms, which act to demobilize all but a threshold number of associations according to stratum and synchronization distance. The surviving associations then continue in ordinary client/server mode.</p>
- <p>If for some reason the number of available servers falls below the threshold, the manycast client resumes sending broadcast messages. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The strategy is determined by the <tt>tos</tt> and <tt>ttl</tt> configuration commands described below.</p>
+ <p>Manycast is a automatic server discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. It uses the grab-n'-drop paradigm with the additional feature that active means are used to grab additional servers should the number of survivors fall below the <tt>minclock</tt> threshold.</p>
+ <p>The manycast paradigm is not the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p>
+ <p>A manycast clients is configured using the <tt>manycastclient</tt> configuration command, which is similar to the <tt>server</tt> configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than <tt>minclock</tt> survivors remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for a future unicast client/server association.</p>
+ <p>A manycast server is configured using the <tt>manycastserver</tt> command, which listens on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies with an ordinary unicast server message.</p>
+ <p>The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. </p>
<p>It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.</p>
- <p>For example, consider an NTP subnet of two primary servers and several secondary servers and a number of dependent clients. With twoAll servers and clients have identical configuration files including both <tt>multicastclient</tt> and <tt>multicastserver</tt> commands using, for instance, multicast group address 239.1.1.1. Each primary server configuration file must include commands for the primary reference source such as a GPS receiver.</p>
- <p>The remaining configuration files for all secondary servers and clients have the same contents, except for the <tt>tos</tt> command, which is specific for each stratum level. For stratum 1 and stratum 2 servers, that command is not necessary. For stratum 3 and above servers the <tt>tos floor</tt> value is set to the intended stratum number. Thus, all stratum 3 configuration files use <tt>tos floor 3</tt>, all stratum 4 files use <tt>tos floor 4</tt> and so forth.</p>
- <p>Once operations have stabilized, the primary servers will find the primary reference source and each other, since they both operate at the same stratum (1), but not with any secondary server or client, since these operate at a higher stratum. The secondary servers will find the servers at the same stratum level. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.</p>
<h4 id="pool">Server Pool Scheme</h4>
- <p>bibbidt</p>
+ <p>The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several hundred operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers with the NTP mitigation algorithms.</p>
+ <p>To support this service the DNS for some volunteer servers as been modified to collect a number of the volunteer servers and return a randomized list in response to a query. The client receiving this list modbilizes some or all of them just as in the other discovery schemes and casts off the excess.</p>
+ <p>The pool scheme is configured using one or <tt>pool</tt> commands with the DNS name <tt><i>region</i>.pool.ntp.org</tt>, where <tt><i>region</i></tt> is a region of the world, country of the region or state of the country or even the whole world if absent. The <tt>pool</tt> command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to use a configuration file containing a single line <tt>pool.ntp.org</tt>.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
- <title>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</h3>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:41</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</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>
- <p>The usual data collected during a performance run of some experiment might include time offsets, time delays, frequency offsets and various error statistics. While time offsets between two clocks can be measured directly, frequency offsets can be estimated only from two or more time offsets made over some time interval in the experiment. In practice, a sequence of time comparisons can be performed over the lifetime of the experiment and the instantaneous frequency estimated either in real time with a recurrence relation, or retrospectively with a polynomial fit to the data.</p>
- <p>Estimating time and frequency errors in real time has been studied by a distinct subspecies of physicists who have made a career of the technology involved. Various means including autoregressive models, Kalman filters and simple weighted-average algorithms are used extensively by national standards laboratories to model cesium-clock ensembles. These techniques have been adapted to computer network and transmission engineering problems as well. This memorandum explores issues in performing experiments of this type and summarizes various techniques found useful in practice.</p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
\ No newline at end of file
<h3>Miscellaneous Options</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">20:47</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 15, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">22:42</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="290">Sunday, December 16, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<hr>
<dl>
<dt><tt>broadcastdelay <i>seconds</i></tt>
<dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31.
</dl>
<h4>Files</h4>
- <tt>ntp.drift</tt> frequency compensation (PPM)
+ <tt>ntp.drift</tt> frequency
+ <h4 id="leap">Leapseconds File</h4>
+ <p>The NIST provides a file documenting the epoch for all historic occasions of leap second insertion since 1972. The leapsecond table shows each epoch of insertion along with the offset of International Atomic Time (TAI) with respect to Coordinated Universal Time (UTC), as disseminated by NTP. The table can be obtained directly from NIST national time servers using <tt>ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.</p>
+ <p>While not strictly a security function, the Autokey protocol provides means to securely retrieve the leapsecond table from a server or peer. Servers load the leapsecond table directly from the file specified in the <tt>crypto</tt> command, with default <tt>ntpkey_leap</tt>, while clients can obtain the table indirectly from the servers using the Autokey protocol. Once loaded, the table can be provided on request to other clients and servers.</p>
+ <p>As explained in the <a href="authopt.html">Authentication Options</a> page, all cryptographically sound key generation schemes must have means to randomize the entropy seed used to initialize the internal random number generator. The OpenSSL library uses a designated random seed file for this purpose. The file must be available when starting the NTP daemon and the <tt>ntp-keygen</tt> program. If a site supports OpenSSL or its companion OpenSSH, it is very likely that means to do this are already available.</p>
+ <p> compensation (PPM)</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<h3>Monitoring Options</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">00:40</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="290">Sunday, December 24, 2006</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:44</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="256">Friday, January 11, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <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 <tt>./scripts</tt> 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>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#intro">introduction</a>
+ <li class="inline"><a href="#cmd">Monitoring Options</a>
+ <li class="inline"><a href="#types">File Set Types</a>
+ </ul> <hr>
+ <h4 id="intro">Introduction</h4>
+ <p><tt>ntpd</tt> includes a comprehensive monitoring facility which collects statistical data of various types and writes the data to files associated with each type at defined intervals. The files associated with a particular type are collectively called the generation file set for that type. The files in the file set are the members of that set.<p>File sets have names specific to the type and generation epoch. The names are constructed from three concatenated elements <i><tt>prefix</tt></i>, <i><tt>filename</tt></i> and <i><tt>suffix</tt></i>:</p>
+ <dl>
+ <dd><i><tt>prefix</tt></i>
+ <dd>The directory path specified in the <tt>statsdir</tt> command.
+ <dt><i><tt>name</tt></i>
+ <dd>The name specified by the <tt>file</tt> option of the <tt>filegen</tt> command.
+ <dt><i><tt>suffix</tt></i>
+ <dd>A string of elements bdginning with . (dot) followed by a string of elementes depending on the particular file set type.
+ </dl>
+ <p>Statistics files can be managed using scripts, examples of which are in the <tt>./scripts</tt> directory. Using these or similar scripts and Unix <tt>cron</tt> jobs, the files can be automatically summarized and archived for retrospective analysis.</p>
+ <h4 id="cmd">Monitoring Commands</h4>
<dl>
- <dt><tt>statistics <i>name</i> [...]</tt>
- <dd>Enables writing of statistics records. Currently, six kinds of <i><tt>name</tt></i>statistics are supported.
+ <dd><tt>filegen <i>name</i> file <i>filename</i> [type <i>type</i>] [link | nolink] [enable | disable]</tt>
+ <dl>
+ <dt><i><tt>name</tt></i>
+ <dd>Specifies the file set type from the list in the next section.
+ <dt><tt>file <i>filename</i></tt>
+ <dd>Specfies the file set name.
+ <dt><tt>type <i>typename</i></tt>
+ <dd>Specifies the file set interval. The following intervals are supported with default <tt>day</tt>:
<dl>
- <dt><tt>clockstats</tt>
- <dd>Enables recording of clock driver statistics information. Each update received from a clock driver appends a line of the following form to the file generation set named <tt>clockstats</tt>:
- <dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next field shows the clock address in dotted-quad notation, The final field shows the last timecode received from the clock in decoded ASCII format, where meaningful. In some clock drivers a good deal of additional information can be gathered and displayed as well. See information specific to each clock for further details.
+ <dt><tt>none</tt>
+ <dd>The file set is actually a single plain file.
+ <dt><tt>pid</tt>
+ <dd>One file set member is created for every incarnation of <tt>ntpd</tt>. . The file name suffix is the string .<tt>n</tt>, where <tt>n</tt> is the process ID of the <tt>ntpd</tt> server process.
+ <dt><tt>day</tt>
+ <dd>One file set member is created per day. A day is defined as the period between 00:00 and 24:00 UTC. The file name suffix is the string .<tt>yyyymmdd</tt>, where <tt>yyyy</tt> is the year, <tt>mm</tt> the month of the year and <tt>dd</tt> the day of the month. Thus, member created on 10 December 1992 would have suffix <tt>.19921210</tt>.
+ <dt><tt>week</tt>
+ <dd>One file set member is created per week. The week is defined as the day of year modulo 7. The file name suffix is the string .<tt>yyyyWww</tt>, where <tt>yyyy</tt> is the year, <tt>W</tt> stands for itself and <tt>ww</tt> the week number. For example, The member created on 10 January 1992 would have suffix <tt>.1992W1</tt>.
+ <dt><tt>month</tt>
+ <dd>One file set member is created per month. The file name suffix is the string .<tt>yyyymm</tt>, where <tt>yyyy</tt> is the year and <tt>mm</tt> the month of the year. For example, The member created on 10 January 1992 would have suffix <tt>.199201</tt>.
+ <dt><tt>year</tt>
+ <dd>One file set member is generated per year. The file name suffix is the string .<tt>yyyy</tt>, where <tt>yyyy</tt> is the year. For example, The member created on 1 January 1992 would have suffix <tt>.1992</tt>.<dt><tt>age</tt>
+ <dd>One file set member is generated every 24 hours of <tt>ntpd</tt> operation. The filename suffix is the string <tt>.adddddddd</tt>, where <tt>a</tt> stands for itself and <tt>dddddddd</tt> is the <tt>ntpd</tt> running time in seconds at the start of the corresponding 24-hour period.
+ </dl>
+ <dt><tt>link | nolink</tt>
+ <dd>It is convenient to be able to access the current file set members by file name, but without the suffix. This feature is enabled by <tt>link</tt> and disabled by <tt>nolink</tt>. If enabled, which is the default, a hard link from the current file set member to a file without suffix is created. When there is already a file with this name and the number of links to this file is one, it is renamed by appending a dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server process. When the number of links is greater than one, the file is unlinked. This allows the current file to be accessed by a constant name.
+ <dt><tt>enable | disable</tt>
+ <dd>Enable or disable the recording function, with default <tt>enable</tt>. These options are intended for remote configutation commands.
+ </dl>
+ <dt><tt>statsdir <i>directory_path</i></tt>
+ <dd>Specify the directory path prefix for statistics file names.
+ </dl>
+ <h4 id="types">File Set Types</h4>
+ <dl> <dt><tt>clockstats</tt>
+ <dd>Record reference clock statistics. Each update received from a reference clock driver appends one line to the <tt>clockstats</tt> file set:<dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>49213</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>525.624</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>127.127.4.1</tt></td>
+ <td>IP</td>
+ <td>reference clock address</td>
+ </tr>
+ <tr>
+ <td><tt><i>message</i></tt></td>
+ <td>text</td>
+ <td>log message</td>
+ </tr>
+ </table>
+ <p>The <tt><i>message</i></tt> field includes the last timecode received in decoded ASCII format, where meaningful. In some cases a good deal of additional information is displayed. See information specific to each reference clock for further details.</p>
<dt><tt>cryptostats</tt>
- <dd>This option requires the OpenSSL cryptographic software library. It enables recording of cryptographic public key protocol information. Each message received by the protocol module appends a line of the following form to the file generation set named <tt>cryptostats</tt>:
- <dd><tt>49213 525.624 127.127.4.1 <i>message</i></tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next field shows the peer address in dotted-quad notation, The final <tt><i>message</i></tt> field includes the message type and certain ancillary information. See the <a href="authopt.html">Authentication Options</a> page for further information.
+ <dd>Record significant events in the Autokey protocol. This option requires the OpenSSL cryptographic software library. Each event of the protocol module appends one line to the <tt>cryptostats</tt> file set:<dd><tt>49213 525.624 127.127.4.1 <i>message</i></tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>49213</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>525.624</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>127.127.4.1</tt></td>
+ <td>IP</td>
+ <td>source address</td>
+ </tr>
+ <tr>
+ <td><tt><i>message</i></tt></td>
+ <td>text</td>
+ <td>log message</td>
+ </tr>
+ </table>
+ <p>The <tt><i>message</i></tt> field includes the message type and certain ancillary information. See the <a href="authopt.html">Authentication Options</a> page for further information.</p>
<dt><tt>loopstats</tt>
- <dd>Enables recording of loop filter statistics information. Each update of the local clock outputs a line of the following form to the file generation set named <tt>loopstats</tt>:
- <dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806 6</tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next five fields show time offset (seconds), frequency offset (parts per million - PPM), RMS jitter (seconds), Allan deviation (PPM) and clock discipline time constant.
+ <dd>Record clock disiplilne loop statistics. Each system clock update appends one line to the <tt>loopstats</tt> file set:<dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806 6</tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>50935</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>75440.031</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>0.000006019</tt></td>
+ <td>s</td>
+ <td>clock offset</td>
+ </tr>
+ <tr>
+ <td><tt>13.778190</tt></td>
+ <td>PPM</td>
+ <td>frequency offset</td>
+ </tr>
+ <tr>
+ <td><tt>0.000351733</tt></td>
+ <td>hex</td>
+ <td>RMS jitter</td>
+ </tr>
+ <tr>
+ <td><tt>0.0133806</tt></td>
+ <td>PPM</td>
+ <td>RMS wander</td>
+ </tr>
+ <tr>
+ <td><tt>6 </tt></td>
+ <td>log<sub>2</sub> s</td>
+ <td>clock discipline loop time constant</td>
+ </tr>
+ </table>
<dt><tt>peerstats</tt>
- <dd>Enables recording of peer statistics information. This includes statistics records of all peers of a NTP server and of special signals, where present and configured. Each valid update appends a line of the following form to the current element of a file generation set named <tt>peerstats</tt>:
- <dt><tt>48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674</tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the peer address in dotted-quad notation and status, respectively. The status field is encoded in hex in the format described in Appendix B of the NTP specification RFC 1305. The final four fields show the offset, delay, dispersion and RMS jitter, all in seconds.
+ <dd>Record peer statistics. Each NTP packet or reference clock update received appends one line to the <tt>peerstats</tt> file set:<dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674</tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>48773</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>10847.650</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>127.127.4.1</tt></td>
+ <td>IP</td>
+ <td>source address</td>
+ </tr>
+ <tr>
+ <td><tt>128.4.1.20</tt></td>
+ <td>IP</td>
+ <td>destination address</td>
+ </tr>
+ <tr>
+ <td><tt>9714</tt></td>
+ <td>hex</td>
+ <td>status word</td>
+ </tr>
+ <tr>
+ <td><tt>-0.001605376</tt></td>
+ <td>s</td>
+ <td>clock offset</td>
+ </tr>
+ <tr>
+ <td><tt>0.000000000 </tt></td>
+ <td>s</td>
+ <td>roundtrip delay</td>
+ </tr>
+ <tr>
+ <td><tt>0.001424877</tt></td>
+ <td>s</td>
+ <td>dispersion</td>
+ </tr>
+ <tr>
+ <td><tt>0.000958674</tt></td>
+ <td>s</td>
+ <td>RMS jitter</td>
+ </tr>
+ </table>
+ <p>The status field is encoded in hex format as described in Appendix B of the NTP specification RFC 1305.</p>
<dt><tt>rawstats</tt>
- <dd>Enables recording of raw-timestamp statistics information. This includes statistics records of all peers of a NTP server and of special signals, where present and configured. Each NTP message received from a peer or clock driver appends a line of the following form to the file generation set named <tt>rawstats</tt>:
- <dt><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000</tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the remote peer or clock address followed by the local address in dotted-quad notation, The final four fields show the originate, receive, transmit and final NTP timestamps in order. The timestamp values are as received and before processing by the various data smoothing and mitigation algorithms.
+ <dd>Record timestamp statistics. Each NTP packet received appends one line to the <tt>rawstats</tt> file set:<dd><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000</tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>50928</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>2132.543</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>128.4.1.1</tt></td>
+ <td>IP</td>
+ <td>source address</td>
+ </tr>
+ <tr>
+ <td><tt>128.4.1.20</tt></td>
+ <td>IP</td>
+ <td>destination address</td>
+ </tr>
+ <tr>
+ <td><tt>3102453281.584327000</tt></td>
+ <td>NTP s</td>
+ <td>receive timestamp</td>
+ </tr>
+ <tr>
+ <td><tt>3102453281.586228000</tt></td>
+ <td>NTP s</td>
+ <td>transmit timestamp</td>
+ </tr>
+ <tr>
+ <td><tt>3102453332.540806000 </tt></td>
+ <td>NTP s</td>
+ <td>destination timestamp</td>
+ </tr>
+ </table>
<dt><tt>sysstats</tt>
- <dd>Enables recording of <tt>ntpd</tt> statistics counters on a periodic basis. Each hour a line of the following form is appended to the file generation set named <tt>sysstats</tt>:
- <dd><tt>50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147</tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The remaining ten fields show the statistics counter values accumulated since the last generated line.
- <dl>
- <dt>Time since restart <tt>36000</tt>
- <dd>Time in hours since the system was last rebooted.
- <dt>Packets received <tt>81965</tt>
- <dd>Total number of packets received.
- <dt>Packets processed <tt>0</tt>
- <dd>Number of packets received in response to previous packets sent
- <dt>Current version <tt>9546</tt>
- <dd>Number of packets matching the current NTP version.
- <dt>Previous version <tt>56</tt>
- <dd>Number of packets matching the previous NTP version.
- <dt>Bad version <tt>71793</tt>
- <dd>Number of packets matching neither NTP version.
- <dt>Access denied <tt>512</tt>
- <dd>Number of packets denied access for any reason.
- <dt>Bad length or format <tt>540</tt>
- <dd>Number of packets with invalid length, format or port number.
- <dt>Bad authentication <tt>10</tt>
- <dd>Number of packets not verified as authentic.
- <dt>Rate exceeded <tt>147</tt>
- <dd>Number of packets discarded due to rate limitation.
- </dl>
+ <dd>Record system statistics. Each hour one line is appended to the <tt>sysstats</tt> file set in the following format:<dd><tt>50928 2132.543 36000 81965 0 9546 56 512 540 10 147</tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>50928</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>2132.543</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>36000</tt></td>
+ <td>s</td>
+ <td>time since restart</td>
+ </tr>
+ <tr>
+ <td><tt>81965</tt></td>
+ <td>#</td>
+ <td>packets received last hour</td>
+ </tr>
+ <tr>
+ <td><tt>0</tt></td>
+ <td>#</td>
+ <td>server packets received last hour</td>
+ </tr>
+ <tr>
+ <td><tt>9546</tt></td>
+ <td>#</td>
+ <td>current version packets last hour</td>
+ </tr>
+ <tr>
+ <td><tt>56</tt></td>
+ <td>#</td>
+ <td>previous version packets last hour</td>
+ </tr>
+ <tr>
+ <td><tt>512</tt></td>
+ <td>#</td>
+ <td>access denied packets last hour</td>
+ </tr>
+ <tr>
+ <td><tt>540</tt></td>
+ <td>#</td>
+ <td>bad length or format packets last hour</td>
+ </tr>
+ <tr>
+ <td><tt>10</tt></td>
+ <td>#</td>
+ <td>bad authentication packets last hour</td>
+ </tr>
+ <tr>
+ <td><tt>147</tt></td>
+ <td>#</td>
+ <td>rate exceeded packets last hour</td>
+ </tr>
+ </table>
<dt><tt>timingstats</tt>
- <dd><b>ONLY</b> available when the deamon is compiled with process time debugging support (--enable-debug-timing - costs performance). Enables recording of <tt>ntpd</tt> processing time information for various selected code paths:
- <dd><tt>53876 36.920 10.0.3.5 1 0.000014592 input processing delay</tt>
- <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next field is a potential <tt>peer address</tt>, <tt>-</tt> or <tt>-REFCLOCK-</tt> depending on the associated io source. Then an event count for the number of processed events in the code path follows. The fifth field is the total time spend for the events. The rest of the line denotes the code path description (see source for more information).
- <dt><tt>statsdir <i>directory_path</i></tt>
- <dd>Indicates the full path of a directory where statistics files should be created (see below). This keyword allows the (otherwise constant) <tt>filegen</tt> filename prefix to be modified for file generation sets, which is useful for handling statistics logs.
- <dt><tt>filegen <i>name</i> [file <i>filename</i>] [type <i>typename</i>] [link | nolink] [enable | disable]</tt>
- <dd>Configures setting of generation file set <i>name</i>. Generation file sets provide a means for handling files that are continuously growing during the lifetime of a server. Server statistics are a typical example for such files. Generation file sets provide access to a set of files used to store the actual data. At any time at most one element of the set is being written to. The type given specifies when and how data will be directed to a new element of the set. This way, information stored in elements of a file set that are currently unused are available for administrational operations without the risk of disturbing the operation of <tt>ntpd</tt>. (Most important: they can be removed to free space for new data produced.)
- <dd>Note that this command can be sent from the <tt>ntpdc</tt> program running at a remote location.
- <dl>
- <dt><i><tt>name</tt></i>
- <dd>This is the type of the statistics records, as shown in the <tt>statistics</tt> command.
- </dl>
- <dd><tt>file <i>filename</i></tt>
- <dl>
- <dd>This is the file name for the statistics records. Filenames of set members are built from three concatenated elements <i><tt>prefix</tt></i>, <i><tt>filename</tt></i> and <i><tt>suffix</tt></i>:
- <dl>
- <dt><i><tt>prefix</tt></i>
- <dd>This is a constant filename path. It is not subject to modifications via the <tt>filegen</tt> option. It is defined by the server, usually specified as a compile-time constant. It may, however, be configurable for individual file generation sets via other commands. For example, the prefix used with <tt>loopstats</tt> and <tt>peerstats</tt> generation can be configured using the <tt>statsdir</tt> option explained above.
- <dt><i><tt>filename</tt></i>
- <dd>This string is directly concatenated to the prefix mentioned above (no intervening <tt>/</tt> (slash)). This can be modified using the <tt>file</tt> argument to the <tt>filegen</tt> statement. No <tt>..</tt> elements are allowed in this component to prevent filenames referring to parts outside the filesystem hierarchy denoted by <tt>prefix</tt>.
- <dt><i><tt>suffix</tt></i>
- <dd>This part is reflects individual elements of a file set. It is generated according to the type of a file set.
- </dl>
- </dl>
- <dd><tt>type <i>typename</i></tt>
- <dl>
- <dd>A file generation set is characterized by its type. The following types are supported:
- <dl>
- <dt><tt>none</tt>
- <dd>The file set is actually a single plain file.
- <dt><tt>pid</tt>
- <dd>One element of file set is used per incarnation of a <tt>ntpd</tt> server. This type does not perform any changes to file set members during runtime, however it provides an easy way of separating files belonging to different <tt>ntpd</tt> server incarnations. The set member filename is built by appending a <tt>.</tt> (dot) to concatenated <i>prefix</i> and <i>filename</i> strings, and appending the decimal representation of the process ID of the <tt>ntpd</tt> server process.
- <dt><tt>day</tt>
- <dd>One file generation set element is created per day. A day is defined as the period between 00:00 and 24:00 UTC. The file set member suffix consists of a <tt>.</tt> (dot) and a day specification in the form <tt>YYYYMMdd. YYYY</tt> is a 4-digit year number (e.g., 1992). <tt>MM</tt> is a two digit month number. <tt>dd</tt> is a two digit day number. Thus, all information written at 10 December 1992 would end up in a file named <tt><i>prefix filename</i>.19921210</tt>.
- <dt><tt>week</tt>
- <dd>Any file set member contains data related to a certain week of a year. The term week is defined by computing day-of-year modulo 7. Elements of such a file generation set are distinguished by appending the following suffix to the file set filename base: A dot, a 4-digit year number, the letter <tt>W</tt>, and a 2-digit week number. For example, information from January, 10th 1992 would end up in a file with suffix <tt>.1992W1</tt>.
- <dt><tt>month</tt>
- <dd>One generation file set element is generated per month. The file name suffix consists of a dot, a 4-digit year number, and a 2-digit month.
- <dt><tt>year</tt>
- <dd>One generation file element is generated per year. The filename suffix consists of a dot and a 4 digit year number.
- <dt><tt>age</tt>
- <dd>This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename suffix consists of a dot, the letter <tt>a</tt>, and an 8-digit number. This number is taken to be the number of seconds the server is running at the start of the corresponding 24-hour period. Information is only written to a file generation by specifying <tt>enable</tt>; output is prevented by specifying <tt>disable</tt>.
- </dl>
- </dl>
- <dd><tt>link | nolink</tt>
- <dl>
- <dd>It is convenient to be able to access the current element of a file generation set by a fixed name. This feature is enabled by specifying <tt>link</tt> and disabled using <tt>nolink</tt>. If <tt>link</tt> is specified, a hard link from the current file set element to a file without suffix is created. When there is already a file with this name and the number of links of this file is one, it is renamed appending a dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server process. When the number of links is greater than one, the file is unlinked. This allows the current file to be accessed by a constant name.
- </dl>
- <dd><tt>enable | disable</tt>
- <dl>
- <dd>Enables or disables the recording function.
- </dl>
+ <dd>(Only available when the deamon is compiled with process time debugging support (--enable-debug-timing - costs performance). Record processing time statistics for various selected code paths.<dd><tt>53876 36.920 10.0.3.5 1 0.000014592 input processing delay</tt>
+ <dd>
+ <table width="100%" border="1" cellspacing="2" cellpadding="0">
+ <tr>
+ <td>Item</td>
+ <td>Units</td>
+ <td>Description</td>
+ </tr>
+ <tr>
+ <td><tt>53876</tt></td>
+ <td>MJD</td>
+ <td>date</td>
+ </tr>
+ <tr>
+ <td><tt>36.920</tt></td>
+ <td>s</td>
+ <td>time past midnight</td>
+ </tr>
+ <tr>
+ <td><tt>10.0.3.5</tt></td>
+ <td>IP</td>
+ <td>server address</td>
+ </tr>
+ <tr>
+ <td><tt>1</tt></td>
+ <td>#</td>
+ <td>event count</td>
+ </tr>
+ <tr>
+ <td><tt>0.000014592</tt></td>
+ <td>s</td>
+ <td>total time</td>
+ </tr>
+ <tr>
+ <td><tt><i>message</i></tt></td>
+ <td>text</td>
+ <td>code path description (see source)</td>
+ </tr>
+ </table>
</dl>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </dl>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
-
</html>
<h3><tt>ntpd</tt> System Log Messages</h3>
<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 error codes, which is more than most of us do.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">15:20</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="307">Wednesday, October 31, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">01:09</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <p><script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <p><script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
</p>
<hr>
<p>You have come here because you found a cryptic message in the system log. This page by no means lists all messages that might be found, since new ones come and old ones go. Generally, however, the most common ones will be found here. They are listed by program module and log severity code in bold: <tt><b>LOG_ERR</b></tt>, <b><tt>LOG_NOTICE</tt></b> and <tt><b>LOG_INFO</b></tt>.</p>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
-<html>
-
- <head>
- <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
- <meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>Notes on setting up a NTP subnet</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <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)
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:44</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</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>
- <ul>
- <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/%7emills/database/rfc/rfc1305/rfc1305a.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305a.pdf">PDF</a>, Body: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305b.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305b.pdf">PDF</a>, Appendices: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.pdf">PDF</a>
- </ul>
- <p>Additional features have are described for <a href="release.html">NTP Version 4 Release Notes</a>. It also retains compatibility with both NTP Version 2, as defined in RFC-1119, and NTP Version 1, as defined in RFC-1059, although this compatibility is sometimes strained and only semiautomatic. In order to support in principle the ultimate precision of about 232 picoseconds in the NTP specification, <tt>ntpd</tt> uses NTP timestamp format for external communication and double precision floating point arithmetic internally. <tt>ntpd</tt> fully implements NTP Versions 2 and 3 authentication and in addition Version 4 autokey. It supports the NTP mode-6 control message facility along with a private mode-7 control- message facility used to remotely reconfigure the system and monitor a considerable amount of internal detail. As extensions to the specification, a flexible address-and-mask restriction facility has been included.</p>
- <p>The code is biased towards the needs of a busy time server with numerous, often hundreds, of clients and other servers. Tables are hashed to allow efficient handling of many associations, though at the expense of additional overhead when the number of associations is small. Many fancy features have been included to permit efficient management and monitoring of a busy primary server, features which are probably excess baggage for a high stratum client. In such cases, a stripped-down version of the protocol, the Simple Network Time Protocol (SNTP) can be used. SNTP and NTP servers and clients can interwork in most situations, as described in: Mills, D.L. Simple Network Time Protocol (SNTP). Network Working Group Report RFC-2030, University of Delaware, October 1996, 14 pp. <a href="http://www.eecis.udel.edu/%7emills/database/rfc2030.txt">(ASCII)</a>.</p>
- <p>The code was written with near demonic attention to details which can affect precision and as a consequence should be able to make good use of high performance, special purpose hardware such as precision oscillators and radio clocks. The present code supports a number of radio clocks, including those for the WWV, CHU, WWVB, MSF, DCF77, GOES and GPS radio and satellite time services and USNO, ACTS and PTB modem time services. It also supports the IRIG-B and IRIG-E signal format connected via an audio codec. The server methodically avoids the use of Unix-specific library routines where possible by implementing local versions, in order to aid in porting the code to perverse Unix and non-Unix platforms.</p>
- <p>While this implementation conforms in most respects to the NTP Version 3 specification RFC-1305, a number of improvements have been made which are described in the conformance statement in the <a href="http://www.eecis.udel.edu/%7emills/biblio.html">NTP Protocol Conformance Statement</a> page. It has been specifically tuned to achieve the highest accuracy possible on whatever hardware and operating-system platform is available. In general, its precision and stability are limited only by the characteristics of the onboard clock source used by the hardware and operating system, usually an uncompensated crystal oscillator. On modern RISC-based processors connected directly to radio clocks via serial-asynchronous interfaces, the accuracy is usually limited by the radio clock and interface to the order of a millisecond or less. The code includes special features to support a pulse-per-second (PPS) signal and/or an IRIG-B signal generated by some radio clocks. When used in conjunction with a suitable hardware level converter, the accuracy can be improved to a few tens of microseconds. Further improvement is possible using an outboard, stabilized frequency source, in which the accuracy and stability are limited only by the characteristics of that source.</p>
- <p>The NTP Version 4 distribution includes, in addition to the daemon itself (<tt><a href="ntpd.html">ntpd</a></tt>), several utility programs, including two remote-monitoring programs (<a href="ntpq.html"><tt>ntpq</tt></a>, <tt><a href="ntpdc.html">ntpdc</a></tt>), a remote clock-setting program similar to the Unix rdate program (<tt>ntpdate</tt>), a traceback utility useful to discover suitable synchronization sources (<tt>ntptrace</tt>), and various programs used to configure the local platform and calibrate the intrinsic errors. NTP has been ported to a large number of platforms, including most RISC and CISC workstations and mainframes manufactured today. Example configuration files for many models of these machines are included in the distribution. While in most cases the standard version of the implementation runs with no hardware or operating system modifications, not all features of the distribution are available on all platforms. For instance, a special feature allowing Sun workstations to achieve accuracies in the order of 100 microseconds requires some minor changes and additions to the kernel and input/output support.</p>
- <p>There are, however, several drawbacks to all of this. <tt>ntpd</tt> is quite fat. This is rotten if your intended platform for the daemon is memory limited. <tt>ntpd</tt> uses <tt>SIGIO</tt> for all input, a facility which appears to not enjoy universal support and whose use seems to exercise the parts of your vendors' kernels which are most likely to have been done poorly. The code is unforgiving in the face of kernel problems which affect performance, and generally requires that you repair the problems in order to achieve acceptable performance. The code has a distinctly experimental flavour and contains features which could charitably be termed failed experiments, but which have not been completely hacked out. Much was learned from the addition of support for a variety of radio clocks, with the result that some radio clock drivers could use some rewriting.</p>
- <h4>How NTP Works</h4>
- <p>The approach used by NTP to achieve reliable time synchronization from a set of possibly unreliable remote time servers is somewhat different than other protocols. In particular, NTP does not attempt to synchronize clocks to each other. Rather, each server attempts to synchronize to Universal Coordinated Time (UTC) using the best available source and available transmission paths to that source. This is a fine point which is worth understanding. A group of NTP-synchronized clocks may be close to each other in time, but this is not a consequence of the clocks in the group having synchronized to each other, but rather because each clock has synchronized closely to UTC via the best source it has access to. As such, trying to synchronize a set of clocks to a set of servers whose time is not in mutual agreement may not result in any sort of useful synchronization of the clocks, even if you don't care about UTC. However, in networks isolated from UTC sources, provisions can made to nominate one of them as a phantom UTC source.</p>
- <p>NTP operates on the premise that there is one true standard time, and that if several servers which claim synchronization to standard time disagree about what that time is, then one or more of them must be broken. There is no attempt to resolve differences more gracefully since the premise is that substantial differences cannot exist. In essence, NTP expects that the time being distributed from the root of the synchronization subnet will be derived from some external source of UTC (e.g., a radio clock). This makes it somewhat inconvenient (though by no means impossible) to synchronize hosts together without a reliable source of UTC to synchronize them to. If your network is isolated and you cannot access other people's servers across the Internet, a radio clock may make a good investment.</p>
- <p>Time is distributed through a hierarchy of NTP servers, with each server adopting a <i>stratum</i> which indicates how far away from an external source of UTC it is operating at. Stratum-1 servers, which are at the top of the pile (or bottom, depending on your point of view), have access to some external time source, usually a radio clock synchronized to time signal broadcasts from radio stations which explicitly provide a standard time service. A stratum-2 server is one which is currently obtaining time from a stratum-1 server, a stratum-3 server gets its time from a stratum-2 server, and so on. To avoid long lived synchronization loops the number of strata is limited to 15.</p>
- <p>Each client in the synchronization subnet (which may also be a server for other, higher stratum clients) chooses exactly one of the available servers to synchronize to, usually from among the lowest stratum servers it has access to. This is, however, not always an optimal configuration, for indeed NTP operates under another premise as well, that each server's time should be viewed with a certain amount of distrust. NTP really prefers to have access to several sources of lower stratum time (at least three) since it can then apply an agreement algorithm to detect insanity on the part of any one of these. Normally, when all servers are in agreement, NTP will choose the best of these, where "best" is defined in terms of lowest stratum, closest (in terms of network delay) and claimed precision, along with several other considerations. The implication is that, while one should aim to provide each client with three or more sources of lower stratum time, several of these will only be providing backup service and may be of lesser quality in terms of network delay and stratum (i.e., a same-stratum peer which receives time from lower stratum sources the local server doesn't access directly can also provide good backup service).</p>
- <p>Finally, there is the issue of association modes. There are a number of modes in which NTP servers can associate with each other, with the mode of each server in the pair indicating the behaviour the other server can expect from it. In particular, when configuring a server to obtain time from other servers, there is a choice of two modes which may be used. Configuring an association in symmetric-active mode (usually indicated by a <tt>peer</tt> declaration in the configuration file) indicates to the remote server that one wishes to obtain time from the remote server and that one is also willing to supply time to the remote server if need be. This mode is appropriate in configurations involving a number of redundant time servers interconnected via diverse network paths, which is presently the case for most stratum-1 and stratum-2 servers on the Internet today. Configuring an association in client mode (usually indicated by a <tt>server</tt> declaration in the configuration file) indicates that one wishes to obtain time from the remote server, but that one is not willing to provide time to the remote server. This mode is appropriate for file-server and workstation clients that do not provide synchronization to other local clients. Client mode is also useful for boot-date-setting programs and the like, which really have no time to provide and which don't retain state about associations over the longer term.</p>
- <p>Where the requirements in accuracy and reliability are modest, clients can be configured to use broadcast and/or multicast modes. These modes are not normally utilized by servers with dependent clients. The advantage of these modes is that clients do not need to be configured for a specific server, so that all clients operating can use the same configuration file. Broadcast mode requires a broadcast server on the same subnet, while multicast mode requires support for IP multicast on the client machine, as well as connectivity via the MBONE to a multicast server. Since broadcast messages are not propagated by routers, only those broadcast servers on the same subnet will be used. There is at present no way to select which of possibly many multicast servers will be used, since all operate on the same group address.</p>
- <p>Where the maximum accuracy and reliability provided by NTP are needed, clients and servers operate in either client/server or symmetric modes. Symmetric modes are most often used between two or more servers operating as a mutually redundant group. In these modes, the servers in the group members arrange the synchronization paths for maximum performance, depending on network jitter and propagation delay. If one or more of the group members fail, the remaining members automatically reconfigure as required. Dependent clients and servers normally operate in client/server mode, in which a client or dependent server can be synchronized to a group member, but no group member can synchronize to the client or dependent server. This provides protection against malfunctions or protocol attacks.</p>
- <p>Servers that provide synchronization to a sizeable population of clients normally operate as a group of three or more mutually redundant servers, each operating with three or more stratum-one or stratum-two servers in client-server modes, as well as all other members of the group in symmetric modes. This provides protection against malfunctions in which one or more servers fail to operate or provide incorrect time. The NTP algorithms have been specifically engineered to resist attacks where some fraction of the configured synchronization sources accidently or purposely provide incorrect time. In these cases a special voting procedure is used to identify spurious sources and discard their data.</p>
- <h4>Configuring Your Subnet</h4>
- At startup time the <tt>ntpd</tt> daemon running on a host reads the initial configuration information from a file, usually <tt>/etc/ntp.conf</tt>, unless a different name has been specified at compile time. Putting something in this file which will enable the host to obtain time from somewhere else is usually the first big hurdle after installation of the software itself, which is described in the <a href="build/build.html">Building and Installing the Distribution</a> page. At its simplest, what you need to do in the configuration file is declare the servers that the daemon should poll for time synchronization. In principle, no such list is needed if some other time server operating in broadcast/multicast mode is available, which requires the client to operate in a broadcastclient mode.
- <p>In the case of a workstation operating in an enterprise network for a public or private organization, there is often an administrative department that coordinates network services, including NTP. Where available, the addresses of appropriate servers can be provided by that department. However, if this infrastructure is not available, it is necessary to explore some portion of the existing NTP subnet now running in the Internet. There are at present many thousands of time servers running NTP in the Internet, a significant number of which are willing to provide a public time- synchronization service. Some of these are listed in the list of public time servers, which can be accessed via the <a href="http://www.eecis.udel.edu/%7entp">NTP web page</a>. These data are updated on a regular basis using information provided voluntarily by various site administrators. There are other ways to explore the nearby subnet using the <tt><a href="ntptrace.html">ntptrace</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> programs.</p>
- <p>It is vital to carefully consider the issues of robustness and reliability when selecting the sources of synchronization. Normally, not less than three sources should be available, preferably selected to avoid common points of failure. It is usually better to choose sources which are likely to be "close" to you in terms of network topology, though you shouldn't worry overly about this if you are unable to determine who is close and who isn't. Normally, it is much more serious when a server becomes faulty and delivers incorrect time than when it simply stops operating, since an NTP-synchronized host normally can coast for hours or even days without its clock accumulating serious error approaching a second, for instance. Selecting at least three sources from different operating administrations, where possible, is the minimum recommended, although a lesser number could provide acceptable service with a degraded degree of robustness.</p>
- <p>Normally, it is not considered good practice for a single workstation to request synchronization from a primary (stratum-1) time server. At present, these servers provide synchronization for hundreds of clients in many cases and could, along with the network access paths, become seriously overloaded if large numbers of workstation clients requested synchronization directly. Therefore, workstations located in sparsely populated administrative domains with no local synchronization infrastructure should request synchronization from nearby stratum-2 servers instead. In most cases the keepers of those servers in the lists of public servers provide unrestricted access without prior permission; however, in all cases it is considered polite to notify the administrator listed in the file upon commencement of regular service. In all cases the access mode and notification requirements listed in the file must be respected. Under no conditions should servers not in these lists be used without prior permission, as to do so can create severe problems in the local infrastructure, especially in cases of dial-up access to the Internet.</p>
- <p>In the case of a gateway or file server providing service to a significant number of workstations or file servers in an enterprise network it is even more important to provide multiple, redundant sources of synchronization and multiple, diversity-routed, network access paths. The preferred configuration is at least three administratively coordinated time servers providing service throughout the administrative domain including campus networks and subnetworks. Each of these should obtain service from at least two different outside sources of synchronization, preferably via different gateways and access paths. These sources should all operate at the same stratum level, which is one less than the stratum level to be used by the local time servers themselves. In addition, each of these time servers should peer with all of the other time servers in the local administrative domain at the stratum level used by the local time servers, as well as at least one (different) outside source at this level. This configuration results in the use of six outside sources at a lower stratum level (toward the primary source of synchronization, usually a radio clock), plus three outside sources at the same stratum level, for a total of nine outside sources of synchronization. While this may seem excessive, the actual load on network resources is minimal, since the interval between polling messages exchanged between peers usually ratchets back to no more than one message every 17 minutes.</p>
- <p>The stratum level to be used by the local time servers is an engineering choice. As a matter of policy, and in order to reduce the load on the primary servers, it is desirable to use the highest stratum consistent with reliable, accurate time synchronization throughout the administrative domain. In the case of enterprise networks serving hundreds or thousands of client file servers and workstations, conventional practice is to obtain service from stratum-1 primary servers listed for public access. When choosing sources away from the primary sources, the particular synchronization path in use at any time can be verified using the <tt>ntptrace</tt> program included in this distribution. It is important to avoid loops and possible common points of failure when selecting these sources. Note that, while NTP detects and rejects loops involving neighboring servers, it does not detect loops involving intervening servers. In the unlikely case that all primary sources of synchronization are lost throughout the subnet, the remaining servers on that subnet can form temporary loops and, if the loss continues for an interval of many hours, the servers will drop off the subnet and free-run with respect to their internal (disciplined) timing sources. After some period with no outside timing source (currently one day), a host will declare itself unsynchronized and provide this information to local application programs.</p>
- <p>In many cases the purchase of one or more radio clocks is justified, in which cases good engineering practice is to use the configurations described above anyway and connect the radio clock to one of the local servers. This server is then encouraged to participate in a special primary-server subnetwork in which each radio-equipped server peers with several other similarly equipped servers. In this way the radio-equipped server may provide synchronization, as well as receive synchronization, should the local or remote radio clock(s) fail or become faulty. <tt>ntpd</tt> treats attached radio clock(s) in the same way as other servers and applies the same criteria and algorithms to the time indications, so can detect when the radio fails or becomes faulty and switch to alternate sources of synchronization. It is strongly advised, and in practice for most primary servers today, to employ the authentication or access-control features of the NTP specification in order to protect against hostile intruders and possible destabilization of the time service. Using this or similar strategies, the remaining hosts in the same administrative domain can be synchronized to the three (or more) selected time servers. Assuming these servers are synchronized directly to stratum-1 sources and operate normally as stratum-2, the next level away from the primary source of synchronization, for instance various campus file servers, will operate at stratum 3 and dependent workstations at stratum 4. Engineered correctly, such a subnet will survive all but the most exotic failures or even hostile penetrations of the various, distributed timekeeping resources.</p>
- <p>The above arrangement should provide very good, robust time service with a minimum of traffic to distant servers and with manageable loads on the local servers. While it is theoretically possible to extend the synchronization subnet to even higher strata, this is seldom justified and can make the maintenance of configuration files unmanageable. Serving time to a higher stratum peer is very inexpensive in terms of the load on the lower stratum server if the latter is located on the same concatenated LAN. When justified by the accuracy expectations, NTP can be operated in broadcast and multicast modes, so that clients need only listen for periodic broadcasts and do not need to send anything.</p>
- <p>When planning your network you might, beyond this, keep in mind a few generic don'ts, in particular:</p>
- <ul>
- <li>Don't synchronize a local time server to another peer at the same stratum, unless the latter is receiving time from lower stratum sources the former doesn't talk to directly. This minimizes the occurrence of common points of failure, but does not eliminate them in cases where the usual chain of associations to the primary sources of synchronization are disrupted due to failures.
- <li style="list-style: none"><br>
- <li>Don't configure peer associations with higher stratum servers. Let the higher strata configure lower stratum servers, but not the reverse. This greatly simplifies configuration file maintenance, since there is usually much greater configuration churn in the high stratum clients such as personal workstations.
- <li style="list-style: none"><br>
- <li>Don't synchronize more than one time server in a particular administrative domain to the same time server outside that domain. Such a practice invites common points of failure, as well as raises the possibility of massive abuse, should the configuration file be automatically distributed do a large number of clients.
- </ul>
- There are many useful exceptions to these rules. When in doubt, however, follow them.
- <h4>Configuring Your Server or Client</h4>
- <p>As mentioned previously, the configuration file is usually called /etc/ntp.conf. This is an ASCII file conforming to the usual comment and whitespace conventions. A working configuration file might look like (in this and other examples, do not copy this directly):</p>
- <pre>
- # peer configuration for host whimsy
- # (expected to operate at stratum 2)
-
- server rackety.udel.edu
- server umd1.umd.edu
- server lilben.tn.cornell.edu
-
- driftfile /etc/ntp.drift
-</pre>
- (Note the use of host names, although host addresses in dotted-quad notation can also be used. It is always preferable to use names rather than addresses, since over time the addresses can change, while the names seldom change.)
- <p>This particular host is expected to operate as a client at stratum 2 by virtue of the <tt>server</tt> keyword and the fact that two of the three servers declared (the first two) have radio clocks and usually run at stratum 1. The third server in the list has no radio clock, but is known to maintain associations with a number of stratum 1 peers and usually operates at stratum 2. Of particular importance with the last host is that it maintains associations with peers besides the two stratum 1 peers mentioned. This can be verified using the <tt>ntpq</tt> program mentioned above. When configured using the <tt>server</tt> keyword, this host can receive synchronization from any of the listed servers, but can never provide synchronization to them.</p>
- <p>Unless restricted using facilities described later, this host can provide synchronization to dependent clients, which do not have to be listed in the configuration file. Associations maintained for these clients are transitory and result in no persistent state in the host. These clients are normally not visible using the <tt>ntpq</tt> program included in the distribution; however, <tt>ntpd</tt> includes a monitoring feature (described later) which caches a minimal amount of client information useful for debugging administrative purposes.</p>
- <p>A time server expected to both receive synchronization from another server, as well as to provide synchronization to it, is declared using the <tt>peer</tt> keyword instead of the <tt>server</tt> keyword. In all other aspects the server operates the same in either mode and can provide synchronization to dependent clients or other peers. If a local source of UTC time is available, it is considered good engineering practice to declare time servers outside the administrative domain as <tt>peer</tt> and those inside as <tt>server</tt> in order to provide redundancy in the global Internet, while minimizing the possibility of instability within the domain itself. A time server in one domain can in principle heal another domain temporarily isolated from all other sources of synchronization. However, it is probably unwise for a casual workstation to bridge fragments of the local domain which have become temporarily isolated.</p>
- <p>Note the inclusion of a <tt>driftfile</tt> declaration. One of the things the NTP daemon does when it is first started is to compute the error in the intrinsic frequency of the clock on the computer it is running on. It usually takes about a day or so after the daemon is started to compute a good estimate of this (and it needs a good estimate to synchronize closely to its server). Once the initial value is computed, it will change only by relatively small amounts during the course of continued operation. The <tt>driftfile</tt> declaration indicates to the daemon the name of a file where it may store the current value of the frequency error so that, if the daemon is stopped and restarted, it can reinitialize itself to the previous estimate and avoid the day's worth of time it will take to recompute the frequency estimate. Since this is a desirable feature, a <tt>driftfile</tt> declaration should always be included in the configuration file.</p>
- <p>An implication in the above is that, should <tt>ntpd</tt> be stopped for some reason, the local platform time will diverge from UTC by an amount that depends on the intrinsic error of the clock oscillator and the time since last synchronized. In view of the length of time necessary to refine the frequency estimate, every effort should be made to operate the daemon on a continuous basis and minimize the intervals when for some reason it is not running.</p>
- <h4>Configuring NTP with NetInfo</h4>
- If NetInfo support is compiled into NTP, you can opt to configure NTP in your NetInfo domain. NTP will look in the NetInfo directory <tt>/locations/ntp</tt> for property/value pairs which are equivalent to the lines in the configuration file described above. Each configuration keyword may have a corresponding property in NetInfo. Each value for a given property is treated as arguments to that property, similar to a line in the configuration file.
- <p>For example, the configuration shown in the configuration file above can be duplicated in NetInfo by adding a property "<tt>server</tt>" with values "<tt>rackety.udel.edu</tt>", "<tt>umd1.umd.edu</tt>", and "<tt>lilben.tn.cornell.edu</tt>"; and a property "<tt>driftfile</tt>" with the single value "<tt>/etc/ntp.drift</tt>".</p>
- <p>Values may contain multiple tokens similar to the arguments available in the configuration file. For example, to use <tt>mimsy.mil</tt> as an NTP version 1 time server, you would add a value "<tt>mimsy.mil version 1</tt>" to the "<tt>server</tt>" property.</p>
- <h4>Ntp4 Versus Previous Versions</h4>
- There are several items of note when dealing with a mixture of <tt>ntp4</tt> and previous distributions of NTP Version 2 (<tt>ntpd</tt>) and NTP Version 1 (<tt>ntp3.4</tt>). The <tt>ntp4</tt> implementation conforms to the NTP Version 3 specification RFC-1305 and, in addition, contains additional features documented in the <a href="release.html">Release Notes</a> page. As such, by default when no additional information is available concerning the preferences of the peer, <tt>ntpd</tt> claims to be version 4 in the packets that it sends from configured associations. The <tt>version</tt> subcommand of the <tt>server</tt>, <tt>peer</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> command can be used to change the default. In unconfigured (ephemeral) associaitons, the daemon always replies in the same version as the request.
- <p>An NTP implementation conforming to a previous version specification ordinarily discards packets from a later version. However, in most respects documented in RFC-1305, The version 2 implementation is compatible with the version 3 algorithms and protocol. The version 1 implementation contains most of the version 2 algorithms, but without important features for clock selection and robustness. Nevertheless, in most respects the NTP versions are backwards compatible. The sticky part here is that, when a previous version implementation receives a packet claiming to be from a version 4 server, it discards it without further processing. Hence there is a danger that in some situations synchronization with previous versions will fail.</p>
- <p>The trouble occurs when an previous version is to be included in an <tt>ntpd</tt> configuration file. With no further indication, <tt>ntpd</tt> will send packets claiming to be version 4 when it polls. To get around this, <tt>ntpd</tt> allows a qualifier to be added to configuration entries to indicate which version to use when polling. Hence the entries</p>
- <pre>
- # specify NTP version 1
-
- server mimsy.mil version
-1 # server running ntpd version 1
- server apple.com version
-2 # server running ntpd version 2
-</pre>
- will cause version 1 packets to be sent to the host mimsy.mil and version 2 packets to be sent to apple.com. If you are testing <tt>ntpd</tt> against previous version servers you will need to be careful about this. Note that, as indicated in the RFC-1305 specification, there is no longer support for the original NTP specification, once called NTP Version 0.
- <h4>Traffic Monitoring</h4>
- <tt>ntpd</tt> handles peers whose stratum is higher than the stratum of the local server and polls using client mode by a fast path which minimizes the work done in responding to their polls, and normally retains no memory of these pollers. Sometimes, however, it is interesting to be able to determine who is polling the server, and how often, as well as who has been sending other types of queries to the server.
- <p>To allow this, <tt>ntpd</tt> implements a traffic monitoring facility which records the source address and a minimal amount of other information from each packet which is received by the server. This feature is normally enabled, but can be disabled if desired using the configuration file entry:</p>
- <pre>
- # disable monitoring feature
- disable monitor
-</pre>
- The recorded information can be displayed using the <tt>ntpdc</tt> query program, described briefly below.
- <h4>Address-and-Mask Restrictions</h4>
- The address-and-mask configuration facility supported by <tt>ntpd</tt> is quite flexible and general, but is not an integral part of the NTP Version 3 specification. The major drawback is that, while the internal implementation is very nice, the user interface is not. For this reason it is probably worth doing an example here. Briefly, the facility works as follows. There is an internal list, each entry of which holds an address, a mask and a set of flags. On receipt of a packet, the source address of the packet is compared to each entry in the list, with a match being posted when the following is true:
- <pre>
- (source_addr & mask) == (address &
-mask)
-</pre>
- A particular source address may match several list entries. In this case the entry with the most one bits in the mask is chosen. The flags associated with this entry are used to control the access.
- <p>In the current implementation the flags always add restrictions. In effect, an entry with no flags set leaves matching hosts unrestricted. An entry can be added to the internal list using a <tt>restrict</tt> declaration. The flags associated with the entry are specified textually. For example, the <tt>notrust</tt> flag indicates that hosts matching this entry, while treated normally in other respects, shouldn't be trusted to provide synchronization even if otherwise so enabled. The <tt>nomodify</tt> flag indicates that hosts matching this entry should not be allowed to do run-time configuration. There are many more flags, see the <a href="ntpd.html"><tt>ntpd</tt></a> page.</p>
- <p>Now the example. Suppose you are running the server on a host whose address is 128.100.100.7. You would like to ensure that run time reconfiguration requests can only be made from the local host and that the server only ever synchronizes to one of a pair of off-campus servers or, failing that, a time source on net 128.100. The following entries in the configuration file would implement this policy:</p>
- <pre>
- # by default, don't trust and don't allow
-modifications
-
- restrict default notrust nomodify
-
- # these guys are trusted for time, but no
-modifications allowed
-
- restrict 128.100.0.0 mask 255.255.0.0 nomodify
- restrict 128.8.10.1 nomodify
- restrict 192.35.82.50 nomodify
-
- # the local addresses are unrestricted
-
- restrict 128.100.100.7
- restrict 127.0.0.1
-</pre>
- The first entry is the default entry, which all hosts match and hence which provides the default set of flags. The next three entries indicate that matching hosts will only have the <tt>nomodify</tt> flag set and hence will be trusted for time. If the mask isn't specified in the <tt>restrict</tt> keyword, it defaults to 255.255.255.255. Note that the address 128.100.100.7 matches three entries in the table, the default entry (mask 0.0.0.0), the entry for net 128.100 (mask 255.255.0.0) and the entry for the host itself (mask 255.255.255.255). As expected, the flags for the host are derived from the last entry since the mask has the most bits set.
- <p>The only other thing worth mentioning is that the <tt>restrict</tt> declarations apply to packets from all hosts, including those that are configured elsewhere in the configuration file and even including your clock pseudopeer(s), if any. Hence, if you specify a default set of restrictions which you don't wish to be applied to your configured peers, you must remove those restrictions for the configured peers with additional <tt>restrict</tt> declarations mentioning each peer separately.</p>
- <h4>Authentication</h4>
- <tt>ntpd</tt> supports the optional authentication procedure specified in the NTP Version 2 and 3 specifications. Briefly, when an association runs in authenticated mode, each packet transmitted has appended to it a 32-bit key ID and a 64/128-bit cryptographic checksum of the packet contents computed using either the Data Encryption Standard (DES) or Message Digest (MD5) algorithms. Note that, while either of these algorithms provide sufficient protection from message- modification attacks, distribution of the former algorithm implementation is restricted to the U.S. and Canada, while the latter presently is free from such restrictions. For this reason, the DES algorithm is not included in the current distribution. Directions for obtaining it in other countries is in the <a href="build/build.html">Building and Installing the Distribution</a> page. With either algorithm the receiving peer recomputes the checksum and compares it with the one included in the packet. For this to work, the peers must share at least one encryption key and, furthermore, must associate the shared key with the same key ID.
- <p>This facility requires some minor modifications to the basic packet processing procedures, as required by the specification. These modifications are enabled by the <tt>enable auth</tt> configuration declaration, which is currently the default. In authenticated mode, peers which send unauthenticated packets, peers which send authenticated packets which the local server is unable to decrypt and peers which send authenticated packets encrypted using a key we don't trust are all marked untrustworthy and unsuitable for synchronization. Note that, while the server may know many keys (identified by many key IDs), it is possible to declare only a subset of these as trusted. This allows the server to share keys with a client which requires authenticated time and which trusts the server, but which is not trusted by the server. Also, some additional configuration language is required to specify the key ID to be used to authenticate each configured peer association. Hence, for a server running in authenticated mode, the configuration file might look similar to the following:</p>
- <pre>
- # peer configuration for 128.100.100.7
- # (expected to operate at stratum 2)
- # fully authenticated this time
-
- peer 128.100.49.105 key 22 #
-suzuki.ccie.utoronto.ca
- peer 128.8.10.1 key 4 #
-umd1.umd.edu
- peer 192.35.82.50 key 6 #
-lilben.tn.cornell.edu
-
- keys /usr/local/etc/ntp.keys # path for
-key file
- trustedkey 1 2 14 15 #
-define trusted keys
- requestkey
-15 #
-key (7) for accessing server variables
- controlkey
-15 #
-key (6) for accessing server variables
-
- authdelay
-0.000094 # authentication delay
-(Sun4c/50 IPX)
-</pre>
- There are a couple of previously unmentioned things in here. The <tt>keys</tt> line specifies the path to the keys file (see below and the <tt>ntpd</tt> document page for details of the file format). The <tt>trustedkey</tt> declaration identifies those keys that are known to be uncompromised; the remainder presumably represent the expired or possibly compromised keys. Both sets of keys must be declared by key identifier in the <tt>ntp.keys</tt> file described below. This provides a way to retire old keys while minimizing the frequency of delicate key-distribution procedures. The <tt>requestkey</tt> line establishes the key to be used for mode-6 control messages as specified in RFC-1305 and used by the <tt>ntpq</tt> utility program, while the <tt>controlkey</tt> line establishes the key to be used for mode-7 private control messages used by the <tt>ntpdc</tt> utility program. These keys are used to prevent unauthorized modification of daemon variables.
- <p>Ordinarily, the authentication delay; that is, the processing time taken between the freezing of a transmit timestamp and the actual transmission of the packet when authentication is enabled (i.e. more or less the time it takes for the DES or MD5 routine to encrypt a single block) is computed automatically by the daemon. If necessary, the delay can be overridden by the <tt>authdelay</tt> line, which is used as a correction for the transmit timestamp.</p>
- Additional utility programs included in the <tt>./authstuff</tt> directory can be used to generate random keys, certify implementation correctness and display sample keys. As a general rule, keys should be chosen randomly, except possibly the request and control keys, which must be entered by the user as a password.
- <p>The <tt>ntp.keys</tt> file contains the list of keys and associated key IDs the server knows about (for obvious reasons this file is better left unreadable by anyone except root). The contents of this file might look like:</p>
- <pre>
- # ntp keys file (ntp.keys)
- 1 N
-29233E0461ECD6AE # DES key in NTP format
- 2 M
-RIrop8KPPvQvYotM # md5 key as an ASCII random string
- 14 M
-sundial
-; # md5 key as an ASCII string
- 15 A
-sundial
-; # DES key as an ASCII string
-
- # the following 3 keys are identical
-
- 10 A SeCReT
- 10 N
-d3e54352e5548080
- 10 S
-a7cb86a4cba80101
-</pre>
- In the keys file the first token on each line indicates the key ID, the second token the format of the key and the third the key itself. There are four key formats. An <tt>A</tt> indicates a DES key written as a 1- to-8 character string in 7-bit ASCII representation, with each character standing for a key octet (like a Unix password). An <tt>S</tt> indicates a DES key written as a hex number in the DES standard format, with the low order bit (LSB) of each octet being the (odd) parity bit. An <tt>N</tt> indicates a DES key again written as a hex number, but in NTP standard format with the high order bit of each octet being the (odd) parity bit (confusing enough?). An <tt>M</tt> indicates an MD5 key written as a 1-to-31 character ASCII string in the <tt>A</tt> format. Note that, because of the simple tokenizing routine, the characters <tt>' ', '#', '\t', '\n'</tt> and <tt>'\0'</tt> can't be used in either a DES or MD5 ASCII key. Everything else is fair game, though. Key 0 (zero) is used for special purposes and should not appear in this file.
- <p>The big trouble with the authentication facility is the keys file. It is a maintenance headache and a security problem. This should be fixed some day. Presumably, this whole bag of worms goes away if/when a generic security regime for the Internet is established. An alternative with NTP Version 4 is the autokey feature, which uses random session keys and public-key cryptography and avoids the key file entirely. While this feature is not completely finished yet, details can be found in the <a href="release.html">Release Notes</a> page.</p>
- <h4>Query Programs</h4>
- Three utility query programs are included with the distribution, <tt>ntpq</tt>, <tt>ntptrace</tt> and <tt>ntpdc</tt>. <tt>ntpq</tt> is a handy program which sends queries and receives responses using NTP standard mode-6 control messages. Since it uses the standard control protocol specified in RFC- 1305, it may be used with NTP Version 2 and Version 3 implementations for both Unix and Fuzzball, but not Version 1 implementations. It is most useful to query remote NTP implementations to assess timekeeping accuracy and expose bugs in configuration or operation.
- <p><tt>ntptrace</tt> can be used to display the current synchronization path from a selected host through possibly intervening servers to the primary source of synchronization, usually a radio clock. It works with both version 2 and version 3 servers, but not version 1.</p>
- <p><tt>ntpdc</tt> is a horrid program which uses NTP private mode-7 control messages to query local or remote servers. The format and contents of these messages are specific to this version of <tt>ntpd</tt> and some older versions. The program does allow inspection of a wide variety of internal counters and other state data, and hence does make a pretty good debugging tool, even if it is frustrating to use. The other thing of note about <tt>ntpdc</tt> is that it provides a user interface to the run time reconfiguration facility. See the respective document pages for details on the use of these programs.</p>
- <h4>Run-Time Reconfiguration</h4>
- <tt>ntpd</tt> was written specifically to allow its configuration to be fully modifiable at run time. Indeed, the only way to configure the server is at run time. The configuration file is read only after the rest of the server has been initialized into a running default-configured state. This facility was included not so much for the benefit of Unix, where it is handy but not strictly essential, but rather for dedicated platforms where the feature is more important for maintenance. Nevertheless, run time configuration works very nicely for Unix servers as well.
- <p>Nearly all of the things it is possible to configure in the configuration file may be altered via NTP mode-7 messages using the <tt>ntpdc</tt> program. Mode-6 messages may also provide some limited configuration functionality (though the only thing you can currently do with mode-6 messages is set the leap-second warning bits) and the <tt>ntpq</tt> program provides generic support for the latter. The leap bits that can be set in the <tt>leap_warning</tt> variable (up to one month ahead) and in the <tt>leap_indication</tt> variable have a slightly different encoding than the usual interpretation:</p>
- <pre>
-
-Value Action
-
-
-00
-p; The daemon passes the leap bits of its
-
-
-synchronisation source (usual mode of operation)
-
- 01/10 A leap
-second is added/deleted
-
-
-11
-p; Leap information from the synchronization source
-
- is
-ignored (thus LEAP_NOWARNING is passed on)
-</pre>
- Mode-6 and mode-7 messages which would modify the configuration of the server are required to be authenticated using standard NTP authentication. To enable the facilities one must, in addition to specifying the location of a keys file, indicate in the configuration file the key IDs to be used for authenticating reconfiguration commands. Hence the following fragment might be added to a configuration file to enable the mode-6 (ntpq) and mode-7 (ntpdc) facilities in the daemon:
- <pre>
- # specify mode-6 and mode-7 trusted keys
-
- requestkey 65535 # for mode-7
-requests
- controlkey 65534 # for mode-6
-requests
-</pre>
- If the <tt>requestkey</tt> and/or the <tt>controlkey</tt> configuration declarations are omitted from the configuration file, the corresponding run-time reconfiguration facility is disabled.
- <p>The query programs require the user to specify a key ID and a key to use for authenticating requests to be sent. The key ID provided should be the same as the one mentioned in the configuration file, while the key should match that corresponding to the key ID in the keys file. As the query programs prompt for the key as a password, it is useful to make the request and control authentication keys typeable (in ASCII format) from the keyboard.</p>
- <h4>Name Resolution</h4>
- <tt>ntpd</tt> includes the capability to specify host names requiring resolution in <tt>peer</tt> and <tt>server</tt> declarations in the configuration file. However, in some outposts of the Internet, name resolution is unreliable and the interface to the Unix resolver routines is synchronous. The hangups and delays resulting from name-resolver clanking can be unacceptable once the NTP server is running (and remember it is up and running before the configuration file is read). However, it is advantageous to resolve time server names, since their addresses are occasionally changed.
- <p>In order to prevent configuration delays due to the name resolver, the daemon runs the name resolution process in parallel with the main daemon code. When the daemon comes across a <tt>peer</tt> or <tt>server</tt> entry with a non-numeric host address, it records the relevant information in a temporary file and continues on. When the end of the configuration file has been reached and one or more entries requiring name resolution have been found, the server runs the name resolver from the temporary file. The server then continues on normally but with the offending peers/servers omitted from its configuration.</p>
- <p>As each name is resolved, it configures the associated entry into the server using the same mode-7 run time reconfiguration facility that <tt>ntpdc</tt> uses. If temporary resolver failures occur, the resolver will periodically retry the requests until a definite response is received. The program will continue to run until all entries have been resolved.</p>
- <h4>Dealing with Frequency Tolerance Violations (<tt>tickadj</tt> and Friends)</h4>
- The NTP Version 3 specification RFC-1305 calls for a maximum oscillator frequency tolerance of +-100 parts-per-million (PPM), which is representative of those components suitable for use in relatively inexpensive workstation platforms. For those platforms meeting this tolerance, NTP will automatically compensate for the frequency errors of the individual oscillator and no further adjustments are required, either to the configuration file or to various kernel variables. For the NTP Version 4 release, this tolerance has been increased to +-500 PPM.
- <p>However, in the case of certain notorious platforms, in particular Sun 4.1.1 systems, the performance can be improved by adjusting the values of certain kernel variables; in particular, <tt>tick</tt> and <tt>tickadj</tt>. The variable <tt>tick</tt> is the increment in microseconds added to the system time on each interval- timer interrupt, while the variable <tt>tickadj</tt> is used by the time adjustment code as a slew rate, in microseconds per tick. When the time is being adjusted via a call to the system routine <tt>adjtime()</tt>, the kernel increases or reduces tick by <tt>tickadj</tt> microseconds per tick until the specified adjustment has been completed. Unfortunately, in most Unix implementations the tick increment must be either zero or plus/minus exactly <tt>tickadj</tt> microseconds, meaning that adjustments are truncated to be an integral multiple of <tt>tickadj</tt> (this latter behaviour is a misfeature, and is the only reason the <tt>tickadj</tt> code needs to concern itself with the internal implementation of <tt>tickadj</tt> at all). In addition, the stock Unix implementation considers it an error to request another adjustment before a prior one has completed.</p>
- <p>Thus, to make very sure it avoids problems related to the roundoff, the <tt>tickadj</tt> program can be used to adjust the values of <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all adjustments given to <tt>adjtime()</tt> are an even multiple of <tt>tickadj</tt> microseconds and computes the largest adjustment that can be completed in the adjustment interval (using both the value of <tt>tick</tt> and the value of <tt>tickadj</tt>) so it can avoid exceeding this limit. It is important to note that not all systems will allow inspection or modification of kernel variables other than at system build time. It is also important to know that, with the current NTP tolerances, it is rarely necessary to make these changes, but in many cases they will substantially improve the general accuracy of the time service.</p>
- <p>Unfortunately, the value of <tt>tickadj</tt> set by default is almost always too large for <tt>ntpd</tt>. NTP operates by continuously making small adjustments to the clock, usually at one-second intervals. If <tt>tickadj</tt> is set too large, the adjustments will disappear in the roundoff; while, if <tt>tickadj</tt> is too small, NTP will have difficulty if it needs to make an occasional large adjustment. While the daemon itself will read the kernel's values of these variables, it will not change the values, even if they are unsuitable. You must do this yourself before the daemon is started using the <tt>tickadj</tt> program included in the <tt>./util</tt> directory of the distribution. Note that the latter program will also compute an optimal value of <tt>tickadj</tt> for NTP use based on the kernel's value of <tt>tick</tt>.</p>
- <p>The <tt>tickadj</tt> program can reset several other kernel variables if asked. It can change the value of <tt>tick</tt> if asked. This is handy to compensate for kernel bugs which cause the clock to run with a very large frequency error, as with SunOS 4.1.1 systems. It can also be used to set the value of the kernel <tt>dosynctodr</tt> variable to zero. This variable controls whether to synchronize the system clock to the time-of-day clock, something you really don't want to be happen when <tt>ntpd</tt> is trying to keep it under control. In some systems, such as recent Sun Solaris kernels, the <tt>dosynctodr</tt> variable is the only one that can be changed by the <tt>tickadj</tt> program. In this and other modern kernels, it is not necessary to change the other variables in any case.</p>
- <p>We have a report that says starting with Solaris 2.6 we should leave <i>dosynctodr</i> alone.</p>
- <p>In order to maintain reasonable correctness bounds, as well as reasonably good accuracy with acceptable polling intervals, <tt>ntpd</tt> will complain if the frequency error is greater than 500 PPM. For machines with a value of <tt>tick</tt> in the 10-ms range, a change of one in the value of <tt>tick</tt> will change the frequency by about 100 PPM. In order to determine the value of <tt>tick</tt> for a particular CPU, disconnect the machine from all sources of time (<tt>dosynctodr</tt> = 0) and record its actual time compared to an outside source (eyeball-and-wristwatch will do) over a day or more. Multiply the time change over the day by 0.116 and add or subtract the result to tick, depending on whether the CPU is fast or slow. An example call to <tt>tickadj</tt> useful on SunOS 4.1.1 is:</p>
- <pre>
- <tt>tickadj</tt> -t 9999 -a 5 -s
-</pre>
- which sets tick 100 PPM fast, <tt>tickadj</tt> to 5 microseconds and turns off the clock/calendar chip fiddle. This line can be added to the <tt>rc.local</tt> configuration file to automatically set the kernel variables at boot time.
- <p>All this stuff about diddling kernel variables so the NTP daemon will work is really silly. If vendors would ship machines with clocks that kept reasonable time and would make their <tt>adjtime()</tt> system call apply the slew it is given exactly, independent of the value of <tt>tickadj</tt>, all this could go away. This is in fact the case on many current Unix systems.</p>
- <h4>Tuning Your Subnet</h4>
- There are several parameters available for tuning the NTP subnet for maximum accuracy and minimum jitter. One of these is the <tt>prefer</tt> configuration declaration described in <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> documentation page. When more than one eligible server exists, the NTP clock-selection and combining algorithms act to winnow out all except the "best" set of servers using several criteria based on differences between the readings of different servers and between successive readings of the same server. The result is usually a set of surviving servers that are apparently statistically equivalent in accuracy, jitter and stability. The population of survivors remaining in this set depends on the individual server characteristics measured during the selection process and may vary from time to time as the result of normal statistical variations. In LANs with high speed RISC-based time servers, the population can become somewhat unstable, with individual servers popping in and out of the surviving population, generally resulting in a regime called <i>clockhopping</i>.
- <p>When only the smallest residual jitter can be tolerated, it may be convenient to elect one of the servers at each stratum level as the preferred one using the keyword <tt>prefer</tt> on the configuration declaration for the selected server:</p>
- <pre>
- # preferred server declaration
-
- peer rackety.udel.edu prefer
-# preferred server
-</pre>
- The preferred server will always be included in the surviving population, regardless of its characteristics and as long as it survives preliminary sanity checks and validation procedures.
- <p>The most useful application of the <tt>prefer</tt> keyword is in high speed LANs equipped with precision radio clocks, such as a GPS receiver. In order to insure robustness, the hosts need to include outside peers as well as the GPS-equipped server; however, as long as that server is running, the synchronization preference should be that server. The keyword should normally be used in all cases in order to prefer an attached radio clock. It is probably inadvisable to use this keyword for peers outside the LAN, since it interferes with the carefully crafted judgement of the selection and combining algorithms.</p>
- <h4>Provisions for Leap Seconds and Accuracy Metrics</h4>
- <tt>ntpd</tt> understands leap seconds and will attempt to take appropriate action when one occurs. In principle, every host running ntpd will insert a leap second in the local timescale in precise synchronization with UTC. This requires that the leap-warning bits be activated some time prior to the occurrence of a leap second at the primary (stratum 1) servers. Subsequently, these bits are propagated throughout the subnet depending on these servers by the NTP protocol itself and automatically implemented by <tt>ntpd</tt> and the time- conversion routines of each host. The implementation is independent of the idiosyncrasies of the particular radio clock, which vary widely among the various devices, as long as the idiosyncratic behavior does not last for more than about 20 minutes following the leap. Provisions are included to modify the behavior in cases where this cannot be guaranteed. While provisions for leap seconds have been carefully crafted so that correct timekeeping immediately before, during and after the occurrence of a leap second is scrupulously correct, stock Unix systems are mostly inept in responding to the available information. This caveat goes also for the maximum-error and statistical-error bounds carefully calculated for all clients and servers, which could be very useful for application programs needing to calibrate the delays and offsets to achieve a near- simultaneous commit procedure, for example. While this information is maintained in the <tt>ntpd</tt> data structures, there is at present no way for application programs to access it. This may be a topic for further development.
- <h4>Clock Support Overview</h4>
- <tt>ntpd</tt> was designed to support radio (and other external) clocks and does some parts of this function with utmost care. Clocks are treated by the protocol as ordinary NTP peers, even to the point of referring to them with an (invalid) IP host address. Clock addresses are of the form 127.127.<i>t.u</i>, where <i>t</i> specifies the particular type of clock (i.e., refers to a particular clock driver) and <i>u</i> is a unit number whose interpretation is clock-driver dependent. This is analogous to the use of major and minor device numbers by Unix and permits multiple instantiations of clocks of the same type on the same server, should such magnificent redundancy be required.
- <p>Because clocks look much like peers, both configuration file syntax and run time reconfiguration commands can be used to control clocks in the same way as ordinary peers. Clocks are configured via <tt>server</tt> declarations in the configuration file, can be started and stopped using ntpdc and are subject to address-and-mask restrictions much like a normal peer, should this stretch of imagination ever be useful. As a concession to the need to sometimes transmit additional information to clock drivers, an additional configuration file is available: the <tt>fudge</tt> statement. This enables one to specify the values of two time quantities, two integral values and two flags, the use of which is dependent on the particular clock driver. For example, to configure a PST radio clock which can be accessed through the serial device <tt>/dev/pst1</tt>, with propagation delays to WWV and WWVH of 7.5 and 26.5 milliseconds, respectively, on a machine with an imprecise system clock and with the driver set to disbelieve the radio clock once it has gone 30 minutes without an update, one might use the following configuration file entries:</p>
- <pre>
- # radio clock fudge fiddles
- server 127.127.3.1
- fudge 127.127.3.1 time1 0.0075 time2 0.0265
- fudge 127.127.3.1 value2 30 flag1 1
-</pre>
- Additional information on the interpretation of these data with respect to various radio clock drivers is given in the <a href="refclock.html">Reference Clock Drivers</a> document page and in the individual driver documents accessible via that page.
- <h4>Towards the Ultimate Tick</h4>
- This section considers issues in providing precision time synchronization in NTP subnets which need the highest quality time available in the present technology. These issues are important in subnets supporting real-time services such as distributed multimedia conferencing and wide-area experiment control and monitoring.
- <p>In the Internet of today synchronization paths often span continents and oceans with moderate to high variations in delay due to traffic spasms. NTP is specifically designed to minimize timekeeping jitter due to delay variations using intricately crafted filtering and selection algorithms; however, in cases where these variations are as much as a second or more, the residual jitter following these algorithms may still be excessive. Sometimes, as in the case of some isolated NTP subnets where a local source of precision time is available, such as a PPS signal produced by a calibrated cesium clock, it is possible to remove the jitter and retime the local clock oscillator of the NTP server. This has turned out to be a useful feature to improve the synchronization quality of time distributed in remote places where radio clocks are not available. In these cases special features of the distribution are used together with the PPS signal to provide a jitter-free timing signal, while NTP itself is used to provide the coarse timing and resolve the seconds numbering.</p>
- <p>Most available radio clocks can provide time to an accuracy in the order of milliseconds, depending on propagation conditions, local noise levels and so forth. However, as a practical matter, all clocks can occasionally display errors significantly exceeding nominal specifications. Usually, the algorithms used by NTP for ordinary network peers, as well as radio clock peers will detect and discard these errors as discrepancies between the disciplined local clock oscillator and the decoded time message produced by the radio clock. Some radio clocks can produce a special PPS signal which can be interfaced to the server platform in a number of ways and used to substantially improve the (disciplined) clock oscillator jitter and wander characteristics by at least an order of magnitude. Using these features it is possible to achieve accuracies in the order of a few tens of microseconds with a fast RISC- based platform.</p>
- <p>There are three ways to implement PPS support, depending on the radio clock model, platform model and serial line interface. These are described in detail in the application notes mentioned in the <a href="index.html">The Network Time Protocol (NTP) Distribution</a> document page. Each of these requires circuitry to convert the TTL signal produced by most clocks to the EIA levels used by most serial interfaces. The <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page describes a device designed to do this. Besides being useful for this purpose, this device includes an inexpensive modem designed for use with the Canadian CHU time/frequency radio station.</p>
- <p>In order to select the appropriate implementation, it is important to understand the underlying PPS mechanism used by ntpd. The PPS support depends on a continuous source of PPS pulses used to calculate an offset within +-500 milliseconds relative to the local clock. The serial timecode produced by the radio or the time determined by NTP in absence of the radio is used to adjust the local clock within +-128 milliseconds of the actual time. As long as the local clock is within this interval the PPS support is used to discipline the local clock and the timecode used only to verify that the local clock is in fact within the interval. Outside this interval the PPS support is disabled and the timecode used directly to control the local clock.</p>
- <h4>Parting Shots</h4>
- There are several undocumented programs which can be useful in unusual cases. They can be found in the <tt>./clockstuff</tt> and <tt>./authstuff</tt> directories of the distribution. One of these is the <tt>propdelay</tt> program, which can compute high frequency radio propagation delays between any two points whose latitude and longitude are known. The program understands something about the phenomena which allow high frequency radio propagation to occur, and will generally provide a better estimate than a calculation based on the great circle distance. Other programs of interest include <tt>clktest</tt>, which allows one to exercise the generic clock line discipline, and <tt>chutest</tt>, which runs the basic reduction algorithms used by the daemon on data received from a serial port.
- <hr>
- <center>
- <img src="pic/pogo1a.gif" alt="gif"></center>
- <br>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
-
-</html>
<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/~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="25" locale="00000409" region="0" t="DateTime" w="61">19:27</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="229">Sunday, July 01, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">01:10</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#synop">Synopsis</a><br>
<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/~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="25" locale="00000409" region="0" t="DateTime" w="99">04:11 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="294">Monday, November 27, 2006</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">01:11</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>More Help</h4>
- <script type="text/javascript" language="javascript" src="scripts/links12.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
<hr>
<h4>Synopsis</h4>
<tt>ntpdc [ -ilnps ] [ -c <i>command</i> ] [ <i>host</i> ] [ ... ]</tt>
<h3><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</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>
<p>The mushroom knows all the command line options.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:07</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="223">Friday, June 16, 2006</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">01:12</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#synop">Synopsis</a><br>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>ntpdsim - Network Time Protocol (NTP) simulator</title>
+ <title>ntpdsim - Network Time Protocol (NTP) Simulator</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
- <h3><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</h3>
+ <h3><tt>ntpdsim</tt> - Network Time Protocol (NTP) Simulator</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>
<p>The mushroom knows all the command line options.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:32</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="223">Friday, June 16, 2006</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:45</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="285">Saturday, January 19, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li><a href="#description">Description</a><br>
<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/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>A typical NTP monitoring packet</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:45</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">01:13</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>More Help</h4>
- <script type="text/javascript" language="javascript" src="scripts/links12.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
<hr>
<h4>Synopsis</h4>
<tt>ntpq [-inp] [-c <i>command</i>] [<i>host</i>] [...]</tt>
<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/~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="25" locale="00000409" region="0" t="DateTime" w="61">18:47</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:06</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 16, 2008</csobj></p>
<br clear="left">
<hr>
<h4>Synopsis</h4>
<tt>ntptrace [ -vdn ] [ -r <i>retries</i> ] [ -t <i>timeout</i> ] [ <i>server</i> ]</tt>
<h4>Description</h4>
- <p><tt>ntptrace</tt> determines where a given Network Time Protocol (NTP) server gets its time from, and follows the chain of NTP servers back to their master time source. If given no arguments, it starts with <tt>localhost</tt>. Here is an example of the output from <tt>ntptrace</tt>:</p>
+ <p><tt>ntptrace</tt> is a <tt>perl</tt> script that uses the <tt>ntpq</tt> utility program to follow the chain of NTP servers from a given host back to the primary time source. For <tt>ntptrace</tt> to work properly, each of these servers must implement the NTP Control and Monitoring Protocol specified in RFC 1305 and enable NTP Mode 6 packets.</p>
+ <p>If given no arguments, <tt>ntptrace</tt> starts with <tt>localhost</tt>. Here is an example of the output from <tt>ntptrace</tt>:</p>
<pre>
% ntptrace
localhost: stratum 4, offset 0.0019529, synch distance 0.144135
<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>
<p>Alice is trying to find the PPS signal connector.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:48</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">22:01</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
+ <h4>Table of Contents</h4>
+ <li class="inline"><a href="#intro">Introduction</a>
+ <li class="inline"><a href="#gadget">Gadget Box</a>
+ <li class="inline"><a href="#opsys">Operating System Support</a>
+ <li class="inline"><a href="#use">Using the Pulse-per-Second (PPS) Signal</a>
<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">
- <h4>Gadget Box</h4>
- <p>The PPS signal can be connected in either of two ways: via the data carrier detector (DCD) pin of a serial port or via the acknowledge (ACK) pin of a parallel port, depending on the hardware and operating system. Note that NTP no longer supports connection via the data leads of a serial port. However, the PPS signal levels are usually incompatible with serial port levels. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional modem designed to decode the radio timecode signals transmitted by Canadian time and frequency station CHU. This can be used with the <a href="drivers/driver7.html">Radio CHU Audio Demodulator/Decoder</a>. A complete set of schematics, PCB artwork and drill templates can be obrtained via the web at <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
- <h4>Operating System Support </h4>
- <p>Both the serial and parallel port connection require operating system support, which is available in only a few operating systems, including FreeBSD, Linux (with PPSkit patch) and Solaris. Support on an experimental basis is available for several other systems, including SunOS and HP/Compaq/Digital Tru64. The PPSAPI application program interface defined in [1] is the only interface currently supported. Older PPS interfaces based on the <tt>ppsclock</tt> and <tt>tty_clk</tt> streams modules are no longer supported. As the PPSAPI is expected to become an IETF cross-platform standard, it should be used by new applications.</p>
- <p>The entire PPS interface functionality is currently provided by inline code in the <tt>timepps.h</tt> header file. While not all implementations support the full PPSAPI specification, they do support all the functions required for the PPS driver described next. The FreeBSD, Linux and Solaris implementations can be used with the stock kernels provided with those systems; however, the Tru64 and SunOS kernels require additional functions not provided in the stock kernels. Solaris users are cautioned that these functions operate improperly in Solaris versions prior to 2.8 with patch Generic_108528-02. Header files for other systems can be found via the web at <a href="ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz">nanokernel.tar.gz</a>.</p>
- <h4>PPS Driver</h4>
- <p>In the preferred mode of operation, PPS signals are processed by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver and other clock drivers which might be involved need not know or care about them. In some cases where there is no other driver, time might be obtained from remote NTP servers via the network and local PPS signals, for instance from a calibrated cesium oscillator, used to stabilize the frequency and remove network jitter. Note that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p>
- <p>The PPS driver operates in conjunction with a preferred peer, as described in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. One of the drivers described in the <a href="refclock.html">Reference Clock Drivers</a> page or another NTP server furnishes the coarse timing and disambiguates the seconds numbering of the PPS signal itself. The NTP daemon mitigates between the clock driver or NTP server and the PPS driver as described in that page in order to provide the most accurate time, while respecting the various types of equipment failures that could happen.</p>
- <p>Some Unix system kernels support a PPS signal directly, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. Specifically, the PPS driver can be used to direct the PPS signal to the kernel for use as a discipline source for both time and frequency. The presence of the kernel support is automatically detected during the NTP build process and supporting code automatically compiled. Note that the PPS driver does not normally enable the PPS kernel code, since performance is generally better without it. However, this code can be enabled by a driver fudge flag if necessary.</p>
- <p>Some configurations may include multiple radio clocks with individual PPS outputs. In some PPSAPI designs multiple PPS signals can be connected to multiple instances of the PPS driver. In such cases the NTP mitigation and grooming algorithms operate with all the radio timecodes and PPS signals to develop the highest degree of redundancy and survivability.</p>
- <h4>Reference</h4>
- <ol>
- <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/mills/database/rfc/rfc2783.txt">ASCII</a>
- </ol>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ <h4 id="intro">Introduction</h4>
+ <p>Most radio clocks are connected using a serial port operating at speeds of 9600 bps. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character like carriage-return <tt><cr></tt>, is normally limited to a hundred microseconds. Using carefuly crafted averaging techniques, the NTP algorithms can whittle this down to a few tens of microseconds. However, some radios produce a PPS signal which can be used to improve the accuracy to few microseconds. This page describes the hardware and software necessar for NTP to use the PPS signal.</p>
+ <div align="center">
+ <img src="pic/gadget.jpg" alt="gif"><br>
+ A Gadget Box built by Chuck Hanavin
+ </div>
+ <h4 id="gadget">Gadget Box</h4>
+ <p>The PPS signal can be connected in either of two ways: via the DCD data carrier detect pin of a serial port or via the ACK acknowledge pin of a parallel port, depending on the hardware and operating system. Note that NTP no longer supports connection via the RD data pin of a serial port.</p>
+ <p>However, the PPS signal levels are usually incompatible with serial port levels. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional modem designed to decode the radio timecode signals transmitted by Canadian time and frequency station CHU. This can be used with the <a href="drivers/driver7.html">Radio CHU Audio Demodulator/Decoder</a>. A complete set of schematics, PCB artwork and drill templates can be obrtained via the web at <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
+ <h4 id="opsys">Operating System Support</h4>
+ <p>Both the serial and parallel port connection require operating system support, which is available in only a few operating systems, including FreeBSD, Linux (with PPSkit patch) and Solaris. Support on an experimental basis is available for several other systems, including SunOS and HP/Compaq/Digital Tru64. The kernel interface described on the <a href="kernpps.html">PPSAPI Interface for Precision Time Signals</a> page is the only interface currently supported. Older PPS interfaces based on the <tt>ppsclock</tt> and <tt>tty_clk</tt> streams modules are no longer supported.</p>
+ <h4>PPS Driver</h4>
+ <p>PPS support requires the PPS driver (described on the <a href="drivers/driver22.html">Type 22 PPS Clock Discipline</a> page. The driver operates in conjunction with a prefer peer, as described in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. The prefer peer is ordinarily the radio clock that provides the PPS signal, but in principle another radio clock or remote Internet server could be designated prerred. A source is desgnated prefer using the <tt>prefer</tt> keyword, as described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> keyword</a> page. Only one source can be designated preferred. PPS signals are processed by the PPS driver and other clock drivers which might be involved need not know or care about PPS capability. Note that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p>
+ <h4 id="pps">Using the Pulse-per-Second (PPS) Signal</h4>
+ <p>The PPS signal can be used in two ways, one using the NTP grooming and mitigations algorithms and the other using PPS signal support in the kernel, as described in the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page. In either case, the PPS signal must be present and within nominal jitter and wander tolerances. In addition, the PPS driver and prefer peer must survive the sanity checks and intersection algorithms. Finally, the offset of the system clock relative to the prefer peer must be less than 128 ms, or well within the 0.5-s unambiguous range. The PPS peer remains active as long as these conditions are met.</p>
+ <p>The presence of PPS kernel support is automatically detected during the NTP configuration process and supporting code automatically compiled. When kernel PPS support is enabled, the PPS driver can direct the signal directly to the kernel. Note that the PPS driver does not normally enable the PPS kernel, since performance is generally better with older systems. However, the kernel can be enabled by a driver fudge flag if necessary. This is advised for newer machines in the Pentium class.</p>
+ <p>The kernel maintains a watchdog timer for the PPS signal; if the signal has not been heard or is out of tolerance for more than some interval, currently two minutes, the kernel discipline is disabled and operation continues as if it were not present. </p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
\ No newline at end of file
<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>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:49</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:20</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/misc.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>
<li class="inline"><a href="#peer">Peer Classification</a>
<li class="inline"><a href="#miti">Mitigation Rules</a>
- <li class="inline"><a href="#pps">Using the Pulse-per-Second (PPS) Signal</a>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
<li>If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to clockhopping, when switching the system peer would not materially improve the time accuracy.
<li>If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification.
</ol>
- <h4 id="pps">Using the Pulse-per-Second (PPS) Signal</h4>
- <p>Most radio clocks are connected using a serial port operating at speeds of 9600 bps or higher. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character, like carriage-return <tt><cr></tt>, is limited to a millisecond or two. However, some radios produce a PPS signal which can be used to improve the accuracy with typical workstation servers to the order of microseconds. The details of how this can be accomplished are discussed in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The following paragraphs discuss how the PPS signal is affected by the mitigation rules.</p>
- <p>First, it should be pointed out that the PPS signal is inherently ambiguous, in that it provides a precise seconds epoch, but does not provide a way to number the seconds. In principle and most commonly, another source of synchronization, either the timecode from an associated radio clock, or even one or more remote NTP servers, is available to perform that function. In all cases, a specific, configured peer or server must be designated as associated with the PPS signal. This is done using the <tt>prefer</tt> keyword as described previously. The PPS signal can be associated in this way with any peer, but is most commonly used with the radio clock generating the PPS signal.</p>
- <p>The PPS signal can be used in two ways to discipline the local clock, one using a special PPS driver described in the <a href="drivers/driver22.html">PPS Clock Discipline</a> page, the other using PPS signal support in the kernel, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. In either case, the signal must be present and within nominal jitter and wander error tolerances. In addition, the associated prefer peer must have survived the sanity checks and intersection algorithms and the dispersion settled below 1 s. This insures that the radio clock hardware is operating correctly and that, presumably, the PPS signal is operating correctly as well. Second, the absolute offset of the local clock from that peer must be less than 128 ms, or well within the 0.5-s unambiguous range of the PPS signal itself. In the case of the PPS driver, the time offsets generated from the PPS signal are propagated via the clock filter to the clock selection procedures just like any other peer. Should these pass the sanity checks and intersection algorithms, they will show up along with the offsets of the prefer peer itself. Note that, unlike the prefer peer, the PPS peer samples are not protected from discard by the clustering algorithm. These complicated procedures insure that the PPS offsets developed in this way are the most accurate, reliable available for synchronization.</p>
- <p>The PPS peer remains active as long as it survives the intersection algorithm and the prefer peer is reachable; however, like any other clock driver, it runs a reachability algorithm on the PPS signal itself. If for some reason the signal fails or displays gross errors, the PPS peer will either become unreachable or stray out of the survivor population. In this case the clock selection remitigates as described above.</p>
- <p>When kernel support for the PPS signal is available, the PPS signal is interfaced to the kernel serial driver code via a modem control lead. As the PPS signal is derived from external equipment, cables, etc., which sometimes fail, a good deal of error checking is done in the kernel to detect signal failure and excessive noise. The way in which the mitigation rules affect the kernel discipline is as follows.</p>
- <p>PPS support requires the PPS driver (type 22) and PPSAPI interface described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. In order to operate, the prefer peer must be designated and the kernel support enabled by the <tt>enable pps</tt> command in the configuration file and the signal must be present and within nominal jitter and wander error tolerances. In the NTP daemon, the PPS discipline is active only when the prefer peer is among the survivors of the clustering algorithm, and its absolute offset is within 128 ms, as determined by the PPS driver. Under these conditions the kernel disregards updates produced by the NTP daemon and uses its internal PPS source instead. The kernel maintains a watchdog timer for the PPS signal; if the signal has not been heard or is out of tolerance for more than some interval, currently two minutes, the kernel discipline is declared inoperable and operation continues as if it were not present.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=windows-1252">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Quick Start</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <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.</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:02</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="292">Monday, December 31, 2007</csobj></p>
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
+ <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 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. The file, called by default <tt>/etc/ntp.conf</tt>, need only contain one line specifying a remote server, for instance</p>
+ <p><tt>server foo.bar.com</tt></p>
+ <p>Choosing an appropriate remote server is somewhat of a black art, but a suboptimal choice is seldom a problem. There are about two dozen public time servers operated by the <a href="http://tf.nist.gov/tf-cgi/servers.cgi">National Institutes of Science and Technology (NIST)</a>, <a href="http://tycho.usno.navy.mil/ntp.html">US Naval Observatory (USNO)</a>, <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/network_time_protocol_e.html"> Canadian Metrology Centre (CMC)</a> and many others available on the Internet. Lists of public primary and secondary NTP servers maintained on the <a href="http://support.ntp.org/bin/view/Servers/WebHome">Public NTP Time Servers</a> page, which is updated frequently.The lists are sorted by country and, in the case of the US, by state. Usually, the best choice is the nearest in geographical terms, but the terms of engagement specified in each list entry should be carefully respected.</p>
+ <p>During operation <tt>ntpd</tt> measures and corrects for incidental clock frequency error and writes the current value to a file specified by the </p>
+ <p><tt>driftfile /etc/ntp.drift</tt></p>
+ <p>command in the configuration file. If <tt>ntpd</tt> is stopped and restarted, it initializes the frequency from this file. In this way the potentially lengthy interval to relearn the frequency error is avoided.</p>
+ <p>That's all there is to it, unless some problem in network connectivity or local operating system configuration occurs. The most common problem is some firewall between the workstation and server. System administrators should understand NTP uses UDP port 123 as both the source and destination port and that NTP does not involve any operating system interaction other than to set the system clock. While almost all modern Unix systems have included NTP and UDP port 123 defined in the services file, this should be checked if <tt>ntpd</tt> fails to come up at all.</p>
+ <p>The best way to confirm NTP is working is using the <a href="ntpq.html"><tt>ntpq</tt></a> utility, although the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility may be useful in extreme cases. See the documentation pages for further information. Don't forget to check for <a href="msyslog.html"> system log messages</a>. In the most extreme cases the <tt>-d</tt> option on the <tt>ntpd</tt> command line results in a blow-by-blow trace of the daemon operations. While the trace output can be cryptic, to say the least, it gives a general idea of what the program is doing and, in particular, details the arriving and departing packets and any errors found.</p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Rate Management and the Kiss-o'-Death</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>Rate Management and the Kiss-o'-Death Packet</h3>
+ <img src="pic/alice61.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>Packet blizzard</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">17:55</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="292">Monday, December 31, 2007</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
+ <h4>Table of Contents</h4>
+ <ul>
+ <li class="inline"><a href="#intro">Introduction</a>
+ <li class="inline"><a href="#poll">Poll Rate Control</a>
+ <li class="inline"><a href="#burst">Burst Control</a>
+ <li class="inline"><a href="#mah">Minimum Average Headway</a>
+ <li class="inline"><a href="#mgt">Minimum Guard Time</a>
+ <li class="inline"><a href="#kod">The Kiss-o'-Death Packet</a>
+ </ul>
+ <hr>
+ <h4 id="intro">Introduction</h4>
+ <p>Some national time metrology laboratories, including NIST and USNO, use the <tt>ntpd</tt> reference implementation in their very busy public time servers. They operate multiple servers behind load-balancing devices to support aggregate rates up to several thousand packets per second. The servers need to defend themselves against all manner of broken implementations that can clog the server and and network infrastructure. On the other hand, friendly <tt>ntpd</tt> clients need to avoid configurations that can result in unfriendly rates.</p>
+ <p>There are several features in <tt>ntpd</tt> designed to defend the servers, clients and network against accidental or intentional flood attack. On the other hand these features are also used to insure <tt>ntpd</tt> is a good citizen, even if configured in unfriendly ways. The ground rules are:</p>
+ <ul>
+ <li>Send at the lowest rate consistent with the required nominal error regime.<li>Maintain strict minimum average headway and guard intervals, even if multiple burst options and/or the Autokey protocol are configured.<li>When the first packet of a burst is sent to a server, do not send further packets until the first packet has been received from the server.<li>Upon receiving a Kiss-o'-Death packet (see below), immediately reduce the sending rate.
+ </ul>
+ <p>Rate management involves four algorithms to control the poll rate control, burst control, minimum average headway and minimum guard time. These are described in following sections.</p>
+ <h4 id="poll">Poll Rate Control</h4>
+ <p>In the <tt>ntpd</tt> design control of the poll interval is an intricate balance between nominal error and network load. As a rule of thumb, if the poll interval increases by 100 percent, nominal error increases by 50 percent. For the default poll interval range from 64 s to 1024 s, this represents an eightfold range in nominal error. Nevertheless and unless the lowest possible nominal error is required, the well mannered NTP client should allow the interval to increase to the maximum when possible.</p>
+ <p>The poll interval is proportional to the time constant of the feedback loop which controls the system clock time and frequency. The optimum time constant depends on the network time jitter and the clock oscillator frequency wander. Errors due to jitter are reduced as the time constant increases, while errors due to wander are decreased as the time constant decreases. The two error characteristics intersect at a point called the Allan intercept. The poll algorithm follows the intercept in response to changing jitter and wander conditions. However, the intercept has a relatively broad characteristic, so the algorithm is biased towards the high side in the interests of reduced network load.</p>
+ <p>The <tt>ntpd</tt> poll interval algorithms slowly but reliably increases the poll interval when jitter dominates the error budget, but quickly reduces the interval when wander dominates it. In addition it avoids needless changes which can cause additional error, especially when operating at very low jitter in the order of microseconds.</p>
+ <p>In <tt>ntpd</tt> the poll interval is represented in log<sub>2</sub> s, so the actual values span the range 6-10. The algorithm uses a jiggle counter which operates over the range from -30 to +30 and is initialized at 0. If the measured offset is less than four times the measured average jitter, the counter is increased by the poll interval; if not, it is decreased by twice the poll interval. If the counter reaches +30, the poll interval is incremented by 1; if the counter reaches -30, the poll interval is decremented by 1. In either case the counter is set to 0.</p>
+ <h4 id="burst">Burst Control</h4>
+ <p>Occasionally it is necessary to send packets at intervals less than the poll interval. For instance, with the burst and iburst options, the poll algorithm sends a burst of several packets at 2-s intervals. The <tt>ntpd</tt> poll algorithm avoids sending needless packets if the server is not responding. If a burst is to be sent, the client sends only a single packet. When the first packet is received from the server, the client continues with the remaining packets in the burst. If the first packet is not received within 64 s, it will be sent again for two additional retries before giving up. The result is to minimize network load if the server is not responding.</p>
+ <p>For the iburst option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the burst option, the number of packets in the burst is determined by the poll interval so that the headway is never less than 16 s. For instance, if operated at the minimum poll interval of 16 s, only a single packet is sent, while the full number of eight packets is sent at poll intervals of 128 s or more.</p>
+ <h4 id="mah">Minimum Average Headway</h4>
+ <p>There are features in <tt>ntpd</tt> to manage the interval between one packet and the next. These features make use of a set of counters, an output counter for each client association and an input counter for each distinct client address. Each counter increments by a value called the headway when a packet is processed and decrements by one each second. The default headway in <tt>ntpd</tt> is 16 s, but this can be changed using the <tt>discard average</tt> command.</p>
+ <p>If the iburst or burst options are present, the poll algorithm sends a burst of packets, instead of a single packet at each poll. The NTPv4 specification requires that bursts contain no more than eight packets; so, starting from an output counter value of zero, the maximum counter value can be no more than 128, called the output ceiling. However, if the burst starts with a counter value other than zero, there is a potential to exceed the ceiling. The poll algorithm avoids this by computing an additional interpacket delay so that the next packet sent will not exceed the ceiling. With this design the long term maximum average headway is never less than 16 s. Designs such as this are often called leaky buckets.</p>
+ <p>The <tt>ntpd</tt> input packet routine uses a special list of entries for each distinct client found. Each entry includes the IP address, input counter and time of the most recent arrival. The entries are ordered by time of arrival, most recent first. As each packet arrives, the IP source address is compared to the IP address in each entry in turn. If a match is found the entry is removed and inserted first on the list. If the IP address does not match any entry, a new entry is created and inserted first, possibly discarding the last entry on the list if it is full. Observers will note this is the same algorithm used for page replacement in virtual memory systems.</p>
+ <p>In the virtual memory algorithm the entry of interest is the last, whereas here the entry of interest is the first. The input counter is decreased by the time since it was last referenced, but not below zero. If the value of the counter plus the headway is greater than the input ceiling of 128, the packet is discarded. Otherwise, the counter is increased by the headway and the packets processed. The result is, if the client maintains a maximum average headway not less than 16 s and transmits no more than eight packets in a burst, the input counter will not exceed the input ceiling.</p>
+ <h4 id="mgt">Minimum Guard Time</h4>
+ <p>A review of past client abuse incidence shows the most frequent scenario is a broken client that attempts to send a number of packets at rates of one per second or less. There have been occasions where this abuse has persisted for days at a time. These scenarios are the most damaging, as they can threaten not only the victim server but the network infrastructure as well.</p>
+ <p>In the <tt>ntpd</tt> server design the minimum headway between the last packet received and the current packet is called the guard time. If the headway is less than the guard time, the packet is discarded. The guard time defaults to 2 s, but this can be changed using the <tt>discard minimum</tt> command.</p>
+ <h4 id="kod">The Kiss-o'-Death Packet</h4>
+ <p>As an optional feature <tt>ntpd</tt> sends a special packet called the Kiss-o'-Death (KoD) packet, when either the minimum average headway or minimum guard time is violated. The KoD is a packet with leap bits 11, stratum 0 and reference ID field other than 0. In this case the reference ID field is a four-character ASCII string, called the kiss code, showing the reason for the KoD. At present, only one kiss code, RATE, is used to tell the client to slow down. In order to make sure the client notices the KoD, the receive and transmit timestamps are set to the transmit timestamp of the client packet and all other fields left as in the client packet. Thus, even if the client ignores the KoD indication, it cannot do any useful time computations. KoDs themselves are rate limited to no more than two per second in order to deflect a flood attack.</p>
+ <p>There is some controversy about the discard and KoD provisions. The nature of the datagram service supporting NTP provides no way to throttle cleints other than behaving badly. Clients are strongly advised to support the KoD, but there are no legal or societal statutes requiring it. The reference implementation responds to a KoD by permanantly disabling the association, but then it should never ignite a KoD unless the <tt>discard</tt> commands are abused.</p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
<h3>Debugging Reference Clock Drivers</h3>
<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="25" locale="00000409" region="0" t="DateTime" w="61">18:49</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">01:24</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Saturday, November 24, 2007</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
- <h4>More Help</h4>
- <script type="text/javascript" language="javascript" src="scripts/links12.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/install.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 occurred 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>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">13:06</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="298">Wednesday, August 10, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:45</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="286">Thursday, January 03, 2008</csobj></p>
<br clear="left">
<h4>Related Links</h4>
- <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>
- </p>
- <h4>Audio Driver Links</h4>
- <p>
- <script type="text/javascript" language="javascript" src="scripts/links8.txt"></script>
- </p>
+ <script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
<h4>Table of Contents</h4>
<ul>
- <li class="inline"><a href="#clock">Reference Clock Drivers</a>
+ <li class="inline"><a href="#clock">Introduction</a>
<li class="inline"><a href="#cal">Driver Calibration</a>
- <li class="inline"><a href="#perf">Performance Enhancements</a>
<li class="inline"><a href="#list">Comprehensive List of Clock Drivers</a>
</ul>
<hr>
- <h4 id="clock">Reference Clock Drivers</h4>
- <p>Support for most of the commonly available radio and modem reference clocks is included in the default configuration of the NTP daemon for Unix <tt>ntpd</tt>. Individual clocks can be activated by configuration file commands, specifically the <tt>server</tt> and <tt>fudge</tt> commands described in the <a href="ntpd.html"><tt>ntpd</tt> program manual page</a>. The following discussion presents Information on how to select and configure the device drivers in a running Unix system.</p>
- <p>Many radio reference clocks can be set to display local time as adjusted for timezone and daylight saving mode. For use with NTP the clock must be set for Coordinated Universal Time (UTC) only. Ordinarily, these adjustments are performed by the kernel, so the fact that the clock runs on UTC will be transparent to the user.</p>
- <p>Radio and modem clocks by convention have addresses in the form 127.127.<i>t.u</i>, where <i>t</i> is the clock type and <i>u</i> is a unit number in the range 0-3 used to distinguish multiple instances of clocks of the same type. Most of these clocks require support in the form of a serial port or special bus peripheral, but some can work directly from the audio codec found in some workstations. The particular device is normally specified by adding a soft link <tt>/dev/device<i>u</i></tt> to the particular hardware device involved, where <i><tt>u</tt></i> correspond to the unit number above.</p>
- <p>Most clock drivers communicate with the reference clock using a serial port, usually at 9600 bps. There are several application program interfaces (API) used in the various Unix and NT systems, most of which can be detected at configuration time. Thus, it is important that the NTP daemon and utilities be compiled on the target system or clone. In some cases special features are available, such as timestamping in the kernel or pulse-per-second (PPS) interface. In most cases these features can be detected at configuration time as well; however, the kernel may have to be recompiled in order for them to work.</p>
- <p>The
audio drivers are a special case. These include support for the NIST time/frequency stations WWV and WWVH, the Canadian time/frequency station CHU and generic IRIG signals. Currently, support for the Solaris and SunOS audio API is included in the distribution. It is left to the volunteer corps to extend this support to other systems. Further information on hookup, debugging and monitoring is given in the <a href="audio.html">Audio Drivers</a> page.</p>
- <p>The local clock driver is also a special case. A server configured with this driver can operate as a primary server to synchronize other clients when no other external synchronization sources are available. If the server is connected directly or indirectly to the public Internet, there is some danger that it can adversely affect the operation of unrelated clients. Carefully read the <a href="drivers/driver1.html">Undisciplined Local Clock</a> page and respect the stratum limit.</p>
- <p>The local clock driver
also supports an external synchronization source such as a high resolution counter disciplined by a GPS receiver, for example. Further information is on the <a href="extern.html">External Clock Discipline and the Local Clock Driver</a> page.</p>
+ <h4 id="clock">Introduction</h4>
+ <p>Drivers for most radio and modem reference clocks is included by default in the NTP distribution. Individual drivers can be activated using <tt>server</tt> commands as described in the <a href="ntpd.html"><tt>ntpd</tt> program manual page</a>. Drivers have addresses in the form 127.127.<i>t.u</i>, where <i>t</i> is the driver type and <i>u</i> is a unit number in the range 0-3 to distinguish multiple instances of the same driver. Most drivers require a serial or parallel port or special bus peripheral, but some can work directly from an audio codec or sound card when availble. The particular device is specified by adding a soft link from the name used by the driver to the device name.</p>
+ <p>All radio clock drivers require that the radio be set for Coordinated Universal Time (UTC) only. Timezone and standard/daylight adjustments are performed by the kernel. There are difference in the various Unix and Windows port interfaces detected at configuration time, so it is important that the NTP daemon and utilities be compiled on the target system or clone.</p>
+ <p>When a pulse-per-second (PPS) signal is available, the <a href="drivers/driver22.html"> PPS Clock Discipline</a> driver is can be used. It normally works in conjunction with the reference clock that produces the signal, but can work with another driver or remote server. When PPS kernel features are present, the driver can redirect the PPS signal to the kernel.</p>
+ <p>In general, performance can be improved, especially when more than one driver is supported, to use the prefer peer function described in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. The prefer peer is ordinarily designated the remote peer or local clock driver which provides the best quality time. All other things equal, only the prefer peer is used to discipline the system clock and jitter-producing "clockhopping" between sources is avoided. This is especially valuable when the PPS clock discipline driver is available.</p>
+ <p>The
re are audio drivers for each of the NIST time stations WWV and WWVH, Canadian time station CHU and generic IRIG signals. Currently, support for FreeBSD, Solaris and SunOS is in the distribution. It is left to the volunteer corps to confirm this works in other systems. Further information on hookup, debugging and monitoring is given in the <a href="audio.html">Audio Drivers</a> page.</p>
+ <p>The <a href="drivers/driver1.html"> Undisciplined Local Clock</a> driver can simulate a reference clock when no external synchronization sources are available. If a server with this driver is connected directly or indirectly to the public Internet, there is some danger that it can destabilize other clients. It is not recommended that the loccal clock driver be used in this way, as the orphan mode descibed on the <a href="assoc.html">Association Management</a> page provides a generic backup capability.</p>
+ <p>The local clock driver
can also be used when an external synchronization source such as the IEEE 1588 Precision Time Protocol or NIST Lockclock directly synchronizes the computer time. Further information is on the <a href="extern.html">External Clock Discipline and the Local Clock Driver</a> page.</p>
<h4 id="cal">Driver Calibration</h4>
- <p>Some drivers depending on longwave and shortwave radio services need to know the radio propagation time from the transmitter to the receiver, which can amount to some tens of milliseconds. This must be calculated for each specific receiver location and requires the geographic coordinates of both the transmitter and receiver. The transmitter coordinates for various radio services are given in the <a href="http://www.eecis.udel.edu/%7emills/ntp/qth.html">Time and Frequency Standard Station Information</a> page. Receiver coordinates can be obtained or estimated from various sources. The actual calculations are beyond the scope of this document.</p>
- <p>When more than one clock driver is supported, it is often the case that each shows small systematic offset differences relative to the rest. To reduce the effects of jitter when switching from one driver to the another, it is useful to calibrate the drivers to a common ensemble offset. The <tt>enable calibrate</tt> configuration command in the <a href="miscopt.html">Miscellaneous Options</a> page is useful for this purpose. The calibration function can also be enabled and disabled using the <tt>ntpdc</tt> program utility.</p>
- <p>Most clock drivers use the <tt>time1</tt> value specified in the <tt>fudge</tt> configuration command to provide the calibration correction when this cannot be provided by the clock or interface. When the calibration function is enabled, the <tt>time1</tt> value is automatically adjusted to match the offset of the remote server or local clock driver selected for synchronization. Ordinarily, the NTP selection algorithm chooses the best from among all sources, usually the best radio clock determined on the basis of stratum, synchronization distance and jitter. The calibration function adjusts the <tt>time1</tt> values for all clock drivers except this source so that their indicated offsets tend to zero. If the selected source is the kernel PPS discipline, the <tt>fudge time1</tt> values for all clock drivers are adjusted.</p>
- <p>The adjustment function is an exponential average designed to improve accuracy, so the function takes some time to converge. The recommended procedure is to enable the function, let it run for an hour or so, then edit the configuration file using the <tt>time1</tt> values displayed by the <tt>ntpq</tt> utility and <tt>clockvar</tt> command. Finally, disable the calibration function to avoid possible future disruptions due to misbehaving clocks or drivers.</p>
- <h4 id="perf">Performance Enhancements</h4>
- <p>In general, performance can be improved, especially when more than one clock driver is supported, to use the prefer peer function described in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. The prefer peer is ordinarily designated the remote peer or local clock driver which provides the best quality time. All other things equal, only the prefer peer source is used to discipline the system clock and jitter-producing "clockhopping" between sources is avoided. This is valuable when more than one clock driver is present and especially valuable when the PPS clock driver (type 22) is used. Support for PPS signals is summarized in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
- <p>Where the highest performance is required, generally better than one millisecond, additional hardware and/or software functions may be required. Kernel modifications for precision time are described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. Special line discipline and streams modules for use in capturing precision timestamps are described in the <a href="ldisc.html">Line Disciplines and Streams Drivers</a> page.</p>
+ <p>Some drivers depending on longwave or shortwave radio services need to know the radio propagation time from the transmitter to the receiver. This must be calculated for each specific receiver location and requires the geographic coordinates of both the transmitter and receiver. The transmitter coordinates for various radio services are given in the <a href="http://www.eecis.udel.edu/%7emills/ntp/qth.html">Time and Frequency Standard Station Information</a> page. Receiver coordinates can be obtained locally or from Google Earth. The actual calculations are beyond the scope of this document.</p>
+ <p>Depending on interface type, port speed, etc., a reference clock can have a small residual offset relative to another. To reduce the effects of jitter when switching from one driver to the another, it is useful to calibrate the drivers to a common ensemble offset. The <tt>enable calibrate</tt> configuration command described on the <a href="miscopt.html">Miscellaneous Options</a> page activates a special feature which automatically calculates a correction factor for each driver relative to an association designated the prefer peer.</p>
<h4 id="list">Comprehensive List of Clock Drivers</h4>
- <p>Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, driver ID, device name and serial line speed
, and features (line disciplines, etc.). For those drivers without specific documentation, please contact the author listed in the <a href="copyright.html">Copyright Notice</a> page.</p>
+ <p>Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, driver ID, device name and serial line speed. For those drivers without specific documentation, please contact the author listed in the <a href="copyright.html">Copyright Notice</a> page.</p>
<ul>
<li class="inline"><a href="drivers/driver1.html">Type 1</a> Undisciplined Local Clock (<tt>LOCAL</tt>)
<li class="inline"><a href="drivers/driver2.html">Type 2</a> Trak 8820 GPS Receiver (<tt>GPS_TRAK</tt>)
<li class="inline"><a href="drivers/driver3.html">Type 3</a> PSTI/Traconex 1020 WWV/WWVH Receiver (<tt>WWV_PST</tt>)
- <li class="inline"><a href="drivers/driver4.html">Type 4</a> Spectracom WWVB and GPS Receivers (<tt>WWVB_SPEC</tt>)
+ <li class="inline"><a href="drivers/driver4.html">Type 4</a> Spectracom WWVB/GPS Receivers (<tt>WWVB_SPEC</tt>)
<li class="inline"><a href="drivers/driver5.html">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers (<tt>TRUETIME</tt>)
<li class="inline"><a href="drivers/driver6.html">Type 6</a> IRIG Audio Decoder (<tt>IRIG_AUDIO</tt>)
<li class="inline"><a href="drivers/driver7.html">Type 7</a> Radio CHU Audio Demodulator/Decoder (<tt>CHU</tt>)
<li class="inline">Type 15 reserved
<li class="inline"><a href="drivers/driver16.html">Type 16</a> Bancomm GPS/IRIG Receiver (<tt>GPS_BANCOMM</tt>)
<li class="inline">Type 17 Datum Precision Time System (<tt>GPS_DATUM</tt>)
- <li class="inline"><a href="drivers/driver18.html">Type 18</a> Automated Computer Time Service (<tt>ACTS_MODEM</tt>)
+ <li class="inline"><a href="drivers/driver18.html">Type 18</a> NIST/USNO/PTB Modem Time Services (<tt>ACTS_MODEM</tt>)
<li class="inline"><a href="drivers/driver19.html">Type 19</a> Heath WWV/WWVH Receiver (<tt>WWV_HEATH</tt>)
<li class="inline"><a href="drivers/driver20.html">Type 20</a> Generic NMEA GPS Receiver (<tt>NMEA</tt>)
<li class="inline">Type 21 TrueTime GPS-VME Interface (<tt>GPS_VME</tt>)
<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</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">15:17</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="307">Wednesday, October 31, 2007</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:47</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="276">Tuesday, January 01, 2008</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.</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 Windows NT and XP. 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 other Windows versions, VMS and various reference clock drivers. Bugs can be reported <a href="bugs.html">here</a>.</p>
+ <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 25 years and the paint still isn't dry.</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 Windows NT and XP. 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 other Windows versions, VMS and various reference clock drivers.</p>
<p>This release has been compiled and tested on many systems, including SunOS 4.1.3, Solaris 2.5.1-2.10, Alpha Tru64 4.0-5.1, Ultrix 4.4, Linux 2.4.2, FreeBSD 4.5-6.2 and HP-UX 10.02. It has been compiled and tested by others on Windows NT4, 2000 and XP, but not yet on other Windows versions or for VMS. There are several new features apparently incompatible with Linux systems, including some modes used with the Autokey protocol. The developer corps looks for help elsewhere to resolve these differences.</p>
<p>This note summarizes the differences between this software release of NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called xntp3-5.x.x.</p>
<h4>New Features</h4>
<ol>
- <li>Support for the IPv6 addressing family is included in this distribution. If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is generated in addition to the default support for the IPv4 address family. Combination IPv6 and IPv4 configurations have been successfully tested in all protocol modes supported by NTP and using both symmetric and public key (Autokey) cryptography.<li>Most calculations are now done using 64-bit floating double format, rather than 64-bit fixed point format. The motivation for this is to reduce size, improve speed and avoid messy bounds checking. Workstations of today are much faster than when the original NTP version was designed in the early 1980s, and it is rare to find a processor architecture that does not support floating double. The fixed point format is still used with raw timestamps, in order to retain the full precision of about 212 picoseconds. However, the algorithms which process raw timestamps all produce fixed point differences before converting to floating double. The differences are ordinarily quite small so can be expressed without loss of accuracy in this format.
-
- <li>The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow increased in poll intervals to 36 hours with only moderate sacrifice in accuracy.</ol>
- <ul>
- <ul>
- <li>A new feature called <i>huffpuff</i> maximizes accuracy in cases of highly asymmetric network delays typical of ISDN and modem access circuits.
- <li>The NTPv4 design allows clients to increase the poll intervals even when synchronized directly to the server. In NTPv3 the poll interval in such cases was clamped to the minimum, usually 64 s. For those servers with hundreds of clients, the new design can dramatically reduce the network load, especially when large numbers of potential clients, as in national laboratory services.
- <li>A scheme designed to reduce "clockhopping" when the choice of servers changes frequently as the result of comparatively insignificant quality changes.
- </ul>
- </ul>
- <ol>
- <li>This release includes support for the <a href="ftp://ftp.udel.edu/usa/ftp/pub/ntp/software/"><i>nanokernel</i></a> precision time kernel support, which is now in stock FreeBSD and optional Linux kernels. If a precision time source such as a GPS timing receiver or cesium clock is available, kernel timekeeping can be improved to the order of one microsecond. The older <i>microtime</i> kernel for Digital/Compaq/HP Tru64, Digital Ultrix, as well as Sun Microsystems SunOS and Solaris, continues to be supported.
- <li>This release includes support for Autokey public-key cryptography, which is the preferred scheme for authenticating servers to clients. Autokey Version 2 uses NTP header extension fields and protocols as described on the NTP project page linked from www.ntp.org. This release includes support for additional message digest and digital signature schemes supported by the OpenSSL software library, as well as new identity schemes based on cryptographic challenge/responce algorithms. The new design greatly simplifies key generation and distribution and provides orderly key refreshment. Security procedures and media formats are consistent with industry standard X.509 Version 3 certificates and authority procedures. Specific improvements to the protocol include a reduction in the number of messages required and a method to protect the cookie used in client/server mode against disclosure. Additional information about Autokey cryptography is contained in the <a href="authopt.html">Authentication Options</a> page and links from there. See also the new <tt>cryptostats</tt> monitoring statistics file in the <a href="monopt.html">Monitoring Options</a> page.
+ <li>Support for the IPv6 addressing family is included in this distribution. If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is generated in addition to the default support for the IPv4 address family.<li>Most calculations are now done using 64-bit floating double format, rather than 64-bit fixed point format. The motivation for this is to reduce size, improve speed and avoid messy bounds checking.<li>The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow increased in poll intervals to 36 hours with only moderate sacrifice in accuracy.
+ <li>A new feature called "huffpuff" maximizes accuracy in cases of highly asymmetric network delays typical of ISDN and telephone modems.
+ <li>The clock selection algorithm has been redesigned to reduce "clockhopping" when the choice of servers changes frequently as the result of comparatively insignificant quality changes.
+ <li>This release includes support for the <a href="ftp://ftp.udel.edu/usa/ftp/pub/ntp/software/">nanokernel</a> precision time kernel modifications, which are now in stock FreeBSD and optional in Linux kernels. With this support the system clock can be disciplined to the order of one nanosecon. The older microtime kernel modifications in Digital/Compaq/HP Tru64, Digital Ultrix and Sun Microsystems SunOS and Solaris, continue to be supported. In either case the support eliminates sawtooth error, which can be in the hundreds of microseconds.
+ <li>This release includes support for Autokey public-key cryptography, which is the preferred scheme for authenticating servers to clients. Additional information about Autokey cryptography is on the <a href="authopt.html">Authentication Options</a> page and links from there. See also the new <tt>cryptostats</tt> monitoring statistics file in the <a href="monopt.html">Monitoring Options</a> page.
+ <li>The OpenSSL cryptographic library has replaced the library formerly available from RSA Laboratories. All cryptographic routines except a version of the MD5 message digest routine have been removed from the base distribution.<li>As the result of the above, the <tt>authstuff</tt> directory, intended as a development and testing aid for porting cryptographic routines to exotic architectures, has been removed. Testing and conformance validation tools are in the OpenSSL software distrbution.
<li>This release includes support for a discrete event simulator (DES), which allows the NTP algorithms to be tested in an embedded environment with systematic and pseudorandom network delay and oscillator wander distributions. This has been used to verify correct operation under conditions of extreme error and misconfiguration. See the <a href="ntpdsim.html"><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a> page.
- <li>NTPv4 includes two new association modes which in most applications can avoid per-host configuration altogether. Both of these are based on IP multicast technology and Autokey cryptography. They provide automatic discovery, configuration and authentication of servers and clients without identifying servers or clients in advance. In multicast mode a server sends a message at fixed intervals using specified multicast group addresses, while clients listen on these addresses.
- <p>Upon receiving the the first message, a client exchanges several messages with the server in order to calibrate the multicast propagation delay between the client and server and run the authentication protocol. In manycast mode a client sends a message to a specified multicast group address and expects one or more servers to reply. Using engineered algorithms, the client selects an appropriate subset of servers from the messages received and continues an ordinary client/server campaign. The manycast scheme can provide somewhat better accuracy than the multicast scheme at the price of additional network overhead. See the <a href="manyopt.html">Automatic NTP Configuration Options</a> page for further information.</p>
- <li>This release includes support for the orphan mode, which replaces the local clock driver for most configurations. The local clock driver provides a synchronization source for networks not connected to the public Internet or reference clock driver. However, it does not opperate with multiple sources nor multiple failures. The orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It can be used in isolated networks or in Internet subnets where the servers or Internet connection have failed. See the <a href="manyopt.html">Automatic NTP Configuration Options</a> page for further information.<li>This release includes support for preemptable servers, which are provisionally mobilized in manycast mode or by participants in the pool scheme. Manycast mode is described in these notes. In the pool scheme multiple client associations are mobilized for a designated DNS name such as pool.ntp.org. The DNS resolver randomizes replies over a set of volunteer service providers. The NTP mitigation algorithms select the best three from among the set and demobilizes the excess. See the <a href="manyopt.html">Automatic NTP Configuration Options</a> page for further information.<li>There are two burst mode features available where special conditions apply. One of these is enabled by the <tt>iburst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where it is important to set the clock quickly when an association is first mobilized. The other is enabled by the <tt>burst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where the network attachment requires an initial calling or training procedure. See the <a href="assoc.html">Association Management</a> page for further information.
- <li>The reference clock driver interface is smaller, more rational and more accurate. Support for pulse-per-second (PPS) signals has been extended to all drivers as an intrinsic function. Most of the drivers in NTPv3 have been converted to the NTPv4 interface and continue to operate as before. New drivers have been added for several GPS receivers now on the market for a total of 44 drivers. Audio drivers for the Canadian standard time and frequency station CHU, the US standard time and frequency stations WWV/H and for IRIG signals have been updated and capabilities added to allow direct connection of these signals to a Sun or FreeBSD audio port. See the <a href="audio.html">Reference Clock Audio Drivers</a> page for further information.
+ <li>NTPv4 includes three new server discovery schemes, which in most applications can avoid per-host configuration altogether. Two of these are based on IP multicast technology, while the remaining one is based on crafted DNS lookups. See the <a href="manyopt.html">Automatic NTP Configuration Schemes</a> page for further information.
+ <li>This release includes comprehensive packet rate management tools to help reduce the level of spurious network traffic and protect the busiest servers from overload. See the <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a> page for further information.
+ <li>This release includes support for the orphan mode, which replaces the local clock driver for most configurations. Orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It can be used in isolated networks or in Internet subnets where the servers or Internet connection have failed. See the <a href="manyopt.html">Automatic NTP Configuration Options</a> page for further information.
+
+ <li>There are two new burst mode features available where special conditions apply. One of these is enabled by the <tt>iburst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where it is important to set the clock quickly when an association is first mobilized. The other is enabled by the <tt>burst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where the network attachment requires an initial calling or training procedure. See the <a href="assoc.html">Association Management</a> page for further information.
+
+ <li>The reference clock driver interface is smaller, more rational and more accurate. Support for pulse-per-second (PPS) signals has been extended to all drivers as an intrinsic function. Most of the drivers in NTPv3 have been converted to the NTPv4 interface and continue to operate as before. New drivers have been added for several GPS receivers now on the market for a total of 44 drivers. Audio drivers for the Canadian standard time and frequency station CHU, the US standard time and frequency stations WWV/H and for IRIG signals have been updated and capabilities added to allow direct connection of these signals to an audio port. See the <a href="audio.html">Reference Clock Audio Drivers</a> page for further information.
+
<li>In all except a very few cases, all timing intervals are randomized, so that the tendency for NTPv3 to self-synchronize and bunch messages, especially with a large number of configured associations, is minimized.
- <li>In NTPv3 a large number of weeds and useless code had grown over the years since the original NTPv1 code was implemented almost twenty years ago. Using a powerful weedwacker, much of the shrubbery has been removed, with effect a substantial reduction in size of almost 40 percent.
- <li>The entire distribution has been converted to gnu <tt>automake</tt>, which should greatly ease the task of porting to new and different programming environments, as well as reduce the incidence of bugs due to improper handling of idiosyncratic kernel functions. Version control is provided by <tt>Bitkeeper</tt> using an online repository at www.ntp.org.
- <li>Several new options have been added for the <tt>ntpd</tt> command line. For the inveterate knob twiddlers several of the more important performance variables can be changed to fit actual or perceived special conditions. In particular, the tos command can be used to limit the accepted stratum range, specify minimum dispersion increment and maximum selection theshold, and activate orphan mode.
+ <li>In NTPv3 a large number of weeds and useless code had grown over the years since the original NTP code was implemented 25 years ago. Using a powerful weedwacker, much of the shrubbery has been removed, with effect a substantial reduction in size of almost 40 percent.
+ <li>The entire distribution has been converted to gnu <tt>automake</tt>, which should greatly ease the task of porting to new and different programming environments, as well as reduce the incidence of bugs due to improper handling of idiosyncratic kernel functions. Version control is provided by Bitkeeper using an online repository at www.ntp.org. Trouble ticket reporting is provided using Bugzilla.
+ <li>Several new options have been added for the <tt>ntpd</tt> command line. For the inveterate knob twiddlers several of the more important performance variables can be changed to fit actual or perceived special conditions. In particular, the <tt>tos</tt> and <tt>tos</tt> commands can be used to adjust thresholds, throw switches and change limits.
<li>The <tt>ntpd</tt> daemon can be operated in a one-time mode similar to <tt>ntpdate</tt>, which program is headed for retirement. See the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page for the new features.
</ol>
<h4>Nasty Surprises</h4>
<p>There are a few things different about this release that have changed since the latest NTP Version 3 release. Following are a few things to worry about:</p>
<ol>
- <li>When both IPv4 and IPv6 address families are in use, the host's resolver library may not choose the intended address family if a server has an IPv4 and IPv6 address associated with the same DNS name. The solution is to use the IPv4 or IPv6 address directly in such cases or use another DNS name that resolves to the intended address family. Older versions of <tt>ntpdc</tt> will only show the IPv4 associations with the <tt>peers</tt> and other simular commands. Older versions of <tt>ntpq</tt> will show 0.0.0.0 for IPv6 associations with the <tt>peers</tt> and other simular commands.
- <li>There is a minor change to the reference ID field of the NTP packet header when operating with IPv6 associations. In IPv4 associations this field contains the 32-bit IPv4 address of the server, in order to detect and avoid loops. In IPv6 associations this field contains the first 32-bits of a MD5 hash formed from the address (IPv4 or IPv6) each of the configured associations. Normally, this detail would not be of concern; however, the <tt>ntptrace</tt> program originally depended on that field in order to display a server traceback to the primary reference source. This program has now been replaced by a script that does the same function, but does not depend on the reference ID field. The <tt>ntpdc</tt> utility now uses a special version number to communicate with the <tt>ntpd</tt> server. The server uses this version number to select which address family to used in reply packets. The <tt>ntpdc</tt> program falls back to the older version behavior when communicating with older NTP versions.
- <li>As required by Defense Trade Regulations (DTR), the cryptographic routines supporting the Data Encryption Standard (DES) have been removed from the base distribution of NTPv3. For NTPv4 a new interface has been implemented for the OpenSSL cryptographic library, which is widely available on the web at www.openssl.org. This library replaces the library formerly available from RSA Laboratories. Besides being somewhat faster and more widely available, the OpenSSL library supports many additional cryptographic algorithms, which are now selectable at run time. Directions for using OpenSSL are in the <a href="build/build.html">Building and Installing the Distribution</a> page.
- <li>As the result of the above, the <tt>./authstuff</tt> directory, intended as a development and testing aid for porting cryptographic routines to exotic architectures, has been removed. Testing and conformance validation tools are in the OpenSSL software distrbution.
- <li>The NTPv4 enable and disable commands have a few changes in the arguments. See the <tt>ntpd</tt> <a href="miscopt.html">Miscellaneous Options</a> page for details. Note that the <tt>authenticate</tt> command has been removed.
- <li>To help reduce the level of spurious network traffic due to obsolete configuration files, a special control message called the <i>kiss-o'-death</i> packet has been implemented. If enabled and a packet is denied service or exceeds the client limits, a compliant server will send this message to the client. A compliant client will cease further transmission and send a message to the system log. See the <a href="accopt.html">Authentication Options</a> page for further information.
+ <li>Some configuration commands have been removed, others added and some changed in minor ways. See the Commands and Options collection on the <a href="sitemap.html">Site Map</a> page.
+ <li>When both IPv4 and IPv6 address families are in use, the host's resolver library may not choose the intended address family if a server has an IPv4 and IPv6 address associated with the same DNS name. The solution is to use the IPv4 or IPv6 address directly in such cases or use another DNS name that resolves to the intended address family. Older versions of <tt>ntpdc</tt> will show only the IPv4 associations with the <tt>peers</tt> and some other commands. Older versions of <tt>ntpq</tt> will show 0.0.0.0 for IPv6 associations with the <tt>peers</tt> and some other commands.<li>There is a minor change to the reference ID field of the NTP packet header when operating with IPv6 associations. In IPv4 associations this field contains the 32-bit IPv4 address of the server, in order to detect and avoid loops. In IPv6 associations this field contains the first 32-bits of a MD5 hash formed from the IPv6 address. All programs in the distribution have been modified to work with both address families.
<li>The <tt>tty_clk</tt> and <tt>ppsclock</tt> pulse-per-second (PPS) line discipline/streams modules are no longer supported. The PPS function is now handled by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver, which uses the new PPSAPI application program interface adopted by the IETF. Note that the <tt>pps</tt> configuration file command has been obsoleted by the driver. See the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.
- <li>Support for the NTPv1 symmetric mode has been discontinued, since it hasn't worked for years. Support continues for the NTPv1 client mode, which is used in some SNTP clients.
- <li>The precision time support in stock Solaris 2.6 has bugs that were fixed in 2.7. A patch is available that fixes the 2.6 bugs. The 2.6 PPS kernel discipline has been disabled by default. For testing, the kernel can be enabled using the <tt>enable kernel</tt> command either in the configuration file or via <tt>ntpdc</tt>.
- <li>The HTML documentation has been partially updated. However, most of the NTPv3 documentation continues to apply to NTPv4. Until a comprehensive update happens, what you see is what you get. We are always happy to accept comments, corrections and bug reports. However, we are most thrilled upon receipt of patches to fix the dang bugs. Bugs can be reported <a href="bugs.html">here</a>..
- </ol>
+ <li>Support for the NTPv1 symmetric mode has been discontinued, since it hasn't worked for years. Support continues for the NTPv1 client mode, which is used by some SNTP clients.</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
-document.write("<ul>\
-<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\
+document.write("<ul><p>Reference Clock Audio Drivers<br><ul>\
+<li class='inline'><a href='audio.html'>Reference Clock Audio Drivers</a><br>\
<li class='inline'><a href='drivers/driver7.html'>Radio CHU Audio Demodulator/Decoder</a><br>\
<li class='inline'><a href='drivers/driver36.html'>Radio WWV/H Audio Demodulator/Decoder</a><br>\
<li class='inline'><a href='drivers/driver6.html'>IRIG Audio Decoder</a>\
-</ul>")
\ No newline at end of file
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></ul>")
\ No newline at end of file
-document.write("<ul>\\r
+document.write("<ul><p>Configuration Commands and Options<br><ul>\
+<li class='inline'><a href='confopt.html'>Server Options</a><br>\
<li class='inline'><a href='accopt.html'>Access Control Options</a><br>\
-<li class='inline'><a href='authopt.html'>Authentication Options</a><br>\\r
-<li class='inline'><a href='manyopt.html'>Server Discovery Options</a><br>\
-<li class='inline'><a href='miscopt.html'>Miscellaneous Options</a><br>\
-<li class='inline'><a href='monopt.html'>Monitoring Options</a><br>\\r
+<li class='inline'><a href='authopt.html'>Authentication Options</a><br>\
+<li class='inline'><a href='monopt.html'>Monitoring Options</a><br>\
<li class='inline'><a href='clockopt.html'>Reference Clock Options</a><br>\
-<li class='inline'><a href='confopt.html'>Server Options</a><br>\
+<li class='inline'><a href='miscopt.html'>Miscellaneous Options</a><br>\
<li class='inline'><a href='ntp_conf.html'>Configuration File Definition (Advanced)</a><br>\
-</ul>")
\ No newline at end of file
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul><p>Client and Server Configuration<br>\
+<ul>\
+<li class='inline'><a href='assoc.html'>Association Management</a><br>\
+<li class='inline'><a href='rate.html'>Rate Management and the Kiss-o'-Death Packet</a><br>\
+<li class='inline'><a href='manyopt.html'>Automatic Server Discovery Schemes</a><br>\
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul><p>External Links<br><ul>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/book.html'>Computer Network Time Synchronization - The Network Time Protocol (book)</a><br>\
+<li class='inline'><a href='http://www.ntp.org/index.html'>NTP: The Network Time Protocol (home page)</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/ntp.html'>Network Time Protocol Research Project (home page)</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/exec.html'>Executive Summary: Computer Network Time Synchronization</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/leap.html'>NTP Timestamp Calculations</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/y2k.html'>The NTP Era and Era Numbering</a><br>\
+<li class='inline'><a <li class='inline'><a href='http://www.eecis.udel.edu/~mills/autocfg.html'>Autonomous Configuration</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autokey.html'>Autonomous Authentication</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/proto.html'>Autokey Protocol</a><br>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/ident.html'>Autokey Identity Schemes</a><br>\
+<li class='inline'><a href='sitemap.html'>Site Map</a><\p>\
+</ul></ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul><p>Build and Install<br><ul>\
+<li class='inline'><a href='build.html'>Building and Installing the Distribution</a><br>\
+<li class='inline'><a href='quick.html'>Quick Start</a><br>\
+<li class='inline'><a href='release.html'>Release Notess</a><br>\
+<li class='inline'><a href='config.html'>Configuration Options</a><br>\
+<li class='inline'><a href='debug.html'>NTP Debugging Techniques</a><br>\
+<li class='inline'><a href='rdebug.html'>Debugging Reference Clock Drivers</a><br>\
+<li class='inline'><a href='msyslog.html'><tt>ntpd</tt> System Log Messages</a><br>\
+<li class='inline'><a href='bugs.html'>NTP Bug Reporting Procedures</a><br>\
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></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='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
-</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
-<li class='inline'><a href='kernpps.html'>PPSAPI Interface for Precision Time Signals</a><br>\
-<li class='inline'><a href='gadget.html'>Gadget Box PPS Level Converter and CHU Modem</a><br>\
-</ul>")
\ No newline at end of file
+++ /dev/null
-document.write("<ul>\\r
-<li class='inline'><a href='debug.html'>NTP Debugging Techniques</a><br>\\r
-<li class='inline'><a href='rdebug.html'>Debugging Reference Clock Drivers</a><br>\\r
-<li class='inline'><a href='msyslog.html'><tt>ntpd</tt> System Log Messages</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='drivers/driver7.html'>Radio CHU Audio Demodulator/Decoder</a><br>\
-<li class='inline'><a href='drivers/driver36.html'>Radio WWV/H Audio Demodulator/Decoder</a><br>\
-<li class='inline'><a href='drivers/driver6.html'>IRIG Audio Decoder</a>\
-</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='groups.html'>Trusted Hosts and Groups</a><br>\
-<li class='inline'><a href='keygen.html'><tt>ntp-keygen</tt> - generate public and private keys</a>\
-<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
+document.write("<ul><p>Program Manual Pages<br><ul>\
+<li class='inline'><a href='ntpd.html'><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a><br>\
+<li class='inline'><a href='ntpq.html'><tt>ntpq</tt> - standard NTP query program</a><br>\
+<li class='inline'><a href='ntpdc.html'><tt>ntpdc</tt> - special NTP query program</a><br>\
+<li class='inline'><a href='ntpdate.html'><tt>ntpdate</tt> - set the date and time via NTP</a><br>\
+<li class='inline'><a href='ntptrace.html'><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a><br>\
+<li class='inline'><a href='tickadj.html'><tt>tickadj</tt> - set time-related kernel variables</a><br>\
+<li class='inline'><a href='ntptime.html'><tt>ntptime</tt> - read kernel time variables</a><br>\
+<li class='inline'><a href='keygen.html'><tt>ntp-keygen</tt> - generate public and private keys</a><br>\
+<li class='inline'><a href='ntpdsim_new.html'><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a><br>\
+<li class='inline'><a href='sntp.html'><tt>sntp</tt> - Simple Network Time Protocol (SNTP) Client</a><br>\
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul><p>Miscellaneous<br><ul>\
+<li class='inline'><a href='copyright.html'>Copyright Notice</a><br>\
+<li class='inline'><a href='prefer.html'>Mitigation Rules and the <tt>prefer</tt> Keyword</a><br>\
+<li class='inline'><a href='kern.html'>Kernel Model for Precision Timekeeping</a><br>\
+<li class='inline'><a href='kernpps.html'>PPSAPI Interface for Precision Time Signals</a><br>\
+<li class='inline'><a href='pps.html'>Pulse-per-second (PPS) Signal Interfacing</a><br>\
+<li class='inline'><a href='gadget.html'>Gadget Box PPS Level Converter and CHU Modem</a><br>\
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></ul>")
\ No newline at end of file
--- /dev/null
+document.write("<ul><p>Reference Clock Support<br><ul>\
+<li class='inline'><a href='refclock.html'>Reference Clock Drivers</a><br>\
+<li class='inline'><a href='extern.html'>External Clock Discipline and the Local Clock Driver</a><br>\
+<li class='inline'><a href='howto.html'>How to Write a Reference Clock Driver</a><br>\
+<li class='inline'><a href='howto.html'>How to build new PARSE clocks</a><br>\
+<li class='inline'><a href='sitemap.html'>Site Map</a></p>\
+</ul></ul>")
\ No newline at end of file
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Site Map</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>Site Map</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>
+ <p>Pleased to meet you.</p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:40</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="292">Monday, December 31, 2007</csobj></p>
+ <br clear="left">
+ <h4>Related Links</h4>
+ <script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/refclock.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/external.txt"></script>
+ <hr>
+ <div align="center">
+ <img src="pic/pogo1a.gif" alt="gif"></div>
+ <br>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
<h3>Simple Network Time Protocol (SNTP) Client</h3>
<img src="pic/dogsnake.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>S is for snakeoil</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:50</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:21</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="294">Monday, November 26, 2007</csobj></p>
<br clear="left">
<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>
<h4>Description</h4>
- <p>This program is a Simple Network Time Protocol (SNTP) client that can be used to query a Network TIme Protocol (NTP) server and display the time offset of the system clock relative to the server clock. Run as root it can correct the system clock to this offset as well. It can be run as an interactive command or from a script by a <tt>cron</tt> job. The program implements the SNTP protocol defined in RFC-2030, which is a subset of the NTP protocol defined in RFC-1305, but does not provide the sanity checks, access controls, security functions and mitigation algorithms as in the full NTP implementation.</p>
- <p>While this program can do other things, including operation as a primitive server, some of these things are truly dangerous in a ubiquitous public time server network. A full disclosure is in the man page in the <tt>./sntp</tt> directory, but be truly advised RFC-2030 specifically <b>forbids</b> a SNTP client to operate as a server for other NTP or SNTP clients. If such operation is contemplated, do <b>not</b> allow access by clients on the public Internet.</p>
+ <p>This program is a Simple Network Time Protocol (SNTP) client that can be used to query a Network Time Protocol (NTP) server and display the time offset of the system clock relative to the server clock. Run as root it can correct the system clock to this offset as well. It can be run as an interactive command or from a script by a <tt>cron</tt> job. The program implements the SNTP protocol defined in RFC-4330, which is a subset of the NTP protocol defined in RFC-1305, but does not provide the sanity checks, access controls, security functions and mitigation algorithms as in the full NTP implementation.</p>
<p>By default, <tt>sntp</tt> writes the local date and time (i.e., not UTC) to the standard output in the format</p>
<p><tt>1996 Oct 15 20:17:25.123 + 4.567 +/- 0.089 secs</tt>,</p>
<p>where the <tt>+ 4.567 +/- 0.089 secs</tt> indicates the time offset and error bound of the system clock relative to the server clock.</p>
<body>
<h3><tt>tickadj</tt> - set time-related kernel variables</h3>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:50</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
+ <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:53</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 16, 2008</csobj></p>
<hr>
<h4>Synopsis</h4>
<tt>tickadj [ -Aqs ] [ -a <i>tickadj</i> ] [ -t <i>tick</i> ]</tt>
<h4>Description</h4>
- <p>The <tt>tickadj</tt> program reads, and optionally modifies, several timekeeping-related variables in older kernels that do not have support for precision ttimekeeping, including HP-UX, SunOS, Ultrix, SGI and probably others. Those machines provide means to patch the kernel <tt>/dev/kmem</tt>. Newer machines with precision time support, including Solaris, Tru64, FreeBSD and Linux (with PPSkit patch) should NOT use the program. The particular variables that can be changed with <tt>tickadj</tt> include <tt>tick</tt>, which is the number of microseconds added to the system time for a clock interrupt, <tt>tickadj</tt>, which sets the slew rate and resolution used by the <tt>adjtime</tt> system call, and <tt>dosynctodr</tt>, which indicates to the kernels on some machines whether they should internally adjust the system clock to keep it in line with time-of-day clock or not.</p>
+ <p>The <tt>tickadj</tt> program reads, and optionally modifies, several timekeeping-related variables in older kernels that do not have support for precision ttimekeeping, including HP-UX, SunOS, Ultrix, SGI and probably others. Those machines provide means to patch the kernel <tt>/dev/kmem</tt>. Newer machines with kernel time support, including Solaris, Tru64, FreeBSD and Linux, should NOT use the program, even if it appears to work, as it will destabilize the kernel time support. Use the <a href="ntptime.html"><tt>ntptime</tt></a> program instead.</p>
+ <p>The particular variables that can be changed with <tt>tickadj</tt> include <tt>tick</tt>, which is the number of microseconds added to the system time for a clock interrupt, <tt>tickadj</tt>, which sets the slew rate and resolution used by the <tt>adjtime</tt> system call, and <tt>dosynctodr</tt>, which indicates to the kernels on some machines whether they should internally adjust the system clock to keep it in line with time-of-day clock or not.</p>
<p>By default, with no arguments, <tt>tickadj</tt> reads the variables of interest in the kernel and displays them. At the same time, it determines an "optimal" value for the value of the <tt>tickadj</tt> variable if the intent is to run the <tt>ntpd</tt> Network Time Protocol (NTP) daemon, and prints this as well. Since the operation of <tt>tickadj</tt> when reading the kernel mimics the operation of similar parts of the <tt>ntpd</tt> program fairly closely, this can be useful when debugging problems with <tt>ntpd</tt>.</p>
<p>Note that <tt>tickadj</tt> should be run with some caution when being used for the first time on different types of machines. The operations which <tt>tickadj</tt> tries to perform are not guaranteed to work on all Unix machines and may in rare cases cause the kernel to crash.</p>
<h4>Command Line Options</h4>
<dt><tt>-t <i>tick</i></tt>
<dd>Set the kernel variable <tt>tick</tt> to the value <i><tt>tick</tt></i> specified.
<dt><tt>-s</tt>
- <dd>Set the kernel variable <tt>dosynctodr</tt> to zero, which disables the hardware time-of-year clock, a prerequisite for running the <tt>ntpd</tt> daemon under SunOS4.
- <dt><tt>-q</tt>
+ <dd>Set the kernel variable <tt>dosynctodr</tt> to zero, which disables the hardware time-of-year clock, a prerequisite for running the <tt>ntpd</tt> daemon under SunOS 4.x.<dt><tt>-q</tt>
<dd>Normally, <tt>tickadj</tt> is quite verbose about what it is doing. The <tt>-q</tt> flag tells it to shut up about everything except errors.
</dl>
<h4>Files</h4>
- <pre>
-/vmunix
-
-/unix
-
-/dev/kmem
-</pre>
+ <tt>/vmunix<br>
+ /unix<br>
+ /dev/kmem<br>
+ </tt>
<h4>Bugs</h4>
Fiddling with kernel variables at run time as a part of ordinary operations is a hideous practice which is only necessary to make up for deficiencies in the implementation of <tt>adjtime</tt> in many kernels and/or brokenness of the system clock in some vendors' kernels. It would be much better if the kernels were fixed and the <tt>tickadj</tt> program went away.
<hr>
projects / thirdparty / ntp.git / commitdiff
