+2001-04-02 Harlan Stenn <stenn@whimsy.udel.edu>
+
+ * html/y2k.htm:
+ * html/tickadj.htm:
+ * html/release.htm:
+ * html/refclock.htm:
+ * html/quick.htm:
+ * html/pps.htm:
+ * html/ntptrace.htm:
+ * html/ntptime.htm:
+ * html/ntpq.htm:
+ * html/ntpdc.htm:
+ * html/ntpdate.htm:
+ * html/ntpd.htm:
+ * html/miscopt.htm:
+ * html/index.htm:
+ * html/genkeys.htm:
+ * html/exec.htm:
+ * html/driver7.htm:
+ * html/driver22.htm:
+ * html/copyright.htm:
+ * html/confopt.htm:
+ * html/build.htm:
+ * html/authopt.htm:
+ * html/assoc.htm:
+ Updates from Dave Mills.
+
2001-04-01 Harlan Stenn <stenn@whimsy.udel.edu>
* configure.in (OPENSSL): Just use -lcrypto.
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><title>
Association Management
</title></head><body><h3>
Association Management
</h3>
-<img align=left src=pic/alice51.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
+<img align=left src=pic/alice51.gif
alt="gif"><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.
<p>Broadcast mode in both NTPv3 and NTPv4 is limited to directly connected subnets such as Ethernets which support broadcast technology. Ordinarily, this technology does not operate beyond the first hop router or gateway. Where service is intended beyond the local subnet, IP multicasting can be used where supported by the operating system and the routers support the Internet Group Management Protocol (IGMP). Most current kernels and available routers do support IP multicast technology, although service providers are sometimes reluctant to deploy it.
-<p>A general discussion of IP multicast technology is beyond the scope here. In simple terms a host or router sending to a IP multicast group (class D) 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. The IANA has assigned multicast group address 224.0.1.1 to NTP, but this address should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped group addresses should be used as described in RFC-2365.
+<p>A general discussion of IP multicast technology is beyond the scope here. In simple terms a host or router sending to a IP multicast group (class D) 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. The IANA has assigned multicast group address 224.0.1.1 to NTP, but this address should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.
<h4>Multicasting</h4>
<p>The manycast client receiving this message mobilizes an ephemeral client association as in ordinary client/server mode according to the matching manycast client template. Then, the client polls the server at its unicast address in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles over a 30-s interval during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client runs the NTP intersection and clustering algorithms, which act to discard all but the best three associations. The surviving associations then continue in ordinary client/server mode.
-<p>The manycast client polling program is designed to reduce as much as possible the volume of messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The program starts with the poll interval specified by the <tt>minpoll</tt> keyword and a time-to-live of one hop. At each transmission the time-to-live is incremented by one until at least three manycast servers are found, at which point the poll interval is clamped at the value specified by the <tt>maxpoll</tt> keyword. Further transmissions use the same poll interval and time-to-live values.
+<p>The manycast client polling program is designed to reduce as much as possible the volume of messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The program uses a poll interval eight times the system poll interval, which starts out at the <tt>minpoll</tt> value and under normal circumstances increases gradually to the <tt>maxpolll</tt> value. Initially, the time-to-live is set at one hop. At each retransmission the time-to-live is incremented by one until at least three manycast servers are found. Further retransmissions use the same time-to-live value.
-<p>If less than three servers are found when the time-to-live has reached the maximum specified by the <tt>ttl</tt> keyword, the poll interval is doubled. For each transmission after that, the poll interval is doubled again until reaching the maximum specified by the <tt>maxpoll</tt> keyword. Further transmissions use the same poll interval and time-to-live values.
+<p>If less than three servers are found when the time-to-live has reached the maximum specified by the <tt>ttl</tt> keyword, the poll interval is doubled. For each transmission after that, the poll interval is doubled again until reaching the maximum of eight times the value specified by the <tt>maxpoll</tt> keyword. Further transmissions use the same poll interval and time-to-live values.
<p>The above scenario happens for each manycast client message, which repeats at the designated poll interval. However, once the ephemeral client association is mobilized, subsequent manycast server replies are discarded, since they will fail the message digest test. If during a poll interval the number of client associations falls below three, all manycast client prototype associations are reset to the initial poll interval and time-to-live values and operation resumes from the beginning. It is important in manycast mode to avoid frequent manycast client messages, since each one requires all manycast servers in range to respond. The result could well be an implosion, either minor or major, depending on the number of servers in range. The recommended value for <tt>maxpoll</tt> is 12 (4,096 s) and for <tt>ttl</tt> is 7.
<p>The <tt>burst</tt> keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. It should only be used where the poll interval is expected to settle to values at or above 1024 s.
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<html><head><title>
-Authentication Options
-</title></head><body><h3>
-Authentication Options
-</h3>
-
-<img align=left src=pic/alice44.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>Our resident cryptographer; now you see him, now you don't.
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Authentication Options</title>
+</head>
+<body>
+<h3>Authentication Options</h3>
+
+<img align="left" src="pic/alice44.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Our resident cryptographer; now you see him, now you don't.<br
+clear="left">
+</p>
+
+<hr>
<h4>Authentication Support</h4>
-<p>Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder intending accidentally or on purpose to masquerade as that server. The NTPv3 specification RFC-1305 defines an 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 augmented 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>NTPv4 retains the NTPv3 schemes, 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 a private value which is generated by each server and never revealed. With Autokey all key distribution and management functions involve only public values, which considerably simplifies key distribution and storage.
-
-<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> subcommands on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> commands as described in the <a href=config.htm>Configuration Options</a> page. The authentication options described below specify the suite of keys, select the key for each configured association and manage the configuration operations.
-
-<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> configuration commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running in another machine. If this flag is enabled, which is the default case, new broadcast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric-key or public-key schemes. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating in the latter mode invites a significant vulnerability where a rogue hacker can seriously disrupt client timekeeping.
-
-<p>In networks with firewalls and large numbers of broadcast clients it may be acceptable to disable authentication, since that avoids key distribution and simplifies network maintenance. However, when the configuration file contains host names, or when a server or client is configured remotely, host names are resolved using the DNS and a
-separate name resolution process. In order to protect against bogus name server messages, name resolution messages are authenticated using an internally generated key which is normally invisible to the user. However, if cryptographic support is disabled, the name resolution process will fail. This can be avoided either by specifying IP addresses instead of host names, which is generally inadvisable, or by enabling the flag for name resolution and disabled it once the name resolution process is complete.
-
-<p>An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers. Cryptographic authentication in this mode uses public-key schemes as described below. The principle advantage of this manycast mode is that potential servers need not be configured in advance, since the client finds them during regular operation, and the configuration files for all clients can be identical.
-
-<p>In addition to the default symmetric-key cryptographic support, support for public-key cryptography is available if the requisite <tt>rsaref20</tt> software distribution has been installed before building the distribution. Public-key cryptography provides secure authentication of servers without compromising accuracy and stability. The security model and protocol schemes for both symmetric-key and public-key cryptography are described below.
+<p>Authentication support allows the NTP client to verify that the
+server is in fact known and trusted and not an intruder intending
+accidentally or on purpose to masquerade as that server. The NTPv3
+specification RFC-1305 defines an 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 augmented 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 schemes, 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 a private value which is generated
+by each server and never revealed. With Autokey all key
+distribution and management functions involve only public values,
+which considerably simplifies key distribution and storage.</p>
+
+<p>Authentication is configured separately for each association
+using the <tt>key</tt> or <tt>autokey</tt> subcommands on the <tt>
+peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>
+manycastclient</tt> commands as described in the <a href=
+"config.htm">Configuration Options</a> page. The authentication
+options described below specify the suite of keys, select the key
+for each configured association and manage the configuration
+operations.</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> configuration commands and also by remote
+configuration commands sent by a <tt>ntpdc</tt> program running in
+another machine. If this flag is enabled, which is the default
+case, new broadcast client and symmetric passive associations and
+remote configuration commands must be cryptographically
+authenticated using either symmetric-key or public-key schemes. If
+this flag is disabled, these operations are effective even if not
+cryptographic authenticated. It should be understood that operating
+in the latter mode invites a significant vulnerability where a
+rogue hacker can seriously disrupt client timekeeping.</p>
+
+<p>In networks with firewalls and large numbers of broadcast
+clients it may be acceptable to disable authentication, since that
+avoids key distribution and simplifies network maintenance.
+However, when the configuration file contains host names, or when a
+server or client is configured remotely, host names are resolved
+using the DNS and a separate name resolution process. In order to
+protect against bogus name server messages, name resolution
+messages are authenticated using an internally generated key which
+is normally invisible to the user. However, if cryptographic
+support is disabled, the name resolution process will fail. This
+can be avoided either by specifying IP addresses instead of host
+names, which is generally inadvisable, or by enabling the flag for
+name resolution and disabled it once the name resolution process is
+complete.</p>
+
+<p>An attractive alternative where multicast support is available
+is manycast mode, in which clients periodically troll for servers.
+Cryptographic authentication in this mode uses public-key schemes
+as described below. The principle advantage of this manycast mode
+is that potential servers need not be configured in advance, since
+the client finds them during regular operation, and the
+configuration files for all clients can be identical.</p>
+
+<p>In addition to the default symmetric-key cryptographic support,
+support for public-key cryptography is available if the requisite
+<tt>rsaref20</tt> software distribution has been installed before
+building the distribution. Public-key cryptography provides secure
+authentication of servers without compromising accuracy and
+stability. The security model and protocol schemes for both
+symmetric-key and public-key cryptography are described below.</p>
<h4>Symmetric-Key Scheme</h4>
-The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate their messages. Keys and related information are specified in a key file, usually called <tt>ntp.keys</tt>, which should be exchanged and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href=ntpq.htm>ntpq</a></tt> and <tt><a href=ntpdc.htm>ntpdc</a></tt> utility programs.
-
-<p>When <tt>ntpd</tt> is first started, it reads the key file specified int he <tt>keys</tt> command and installs the keys in the key cache. However, the keys must be activated with the <tt>trusted</tt> command before use. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using <tt>ntpdc</tt>. This also provides a revocation capability that can be used if a key becomes compromised. The <tt>requestkey</tt> command selects the key used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key used as the password for the <tt>ntpq</tt> utility.
+The original RFC-1305 specification allows any one of possibly
+65,534 keys, each distinguished by a 32-bit key identifier, to
+authenticate an association. The servers and clients involved must
+agree on the key and key identifier to authenticate their messages.
+Keys and related information are specified in a key file, usually
+called <tt>ntp.keys</tt>, which should be exchanged and stored
+using secure procedures beyond the scope of the NTP protocol
+itself. Besides the keys used for ordinary NTP associations,
+additional keys can be used as passwords for the <tt><a href=
+"ntpq.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">ntpdc</a></tt>
+utility programs.
+
+<p>When <tt>ntpd</tt> is first started, it reads the key file
+specified int he <tt>keys</tt> command and installs the keys in the
+key cache. However, the keys must be activated with the <tt>
+trusted</tt> command before use. This allows, for instance, the
+installation of possibly several batches of keys and then
+activating or deactivating each batch remotely using <tt>
+ntpdc</tt>. This also provides a revocation capability that can be
+used if a key becomes compromised. The <tt>requestkey</tt> command
+selects the key used as the password for the <tt>ntpdc</tt>
+utility, while the <tt>controlkey</tt> command selects the key used
+as the password for the <tt>ntpq</tt> utility.</p>
<h4>Public-Key Scheme</h4>
-The original NTPv3 authentication scheme described in RFC-1305 continues to be supported; however, in NTPv4 an additional authentication scheme called Autokey is available. It uses MD5 message digest, RSA public-key signature and Diffie-Hellman key agreement algorithms available from several sources, but not included in the NTPv4 software distribution. In order to be effective, the <tt>rsaref20</tt> package must be installed as described in the <tt>README.rsa</tt> file. Once installed, the configure and build process automatically detects it and compiles the routines required.
-
-The Autokey scheme has several modes of operation corresponding to the various NTP modes supported. RSA signatures with timestamps are used in all modes to verify the source of cryptographic values. All modes use a special cookie which can be computed independently by the client and server. In symmetric modes the cookie is constructed using the Diffie-Hellman key agreement algorithm. In other modes the cookie is constructed from the IP addresses and a private value known only to the server. All modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. These schemes are described along with an executive summary, current status, briefing slides and reading list, on the <a href=http://www.eecis.udel.edu/~mills/autokey.htm>Autonomous Authentication</a> page.
-
-<p>The cryptographic values used by the Autokey scheme are incorporated as a set of files generated by the <a href=genkeys.htm><tt>ntp-genkeys</tt></a> program, including the symmetric private keys, public/private key pair, and the agreement parameters. See the <tt>ntp-genkeys</tt> page for a description of the formats of these files. They contain cryptographic values generated by the algorithms of the <tt>rsaref20</tt> package and are in printable ASCII format. All file names include the timestamp, in NTP seconds, following the default names given below. Since the file data are derived from random values seeded by the system clock and the file name includes the timestamp, every generation produces a different file and different file name.
-
-<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It must be distributed by secure means to other servers and clients sharing the same security compartment and made visible only to root. While this file is not used with the Autokey scheme, it is needed to authenticate some remote configuration commands used by the <a href=ntpdc.htm><tt>ntpq</tt></a> and <a href=ntpq.htm><tt>ntpdc</tt></a> utilities. The <tt>ntpkey</tt> file contains the RSA private key. It is useful only to the machine that generated it and never shared with any other daemon or application program, so must be made visible only to root.
-
-<p>The <tt>ntp_dh</tt> file contains the agreement parameters. It is necessary that all servers and clients of a security compartment share a single set of parameters, but it does not matter which <tt>ntp_dh</tt> file generates them. Servers load the parameters directly from the file, while the clients can load them indirectly from the servers using the Autokey protocol. Note that the parameters will be requested by all associations, either configured or not; but, none of the associations can proceed until one of them has received them. Once loaded, the parameters can be provided on request to other clients and servers. The <tt>ntp_dh</tt> file can be also be distributed using insecure means, since the data are public values.
-
-<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public key, where <tt><i>host</i></tt> is the name of the host. Each <tt>server</tt> or <tt>peer</tt> association requires the public key associated with the particular server or peer to be loaded either directly from the file or indirectly from the server using the Autokey protocol. In addition, public keys are required for all configured associations, including those that might be mobilized by multicast servers or symmetric peers. These files can be widely distributed and stored using insecure means, since the data are public values.
-
-<p>Due to the widespread use of interface-specific naming, the host names used in configured and mobilized associations are determined by the Unix <tt>gethostname()</tt> library routine. Both the <tt>ntp-genkeys</tt> program and the Autokey protocol derive the name of the public key file using the name returned by this routine. While every server and client is required to load their own public and private keys, the public keys for each client or peer association can be obtained from the server or peer using the Autokey protocol. Note however, that at the current stage of development the authenticity of the server or peer and the cryptographic binding of the server name, address and public key is not yet established by a certificate authority or web of trust. Therefore, when the most secure requirements apply, the public keys and agreement parameters should be loaded from files, rather than using the Autokey protocol.
-
-<h4>Leapseconds Table</tt>
-
-<p>The NIST provides a table showing 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 Universtal 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>While not strictly a security function, the Autokey scheme 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, while clients can load the table indirectly from the servers using the Autokey protocol. Once loaded, the table can be provided on request to other clients and servers.
+The original NTPv3 authentication scheme described in RFC-1305
+continues to be supported; however, in NTPv4 an additional
+authentication scheme called Autokey is available. It uses MD5
+message digest, RSA public-key signature and Diffie-Hellman key
+agreement algorithms available from several sources, but not
+included in the NTPv4 software distribution. In order to be
+effective, the <tt>rsaref20</tt> package must be installed as
+described in the <tt>README.rsa</tt> file. Once installed, the
+configure and build process automatically detects it and compiles
+the routines required. The Autokey scheme has several modes of
+operation corresponding to the various NTP modes supported. RSA
+signatures with timestamps are used in all modes to verify the
+source of cryptographic values. All modes use a special cookie
+which can be computed independently by the client and server. In
+symmetric modes the cookie is constructed using the Diffie-Hellman
+key agreement algorithm. In other modes the cookie is constructed
+from the IP addresses and a private value known only to the server.
+All modes use in addition a variant of the S-KEY scheme, in which a
+pseudo-random key list is generated and used in reverse order.
+These schemes are described along with an executive summary,
+current status, briefing slides and reading list, on the <a href=
+"http://www.eecis.udel.edu/~mills/autokey.htm">Autonomous
+Authentication</a> page.
+
+<p>The cryptographic values used by the Autokey scheme are
+incorporated as a set of files generated by the <a href=
+"genkeys.htm"><tt>ntp-genkeys</tt></a> program, including the
+symmetric private keys, public/private key pair, and the agreement
+parameters. See the <tt>ntp-genkeys</tt> page for a description of
+the formats of these files. They contain cryptographic values
+generated by the algorithms of the <tt>rsaref20</tt> package and
+are in printable ASCII format. All file names include the
+timestamp, in NTP seconds, following the default names given below.
+Since the file data are derived from random values seeded by the
+system clock and the file name includes the timestamp, every
+generation produces a different file and different file name.</p>
+
+<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It
+must be distributed by secure means to other servers and clients
+sharing the same security compartment and made visible only to
+root. While this file is not used with the Autokey scheme, it is
+needed to authenticate some remote configuration commands used by
+the <a href="ntpdc.htm"><tt>ntpq</tt></a> and <a href="ntpq.htm">
+<tt>ntpdc</tt></a> utilities. The <tt>ntpkey</tt> file contains the
+RSA private key. It is useful only to the machine that generated it
+and never shared with any other daemon or application program, so
+must be made visible only to root.</p>
+
+<p>The <tt>ntp_dh</tt> file contains the agreement parameters,
+which are used only in symmetric (active and passive) modes. It is
+necessary that both peers beginning a symmetric-mode association
+share the same parameters, but it does not matter which <tt>
+ntp_dh</tt> file generates them. If one of the peers contains the
+parameters, the other peer obtains them using the Autokey protocol.
+If both peers contain the parameters, the most recent copy is used
+by both peers. If a peer does not have the parameters, they will be
+requested by all associations, either configured or not; but, none
+of the associations can proceed until one of them has received the
+parameters. Once loaded, the parameters can be provided on request
+to other clients and servers. The <tt>ntp_dh</tt> file can be also
+be distributed using insecure means, since the data are public
+values.</p>
+
+<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public
+key, where <tt><i>host</i></tt> is the name of the host. Each host
+must have its own <tt>ntpkey_<i>host</i></tt> file, which is
+normally provided to other hosts using the Autokey protocol Each
+<tt>server</tt> or <tt>peer</tt> association requires the public
+key associated with the particular server or peer to be loaded
+either directly from a local file or indirectly from the server
+using the Autokey protocol. These files can be widely distributed
+and stored using insecure means, since the data are public
+values.</p>
+
+<p>The optional <tt>ntpkey_certif_<i>host</i></tt> file contains
+the PKI certificate for the host. This provides a binding between
+the host hame and RSA public key. In the current implementation the
+certificate is obtained by a client, if present, but the contents
+are ignored.</p>
+
+<p>Due to the widespread use of interface-specific naming, the host
+names used in configured and mobilized associations are determined
+by the Unix <tt>gethostname()</tt> library routine. Both the <tt>
+ntp-genkeys</tt> program and the Autokey protocol derive the name
+of the public key file using the name returned by this routine.
+While every server and client is required to load their own public
+and private keys, the public keys for each client or peer
+association can be obtained from the server or peer using the
+Autokey protocol. Note however, that at the current stage of
+development the authenticity of the server or peer and the
+cryptographic binding of the server name, address and public key is
+not yet established by a certificate authority or web of trust.</p>
+
+<h4>Leapseconds Table</h4>
+
+<p>The NIST provides a table showing 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
+Universtal 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 scheme
+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, while clients can
+load 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>
<h4>Key Management</h4>
-<p>All key files are installed by default in <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks and avoids installing them in each machine separately. The default can be overridden by the <tt>keysdir</tt> configuration command. However, this is not a good place to install the private key file, since each machine needs its own file. A suitable place to install it is in <tt>/etc</tt>, which is normally not in a shared filesystem.
-
-<p>The recommended practice is to keep the timestamp extensions when installing a file and to install a link from the default name (without the timestamp extension) to the actual file. This allows new file generations to be activated simply by changing the link. However, <tt>ntpd</tt> parses the link name when present to extract the extension value and sends it along with the public key and host name when requested. This allows clients to verify that the file and generation time are always current. However, the actual location of each file can be overridden by the <tt>crypto</tt> configuration command.
-
-<p>All cryptographic keys and related parameters should be regenerated on a periodic and automatic basis, like once per month. The <tt>ntp-genkeys</tt> program uses the same timestamp extension for all files generated at one time, so each generation is distinct and can be readily recognized in monitoring data. While a public/private key pair must be generated by every server and client, the public keys and agreement parameters do not need to be explicitly copied to all machines in the same security compartment, since they can be obtained automatically using the Autokey protocol. However, it is necessary that all primary servers have the same agreement parameter file. The recommended way to do this is for one of the primary servers to generate that file and then copy it to the other primary servers in the same compartment using the Unix <tt>rdist</tt> command. Future versions of the Autokey protocol are to contain provisions for an agreement protocol to do this automatically.
-
-<p>Servers and clients can make a new generation in the following way. All machines have loaded the old generation at startup and are operating normally. At designated intervals, each machine generates a new public/private key pair and makes links from the default file names to the new file names. The <tt>ntpd</tt> is then restarted and loads the new generation, with result clients no longer can authenticate correctly. The Autokey protocol is designed so that after a few minutes the clients time out and restart the protocol from the beginning, with result the new generation is loaded and operation continues as before. A similar procedure can be used for the agreement parameter file, but in this case precautions must be take to be sure that all machines with this file have the same copy.
+<p>All key files are installed by default in <tt>
+/usr/local/etc</tt>, which is normally in a shared filesystem in
+NFS-mounted networks and avoids installing them in each machine
+separately. The default can be overridden by the <tt>keysdir</tt>
+configuration command. However, this is not a good place to install
+the private key file, since each machine needs its own file. A
+suitable place to install it is in <tt>/etc</tt>, which is normally
+not in a shared filesystem.</p>
+
+<p>The recommended practice is to keep the timestamp extensions
+when installing a file and to install a link from the default name
+(without the timestamp extension) to the actual file. This allows
+new file generations to be activated simply by changing the link.
+However, <tt>ntpd</tt> parses the link name when present to extract
+the extension value and sends it along with the public key and host
+name when requested. This allows clients to verify that the file
+and generation time are always current. However, the actual
+location of each file can be overridden by the <tt>crypto</tt>
+configuration command.</p>
+
+<p>All cryptographic keys and related parameters should be
+regenerated on a periodic and automatic basis, like once per month.
+The <tt>ntp-genkeys</tt> program uses the same timestamp extension
+for all files generated at one time, so each generation is distinct
+and can be readily recognized in monitoring data. While a
+public/private key pair must be generated by every server and
+client, the public keys and agreement parameters do not need to be
+explicitly copied to all machines in the same security compartment,
+since they can be obtained automatically using the Autokey
+protocol. However, it is necessary that all primary servers have
+the same agreement parameter file. The recommended way to do this
+is for one of the primary servers to generate that file and then
+copy it to the other primary servers in the same compartment using
+the Unix <tt>rdist</tt> command. Future versions of the Autokey
+protocol are to contain provisions for an agreement protocol to do
+this automatically.</p>
+
+<p>Servers and clients can make a new generation in the following
+way. All machines have loaded the old generation at startup and are
+operating normally. At designated intervals, each machine generates
+a new public/private key pair and makes links from the default file
+names to the new file names. The <tt>ntpd</tt> is then restarted
+and loads the new generation, with result clients no longer can
+authenticate correctly. The Autokey protocol is designed so that
+after a few minutes the clients time out and restart the protocol
+from the beginning, with result the new generation is loaded and
+operation continues as before. A similar procedure can be used for
+the agreement parameter file, but in this case precautions must be
+take to be sure that all machines with this file have the same
+copy.</p>
<h4>Authentication Commands</h4>
<dl>
+<dt><tt>autokey [<i>logsec</i>]</tt></dt>
-<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.</dd>
+<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.</dd>
<dt><tt>controlkey <i>key</i></tt></dt>
-<dd>Specifies the key identifier to use with the <a href=ntpq.htm><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 65534, inclusive.</dd>
-
-<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>] [publickey <i>file</i>] [dhparms <i>file</i>] [leap <i>file</i>] </tt></dt> <dd>This command requires the NTP daemon build process be configured with the RSA library. This command activates public-key cryptography and loads the required RSA private and public key files and the optional Diffie-Hellman agreement parameter file, if present. If one or more files are left unspecified, the default names are used as described below. Following are the subcommands:</dd>
+<dd>Specifies the key identifier to use with the <a href=
+"ntpq.htm"><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 65534, inclusive.</dd>
+
+<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>]
+[publickey <i>file</i>] [dhparms <i>file</i>] [leap <i>
+file</i>]</tt></dt>
+
+<dd>This command requires the NTP daemon build process be
+configured with the RSA library. This command activates public-key
+cryptography and loads the required RSA private and public key
+files and the optional Diffie-Hellman agreement parameter file, if
+present. If one or more files are left unspecified, the default
+names are used as described below. Following are the
+subcommands:</dd>
+
+<dd>
<dl>
+<dt><tt>privatekey <i>file</i></tt></dt>
+
+<dd>Specifies the location of the RSA private key file, which
+otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
-<dt><tt>privatekey <i>file</tt></i>
-<dd>Specifies the location of the RSA private key file, which otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
+<dt><tt>publickey <i>file</i></tt></dt>
-<dt><tt>publickey <i>file</tt></i>
-<dd>Specifies the location of the RSA public key file, which otherwise defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>., where <i>host</i> is the name of the generating machine.</dd>
+<dd>Specifies the location of the RSA public key file, which
+otherwise defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>.,
+where <i>host</i> is the name of the generating machine.</dd>
-<dt><tt>dhparms <i>file</tt></i>
-<dd>Specifies the location of the Diffie-Hellman parameters file, which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
-<dt><tt>leap <i>file</tt></i>
-<dd>Specifies the location of the leapsecond table file, which otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
+<dt><tt>dhparms <i>file</i></tt></dt>
+<dd>Specifies the location of the Diffie-Hellman parameters file,
+which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
+
+<dt><tt>leap <i>file</i></tt></dt>
+
+<dd>Specifies the location of the leapsecond table file, which
+otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
</dl>
+</dd>
<dt><tt>keys <i>keyfile</i></tt></dt>
-<dd>Specifies the location of the DES/MD5 private key file containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating in symmetric-key mode.</dd>
+
+<dd>Specifies the location of the DES/MD5 private key file
+containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>
+ntpq</tt> and <tt>ntpdc</tt> when operating in symmetric-key
+mode.</dd>
<dt><tt>keysdir <i>path</i></tt></dt>
-<dd>This command requires the NTP daemon build process be configured with the RSA library. It specifies the default directory path for the private key file, agreement parameters file and one or more public key files. The default when this command does not appear in the
-configuration file is <tt>/usr/local/etc/</tt>.</dd>
+
+<dd>This command requires the NTP daemon build process be
+configured with the RSA library. It specifies the default directory
+path for the private key file, agreement parameters file and one or
+more public key files. The default when this command does not
+appear in the configuration file is <tt>/usr/local/etc/</tt>.</dd>
<dt><tt>requestkey <i>key</i></tt></dt>
-<dd>Specifies the key identifier to use with the <a href=ntpdc.htm><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 65534, inclusive.</dd>
-<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 of the scheme; 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.</dd>
+<dd>Specifies the key identifier to use with the <a href=
+"ntpdc.htm"><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 65534,
+inclusive.</dd>
+
+<dt><tt>revoke [<i>logsec</i>]</tt></dt>
+
+<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 of the scheme;
+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.</dd>
<dt><tt>trustedkey <i>key</i> [...]</tt></dt>
-<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.</dd>
+<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.</dd>
</dl>
<h4>Files</h4>
-<tt>ntp.keys</tt> private MD5 keys
-<br><tt>ntpkey</tt> RSA private key
-<br><tt>ntpkey_<i>host</i></tt> RSA public key
-<br><tt>ntp_dh</tt> Diffie-Hellman agreement parameters
+<tt>ntp.keys</tt> private MD5 keys <br>
+<tt>ntpkey</tt> RSA private key <br>
+<tt>ntpkey_<i>host</i></tt> RSA public key <br>
+<tt>ntp_dh</tt> Diffie-Hellman agreement parameters
<h4>Bugs</h4>
-The <tt>ntpkey_<i>host</i></tt> files are really digital certificates. These should be obtained via secure directory services when they become universally available.
+The <tt>ntpkey_<i>host</i></tt> files are really digital
+certificates. These should be obtained via secure directory
+services when they become universally available.
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
-<html><head><title>
-Building and Installing the Distribution
-</title></head><body><h3>
-Building and Installing the Distribution
-</h3>
-
-<img align=left src=pic/beaver.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
-
-<p>For putting out compiler fires.
-<br clear=left><hr>
-
-<H4>Building and Installing the Distribution</H4>
-
-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 bew idiosyncratic and the
-libraries may have different semantics. It is not possible in a software
-distribution such as this one to support every individual sysdtem with a
-common set of binaries, even with the same system but different
-versions. Therefore, it is necessary to configure each system
-individually 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 "make" and the autoconfigure
-system does the rest. There are some exceptions, as noted below.
-
-<p>The autoconfigure system 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 available.
-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.
-
-Some programs included in this distribution use cryptographic algorithms
-to verify server authenticity and credentials. As required by the
-International Trade in Arms Regulations (ITAR), now called the Defense
-Trade Regulations (DTR), certain cryptographic products and media,
-including the Data Encryption Standard (DES), cannot be exported without
-per-instance license. For this reason, the DES encryption routine has
-been removed from the the current version, even though it is used only
-to compute a message digest. Current DTR regulations allow export of the
-the MD5 message digest routine, which is in fact the preferred
-algorithm, and this is included in the current
-version.
-
-<P>The NTP authentication routines conform to the interface used by RSA
-Laboratories in the <TT>rsaref20.zip</TT> package, which is downloadable
-from <TT>ftp.rsa.com</TT> or via the web at <TT>www.rsa.com</TT>.
-Outside the U.S. and Canada, the functionally identical
-<TT>rsaeuro.zip</TT> package is available from J.S.A. Kapp and other
-sources. The recommended way to integrate the DES routines in either
-package with the NTP build procedures is to copy the <TT>desc.c</TT>
-file from the <TT>./source</TT> directory in the package to the
-<TT>./libntp</TT> directory in the distribution. Then copy the header
-files <TT>rsaref.h</TT>, <TT>des.h</TT> and <TT>md2.h</TT> in the
-<TT>./source</TT> directory to the <TT>./include</TT> directory. Do not
-copy the <TT>global.h</TT> header file; the one in the distribution has
-been modified. These steps must be completed before the configuration
-process described below.
-
-<H4>Building and Installing under Unix</H4>
-
-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 - consider using the GNU tools and <TT>gcc</TT>
-compiler in this case). For a successful build, all of these tools
-should be accessible via the current path.
-
-<H4>Configuration</H4>
-
-Use the <TT>./configure</TT> command to perform an automatic
-configuration procedure. This procedure 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
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Building and Installing the Distribution</title>
+</head>
+<body>
+<h3>Building and Installing the Distribution</h3>
+
+<img align="left" src="pic/beaver.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
+Walt Kelly</a>
+
+<p>For putting out compiler fires.<br clear="left">
+</p>
+
+<hr>
+<h4>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 sysdtem with a common set of binaries, even with
+the same system but different versions. Therefore, it is necessary
+to configure each system individually 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 "make" and the autoconfigure system does the rest. There
+are some exceptions, as noted below.</p>
+
+<p>Some programs included in this distribution use cryptographic
+algorithms to verify server authenticity and credentials. As
+required by the International Trade in Arms Regulations (ITAR), now
+called the Defense Trade Regulations (DTR), certain cryptographic
+products and media, including the Data Encryption Standard (DES),
+cannot be exported without per-instance license. For this reason,
+the DES encryption routine has been removed from the the current
+version, even though it is used only to compute a message digest.
+Current DTR regulations allow export of the the MD5 message digest
+routine, which is in fact the preferred algorithm, and this is
+included in the current version.</p>
+
+<p>The NTP authentication routines conform to the interface used by
+RSA Laboratories in the <tt>rsaref20.zip</tt> package, which was
+formerly downloadable from <tt>ftp.rsa.com</tt> or via the web at
+<tt>www.rsa.com</tt>, but this may no longer be the case. Outside
+the US and Canada, the functionally identical <tt>rsaeuro.zip</tt>
+package is available from J.S.A. Kapp and other sources. The
+recommended way to integrate the routines in either package with
+the NTP build procedures is to uncompress and extract the <tt>
+rsaref20</tt> files in a top level directory with that name. Then
+install a link to that directory from <tt>rsaref2</tt> in the top
+level directory of the distribution. These steps must be completed
+before the configuration process described below.</p>
+
+<h4>Building and Installing under Unix</h4>
+
+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 - consider using the GNU tools and
+<tt>gcc</tt> compiler in this case). For a successful build, all of
+these tools should be accessible via the current path.
+
+<p>The first thing to do is uncompress the distribution and extract
+the source tree. 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 saves lots of messy fiddling. If you need to
-delete either the debugging code or one or more or all reference clock
-drivers to save space, see the <A HREF="config.htm">Configuration
-Options</A> page.
-
-<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 with
-the distribution base directory active, 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 configure with
-the <TT>../configure</TT> command. The remaining steps are the same
-whether building in the base directory or in the subdirectory.
-
-<H4>Compilation</H4>
-
-Peruse the operating-system-specific information for your architecture
-under <A HREF="hints.htm">Hints and Kinks</A>.
-
-<P>Use the <TT>make</TT> command to compile all source modules,
+delete either the debugging code or one or more or all reference
+clock drivers to save space, see the <a href="config.htm">
+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 with the distribution base directory
+active, 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 configure with the <tt>
+../configure</tt> command. The remaining steps are the same whether
+building in the base directory or in the subdirectory.</p>
+
+<h4>Compilation</h4>
+
+Peruse the operating-system-specific information for your
+architecture under <a href="hints.htm">Hints and Kinks</a>.
+
+<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 the use of <TT>gcc</TT> can
-result in quite a few complaints about system header files and type
-inconsistencies, especially about pointer variables. This is usually the
-case when the system header files are not up to ANSI standards or
-<TT>gcc</TT>-isms, when gcc is not installed properly, or when operating
-system updates and patches are applied and gcc is not reinstalled. While
-the autoconfigure process is quite thorough, the Unix programming
-cultures of the various workstation makers still remain idiosyncratic.
-
-<H4>Installation</H4>
-
-As root, use the <TT>make install</TT> command to install the binaries
-in the destination directory. You must of course have write permission
-on the install destination directory. This includes the programs <TT><A
-HREF="ntpd.htm">ntpd</A></TT> (the daemon), <TT><A
-HREF="ntpdc.htm">ntpdc</A></TT> (an <TT>ntpd</TT>-dependent query
-program), <TT><A HREF="ntpq.htm">ntpq</A></TT> (a standard query
-program), <TT><A HREF="ntpdate.htm">ntpdate</A></TT> (an <TT>rdate</TT>
-replacement for boot time date setting and sloppy time keeping) and
-<TT><A HREF="ntptrace.htm">ntptrace</A></TT> (a utility useful to find
-the primary (stratum-1) servers). In some systems, the <TT><A
-HREF="tickadj.htm">tickadj</A></TT> (a utility useful to adjust kernel
-variables) is installed. If the precision time kernel modifications are
-present, the <TT><A HREF="ntptime.htm">ntptime</A></TT> (a utility
-useful to debug kernel time functions) is installed.
-
-<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 possibly a
-cryptographic key file <TT>ntp.keys</TT>. Directions for doing that are
-in the <A HREF="notes.htm">Notes on Configuring NTP and Setting up a NTP
-Subnet</A>. The behavior when the daemon starts for the first time can
-be counterintuitive. To reduce the level of angst, see the <a
-href=quick.htm>Quick Start</a> page. A tutorial on debugging technique
-is in <A HREF="debug.htm">NTP Debugging Technique</A>.
-
-<P>If problems peculiar to the particular hardware and software
-environment (e.g. operating system -specific issues) are suspected,
-browse the <A HREF="hints.htm">Hints and Kinks</A> page.
-
-<P>Bug reports of a general nature can be sent to David Mills <A
-HREF="mailto: mills@udel.edu"><mills@udel.edu></A>. Bug reports of a
-specific nature on features implemented by the programmer corps
-mentioned in the <A HREF="copyright.htm">Copyright</A> page should be
-sent directly to the implementor listed in that page, with copy to
-mills@udel.edu.
-
-<P><B>Please include the version of the source distribution (e.g., ntp-
-4.0.70a) in your bug report.</B>
-
-<P><B>Please include the <B>output</B> of <TT>config.guess</TT> in your
-bug report.</B>
-
-<P><B>It will look something like: <TT>pdp11-dec-fuzzos3.4</TT></B>
-
-<P>Additional <TT>make</TT> commands
-
-<DL>
-
-<DT><TT>make clean</TT></DT>
-
-<DD>Cleans out object files, programs and temporary files.</DD>
-
-<DT><TT>make distclean</TT></DT>
-
-<DD>Does the work of <TT>clean</TT>, but cleans out all directories in
-preparation for a new distribution release.</DD>
-
-<DT><TT>make dist</TT></DT>
-
-<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.</DD>
-
-</DL>
-
-<H4>Building and Installing under Windows NT</H4>
-See <tt><a href="hints/winnt.htm">hints/winnt.htm</a> </tt>for directions
-to compile the sources and install the executables.
-
-<hr><a href=index.htm><img align=left
-src=pic/home.gif></a><address><a href="mailto:mills@udel.edu"> David L.
-Mills <mills@udel.edu></a>
-</address></body></html>
+warnings using <tt>cc</tt> and a moderate level of warnings using
+<tt>gcc</tt>. Note: On some Unix platforms the use of <tt>gcc</tt>
+can result in quite a few complaints about system header files and
+type inconsistencies, especially about pointer variables. This is
+usually the case when the system header files are not up to ANSI
+standards or <tt>gcc</tt>-isms, when gcc is not installed properly,
+or when operating system updates and patches are applied and gcc is
+not reinstalled. While the autoconfigure process is quite thorough,
+the Unix programming cultures of the various workstation makers
+still remain idiosyncratic.</p>
+
+<h4>Installation</h4>
+
+As root, use the <tt>make install</tt> command to install the
+binaries in the destination directory. You must of course have
+write permission on the install in the destination directory. This
+includes the following programs:
+
+<ul>
+<li><a href="ntpd.htm"><tt>ntpd</tt> - Network Time Protocol (NTP)
+daemon</a></li>
+
+<li><a href="ntpq.htm"><tt>ntpq</tt> - standard NTP query
+program</a></li>
+
+<li><a href="ntpdc.htm"><tt>ntpdc</tt> - special NTP query
+program</a></li>
+
+<li><a href="ntpdate.htm"><tt>ntpdate</tt> - set the date and time
+via NTP</a></li>
+
+<li><a href="ntptrace.htm"><tt>ntptrace</tt> - trace a chain of NTP
+servers back to the primary source</a></li>
+</ul>
+
+<p>If the precision time kernel modifications are present, the
+following program is installed:</p>
+
+<ul>
+<li><a href="ntptime.htm"><tt>ntptime</tt> - read kernel time
+variables</a></li>
+</ul>
+
+<p>If the public key authentication functions are present, the
+following program is installed:</p>
+
+<ul>
+<li><a href="genkeys.htm"><tt>ntp-genkeys</tt> - generate public
+and private keys</a></li>
+</ul>
+
+<p>In some systems that include the capability to edit kernel
+variables, the following program is installed:</p>
+
+<ul>
+<li><a href="tickadj.htm"><tt>tickadj</tt> - set time-related
+kernel variables</a></li>
+</ul>
+
+<h4>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
+possibly a cryptographic key file <tt>ntp.keys</tt>. Newbies should
+see the <a href="quick.htm">Quick Start</a> page for orientation.
+Seasoned veterans can start with the <a href="ntpd.htm"><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.htm">Notes on Configuring NTP and Setting up a NTP
+Subnet</a> page.</p>
+
+<h4>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.htm">Hints and Kinks</a> page. For other
+problems a tutorial on debugging technique is in the <a href=
+"debug.htm">NTP Debugging Technique</a> page. As always, the first
+line of general assistance is the <a href="http://www.ntp.org">NTP
+web site 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. Bug reports of a specific
+nature should be sent to <a href="mailto:bugs@mail.ntp.org">
+<bugs@mail.ntp.org></a>. Bug reports of a specific nature on
+features implemented by the programmer corps mentioned in the <a
+href="copyright.htm">Copyright</a> page should be sent directly to
+the implementor listed in that page, with copy to
+bugs@mail.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>
+
+<p>Additional <tt>make</tt> commands</p>
+
+<dl>
+<dt><tt>make clean</tt></dt>
+
+<dd>Cleans out object files, programs and temporary files.</dd>
+
+<dt><tt>make distclean</tt></dt>
+
+<dd>Does the work of <tt>clean</tt>, but cleans out all directories
+in preparation for a new distribution release.</dd>
+
+<dt><tt>make dist</tt></dt>
+
+<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.</dd>
+</dl>
+
+<h4>Building and Installing under Windows NT</h4>
+
+See <tt><a href="hints/winnt.htm">hints/winnt.htm</a></tt> for
+directions to compile the sources and install the executables.
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
-<html><head><title>
-Configuration Options
-</title></head><body><h3>
-Configuration Options
-</h3>
-
-<img align=left src=pic/boom3a.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
-
-<p>The chicken is getting configuration advice.
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Configuration Options</title>
+</head>
+<body>
+<h3>Configuration Options</h3>
+
+<img align="left" src="pic/boom3a.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
+Walt Kelly</a>
+
+<p>The chicken is getting configuration advice.<br clear="left">
+</p>
+
+<hr>
<h4>Configuration Support</h4>
-<p>Following is a description of the configuration commands in NTPv4. These commands have the same basic functions as in NTPv3 and in some cases new functions and new arguments. There are two classes of commands, configuration commands that configure a persistent association with a remote server or peer or reference clock, and auxilliary commands that specify environmental variables that control various related operations.
+<p>Following is a description of the configuration commands in
+NTPv4. These commands have the same basic functions as in NTPv3 and
+in some cases new functions and new arguments. There are two
+classes of commands, configuration commands that configure a
+persistent association with a remote server or peer or reference
+clock, and auxilliary commands that specify environmental variables
+that control various related operations.</p>
<h4>Configuration Commands</h4>
-<p>The various modes are determined by the command keyword and the type of the required IP address. Addresses are classed by type as (s) a remote server or peer (IP class A, B and C), (b) the broadcast address of a local interface, (m) a multicast address (IP class D), or (r) a reference clock address (127.127.x.x). Note that only those options applicable to each command are listed below. Use of options not listed may not be caught as an error, but may result in some weird and even destructive behavior.
-<dl>
+<p>The various modes are determined by the command keyword and the
+type of the required IP address. Addresses are classed by type as
+(s) a remote server or peer (IP class A, B and C), (b) the
+broadcast address of a local interface, (m) a multicast address (IP
+class D), or (r) a reference clock address (127.127.x.x). Note that
+only those options applicable to each command are listed below. Use
+of options not listed may not be caught as an error, but may result
+in some weird and even destructive behavior.</p>
-<dt><tt>peer <i>address</i> [key <i>key</i> | autokey] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>maxpoll</i>]</tt></dt>
-
-<p><dt><tt>server <i>address</i> [key <i>key</i> | autokey] [burst] [iburst] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>maxpoll</i>]</tt></dt>
+<dl>
+<dt><tt>server <i>address</i> [key <i>key</i> | autokey] [burst]
+[iburst] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>]
+[maxpoll <i>maxpoll</i>]</tt></dt>
-<p><dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey] [version <i>version</i>] [minpoll <i>minpoll</i>] [ttl <i>ttl</i>]</tt></dt>
+<dt><tt>peer <i>address</i> [key <i>key</i> | autokey] [version <i>
+version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>
+maxpoll</i>]</tt></dt>
-<p><dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey] [version <i>version</i>] [minpoll <i>minpoll</i> [maxpoll <i>maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
+<dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey]
+[version <i>version</i>] [minpoll <i>minpoll</i>] [ttl <i>
+ttl</i>]</tt></dt>
-<p><dd>These four commands specify the time server name or address to be used and the mode in which to operate. The <i>address</i> can be either a DNS name or a IP address in dotted-quad notation. Additional information on association behavior can be found in the <a href="assoc.htm">Association Management</a> page.</dd>
+<dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey]
+[version <i>version</i>] [minpoll <i>minpoll</i> [maxpoll <i>
+maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
-<dd><dl>
+<dd>These four commands specify the time server name or address to
+be used and the mode in which to operate. The <i>address</i> can be
+either a DNS name or a IP address in dotted-quad notation.
+Additional information on association behavior can be found in the
+<a href="assoc.htm">Association Management</a> page.
+<dl>
<dt><tt>server</tt></dt>
-<dd>For type s and r addresses, this command mobilizes a persistent client mode association with the specified remote server or local radio clock. In this mode the local clock can synchronized to the remote server, but the remote server can never be synchronized to the local clock. This command should NOT be used for type <tt>b</tt> or <tt>m</tt> addresses.</</dd>
+
+<dd>For type s and r addresses, this command mobilizes a persistent
+client mode association with the specified remote server or local
+radio clock. In this mode the local clock can synchronized to the
+remote server, but the remote server can never be synchronized to
+the local clock. This command should NOT be used for type <tt>
+b</tt> or <tt>m</tt> addresses.</</dd></dd>
<dt><tt>peer</tt></dt>
-<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active mode association with the specified remote peer. In this mode the local clock can be synchronized to the remote peer or the remote peer can be synchronized to the local clock. This is useful in a network of servers where, depending on various failure scenarios, either the local or remote peer may be the better source of time. This command should NOT be used for type <tt>b</tt>, <tt>m</tt> or <tt>r</tt> addresses.</dd>
+
+<dd>For type s addresses (only), this command mobilizes a
+persistent symmetric-active mode association with the specified
+remote peer. In this mode the local clock can be synchronized to
+the remote peer or the remote peer can be synchronized to the local
+clock. This is useful in a network of servers where, depending on
+various failure scenarios, either the local or remote peer may be
+the better source of time. This command should NOT be used for type
+<tt>b</tt>, <tt>m</tt> or <tt>r</tt> addresses.</dd>
<dt><tt>broadcast</tt></dt>
-<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this command mobilizes a persistent broadcast mode association. Multiple commands can be used to specify multiple local broadcast interfaces (subnets) and/or multiple multicast groups. Note that local broadcast messages go only to the interface associated with the subnet specified, but multicast messages go to all interfaces.</dd>
-<p><dd>In broadcast mode the local server sends periodic broadcast messages to a client population at the <i><tt>address</tt></i> specified, which is usually the broadcast address on (one of) the local network(s) or a multicast address assigned to NTP. The IANA has assigned the multicast group address 224.0.1.1 exclusively to NTP, but other nonconflicting addresses can be used to contain the messages within administrative boundaries. Ordinarily, this specification applies only to the local server operating as a sender; for operation as a broadcast client, see the <tt>broadcastclient</tt> or <tt>multicastclient</tt> commands below.</dd>
+<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this
+command mobilizes a persistent broadcast mode association. Multiple
+commands can be used to specify multiple local broadcast interfaces
+(subnets) and/or multiple multicast groups. Note that local
+broadcast messages go only to the interface associated with the
+subnet specified, but multicast messages go to all interfaces.</dd>
+
+<dd>In broadcast mode the local server sends periodic broadcast
+messages to a client population at the <i><tt>address</tt></i>
+specified, which is usually the broadcast address on (one of) the
+local network(s) or a multicast address assigned to NTP. The IANA
+has assigned the multicast group address 224.0.1.1 exclusively to
+NTP, but other nonconflicting addresses can be used to contain the
+messages within administrative boundaries. Ordinarily, this
+specification applies only to the local server operating as a
+sender; for operation as a broadcast client, see the <tt>
+broadcastclient</tt> or <tt>multicastclient</tt> commands
+below.</dd>
+
+<dt><tt>manycastclient</tt></dt>
+
+<dd>For type <tt>m</tt> addresses (only), this command mobilizes a
+manycast client mode association for the multicast address
+specified. In this case a specific address must be supplied which
+matches the address used on the <tt>manycastserver</tt> command for
+the designated manycast servers. The NTP multicast address
+224.0.1.1 assigned by the IANA should NOT be used, unless specific
+means are taken to avoid spraying large areas of the Internet with
+these messages and causing a possibly massive implosion of replies
+at the sender.</dd>
+
+<dd>The <tt>manycast</tt> command specifies that the local server
+is to operate in client mode with the remote servers that are
+discovered as the result of broadcast/multicast messages. The
+client broadcasts a request message to the group address associated
+with the specified <i><tt>address</tt></i> and specifically enabled
+servers respond to these messages. The client selects the servers
+providing the best time and continues as with the <tt>server</tt>
+command. The remaining servers are discarded as if never
+heard.</dd>
+
+<dt>Options</dt>
-<dt><tt>manycastclient</tt>
-<dd>For type <tt>m</tt> addresses (only), this command mobilizes a manycast client mode association for the multicast address specified. In this case a specific address must be supplied which matches the address used on the <tt>manycastserver</tt> command for the designated manycast servers. The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to avoid spraying large areas of the Internet with these messages and causing a possibly massive implosion of replies at the sender. </dd>
+<dt><tt>autokey</tt></dt>
-<p><dd>The <tt>manycast</tt> command specifies that the local server is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified <i><tt>address</tt></i> and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the <tt>server</tt> command. The remaining servers are discarded as if never heard.</dd>
+<dd>All packets sent to and received from the server or peer are to
+include authentication fields encrypted using the autokey scheme
+described in the <a href="authopt.htm">Authentication Options</a>
+page.</dd>
-</dl>
+<dt><tt>burst</tt></dt>
-<dd>Options</dd>
+<dd>when the server is reachable and at each poll interval, send a
+burst of eight packets instead of the usual one packet. The spacing
+between the first and the second packets is about 16s to allow a
+modem call to complete, while the spacing between the remaining
+packets is about 2s. This is designed to improve timekeeping
+quality with the <tt>server</tt> command and <tt>s</tt>
+addresses.</dd>
-<dl><dd>
+<dt><tt>iburst</tt></dt>
-<dt><tt>autokey</tt></dt>
-<dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the autokey scheme described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
+<dd>When the server is unreachable and at each poll interval, send
+a burst of eight packets instead of the usual one. As long as the
+server is unreachable, the spacing between packets is about 16s to
+allow a modem call to complete. Once the server is reachable, the
+spacing between packets is about 2s. This is designed to speed the
+initial synchronization acquisition with the <tt>server</tt>
+command and <tt>s</tt> addresses and when <tt>ntpd</tt> is started
+with the <tt>-q</tt> option.</dd>
-<dt><tt>burst</tt></dt>
-<dd>At each poll interval, send a burst of eight packets instead of the usual one packet. The spacing between the first and the second packets is about 20s to allow a modem call to complete, while the spacing between the remaining packets is about 2s. This is designed to improve timekeeping quality with the <tt>server</tt> command and <tt>s</tt> addresses.</dd>
+<dt><tt>key</tt> <i><tt>key</tt></i></dt>
-<dt><tt>iburst</tt></dt>
-<dd>At the first poll interval, send a burst of eight packets instead of the usual one. The spacing between the first and the second packets is about 20s to allow a modem call to complete, while the spacing between the remaining packets is about 2s. This is designed to speed the initial synchronization acquisition with the <tt>server</tt> command and <tt>s</tt> addresses.</dd>
+<dd>All packets sent to and received from the server or peer are to
+include authentication fields encrypted using the specified <i>
+key</i> identifier with values from 1 to 65534, inclusive. The
+default is to include no encryption field.</dd>
-<dt><tt>key </tt><i><tt>key</tt></i></dt>
-<dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified <i>key</i> identifier with values from 1 to 65534, inclusive. The default is to include no encryption field.</dd>
+<dt><tt>minpoll <i>minpoll</i></tt><br>
+<tt>maxpoll <i>maxpoll</i></tt></dt>
-<dt><tt>minpoll <i>minpoll</i></tt>
-<br><tt>maxpoll <i>maxpoll</i></tt>
-<dd>These options specify the minimum and maximum polling intervals for NTP messages, in seconds to the power of two. The default range is 6 (64 s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.</dd>
+<dd>These options specify the minimum and maximum polling intervals
+for NTP messages, in seconds to the power of two. The default range
+is 6 (64 s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17
+(36.4 h) inclusive.</dd>
<dt><tt>prefer</tt></dt>
-<dd>Marks the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the <a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt> Keyword </a>page for further information.</dd>
+
+<dd>Marks the server as preferred. All other things being equal,
+this host will be chosen for synchronization among a set of
+correctly operating hosts. See the <a href="prefer.htm">Mitigation
+Rules and the <tt>prefer</tt> Keyword</a> page for further
+information.</dd>
<dt><tt>ttl <i>ttl</i></tt></dt>
-<dd>This option is used only with broadcast server and manycast client modes. It specifies the time-to-live <i><tt>ttl</tt></i> to use on broadcast server and multicast server and the maximum <i><tt>ttl</tt></i> for the expanding ring search with manycast client packets. Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator.</dd>
+
+<dd>This option is used only with broadcast server and manycast
+client modes. It specifies the time-to-live <i><tt>ttl</tt></i> to
+use on broadcast server and multicast server and the maximum <i>
+<tt>ttl</tt></i> for the expanding ring search with manycast client
+packets. Selection of the proper value, which defaults to 127, is
+something of a black art and should be coordinated with the network
+administrator.</dd>
<dt><tt>version <i>version</i></tt></dt>
-<dd>Specifies the version number to be used for outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.</dd>
-</dl></dd></dl></dd>
+<dd>Specifies the version number to be used for outgoing NTP
+packets. Versions 1-4 are the choices, with version 4 the
+default.</dd>
+</dl>
+</dd>
+</dl>
<h4>Auxilliary Commands</h4>
<dl>
-
-<dt><tt>broadcastclient</tt>
-<dd>This command enables reception of broadcast server messages to any local interface (type b) address. Upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding broadcast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
-
-<dt><tt>manycastserver <i>address</i> [...]</tt>
-<dd>This command enables reception of manycast client messages to the multicast group address(es) (type m) specified. At least one address is required, but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
-
-<dt><tt>multicastclient [<i>address</i>] [...]</tt>
-<dd>This command enables reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
-
+<dt><tt>broadcastclient</tt></dt>
+
+<dd>This command enables reception of broadcast server messages to
+any local interface (type b) address. Upon receiving a message for
+the first time, the broadcast client measures the nominal server
+propagation delay using a brief client/server exchange with the
+server, then enters the broadcast client mode, in which it
+synchronizes to succeeding broadcast messages. Note that, in order
+to avoid accidental or malicious disruption in this mode, both the
+server and client should operate using symmetric-key or public-key
+authentication as described in the <a href="authopt.htm">
+Authentication Options</a> page.</dd>
+
+<dt><tt>manycastserver <i>address</i> [...]</tt></dt>
+
+<dd>This command enables reception of manycast client messages to
+the multicast group address(es) (type m) specified. At least one
+address is required, but The NTP multicast address 224.0.1.1
+assigned by the IANA should NOT be used, unless specific means are
+taken to limit the span of the reply and avoid a possibly massive
+implosion at the original sender. Note that, in order to avoid
+accidental or malicious disruption in this mode, both the server
+and client should operate using symmetric-key or public-key
+authentication as described in the <a href="authopt.htm">
+Authentication Options</a> page.</dd>
+
+<dt><tt>multicastclient [<i>address</i>] [...]</tt></dt>
+
+<dd>This command enables reception of multicast server messages to
+the multicast group address(es) (type m) specified. Upon receiving
+a message for the first time, the multicast client measures the
+nominal server propagation delay using a brief client/server
+exchange with the server, then enters the broadcast client mode, in
+which it synchronizes to succeeding multicast messages. Note that,
+in order to avoid accidental or malicious disruption in this mode,
+both the server and client should operate using symmetric-key or
+public-key authentication as described in the <a href=
+"authopt.htm">Authentication Options</a> page.</dd>
</dl>
<h4>Bugs</h4>
-<p>The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.
+<p>The syntax checking is not picky; some combinations of
+ridiculous and even hilarious options and modes may not be
+detected.</p>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html><head><title>
Copyright Notice
</title></head><body><h3>
<li><A HREF="mailto: greg.brackley@bigfoot.com">Greg Brackley <greg.brackley@bigfoot.com></a> Major rework of WINNT port. Clean up recvbuf and iosignal code into separate modules.</li>
-<li><A HREF="mailto: Marc.Brett@westerngeco.com">Marc Brett <Marc.Brett@westerngeco.com></a> Magnavox GPS clock driver</li>
+<li><A HREF="mailto: Marc.Brett@westgeo.com">Marc Brett <Marc.Brett@westgeo.com></a> Magnavox GPS clock driver</li>
<li><A HREF="mailto: Piete.Brooks@cl.cam.ac.uk">Piete Brooks <Piete.Brooks@cl.cam.ac.uk></a> MSF clock driver, Trimble PARSE support</li>
</ol>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
+<hr>
+<a href=index.htm><img align=left src=pic/home.gif alt="gif"></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></body></html>
-<html><head><title>
-PPS Clock Discipline
-</title></head><body><h3>
-PPS Clock Discipline
-</h3><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>PPS Clock Discipline</title>
+</head>
+<body>
+<h3>PPS Clock Discipline</h3>
+
+<hr>
<h4>Synopsis</h4>
-Address: 127.127.22.<I>u</I>
-<br>Reference ID: <tt>PPS</tt>
-<br>Driver ID: <tt>PPS</tt>
-<br>Serial or Parallel Port: <tt>/dev/pps<I>u</I></tt>
-<br>Requires: PPSAPI interface
+Address: 127.127.22.<i>u</i> <br>
+Reference ID: <tt>PPS</tt> <br>
+Driver ID: <tt>PPS</tt> <br>
+Serial or Parallel Port: <tt>/dev/pps<i>u</i></tt> <br>
+Requires: PPSAPI interface
-<p>Note: This driver supersedes an older one of the same name. The older driver operated with several somewhat archaic signal interface devices, required intricate configuration and was poorly documented. This driver operates only with the PPSAPI interface proposed as an IETF standard.
+<p>Note: This driver supersedes an older one of the same name. The
+older driver operated with several somewhat archaic signal
+interface devices, required intricate configuration and was poorly
+documented. This driver operates only with the PPSAPI interface
+proposed as an IETF standard.</p>
<h4>Description</h4>
-<p>This driver furnishes an interface for the pulse-per-second (PPS) produced by a cesium clock, radio clock or related equipment. It can be used to augment the serial timecode generated by a GPS receiver, for example. It can be used to remove accumulated jitter and re-time a secondary server when synchronized to a primary server over a congested, wide-area network and before redistributing the time to local clients. The driver includes extensive signal sanity checks and grooming algorithms. A range gate and frequency discriminator reject noise and signals with incorrect frequency. A multiple-stage median filter rejects jitter due to hardware interrupt and operating system latencies. A trimmed-mean algorithm determines the best time samples. With typical workstations and processing loads, the incidental jitter can be reduced to less than a microsecond.
-
-<p>While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose a auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source is marked as the prefer peer, as described in the <a href=prefer.htm>Mitigation Rules and the <tt>prefer</tt> Keyword </A>page.
-
-<p>The driver requires the PPSAPI interface<sup>1</sup>, which is a proposed IETF standard. The interface consists of the <tt>timepps.h</tt> header file and associated kernel support. Support for this interface is included in current versions of FreeBSD and Linux and proprietary versions for Digital/Compaq Tru64 (Alpha), Sun Solaris and Sun SunOS.
-
-<p>The PPS source can be connected via a serial or parallel port, depending on the hardware and operating system. The port can be dedicated to the PPS source or shared with another device. A radio clock is usually connected via a serial port and the PPS source connected via a level converter to the data carrier detect (DCD) pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some systems where a parallel port and driver are available, the PPS signal can be connected directly to the ACK pin (pin 10) of the connector. Whether the PPS signal is connected via a dedicated port or shared with another device, the driver opens the device <tt>/dev/pps%d</tt>, where <tt>%d</tt> is the unit number. As with other drivers, links can be used to redirect the logical name can be redirected to the actual physical device.
-
-<p>Note that the PPS source is considered reachable only if the auxiliary source is the prefer peer, is reachable and is selected to discipline the system clock. The stratum assigned to the PPS source is automatically determined. If the auxiliary source is unreachable or inoperative, the stratum is set to 16; otherwise it is set to match the stratum of the auxiliary source. Since the stratum is determined dynamically, it is not possible to assign another stratum using the <tt>fudge</tt> command as in other drivers.
+<p>This driver furnishes an interface for the pulse-per-second
+(PPS) produced by a cesium clock, radio clock or related equipment.
+It can be used to augment the serial timecode generated by a GPS
+receiver, for example. It can be used to remove accumulated jitter
+and re-time a secondary server when synchronized to a primary
+server over a congested, wide-area network and before
+redistributing the time to local clients. The driver includes
+extensive signal sanity checks and grooming algorithms. A range
+gate and frequency discriminator reject noise and signals with
+incorrect frequency. A multiple-stage median filter rejects jitter
+due to hardware interrupt and operating system latencies. A
+trimmed-mean algorithm determines the best time samples. With
+typical workstations and processing loads, the incidental jitter
+can be reduced to less than a microsecond.</p>
+
+<p>While this driver can discipline the time and frequency relative
+to the PPS source, it cannot number the seconds. For this purpose a
+auxiliary source is required, ordinarily a radio clock operated as
+a primary reference (stratum 1) source; however, another NTP time
+server can be used as well. For this purpose, the auxiliary source
+is marked as the prefer peer, as described in the <a href=
+"prefer.htm">Mitigation Rules and the <tt>prefer</tt> Keyword</a>
+page.</p>
+
+<p>The driver requires the PPSAPI interface<sup>1</sup>, which is a
+proposed IETF standard. The interface consists of the <tt>
+timepps.h</tt> header file and associated kernel support. Support
+for this interface is included in current versions of FreeBSD and
+Linux and proprietary versions for Digital/Compaq Tru64 (Alpha),
+Sun Solaris and Sun SunOS. See the <a href="pps.htm">
+Pulse-per-second (PPS) Signal Interfacing</a> page for further
+information</p>
+
+<p>The PPS source can be connected via a serial or parallel port,
+depending on the hardware and operating system. The port can be
+dedicated to the PPS source or shared with another device. A radio
+clock is usually connected via a serial port and the PPS source
+connected via a level converter to the data carrier detect (DCD)
+pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some
+systems where a parallel port and driver are available, the PPS
+signal can be connected directly to the ACK pin (pin 10) of the
+connector. Whether the PPS signal is connected via a dedicated port
+or shared with another device, the driver opens the device <tt>
+/dev/pps%d</tt>, where <tt>%d</tt> is the unit number. As with
+other drivers, links can be used to redirect the logical name can
+be redirected to the actual physical device.</p>
+
+<p>Note that the PPS source is considered reachable only if the
+auxiliary source is the prefer peer, is reachable and is selected
+to discipline the system clock. The stratum assigned to the PPS
+source is automatically determined. If the auxiliary source is
+unreachable or inoperative, the stratum is set to 16; otherwise it
+is set to match the stratum of the auxiliary source. Since the
+stratum is determined dynamically, it is not possible to assign
+another stratum using the <tt>fudge</tt> command as in other
+drivers.</p>
<h4>Fudge Factors</h4>
<dl>
+<dt><tt>time1 <i>time</i></tt></dt>
+
+<dd>Specifies the time offset calibration factor, in seconds and
+fraction, with default 0.0.dd></dd>
-<dt><tt>time1 <I>time</I></tt></dt>
-<dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.dd>
+<dt><tt>time2 <i>time</i></tt></dt>
-<dt><tt>time2 <I>time</I></tt></dt>
<dd>Not used by this driver.</dd>
-<dt><tt>stratum <I>number</I></tt></dt>
-<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd>
+<dt><tt>stratum <i>number</i></tt></dt>
+
+<dd>Specifies the driver stratum, in decimal from 0 to 15, with
+default 0.</dd>
+
+<dt><tt>refid <i>string</i></tt></dt>
-<dt><tt>refid <I>string</I></tt></dt>
-<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>PPS</tt>.</dd>
+<dd>Specifies the driver reference identifier, an ASCII string from
+one to four characters, with default <tt>PPS</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
+
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
-<dd>Specifies the PPS signal on-time edge: 0 for assert (default), 1 for clear.<dd>
+
+<dd>Specifies the PPS signal on-time edge: 0 for assert (default),
+1 for clear.</dd>
<dt><tt>flag3 0 | 1</tt></dt>
-<dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.</dd>
+
+<dd>Controls the kernel PPS discipline: 0 for disable (default), 1
+for enable.</dd>
<dt><tt>flag4 0 | 1</tt></dt>
-<dd>Not used by this driver.</dd>
+<dd>Not used by this driver.</dd>
</dl>
-<p>Additional Information
+<p>Additional Information</p>
-<p><A HREF="refclock.htm">Reference Clock Drivers</A></dl>
+<p><a href="refclock.htm">Reference Clock Drivers</a></p>
-<p>Reference
+<p>Reference</p>
<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.</li>
+</ol>
-<p><li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp.</li>
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
-</ol>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
<h4>Description</h4>
-This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. Transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.
+<p>This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. It replaces an earlier one, built by Dennis Ferguson in 1988, which required a special line discipline to preprocessed the signal. The new driver includes more powerful algorithms implemented directly in the driver and requires no preprocessing.
-<p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described in the <a href=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</a> page. The driver can be compiled to use a modem to receive the radio signal and demodulate the data. Alternatively, the driver can be compiled to use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone on line input port. Ordinarily, the driver is compiled for the audio codec only for SunOS and Solaris machines and for the serial port for other machines.
+<p>CHU transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.
-<p>The driver replaces an earlier one built by Dennis Ferguson in 1988. The earlier driver required a special line discipline which preprocessed the signal in order to improve accuracy and avoid errors. The new driver includes more powerful algorithms implemented directly in the driver and requires no line discipline. It decodes the data using a maximum-likelihood technique which exploits the considerable degree of redundancy available to maximize accuracy and minimize errors.
+<p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described in the <a href=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</a> page. The driver can use the modem to receive the radio signal and demodulate the data or, if available, the driver can use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone on line input port.
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href=driver36.htm>Radio WWV/H Audio Demodulator/Decoder</a> and the <a href=driver6.htm>IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href=audio.htm>Reference Clock Audio Drivers</a> page.
<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h), although this can be changed with configuration commands. As long as the clock is set or verified at least once during this interval, the NTP algorithms will consider the source reachable and selectable to discipline the system clock. However, if this does not happen for eight poll intervals, the algorithms will consider the source unreachable and some other source will be chosen (if available) to discipline the system clock.
-<p>The decoding algorithms take advantage of all the redundancy available in each broadcast message or burst. In each burst described in the next section, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.
+<p>The decoding algorithms process the data using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.
-<p>A timecode in the format described below is assembled when all bursts have been received in the minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the above requirements are met. The <tt>yyyy</tt> year field in the timecode indicates whether a valid format B burst has been received. Upon startup, this field is initialized at zero; when a valid format B burst is received, it will be set to the correct Gregorian year. The <tt>q</tt> quality character field in the timecode indicates whether a valid timecode has been determined. If any of the high order three bits of this character are set, the timecode is invalid.
+<p>A timecode in the format described below is assembled when all bursts have been received in the minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the above requirements are met. The <tt>yyyy</tt> year field in the timecode indicates whether a valid format B burst has been received. Upon startup, this field is initialized at zero; when a valid format B burst is received, it is set to the current Gregorian year. The <tt>q</tt> quality character field in the timecode indicates whether a valid timecode has been determined. If any of the high order three bits of this character are set, the timecode is invalid.
<p>Once the clock has been set for the first time, it will appear reachable and selectable to discipline the system clock, even if the broadcast signal is lost. Since the signals are almost always available during some period of the day and the NTP clock discipline algorithms are designed to work well even in this case, it is unlikely that the system clock could drift more than a few tens of milliseconds during periods of signal loss. To protect against this most unlikely situation, if after four days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.
-<html><head><title>
-Executive Summary - Computer Network Time Synchronization
-</title></head><body><H3>
-Executive Summary - Computer Network Time Synchronization
-</h3>
-
-<img align=left src=pic/alice12.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>The executive is the one on the left.
-
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" &lt;html>
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Executive Summary - Computer Network Time
+Synchronization</title>
+</head>
+<body>
+<h3>Executive Summary - Computer Network Time Synchronization</h3>
+
+<img align="left" src="pic/alice12.gif" alt="gif"><a href=
+"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
+Carroll</a>
+
+<p>The executive is the one on the left.<br clear="left">
+</p>
+
+<hr>
<h4>Introduction</h4>
-<p>The standard timescale used by most nations of the world is Coordinated UniversalTime (UTC), which is based on the Earth's rotation about its axis, and the Gregorian Calendar, which is based on the Earth's rotation about the Sun. The UTC timescale is disciplined with respect to International Atomic Time (TAI) by inserting leap seconds at intervals of about 18 months. UTC time is disseminated by various means, including radio and satellite navigation systems, telephone modems and portable clocks.
-
-<p>Special purpose receivers are available for many time-dissemination services, including the Global Position System (GPS) and other services operated by various national governments. For reasons of cost and convenience, it is not possible to equip every computer with one of these receivers. However, it is possible to equip some number of computers acting as primary time servers to synchronize a much larger number of secondary servers and clients connected by a common network. In order to do this, a distributed network clock synchronization
-protocol is required which can read a server clock, transmit the reading to one or more clients and adjust each client clock as required. Protocols that do this include the Network Time Protocol (NTP), Digital Time Synchronization Protocol (DTSS) and others found in the literature (See "Further Reading" at the end of this article.)
+<p>The standard timescale used by most nations of the world is
+Coordinated UniversalTime (UTC), which is based on the Earth's
+rotation about its axis, and the Gregorian Calendar, which is based
+on the Earth's rotation about the Sun. The UTC timescale is
+disciplined with respect to International Atomic Time (TAI) by
+inserting leap seconds at intervals of about 18 months. UTC time is
+disseminated by various means, including radio and satellite
+navigation systems, telephone modems and portable clocks.</p>
+
+<p>Special purpose receivers are available for many
+time-dissemination services, including the Global Position System
+(GPS) and other services operated by various national governments.
+For reasons of cost and convenience, it is not possible to equip
+every computer with one of these receivers. However, it is possible
+to equip some number of computers acting as primary time servers to
+synchronize a much larger number of secondary servers and clients
+connected by a common network. In order to do this, a distributed
+network clock synchronization protocol is required which can read a
+server clock, transmit the reading to one or more clients and
+adjust each client clock as required. Protocols that do this
+include the Network Time Protocol (NTP), Digital Time
+Synchronization Protocol (DTSS) and others found in the literature
+(See "Further Reading" at the end of this article.)</p>
<h4>Protocol Design Issues</h4>
-<p>The synchronization protocol determines the time offset of the server clock relative to the client clock. The various synchronization protocols in use today provide different means to do this, but they all follow the same general model. On request, the server sends a message including its current clock value or <i>timestamp</i> and the client records its own timestamp upon arrival of the message. For the best accuracy, the client needs to measure the server-client propagation delay to determine its clock offset relative to the server. Since it is not possible to determine the one-way delays, unless the actual clock offset is known, the protocol measures the total roundtrip delay and assumes the propagation times are statistically equal in each direction. In general, this is a useful approximation; however, in the Internet of today, network paths and the associated delays can differ significantly due to the individual service providers.
-
-<p>The community served by the synchronization protocol can be very large. For instance, the NTP community in the Internet of 1998 includes over 230 primary time servers, synchronized by radio, satellite and modem, and well over 100,000 secondary servers and clients. In addition, there are many thousands of private communities in large government, corporate and institution networks. Each community is organized as a tree graph or <i>subnet</i>, with the primary servers at the root and secondary servers and clients at increasing hop count, or stratum level, in corporate, department and desktop networks. It is usually necessary at each stratum level to employ redundant servers and diverse network paths in order to protect against broken software, hardware and network links.
-
-<p>Synchronization protocols work in one or more association modes, depending on the protocol design. Client/server mode, also called master/slave mode, is supported in both DTSS and NTP. In this mode, a client synchronizes to a stateless server as in the conventional RPC model. NTP also supports symmetric mode, which allows either of two peer servers to synchronize to the other, in order to provide mutual backup. DTSS and NTP support a broadcast mode which allows many clients to synchronize to one or a few servers, reducing network traffic when large numbers of clients are involved. In NTP, IP multicast can be used when the subnet spans multiple networks.
-
-<p>Configuration management can be a serious problem in large subnets. Various schemes which index public databases and network directory services are used in DTSS and NTP to discover servers. Both protocols use broadcast modes to support large client populations; but, since listen-only clients cannot calibrate the delay, accuracy can suffer. In NTP, clients determine the delay at the time a server is first discovered by polling the server in client/server mode and then reverting to listen-only mode. In addition, NTP clients can broadcast a special "manycast" message to solicit responses from nearby servers and continue in client/server mode with the respondents.
+<p>The synchronization protocol determines the time offset of the
+server clock relative to the client clock. The various
+synchronization protocols in use today provide different means to
+do this, but they all follow the same general model. On request,
+the server sends a message including its current clock value or <i>
+timestamp</i> and the client records its own timestamp upon arrival
+of the message. For the best accuracy, the client needs to measure
+the server-client propagation delay to determine its clock offset
+relative to the server. Since it is not possible to determine the
+one-way delays, unless the actual clock offset is known, the
+protocol measures the total roundtrip delay and assumes the
+propagation times are statistically equal in each direction. In
+general, this is a useful approximation; however, in the Internet
+of today, network paths and the associated delays can differ
+significantly due to the individual service providers.</p>
+
+<p>The community served by the synchronization protocol can be very
+large. For instance, the NTP community in the Internet of 1998
+includes over 230 primary time servers, synchronized by radio,
+satellite and modem, and well over 100,000 secondary servers and
+clients. In addition, there are many thousands of private
+communities in large government, corporate and institution
+networks. Each community is organized as a tree graph or <i>
+subnet</i>, with the primary servers at the root and secondary
+servers and clients at increasing hop count, or stratum level, in
+corporate, department and desktop networks. It is usually necessary
+at each stratum level to employ redundant servers and diverse
+network paths in order to protect against broken software, hardware
+and network links.</p>
+
+<p>Synchronization protocols work in one or more association modes,
+depending on the protocol design. Client/server mode, also called
+master/slave mode, is supported in both DTSS and NTP. In this mode,
+a client synchronizes to a stateless server as in the conventional
+RPC model. NTP also supports symmetric mode, which allows either of
+two peer servers to synchronize to the other, in order to provide
+mutual backup. DTSS and NTP support a broadcast mode which allows
+many clients to synchronize to one or a few servers, reducing
+network traffic when large numbers of clients are involved. In NTP,
+IP multicast can be used when the subnet spans multiple
+networks.</p>
+
+<p>Configuration management can be a serious problem in large
+subnets. Various schemes which index public databases and network
+directory services are used in DTSS and NTP to discover servers.
+Both protocols use broadcast modes to support large client
+populations; but, since listen-only clients cannot calibrate the
+delay, accuracy can suffer. In NTP, clients determine the delay at
+the time a server is first discovered by polling the server in
+client/server mode and then reverting to listen-only mode. In
+addition, NTP clients can broadcast a special "manycast" message to
+solicit responses from nearby servers and continue in client/server
+mode with the respondents.</p>
<h4>Security Issues</h4>
-<p>A reliable network time service requires provisions to prevent accidental or malicious attacks on the servers and clients in the network. Reliability requires that clients can determine that received messages are authentic; that is, were actually sent by the intended server and not manufactured or modified by an intruder. Ubiquity requires that any client can verify the authenticity of any server using only public information. This is especially important in such ubiquitous network services as directory services, cryptographic key management and time synchronization.
-
-<p>NTP includes provisions to cryptographically authenticate individual servers using symmetric-key cryptography in which clients authenticate servers using shared secret keys. However, the secret keys must be distributed in advance using secure means beyond the scope of the protocol. This can be awkward and fragile with a large population of potential clients, possibly intruding hackers.
-
-<p>Modern public-key cryptography provides means to reliably bind the server identification credentials and related public values using public directory services. However, these means carry a high computing cost, especially when large numbers of time-critical clients are involved as often the case with NTP servers. In addition, there are problems unique to NTP in the interaction between the authentication and synchronization functions, since each requires the other for success.
-
-<p>The recent NTP Version 4 includes a revised security model and authentication scheme supporting both symmetric and public-key cryptography. The public-key variant is specially crafted to reduce the risk of intrusion, minimize the consumption of processor resources and minimize the vulnerability to hacker attack.
+<p>A reliable network time service requires provisions to prevent
+accidental or malicious attacks on the servers and clients in the
+network. Reliability requires that clients can determine that
+received messages are authentic; that is, were actually sent by the
+intended server and not manufactured or modified by an intruder.
+Ubiquity requires that any client can verify the authenticity of
+any server using only public information. This is especially
+important in such ubiquitous network services as directory
+services, cryptographic key management and time
+synchronization.</p>
+
+<p>NTP includes provisions to cryptographically authenticate
+individual servers using symmetric-key cryptography in which
+clients authenticate servers using shared secret keys. However, the
+secret keys must be distributed in advance using secure means
+beyond the scope of the protocol. This can be awkward and fragile
+with a large population of potential clients, possibly intruding
+hackers.</p>
+
+<p>Modern public-key cryptography provides means to reliably bind
+the server identification credentials and related public values
+using public directory services. However, these means carry a high
+computing cost, especially when large numbers of time-critical
+clients are involved as often the case with NTP servers. In
+addition, there are problems unique to NTP in the interaction
+between the authentication and synchronization functions, since
+each requires the other for success.</p>
+
+<p>The recent NTP Version 4 includes a revised security model and
+authentication scheme supporting both symmetric and public-key
+cryptography. The public-key variant is specially crafted to reduce
+the risk of intrusion, minimize the consumption of processor
+resources and minimize the vulnerability to hacker attack.</p>
<h4>Computer Clock Modelling and Error Analysis</h4>
-Most computers include a quartz resonator-stabilized oscillator and hardware counter that interrupts the processor at intervals of a few milliseconds. At each interrupt, a quantity called <i>tick</i> is added to a system variable representing the clock time. The clock can be read by system and application programs and set on occasion to an external reference. Once set, the clock readings increment at a nominal rate, depending on the value of <i>tick</i>. Typical Unix system kernels provide a programmable mechanism to increase or decrease the value of <i>tick</i> by a small, fixed amount in order to amortize a given time adjustment smoothly over multiple <i>tick</i> intervals.
-
-<p>Clock errors are due to variations in network delay and latencies in computer hardware and software (jitter), as well as clock oscillator instability (wander). The time of a client relative to its server can be expressed
-
-<p><center><i>T</i>(<i>t</i>) = <i>T</i>(<i>t</i><sub>0</sub>) + <i>R</i>(<i>t - t</i><sub>0</sub>) + 1/2 <i>D</i>(<i>t - T</i><sub>0</sub>)<sup>2</sup>,</center>
-
-<p>where <i>t</i> is the current time, <i>T</i> is the time offset at the last measurement update <i>t</i><sub>0</sub>, <i>R</i> is the frequency offset and <i>D</i> is the drift due to resonator ageing. All three terms include systematic offsets that can be corrected and random variations that cannot. Some protocols, including DTSS, estimate only the first term in this expression, while others, including NTP, estimate the first two terms. Errors due to the third term, while important to model resonator aging in precision applications, are neglected, since they are usually dominated by errors in the first two terms.
-
-<p>The synchronization protocol estimates <i>T</i>(<i>t</i><sub>0</sub>) (and <i>R</i>(<i>t</i><sub>0</sub>), where relevant) at regular intervals <font face="symbol">t</font> and adjusts the clock to minimize <i>T</i>(<i>t</i>) in future. In common cases, <i>R</i> can have systematic offsets of several hundred parts-per-million (PPM) with random variations of several PPM due to ambient temperature changes. If not corrected, the resulting errors can accumulate to seconds per day. In order that these errors do not exceed a nominal specification, the protocol must periodically re-estimate <i>T</i> and <i>R</i> and compensate for variations by adjusting the clock at regular intervals. As a practical matter, for nominal accuracies of tens of milliseconds, this requires clients to exchange messages with servers at intervals in the order of tens of minutes.
-
-<p>Analysis of quartz-resonator stabilized oscillators show that errors are a function of the averaging time, which in turn depends on the interval between corrections. At correction intervals less than a few hundred seconds, errors are dominated by jitter, while, at intervals greater than this, errors are dominated by wander. As explained later, the characteristics of each regime determine the algorithm used to discipline the clock. These errors accumulate at each stratum level from the root to the leaves of the subnet tree. It is possible to quantify these errors by statistical means, as in NTP. This allows real-time applications to adjust audio or video playout delay, for example. However, the required statistics may be different for various classes of applications. Some applications need absolute error bounds guaranteed never to exceeded, as provided by the following correctness principles.
+Most computers include a quartz resonator-stabilized oscillator and
+hardware counter that interrupts the processor at intervals of a
+few milliseconds. At each interrupt, a quantity called <i>tick</i>
+is added to a system variable representing the clock time. The
+clock can be read by system and application programs and set on
+occasion to an external reference. Once set, the clock readings
+increment at a nominal rate, depending on the value of <i>tick</i>.
+Typical Unix system kernels provide a programmable mechanism to
+increase or decrease the value of <i>tick</i> by a small, fixed
+amount in order to amortize a given time adjustment smoothly over
+multiple <i>tick</i> intervals.
+
+<p>Clock errors are due to variations in network delay and
+latencies in computer hardware and software (jitter), as well as
+clock oscillator instability (wander). The time of a client
+relative to its server can be expressed</p>
+
+<center><i>T</i>(<i>t</i>) = <i>T</i>(<i>t</i><sub>0</sub>) + <i>
+R</i>(<i>t - t</i><sub>0</sub>) + 1/2 <i>D</i>(<i>t -
+t</i><sub>0</sub>)<sup>2</sup>,</center>
+
+<p>where <i>t</i> is the current time, <i>T</i> is the time offset
+at the last measurement update <i>t</i><sub>0</sub>, <i>R</i> is
+the frequency offset and <i>D</i> is the drift due to resonator
+ageing. All three terms include systematic offsets that can be
+corrected and random variations that cannot. Some protocols,
+including DTSS, estimate only the first term in this expression,
+while others, including NTP, estimate the first two terms. Errors
+due to the third term, while important to model resonator aging in
+precision applications, are neglected, since they are usually
+dominated by errors in the first two terms.</p>
+
+<p>The synchronization protocol estimates <i>
+T</i>(<i>t</i><sub>0</sub>) (and <i>R</i>(<i>t</i><sub>0</sub>),
+where relevant) at regular intervals <font face="symbol">t</font>
+and adjusts the clock to minimize <i>T</i>(<i>t</i>) in future. In
+common cases, <i>R</i> can have systematic offsets of several
+hundred parts-per-million (PPM) with random variations of several
+PPM due to ambient temperature changes. If not corrected, the
+resulting errors can accumulate to seconds per day. In order that
+these errors do not exceed a nominal specification, the protocol
+must periodically re-estimate <i>T</i> and <i>R</i> and compensate
+for variations by adjusting the clock at regular intervals. As a
+practical matter, for nominal accuracies of tens of milliseconds,
+this requires clients to exchange messages with servers at
+intervals in the order of tens of minutes.</p>
+
+<p>Analysis of quartz-resonator stabilized oscillators show that
+errors are a function of the averaging time, which in turn depends
+on the interval between corrections. At correction intervals less
+than a few hundred seconds, errors are dominated by jitter, while,
+at intervals greater than this, errors are dominated by wander. As
+explained later, the characteristics of each regime determine the
+algorithm used to discipline the clock. These errors accumulate at
+each stratum level from the root to the leaves of the subnet tree.
+It is possible to quantify these errors by statistical means, as in
+NTP. This allows real-time applications to adjust audio or video
+playout delay, for example. However, the required statistics may be
+different for various classes of applications. Some applications
+need absolute error bounds guaranteed never to exceeded, as
+provided by the following correctness principles.</p>
<h4>Correctness Principles</h4>
-<p>Applications requiring reliable time synchronization such as air traffic control must have confidence that the local clock is correct within some bound relative to a given timescale such as UTC. There is a considerable body of literature that studies these issues with respect to various failure models such as fail-stop and Byzantine disagreement. While these models inspire much confidence in a theoretical setting, most require multiple message rounds for each measurement and would be impractical in a large computer network such as the Internet. However, it can be shown that the worst-case error in reading a remote server clock cannot exceed one-half the roundtrip delay measured by the client. This is a valuable insight, since it permits strong statements about the correctness of the timekeeping system.
-<p>In the Probabilistic Clock Synchronization (PCS) scheme devised by Cristian, a maximum error tolerance is established in advance and time value samples associated with roundtrip delays that exceed twice this value are discarded. By the above argument, the remaining samples must represent time values within the specified tolerance. As the tolerance is decreased, more samples fail the test until a point where no samples survive. The tolerance can be adjusted for the best compromise between the highest accuracy consistent with acceptable sample survival rate.
-
-<p>In a scheme devised by Marzullo and exploited in NTP and DTSS, the worst-case error determined for each server determines a correctness interval. If each of a number of servers are in fact synchronized to a common timescale, the actual time must be contained in the intersection of their correctness intervals. If some intervals do not intersect, then the clique containing the maximum number of intersections is assumed correct <i>truechimers</i> and the others assumed incorrect <i>false<i>tick</i>ers</i>. Only the truechimers are used to adjust the system
-clock.
+<p>Applications requiring reliable time synchronization such as air
+traffic control must have confidence that the local clock is
+correct within some bound relative to a given timescale such as
+UTC. There is a considerable body of literature that studies these
+issues with respect to various failure models such as fail-stop and
+Byzantine disagreement. While these models inspire much confidence
+in a theoretical setting, most require multiple message rounds for
+each measurement and would be impractical in a large computer
+network such as the Internet. However, it can be shown that the
+worst-case error in reading a remote server clock cannot exceed
+one-half the roundtrip delay measured by the client. This is a
+valuable insight, since it permits strong statements about the
+correctness of the timekeeping system.</p>
+
+<p>In the Probabilistic Clock Synchronization (PCS) scheme devised
+by Cristian, a maximum error tolerance is established in advance
+and time value samples associated with roundtrip delays that exceed
+twice this value are discarded. By the above argument, the
+remaining samples must represent time values within the specified
+tolerance. As the tolerance is decreased, more samples fail the
+test until a point where no samples survive. The tolerance can be
+adjusted for the best compromise between the highest accuracy
+consistent with acceptable sample survival rate.</p>
+
+<p>In a scheme devised by Marzullo and exploited in NTP and DTSS,
+the worst-case error determined for each server determines a
+correctness interval. If each of a number of servers are in fact
+synchronized to a common timescale, the actual time must be
+contained in the intersection of their correctness intervals. If
+some intervals do not intersect, then the clique containing the
+maximum number of intersections is assumed correct <i>
+truechimers</i> and the others assumed incorrect <i>
+falsetickers</i>. Only the truechimers are used to adjust the
+system clock.</p>
<h4>Data Grooming Algorithms</h4>
-By its very nature, clock synchronization is a continuous process, resulting in a sequence of measurements with each of possibly several servers and resulting in a clock adjustment. In some protocols, crafted algorithms are used to improve the time and frequency estimates and refine the clock adjustment. Algorithms described in the literature are based on trimmed-mean and median filter methods. The clock filter algorithm used in NTP is based on the above observation that the correctness interval depends on the roundtrip delay. The algorithm accumulates offset/delay samples in a window of several samples and selects the offset sample associated with the minimum delay. In general, larger window sizes provide better estimates; however, stability considerations limit the window size to about eight.
-
-<p>The same principle could be used when selecting the best subset of servers and combining their offsets to determine the clock adjustment. However, different servers often show different systematic offsets, so the best statistic for the central tendency of the server population may not be obvious. Various kinds of clustering algorithms have been found useful for this purpose. The one used in NTP sorts the offsets by a quality metric, then calculates the variance of all servers relative to each server separately. The algorithm repeatedly discards the outlyer with the largest variance until further discards will not improve the residual variance or until a minimum number of servers remain. The final clock adjustment is computed as a weighted average of the survivors.
-
-<p>At the heart of the synchronization protocol is the algorithm used to adjust the system clock in accordance with the final adjustment determined by the above algorithms. This is called the clock discipline algorithm or simply the discipline. Such algorithms can be classed according to whether they minimize the time offset or frequency offset or both. For instance, the discipline used in DTSS minimizes only the time offset, while the one used in NTP minimizes both time and frequency offsets. While the DTSS algorithm cannot remove residual errors due to systematic frequency errors, the NTP algorithm is more complicated and less forgiving of design and implementation mistakes.
-
-<p>All clock disciplines function as a feedback loop, with measured offsets used to adjust the clock oscillator phase and frequency to match the external synchronization source. The behavior of feedback loops is well understood and modelled by mathematical analysis. The significant design parameter is the time constant, or responsiveness to external or internal variations in time or frequency. Optimum selection of time constant depends on the interval between update messages. In general, the longer these intervals, the larger the time constant and vice versa. In practice and with typical network configurations the optimal poll intervals vary between one and twenty minutes for network paths to some thousands of minutes for modem paths.
+By its very nature, clock synchronization is a continuous process,
+resulting in a sequence of measurements with each of possibly
+several servers and resulting in a clock adjustment. In some
+protocols, crafted algorithms are used to improve the time and
+frequency estimates and refine the clock adjustment. Algorithms
+described in the literature are based on trimmed-mean and median
+filter methods. The clock filter algorithm used in NTP is based on
+the above observation that the correctness interval depends on the
+roundtrip delay. The algorithm accumulates offset/delay samples in
+a window of several samples and selects the offset sample
+associated with the minimum delay. In general, larger window sizes
+provide better estimates; however, stability considerations limit
+the window size to about eight.
+
+<p>The same principle could be used when selecting the best subset
+of servers and combining their offsets to determine the clock
+adjustment. However, different servers often show different
+systematic offsets, so the best statistic for the central tendency
+of the server population may not be obvious. Various kinds of
+clustering algorithms have been found useful for this purpose. The
+one used in NTP sorts the offsets by a quality metric, then
+calculates the variance of all servers relative to each server
+separately. The algorithm repeatedly discards the outlyer with the
+largest variance until further discards will not improve the
+residual variance or until a minimum number of servers remain. The
+final clock adjustment is computed as a weighted average of the
+survivors.</p>
+
+<p>At the heart of the synchronization protocol is the algorithm
+used to adjust the system clock in accordance with the final
+adjustment determined by the above algorithms. This is called the
+clock discipline algorithm or simply the discipline. Such
+algorithms can be classed according to whether they minimize the
+time offset or frequency offset or both. For instance, the
+discipline used in DTSS minimizes only the time offset, while the
+one used in NTP minimizes both time and frequency offsets. While
+the DTSS algorithm cannot remove residual errors due to systematic
+frequency errors, the NTP algorithm is more complicated and less
+forgiving of design and implementation mistakes.</p>
+
+<p>All clock disciplines function as a feedback loop, with measured
+offsets used to adjust the clock oscillator phase and frequency to
+match the external synchronization source. The behavior of feedback
+loops is well understood and modelled by mathematical analysis. The
+significant design parameter is the time constant, or
+responsiveness to external or internal variations in time or
+frequency. Optimum selection of time constant depends on the
+interval between update messages. In general, the longer these
+intervals, the larger the time constant and vice versa. In practice
+and with typical network configurations the optimal poll intervals
+vary between one and twenty minutes for network paths to some
+thousands of minutes for modem paths.</p>
<h4>Further Reading</h4>
<ol>
+<li>
+<p>Cristian, F. Probabilistic clock synchronization. In Distributed
+Computing 3, Springer Verlag, 1989, 146-158.</p>
+</li>
+
+<li>
+<p>Digital Time Service Functional Specification Version T.1.0.5.
+DigitalEquipment Corporation, 1989.</p>
+</li>
+
+<li>
+<p>Gusella, R., and S. Zatti. TEMPO - A network time controller for
+a distributed Berkeley UNIX system. IEEE Distributed Processing
+Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also
+in: Proc. Summer 1984 USENIX (Salt Lake City, June 1984).</p>
+</li>
+
+<li>
+<p>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
+distributed real-time systems. IEEE Trans. Computers C-36, 8
+(August 1987), 933-939.</p>
+</li>
+
+<li>
+<p>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
+presence of faults. JACM 32, 1 (January 1985), 52-78.</p>
+</li>
+
+<li>
+<p>Marzullo, K., and S. Owicki. Maintaining the time in a
+distributed system. ACM Operating Systems Review 19, 3 (July 1985),
+44-54.</p>
+</li>
+
+<li>
+<p>Mills, D.L. Adaptive hybrid clock discipline algorithm for the
+Network Time Protocol. <i>IEEE/ACM Trans. Networking 6, 5</i>
+(October 1998), 505-514.</p>
+</li>
+
+<li>
+<p>Mills, D.L. Improved algorithms for synchronizing computer
+network clocks. <i>IEEE/ACM Trans. Networks 3, 3</i> (June 1995),
+245-254.</p>
+</li>
+
+<li>
+<p>Mills, D.L. Internet time synchronization: the Network Time
+Protocol. IEEE Trans. Communications COM-39, 10 (October 1991),
+1482-1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global
+States and Time in Distributed Systems, IEEE Press, Los Alamitos,
+CA, 91-102.</p>
+</li>
+
+<li>
+<p>Mills, D.L. Modelling and analysis of computer network clocks.
+Electrical Engineering Department Report 92-5-2, University of
+Delaware, May 1992, 29 pp.</p>
+</li>
+
+<li>
+<p>NIST Time and Frequency Dissemination Services. NBS Special
+Publication432 (Revised 1990), National Institute of Science and
+Technology, U.S. Department of Commerce, 1990.</p>
+</li>
+
+<li>
+<p>Schneider, F.B. A paradigm for reliable clock synchronization.
+Department of Computer Science Technical Report TR 86-735, Cornell
+University, February 1986.</p>
+</li>
+
+<li>
+<p>Srikanth, T.K., and S. Toueg. Optimal clock synchronization.
+JACM 34, 3 (July 1987), 626-645.</p>
+</li>
+
+<li>
+<p>Stein, S.R. Frequency and time - their measurement and
+characterization (Chapter 12). In: E.A. Gerber and A. Ballato
+(Eds.). Precision Frequency Control, Vol. 2, Academic Press, New
+York 1985, 191-232, 399-416. Also in: Sullivan, D.B., D.W. Allan,
+D.A. Howe and F.L. Walls (Eds.). Characterization of Clocks and
+Oscillators. National Institute of Standards and Technology
+Technical Note 1337, U.S. Government Printing Office (January,
+1990), TN61-TN119.</p>
+</li>
+</ol>
-<p><li>Cristian, F. Probabilistic clock synchronization. In Distributed Computing 3, Springer Verlag, 1989, 146-158.</li>
-
-<p><li>Digital Time Service Functional Specification Version T.1.0.5. DigitalEquipment Corporation, 1989.</li>
-
-<p><li>Gusella, R., and S. Zatti. TEMPO - A network time controller for a distributed Berkeley UNIX system. IEEE Distributed Processing Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in: Proc. Summer 1984 USENIX (Salt Lake City, June 1984).</li>
-
-<p><li>Kopetz, H., and W. Ochsenreiter. Clock synchronization in distributed real-time systems. IEEE Trans. Computers C-36, 8 (August 1987), 933-939.</li>
-
-<p><li>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the presence of faults. JACM 32, 1 (January 1985), 52-78.</li>
-
-<p><li>Marzullo, K., and S. Owicki. Maintaining the time in a distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-54.</li>
-
-<p><li>Mills, D.L. Adaptive hybrid clock discipline algorithm for the Network Time Protocol. <i>IEEE/ACM Trans. Networking 6, 5</i> (October 1998), 505-514.</li>
-
-<p><li>Mills, D.L. Improved algorithms for synchronizing computer network clocks. <i>IEEE/ACM Trans. Networks 3, 3</i> (June 1995), 245-254.</li>
-
-<p><li>Mills, D.L. Internet time synchronization: the Network Time Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and Time in Distributed Systems, IEEE Press, Los Alamitos, CA, 91-102.</li>
-
-<p><li>Mills, D.L. Modelling and analysis of computer network clocks. Electrical Engineering Department Report 92-5-2, University of Delaware, May 1992, 29 pp.</li>
-
-<p><li>NIST Time and Frequency Dissemination Services. NBS Special Publication432 (Revised 1990), National Institute of Science and Technology, U.S. Department of Commerce, 1990.</li>
-
-<p><li>Schneider, F.B. A paradigm for reliable clock synchronization. Department of Computer Science Technical Report TR 86-735, Cornell University, February 1986.</li>
-
-<p><li>Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM 34, 3 (July 1987), 626-645.</li>
-
-<p><li>Stein, S.R. Frequency and time - their measurement and characterization (Chapter 12). In: E.A. Gerber and A. Ballato (Eds.). Precision Frequency Control, Vol. 2, Academic Press, New York 1985, 191-232, 399-416. Also in: Sullivan, D.B., D.W. Allan, D.A. Howe and F.L. Walls (Eds.). Characterization of Clocks and Oscillators. National Institute of Standards and Technology Technical Note 1337, U.S. Government Printing Office (January, 1990), TN61-TN119.</li>
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"home"></a>
-</ol>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
-<html><head><title>
-<tt>ntp_genkeys</tt> - generate public and private keys
-</title></head><body><h3>
-<tt>ntp_genkeys</tt> - generate public and private keys
-</h3>
-
-<img align=left src=pic/alice23.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>Alice holds the key.
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntp-genkeys - generate public and private keys</title>
+</head>
+<body>
+<h3><tt>ntp-genkeys</tt> - generate public and private keys</h3>
+
+<img align="left" src="pic/alice23.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>Alice holds the key.<br clear="left">
+</p>
+
+<hr>
<h4>Synopsis</h4>
-<tt>ntp_genkeys</tt>
+<tt>ntp-genkeys</tt>
-<H4>Description</H4>
+<h4>Description</h4>
-<p>The cryptographic values used by the autokey scheme are incorporated
-as a set of four files generated by the <tt>ntp_genkeys</tt> program,
-including <tt>ntp.keys</tt> containing the DES/MD5 private keys,
-<tt>ntpkey</tt> containing the RSA private key,
+<p>This program generates random keys used by either or both the
+NTPv3/NTPv4 symmetric key or the NTPv4 public key (Autokey)
+cryptographic authentication schemes. By default the program
+generates the <tt>ntp.keys</tt> file containing 16 random symmetric
+keys. In addition, if the <tt>rsaref20</tt> package is configured
+for the software build, the program generates cryptographic values
+used by the Autokey scheme. These values are incorporated as a set
+of three files, <tt>ntpkey</tt> containing the RSA private key,
<tt>ntpkey_<i>host</i></tt> containing the RSA public key, where
<tt><i>host</i></tt> is the DNS name of the generating machine, and
-<tt>ntpkey_dh</tt> containing the parameters for the Diffie-Hellman key-
-agreement algorithm. The files contain cryptographic values generated by
-the algorithms of the <tt>rsaref20</tt> package and are in printable
-ASCII format. A timestamp in NTP seconds is appended to each file name
-shown here. Since the algorithms are seeded by the system clock, each
-run of this program produces a different file and file name. There are
-no options or frills of any sort, although a number of options would
-seem to be appropriate.
-
-<p>The <tt>ntp.keys</tt> file contains 16 MD5 keys. Each key consists of
-16 characters randomized over the ASCII 95-character printing subset.
-The file is read by the daemon at the location specified by the
-<tt>keys</tt> configuration file command and made visible only to root.
-An additional key consisting of a easily remembered password should be
-added by hand for use with the <tt>ntpq</tt> and <tt>ntpdc</tt>
-programs. The file must be distributed by secure means to other servers
-and clients sharing the same security compartment. While the key
-identifiers for MD5 and DES keys must be in the range 1-65534,
-inclusive, the <tt>ntp_genkeys</tt> program uses only the identifiers
-from 1 to 16. The key identifier for each association is specified as
-the key argument in the <tt>server</tt> or peer configuration file
-command.
-
-<p>The <tt>ntpkey</tt> file contains the RSA private key. It is read by
-the daemon at the location specified by the <tt>privatekey</tt> argument
-of the <tt>crypto</tt> configuration file command and made visible only
-to root. This file is useful only to the machine that generated it and
-never shared with any other daemon or application program.
-
-<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public key,
-where <tt><i>host</i></tt> is the DNS name of the host that generated
-it. The file is read by the daemon at the location specified by the
-<tt>publickey</tt> argument to the <tt>server</tt> or <tt>peer</tt>
-configuration file command. This file can be widely distributed and
-stored without using secure means, since the data are public values.
-
-<p>The <tt>ntp_dh</tt> file contains two Diffie-Hellman parameters: the
-prime modulus and the generator. The file is read by the daemon at the
-location specified by the <tt>dhparams</tt> argument of the
-<tt>crypto</tt> configuration file command. The file can be distributed
-by insecure means to other servers and clients sharing the same key
-agreement compartment, since the data are public values.
+<tt>ntpkey_dh</tt> containing the parameters for the Diffie-Hellman
+key-agreement algorithm. All files and are in printable ASCII
+format. A timestamp in NTP seconds is appended to each. Since the
+algorithms are seeded by the system clock, each run of this program
+produces a different file and file name.</p>
+
+<p>The <tt>ntp.keys</tt> file contains 16 MD5 keys. Each key
+consists of 16 characters randomized over the ASCII 95-character
+printing subset. The file is read by the daemon at the location
+specified by the <tt>keys</tt> configuration file command and made
+visible only to root. An additional key consisting of a easily
+remembered password should be added by hand for use with the <tt>
+ntpq</tt> and <tt>ntpdc</tt> programs. The file must be distributed
+by secure means to other servers and clients sharing the same
+security compartment. While the key identifiers for MD5 and DES
+keys must be in the range 1-65534, inclusive, the <tt>
+ntp-genkeys</tt> program uses only the identifiers from 1 to 16.
+The key identifier for each association is specified as the key
+argument in the <tt>server</tt> or peer configuration file
+command.</p>
+
+<p>The <tt>ntpkey</tt> file contains the RSA private key. It is
+read by the daemon at the location specified by the <tt>
+privatekey</tt> argument of the <tt>crypto</tt> configuration file
+command and made visible only to root. This file is useful only to
+the machine that generated it and never shared with any other
+daemon or application program.</p>
+
+<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public
+key, where <tt><i>host</i></tt> is the DNS name of the host that
+generated it. The file is read by the daemon at the location
+specified by the <tt>publickey</tt> argument to the <tt>server</tt>
+or <tt>peer</tt> configuration file command. This file can be
+widely distributed and stored without using secure means, since the
+data are public values.</p>
+
+<p>The <tt>ntp_dh</tt> file contains two Diffie-Hellman parameters:
+the prime modulus and the generator. The file is read by the daemon
+at the location specified by the <tt>dhparams</tt> argument of the
+<tt>crypto</tt> configuration file command. The file can be
+distributed by insecure means to other servers and clients sharing
+the same key agreement compartment, since the data are public
+values.</p>
<p>The file formats begin with two lines, the first containing the
-generating system DNS name and the second the datestamp. Lines beginning
-with <tt>#</tt> are considered comments and ignored by the daemon. In
-the <tt>ntp.keys</tt> file, the next 16 lines contain the MD5 keys in
-order. If necessary, this file can be further customized by an ordinary
-text editor. The format is described in the following section. In the
-<tt>ntpkey</tt> and <tt>ntpkey_<i>host</i></tt> files, the next line
-contains the modulus length in bits followed by the key as a PEM encoded
-string. In the <tt>ntpkey_dh</tt> file, the next line contains the prime
-length in bytes followed by the prime as a PEM encoded string, and the
-next and final line contains the generator length in bytes followed by
-the generator as a PEM encoded string.
-
-<p>Note: See the file <tt>./source/rsaref.h</tt> in the
-<tt>rsaref20</tt> package for explanation of return values, if
-necessary.
-
-<H4>Private Key File Format</H4>
-
-In the case of DES, the keys are 56 bits long with, depending on type,
-a parity check on each byte. In the case of MD5, the keys are 64 bits (8
-bytes). <TT>ntpd</TT> reads its keys from a file specified using the
-<TT>-k</TT> command line option or the <TT>keys</TT> statement in the
-configuration file. While key number 0 is fixed by the NTP standard (as
-56 zero bits) and may not be changed, one or more of the keys numbered 1
-through 15 may be arbitrarily set in the keys file.
-
-<P>The key file uses the same comment conventions as the configuration
-file. Key entries use a fixed format of the form
-
-<P><I><TT>keyno type key</TT></I>
-
-<P>where <I><TT>keyno</TT></I> is a positive integer,
-<I><TT>type</TT></I> is a single character which defines the key format,
-and <I><TT>key</TT></I> is the key itself.
-
-<P>The key may be given in one of three different formats, controlled by
-the <I><TT>type</TT></I> character. The three key types, and
-corresponding formats, are listed following.
-<DL>
-
-<DT><TT>S</TT></DT>
-<DD>The key is a 64-bit hexadecimal number in the format specified in
-the DES specification; that is, the high order seven bits of each octet
-are used to form the 56-bit key while the low order bit of each octet is
-given a value such that odd parity is maintained for the octet. Leading
-zeroes must be specified (i.e., the key must be exactly 16 hex digits
-long) and odd parity must be maintained. Hence a zero key, in standard
-format, would be given as <TT>0101010101010101</TT>.</DD>
-
-<DT><TT>N</TT></DT>
-<DD>The key is a 64-bit hexadecimal number in the format specified in
-the NTP standard. This is the same as the DES format, except the bits in
-each octet have been rotated one bit right so that the parity bit is now
-the high order bit of the octet. Leading zeroes must be specified and
-odd parity must be maintained. A zero key in NTP format would be
-specified as <TT>8080808080808080</TT>.</DD>
-
-<DT><TT>A</TT></DT>
-<DD>The key is a 1-to-8 character ASCII string. A key is formed from
-this by using the low order 7 bits of each ASCII character in the
-string, with zeroes added on the right when necessary to form a full
-width 56-bit key, in the same way that encryption keys are formed from
-Unix passwords.</DD>
-
-<DT><TT>M</TT></DT>
-<DD>The key is a 1-to-8 character ASCII string, using the MD5
-authentication scheme. Note that both the keys and the authentication
-schemes (DES or MD5) must be identical between a set of peers sharing
-the same key number.</DD>
-</DL>
-
-<p>Note that the keys used by the <TT>ntpq</TT> and <TT>ntpdc</TT>
-programs are checked against passwords requested by the programs and
-entered by hand, so it is generally appropriate to specify these keys in
-ASCII format.
+generating system DNS name and the second the datestamp. Lines
+beginning with <tt>#</tt> are considered comments and ignored by
+the daemon. In the <tt>ntp.keys</tt> file, the next 16 lines
+contain the MD5 keys in order. If necessary, this file can be
+further customized by an ordinary text editor. The format is
+described in the following section. In the <tt>ntpkey</tt> and <tt>
+ntpkey_<i>host</i></tt> files, the next line contains the modulus
+length in bits followed by the key as a PEM encoded string. In the
+<tt>ntpkey_dh</tt> file, the next line contains the prime length in
+bytes followed by the prime as a PEM encoded string, and the next
+and final line contains the generator length in bytes followed by
+the generator as a PEM encoded string.</p>
+
+<p>Note: See the file <tt>./source/rsaref.h</tt> in the <tt>
+rsaref20</tt> package for explanation of return values, if
+necessary.</p>
+
+<h4>Symmetric Key File Format</h4>
+
+In the case of DES, the keys are 56 bits long with, depending on
+type, a parity check on each byte. In the case of MD5, the keys are
+64 bits (8 bytes). <tt>ntpd</tt> reads its keys from a file
+specified using the <tt>-k</tt> command line option or the <tt>
+keys</tt> statement in the configuration file. While key number 0
+is fixed by the NTP standard (as 56 zero bits) and may not be
+changed, one or more of the keys numbered 1 through 15 may be
+arbitrarily set in the keys file.
+
+<p>The key file uses the same comment conventions as the
+configuration file. Key entries use a fixed format of the form</p>
+
+<p><i><tt>keyno type key</tt></i></p>
+
+<p>where <i><tt>keyno</tt></i> is a positive integer, <i><tt>
+type</tt></i> is a single character which defines the key format,
+and <i><tt>key</tt></i> is the key itself.</p>
+
+<p>The key may be given in one of three different formats,
+controlled by the <i><tt>type</tt></i> character. The three key
+types, and corresponding formats, are listed following.</p>
+
+<dl>
+<dt><tt>S</tt></dt>
+
+<dd>The key is a 64-bit hexadecimal number in the format specified
+in the DES specification; that is, the high order seven bits of
+each octet are used to form the 56-bit key while the low order bit
+of each octet is given a value such that odd parity is maintained
+for the octet. Leading zeroes must be specified (i.e., the key must
+be exactly 16 hex digits long) and odd parity must be maintained.
+Hence a zero key, in standard format, would be given as <tt>
+0101010101010101</tt>.</dd>
+
+<dt><tt>N</tt></dt>
+
+<dd>The key is a 64-bit hexadecimal number in the format specified
+in the NTP standard. This is the same as the DES format, except the
+bits in each octet have been rotated one bit right so that the
+parity bit is now the high order bit of the octet. Leading zeroes
+must be specified and odd parity must be maintained. A zero key in
+NTP format would be specified as <tt>8080808080808080</tt>.</dd>
+
+<dt><tt>A</tt></dt>
+
+<dd>The key is a 1-to-8 character ASCII string. A key is formed
+from this by using the low order 7 bits of each ASCII character in
+the string, with zeroes added on the right when necessary to form a
+full width 56-bit key, in the same way that encryption keys are
+formed from Unix passwords.</dd>
+
+<dt><tt>M</tt></dt>
+
+<dd>The key is a 1-to-8 character ASCII string, using the MD5
+authentication scheme. Note that both the keys and the
+authentication schemes (DES or MD5) must be identical between a set
+of peers sharing the same key number.</dd>
+</dl>
+
+<p>Note that the keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt>
+programs are checked against passwords requested by the programs
+and entered by hand, so it is generally appropriate to specify
+these keys in ASCII format.</p>
<h4>Files</h4>
-The RSA Laboratories package <tt>rsaref20</tt> of cryptographic routines
-is necessary in order to build and use this program.
+The RSA Laboratories package <tt>rsaref20</tt> of cryptographic
+routines is necessary in order to build and use this program.
<h4>Bugs</h4>
-It can take quite a while to generate the RSA public/private key pair
-and Diffie-Hellman parameters, from a few seconds on a modern
-workstation to several minutes on older machines.
+It can take quite a while to generate the RSA public/private key
+pair and Diffie-Hellman parameters, from a few seconds on a modern
+workstation to several minutes on older machines.
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
-<html><head><title>
-The Network Time Protocol (NTP) Distribution
-</title></head><body><h3>
-The Network Time Protocol (NTP) Distribution
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>The Network Time Protocol (NTP) Distribution</title>
+</head>
+<body>
+<h3>The Network Time Protocol (NTP) Distribution</h3>
-<img align=left src=pic/barnstable.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
+<img align="left" src="pic/barnstable.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm"><i>P.T. Bridgeport
+Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
-<p>Pleased to meet you.
-<br clear=left><hr>
+<p>Pleased to meet you.<br clear="left">
+</p>
+<hr>
<h4>Introduction</h4>
-Note: The software contained in this distribution is available without charge under the conditions set forth in the <a href=copyright.htm>Copyright Notice</a>.
+Note: The software contained in this distribution is available
+without charge under the conditions set forth in the <a href=
+"copyright.htm">Copyright Notice</a>.
-<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks and some provide automatic server discovery using IP multicast.
+<p>The Network Time Protocol (NTP) is used to synchronize the time
+of a computer client or server to another server or reference time
+source, such as a radio or satellite receiver or modem. It provides
+accuracies typically within a millisecond on LANs and up to a few
+tens of milliseconds on WANs relative to Coordinated Universal Time
+(UTC) via a Global Positioning Service (GPS) receiver, for example.
+Typical NTP configurations utilize multiple redundant servers and
+diverse network paths in order to achieve high accuracy and
+reliability. Some configurations include cryptographic
+authentication to prevent accidental or malicious protocol attacks
+and some provide automatic server discovery using IP multicast.</p>
-<p>Background information on computer network time synchronization can be found on the <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found in the <a href=biblio.htm>Protocol Conformance Statement</a> page. Discussion on year-2000 issues can be found in the <a href=y2k.htm>Year 2000 Conformance Statement page</a>. Background information, bibliography and briefing slides suitable for presentations can be found in the <a href=http://www.eecis.udel.edu/~mills/ntp.htm> 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>. Please send bug reports to <a href=mailto:bugs@mail.ntp.org><bugs@mail.ntp.org></a>.
+<p>Background information on computer network time synchronization
+can be found on the <a href="exec.htm">Executive Summary - Computer
+Network Time Synchronization</a> page. Discussion on protocol
+conformance issues and interoperability with previous NTP versions
+can be found in the <a href="biblio.htm">Protocol Conformance
+Statement</a> page. Discussion on year-2000 issues can be found in
+the <a href="y2k.htm">Year 2000 Conformance Statement page</a>.
+Background information, bibliography and briefing slides suitable
+for presentations can be found in the <a href=
+"http://www.eecis.udel.edu/~mills/ntp.htm">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>. Please send bug reports to <a href=
+"mailto:bugs@mail.ntp.org"><bugs@mail.ntp.org></a>.</p>
<h4>Building and Installing NTP</h4>
-The <a href=build.htm>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 in the <a href=config.htm>Configuration Options</a> and <a href=release.htm>Release Notes</a> pages.
+The <a href="build.htm">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 in the <a
+href="config.htm">Configuration Options</a> and <a href=
+"release.htm">Release Notes</a> pages. Note that support for strong
+cryptography requires cryptographic libraries not included in this
+distribution.
-<p>Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for over three dozen radio clocks and modem services. A list of the particular receivers and modem drivers supported in the distribution is given in the <a href=refclock.htm>Reference Clock Drivers</a> page. For most popular workstations marketed by Digital/Compaq, Sun 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>Bringing up a NTP primary server requires a radio or satellite
+receiver or modem. It is also possible to configure a machine on an
+isolated network with the local clock driver and have other
+machines synchronize to it. The distribution includes hardware
+drivers for the local clock and over three dozen radio clocks and
+modem services. A list of supported drivers is given in the <a
+href="refclock.htm">Reference Clock Drivers</a> page. For most
+popular workstations marketed by Digital/Compaq, Sun 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>
<h4>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=quick.htm>Quick Start</a> page may be useful to get a simple workstation on the air with an existing server.
+<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="quick.htm">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.htm>Notes on Configuring NTP and Setting up a NTP Subnet</a> page. However, in many common cases involving simple network topologies and workstations, the cpnfiguration data can be specified entirely on the command line for the <a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>.
+<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.htm">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.htm">
+<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.htm>Association Management</a> page. NTP support for one or more computers is normally engineered as part of the existing NTP synchronization subnet. The existing NTP 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>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.htm">Association Management</a> page. NTP support
+for one or more computers is normally engineered as part of the
+existing NTP synchronization subnet. The existing NTP 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>The NTP subnet in late 2000 includes pver a 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 over a hundred public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total in excess of 100,000 clients and servers in the Internet. The current lists are maintained in the <a href=http://www.eecis.udel.edu/~mills/ntp/index.htm>Information on Time and Frequency Services</a> page, which is updated frequently. There are numerous private primary and secondary servers not normally available to the public as well. You are strongly discouraged from using these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and your traffic can bring up expensive ISDN lines, causing much grief and frustration.
+<p>The NTP subnet in late 2000 includes over a 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 over a hundred public secondary (stratum
+2) servers synchronized to the primary servers and providing
+synchronization to a total in excess of 100,000 clients and servers
+in the Internet. The current lists are maintained in the <a href=
+"http://www.eecis.udel.edu/~mills/ntp/index.htm">Information on
+Time and Frequency Services</a> page, which is updated frequently.
+There are numerous private primary and secondary servers not
+normally available to the public as well. You are strongly
+discouraged from using these servers, since they sometimes hide in
+little ghettos behind dinky links to the outside world and your
+traffic can bring up expensive ISDN lines, causing much grief and
+frustration.</p>
<h4>Resolving Problems</h4>
-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 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.htm>NTP Debugging Techniques</a> and <a href=hints.htm>Hints and Kinks</a> pages contain useful information for identifying problems and devising solutions.
+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 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.htm">NTP Debugging Techniques</a>
+and <a href="hints.htm">Hints and Kinks</a> pages contain useful
+information for identifying problems and devising solutions.
-<p>Users are requested to report bugs, offer suggestions and contribute additions to this distribution. The <a href=patches.htm>Patching Procedures</a> page suggests procedures which greatly simplify distribution updates, while the <a href=porting.htm>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=refclock.htm>Reference Clock Drivers</a> page. Further information on NTP in the Internet can be found in the <a href=http://www.eecis.udel.edu/~ntp>NTP web page</a>.
+<p>Users are requested to report bugs, offer suggestions and
+contribute additions to this distribution. The <a href=
+"patches.htm">Patching Procedures</a> page suggests procedures
+which greatly simplify distribution updates, while the <a href=
+"porting.htm">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="refclock.htm">Reference Clock
+Drivers</a> page. Further information on NTP in the Internet can be
+found in the <a href="http://www.eecis.udel.edu/~ntp">NTP web
+page</a>.</p>
<h4>Program Manual Pages</h4>
<ul>
+<li><a href="ntpd.htm"><tt>ntpd</tt> - Network Time Protocol (NTP)
+daemon</a></li>
-<li><a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a></li>
-<li><a href=ntpq.htm><tt>ntpq</tt> - standard NTP query program</a></li>
-<li><a href=ntpdc.htm><tt>ntpdc</tt> - special NTP query program</a></li>
-<li><a href=ntpdate.htm><tt>ntpdate</tt> - set the date and time via NTP</a></li>
-<li><a href=ntptrace.htm><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a></li>
-<li><a href=tickadj.htm><tt>tickadj</tt> - set time-related kernel variables</a></li>
-<li><a href=ntptime.htm><tt>ntptime</tt> - read kernel time variables</a></li>
-<li><a href=genkeys.htm><tt>ntp_genkeys</tt> - generate public and private keys</a></li>
+<li><a href="ntpq.htm"><tt>ntpq</tt> - standard NTP query
+program</a></li>
+<li><a href="ntpdc.htm"><tt>ntpdc</tt> - special NTP query
+program</a></li>
+
+<li><a href="ntpdate.htm"><tt>ntpdate</tt> - set the date and time
+via NTP</a></li>
+
+<li><a href="ntptrace.htm"><tt>ntptrace</tt> - trace a chain of NTP
+servers back to the primary source</a></li>
+
+<li><a href="tickadj.htm"><tt>tickadj</tt> - set time-related
+kernel variables</a></li>
+
+<li><a href="ntptime.htm"><tt>ntptime</tt> - read kernel time
+variables</a></li>
+
+<li><a href="genkeys.htm"><tt>ntp-genkeys</tt> - generate public
+and private keys</a></li>
</ul>
<h4>Supporting Documentation</h4>
<ul>
+<li><a href="http://www.eecis.udel.edu/~mills/ntp.htm">NTP Project
+and Reference Library</a></li>
+
+<li><a href="copyright.htm">Copyright Notice</a></li>
+
+<li><a href="exec.htm">Executive Summary - Computer Network Time
+Synchronization</a></li>
+
+<li><a href="biblio.htm">Protocol Conformance Statement</a></li>
+
+<li><a href="y2k.htm">Year 2000 Conformance Statement</a></li>
+
+<li><a href="notes.htm">Notes on Configuring NTP and Setting up a
+NTP Subnet</a></li>
+
+<li><a href="release.htm">NTP Version 4 Release Notes</a></li>
-<li><a href=http://www.eecis.udel.edu/~mills/ntp.htm>NTP Reference Library</a></li>
-<li><a href=copyright.htm>Copyright Notice</a></li>
-<li><a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a></li>
-<li><a href=biblio.htm>Protocol Conformance Statement</a></li>
-<li><a href=y2k.htm>Year 2000 Conformance Statement</a></li>
-<li><a href=notes.htm>Notes on Configuring NTP and Setting up a NTP Subnet</a></li>
-<li><a href=release.htm>NTP Version 4 Release Notes</a></li>
-<li><a href=build.htm>Building and Installing the Distribution</a></li>
-<li><a href=config.htm>Configuration Options</a></li>
-<li><a href=debug.htm>NTP Debugging Techniques</a></li>
-<li><a href=refclock.htm>Reference Clock Drivers</a></li>
-<li><a href=patches.htm>Patching Procedures</a></li>
-<li><a href=hints.htm>Hints and Kinks</a></li>
-<li><a href=porting.htm>Porting Hints</a></li>
+<li><a href="build.htm">Building and Installing the
+Distribution</a></li>
+<li><a href="config.htm">Configuration Options</a></li>
+
+<li><a href="debug.htm">NTP Debugging Techniques</a></li>
+
+<li><a href="refclock.htm">Reference Clock Drivers</a></li>
+
+<li><a href="patches.htm">Patching Procedures</a></li>
+
+<li><a href="hints.htm">Hints and Kinks</a></li>
+
+<li><a href="porting.htm">Porting Hints</a></li>
</ul>
<h4>Application Notes</h4>
<ul>
+<li><a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt>
+Keyword</a></li>
-<li><a href=prefer.htm>Mitigation Rules and the <tt>prefer</tt> Keyword</a></li>
-<li><a href=assoc.htm>Association Management</a></li>
-<li><a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a></li>
-<li><a href=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</a></li>
-<li><a href=measure.htm>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</a></li>
-<li><a href=kern.htm>Kernel Model for Precision Timekeeping</a></li>
-<li><a href=kernpps.htm>Kernel Programming Interface for Precision Time Signals</a></li>
+<li><a href="assoc.htm">Association Management</a></li>
+<li><a href="pps.htm">Pulse-per-second (PPS) Signal
+Interfacing</a></li>
+
+<li><a href="gadget.htm">Gadget Box PPS Level Converter and CHU
+Modem</a></li>
+
+<li><a href="measure.htm">Time and Time Interval Measurement with
+Application to Computer and Network Performance Evaluation</a></li>
+
+<li><a href="kern.htm">Kernel Model for Precision
+Timekeeping</a></li>
+
+<li><a href="kernpps.htm">Kernel Programming Interface for
+Precision Time Signals</a></li>
</ul>
-<hr><center><img src=pic/pogo1a.gif></center>
+<hr>
+<center><img src="pic/pogo1a.gif" alt="gif"></center>
+
+<br>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
-<html><head><title>
-Miscellaneous Options
-</title></head><body><h3>
-Miscellaneous Options
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Miscellaneous Options</title>
+</head>
+<body>
+<h3>Miscellaneous Options</h3>
-<img align=left src=pic/boom3.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+<img align="left" src="pic/boom3.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
+Walt Kelly</a>
-<p>We have three, now looking for more.
-<br clear=left><hr>
+<p>We have three, now looking for more.<br clear="left">
+</p>
+<hr>
<dl>
+<dt><tt>broadcastdelay <i>seconds</i></tt></dt>
-<dt><tt>broadcastdelay <I>seconds</I></tt></dt>
-<dd>The broadcast and multicast modes require a special calibration to determine the network delay between the local and remote servers. Ordinarily, this is done automatically by the initial protocol exchanges between the client and server. In some cases, the calibration procedure may fail due to network or server access controls, for example. This command specifies the default delay to be used under these circumstances. Typically (for Ethernet), a number between 0.003 and 0.007 seconds is appropriate. The default when this command is not used is 0.004 seconds.</dd>
+<dd>The broadcast and multicast modes require a special calibration
+to determine the network delay between the local and remote
+servers. Ordinarily, this is done automatically by the initial
+protocol exchanges between the client and server. In some cases,
+the calibration procedure may fail due to network or server access
+controls, for example. This command specifies the default delay to
+be used under these circumstances. Typically (for Ethernet), a
+number between 0.003 and 0.007 seconds is appropriate. The default
+when this command is not used is 0.004 seconds.</dd>
-<dt><tt>driftfile <i>driftfile</i></tt>
-<dd>This command specifies the name of the file used to record the frequency offset of the local clock oscillator. If the file exists, it is read at startup in order to set the initial frequency offset and then updated once per hour with the current frequency offset computed by the daemon. If the file does not exist or this command is not given, the initial frequency offset is assumed zero. In this case, it may take some hours for the frequency to stabilize and the residual timing errors to subside.</dd>
+<dt><tt>driftfile <i>driftfile</i></tt></dt>
-<p><dd>The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version. This implies that <tt>ntpd</tt> must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.</dd>
+<dd>This command specifies the name of the file used to record the
+frequency offset of the local clock oscillator. If the file exists,
+it is read at startup in order to set the initial frequency offset
+and then updated once per hour with the current frequency offset
+computed by the daemon. If the file does not exist or this command
+is not given, the initial frequency offset is assumed zero. In this
+case, it may take some hours for the frequency to stabilize and the
+residual timing errors to subside.
-<dt><tt>enable [auth | bclient | calibrate | kernel | monitor | ntp | stats]</tt>
-<br><tt>disable [auth | bclient | calibrate | kernel | monitor | ntp | stats</tt>
-<dd>Provides a way to enable or disable various server options. Flags not mentioned are unaffected. Note that all of these flags can be controlled remotely using the <a href="ntpdc.htm"><tt>ntpdc</tt></a> utility program.</dd>
+<p>The file format consists of a single line containing a single
+floating point number, which records the frequency offset measured
+in parts-per-million (PPM). The file is updated by first writing
+the current drift value into a temporary file and then renaming
+this file to replace the old version. This implies that <tt>
+ntpd</tt> must have write permission for the directory the drift
+file is located in, and that file system links, symbolic or
+otherwise, should be avoided.</p>
+</dd>
-<dd><dl>
+<dt><tt>enable [auth | bclient | calibrate | kernel | monitor | ntp
+| stats]</tt><br>
+<tt>disable [auth | bclient | calibrate | kernel | monitor | ntp |
+stats</tt></dt>
+<dd>Provides a way to enable or disable various server options.
+Flags not mentioned are unaffected. Note that all of these flags
+can be controlled remotely using the <a href="ntpdc.htm"><tt>
+ntpdc</tt></a> utility program.</dd>
+
+<dd>
+<dl>
<dt><tt>bclient</tt></dt>
-<dd>When enabled, this is identical to the <tt>broadcastclient</tt> command. The default for this flag is <tt>disable</tt>.</dd>
+
+<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
+command. The default for this flag is <tt>disable</tt>.</dd>
<dt><tt>calibrate</tt></dt>
-<dd>Enables the calibration facility, which automatically adjusts the <tt>time1</tt> values for each clock driver to display the same offset as the currently selected source or kernel discipline signal. See the <a href=refclock.htm>Reference Clock Drivers</a> for further information. The default for this flag is <tt>disable</tt>.</dd>
+
+<dd>Enables the calibration facility, which automatically adjusts
+the <tt>time1</tt> values for each clock driver to display the same
+offset as the currently selected source or kernel discipline
+signal. See the <a href="refclock.htm">Reference Clock Drivers</a>
+for further information. The default for this flag is <tt>
+disable</tt>.</dd>
<dt><tt>kernel</tt></dt>
-<dd>Enables the precision-time kernel support for the <tt>ntp_adjtime()</tt> system call, if implemented. Ordinarily, support for this routine is detected automatically when the NTP daemon is compiled, so it is not necessary for the user to worry about this flag. It flag is provided primarily so that this support can be disabled during kernel development. The default for this flag is <tt>enable</tt>.</dd>
+
+<dd>Enables the precision-time kernel support for the <tt>
+ntp_adjtime()</tt> system call, if implemented. Ordinarily, support
+for this routine is detected automatically when the NTP daemon is
+compiled, so it is not necessary for the user to worry about this
+flag. It flag is provided primarily so that this support can be
+disabled during kernel development. The default for this flag is
+<tt>enable</tt>.</dd>
<dt><tt>monitor</tt></dt>
-<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program and the <tt>monlist</tt> command or further information. The default for this flag is <tt>enable</tt>.</dd>
+
+<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program
+and the <tt>monlist</tt> command or further information. The
+default for this flag is <tt>enable</tt>.</dd>
<dt><tt>ntp</tt></dt>
-<dd>Enables the server to adjust its local clock by means of NTP. If disabled, the local clock free-runs at its intrinsic time and frequency offset. This flag is useful in case the local clock is controlled by some other device or protocol and NTP is used only to provide
-synchronization to other clients. In this case, the local clock driver can be used to provide this function and also certain time variables for error estimates and leap-indicators. See the <a href="refclock.htm">Reference Clock Drivers </a>page for further information. The default for this flag is <tt>enable</tt>.</dd>
+
+<dd>Enables the server to adjust its local clock by means of NTP.
+If disabled, the local clock free-runs at its intrinsic time and
+frequency offset. This flag is useful in case the local clock is
+controlled by some other device or protocol and NTP is used only to
+provide synchronization to other clients. In this case, the local
+clock driver can be used to provide this function and also certain
+time variables for error estimates and leap-indicators. See the <a
+href="refclock.htm">Reference Clock Drivers</a> page for further
+information. The default for this flag is <tt>enable</tt>.</dd>
<dt><tt>pps</tt></dt>
-<dd>Enables the precision-time kernel support for the pulse-per-second (PPS) signal generated by some radio clocks and laboratory equipment. See the <a href="pps.htm">Pulse-per-second (PPS) Signal Interfacing
-Monitoring Options </a>. The default for this flag is <tt>enable</tt>.</dd>
+
+<dd>Enables the precision-time kernel support for the
+pulse-per-second (PPS) signal generated by some radio clocks and
+laboratory equipment. See the <a href="pps.htm">Pulse-per-second
+(PPS) Signal Interfacing Monitoring Options</a> . The default for
+this flag is <tt>enable</tt>.</dd>
<dt><tt>stats</tt></dt>
-<dd>Enables the statistics facility. See the <a href="monopt.htm">Monitoring Options </a>page for further information. The default for this flag is <tt>enable</tt>.</dd>
+<dd>Enables the statistics facility. See the <a href="monopt.htm">
+Monitoring Options</a> page for further information. The default
+for this flag is <tt>enable</tt>.</dd>
</dl>
+</dd>
+
+<dt><tt>logconfig <i>configkeyword</i></tt></dt>
+
+<dd>This command controls the amount and type of output written to
+the system <tt>syslog</tt> facility or the alternate <tt>
+logfile</tt> log file. By default, all output is turned on. All <i>
+<tt>configkeyword</tt></i> keywords can be prefixed with <tt>
+=</tt>, <tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the <tt>
+syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages.
+<tt>syslog messages</tt> can be controlled in four classes
+(<tt>clock</tt>, <tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>).
+Within these classes four types of messages can be controlled.</dd>
+
+<dd>Informational messages (<tt>info</tt>) control configuration
+information. Event messages (<tt>events</tt>) control logging of
+events (reachability, synchronization, alarm conditions).
+Statistical output is controlled with the <tt>statistics</tt>
+keyword. The final message group is the status messages. This
+describes mainly the synchronizations status. Configuration
+keywords are formed by concatenating the message class with the
+event class. The <tt>all</tt> prefix can be used instead of a
+message class. A message class may also be followed by the <tt>
+all</tt> keyword to enable/disable all messages of the respective
+message class.</dd>
+
+<dd>Thus, a minimal log configuration could look like this:
+
+<p><tt>logconfig=syncstatus +sysevents</tt></p>
-<dt><tt>logconfig <I>configkeyword</I></tt></dt>
-<dd>This command controls the amount and type of output written to the system <tt>syslog</tt> facility or the alternate <tt>logfile</tt> log file. By default, all output is turned on. All <I><tt>configkeyword</tt></I> keywords can be prefixed with <tt>=</tt>, <tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the <tt>syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages. <tt>syslog messages</tt> can be controlled in four classes (<tt>clock</tt>, <tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>). Within these classes four types of messages can be controlled.</dd>
+<p>This would just list the synchronizations state of <tt>ntpd</tt>
+and the major system events. For a simple reference server, the
+following minimum message configuration could be useful:</p>
-<dd>Informational messages (<tt>info</tt>) control configuration information. Event messages (<tt>events</tt>) control logging of events (reachability, synchronization, alarm conditions). Statistical output is controlled with the <tt>statistics</tt> keyword. The final message group is the status messages. This describes mainly the synchronizations status. Configuration keywords are formed by concatenating the message class with the event class. The <tt>all</tt> prefix can be used instead of a message class. A message class may also be followed by the <tt>all</tt> keyword to enable/disable all messages of the respective message class.</dd>
+<p><tt>logconfig=syncall +clockall</tt></p>
-<dd>Thus, a minimal log configuration could look like this:</dd>
+<p>This configuration will list all clock information and
+synchronization information. All other events and messages about
+peers, system events and so on is suppressed.</p>
+</dd>
-<p><dd><tt>logconfig = syncstatus +sysevents</tt></dd>
+<dt><tt>logfile <i>logfile</i></tt></dt>
-<p><dd>This would just list the synchronizations state of <tt>ntpd</tt> and the major system events. For a simple reference server, the following minimum message configuration could be useful:</dd>
+<dd>This command specifies the location of an alternate log file to
+be used instead of the default system <tt>syslog</tt>
+facility.</dd>
-<p><dd><tt>logconfig = syncall +clockall</tt></dd>
+<dt><tt>setvar <i>variable</i> [default]</tt></dt>
-<p><dd>This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.</dd>
+<dd>This command adds an additional system variable. These
+variables can be used to distribute additional information such as
+the access policy. If the variable of the form <tt><i>name</i> =
+<i>value</i></tt> is followed by the <tt>default</tt> keyword, the
+variable will be listed as part of the default system variables
+(<tt>ntpq rv</tt> command). These additional variables serve
+informational purposes only. They are not related to the protocol
+other that they can be listed. The known protocol variables will
+always override any variables defined via the <tt>setvar</tt>
+mechanism. There are three special variables that contain the names
+of all variable of the same group. The <tt>sys_var_list</tt> holds
+the names of all system variables. The <tt>peer_var_list</tt> holds
+the names of all peer variables and the <tt>clock_var_list</tt>
+holds the names of the reference clock variables.</dd>
-<dt><tt>logfile <I>logfile</I></tt></dt>
-<dd>This command specifies the location of an alternate log file to be used instead of the default system <tt>syslog</tt> facility.</dd>
+<dt><tt>tinker [ step <i>step</i> | panic <i>panic</i> | dispersion
+<i>dispersion</i> | stepout <i>stepout</i> ]</tt></dt>
-<dt><tt>setvar <I>variable</I> [default]</tt></dt>
-<dd>This command adds an additional system variable. These variables can be used to distribute additional information such as the access policy. If the variable of the form <tt><I>name</I> = <I>value</I></tt> is followed by the <tt>default</tt> keyword, the variable will be listed as part of the default system variables (<tt>ntpq rv</tt> command). These additional variables serve informational purposes only. They are not related to the protocol other that they can be listed. The known protocol variables will always override any variables defined via the <tt>setvar</tt> mechanism. There are three special variables that contain the names of all variable of the same group. The <tt>sys_var_list</tt> holds the names of all system variables. The <tt>peer_var_list</tt> holds the names of all peer variables and the <tt>clock_var_list</tt> holds the names of the reference clock variables.</dd>
+<dd>This command can be used to alter several system variables in
+very exceptional circumstances. The default values of these
+variables have been carefully optimized for a wide range of network
+speeds and reliability expectations. In general, they interact in
+intricate ways that are hard to predict and some combinations can
+result in some very nasty behavior. Very rarely is it necessary to
+change the default values; but, some folks can't resist twisting
+the knobs anyway and this command is for them. Emphasis added:
+twisters are on their own and can expect no help from the support
+group.
-<dt><tt>trap <I>host_address</I> [port <I>port_number</I>] [interface
-<I>interface_address</I>]</tt></dt>
-<dd>This command configures a trap receiver at the given host address and port number for sending messages with the specified local interface address. If the port number is unspecified, a value of 18447 is used. If the interface address is not specified, the message is sent with a source address of the local interface the message is sent through. Note that on a multihomed host the interface used may vary from time to time with routing changes.</dd>
+<p>All arguments are in floating point seconds or seconds per
+second. The variables operate as follows:</p>
+</dd>
-<dd>The trap receiver will generally log event messages and other information from the server in a log file. While such monitor programs may also request their own trap dynamically, configuring a trap receiver will ensure that no messages are lost when the server is started.</dd>
+<dd>
+<dl>
+<dt><tt>step <i>step</i></tt></dt>
+
+<dd>The argument becomes the new value for the step-adjustment
+threshold, normally 0.128 s.</dd>
+
+<dt><tt>panic <i>panic</i></tt></dt>
+
+<dd>The argument becomes the new value for the panic-stop
+threshold, normally 1000 s.</dd>
+
+<dt><tt>dispersion <i>dispersion</i></tt></dt>
+
+<dd>The argument becomes the new value for the dispersion increase
+rate, normally .000015.</dd>
+
+<dt><tt>stepout <i>stepout</i></tt></dt>
+<dd>The argument becomes the new value for the watchdog timeout,
+normally 900 s.</dd>
+</dl>
+</dd>
+
+<dt><tt>trap <i>host_address</i> [port <i>port_number</i>]
+[interface <i>interface_address</i>]</tt></dt>
+
+<dd>This command configures a trap receiver at the given host
+address and port number for sending messages with the specified
+local interface address. If the port number is unspecified, a value
+of 18447 is used. If the interface address is not specified, the
+message is sent with a source address of the local interface the
+message is sent through. Note that on a multihomed host the
+interface used may vary from time to time with routing changes.
+
+<p>The trap receiver will generally log event messages and other
+information from the server in a log file. While such monitor
+programs may also request their own trap dynamically, configuring a
+trap receiver will ensure that no messages are lost when the server
+is started.</p>
+</dd>
</dl>
<h4>Files</h4>
-<tt>ntp.drift</tt> frequency compensation (PPM)
+<tt>ntp.drift</tt> frequency compensation (PPM)
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
-<html><head><title>
-<tt>ntpd</tt> - Network Time Protocol (NTP) daemon
-</title></head><body><h3>
-<tt>ntpd</tt> - Network Time Protocol (NTP) daemon
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntpd - Network Time Protocol (NTP) daemon</title>
+</head>
+<body>
+<h3><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</h3>
+
+<img align="left" src="pic/alice47.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The mushroom knows all the command line options.<br clear=
+"left">
+</p>
+
+<hr>
+<h4>Synopsis</h4>
-<img align=left src=pic/alice47.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+<tt>ntpd [ -aAbdgLmNPqx ] [ -c <i>conffile</i> ] [ -f <i>
+driftfile</i> ] [ -g ] [ -k <i>keyfile</i> ] [ -l <i>logfile</i> ]
+[ -N high ] [ -p <i>pidfile</i> ] [ -r <i>broadcastdelay</i> ] [ -s
+<i>statsdir</i> ] [ -t <i>key</i> ] [ -v <i>variable</i> ] [ -V <i>
+variable</i> ] [ -x ]</tt>
+
+<h4>Description</h4>
+
+The <tt>ntpd</tt> program is an operating system daemon which sets
+and maintains the system time of day in synchronism with Internet
+standard time servers. It is a complete implementation of the
+Network Time Protocol (NTP) version 4, but also retains
+compatibility with version 3, as defined by RFC-1305, and version 1
+and 2, as defined by RFC-1059 and RFC-1119, respectively. <tt>
+ntpd</tt> does most computations in 64-bit floating point
+arithmetic and does relatively clumsy 64-bit fixed point operations
+only when necessary to preserve the ultimate precision, about 232
+picoseconds. While the ultimate precision, is not achievable with
+ordinary workstations and networks of today, it may be required
+with future gigahertz CPU clocks and gigabit LANs.
+
+<h4>Now NTP Operates</h4>
+
+<p>The <tt>ntpd</tt> program operates by exchanging messages with
+one or more configured servers at designated poll intervals. When
+started, whether for the first or subsequent times, the program
+requires several exahanges from the majority of these servers so
+the signal processing and mitigation algorithms can accumulate and
+groom the data and set the clock. In order to protect the network
+from bursts, the initial poll interval for each server is delayed
+an interval randomized over 0-16s. At the default initial poll
+interval of 64s, several minutes can elapse before the clock is
+set. The initial delay to set the clock can be reduced using the
+<tt>iburst</tt> keyword with the <tt>server</tt> configuration
+command, as described on the <a href="confopt.htm">Configuration
+Options</a> page.</p>
+
+<p>Most operating systems and hardware of today incorporate a
+time-of-year (TOY) chip to maintain the time during periods when
+the power is off. When the machine is booted, the chip is used to
+initialize the operating system time. After the machine has
+synchronized to a NTP server, the operating system corrects the
+chip from time to time. In case there is no TOY chip or for some
+reason its time is more than 1000s from the server time, <tt>
+ntpd</tt> assumes something must be terribly wrong and the only
+reliable action is for the operator to intervene and set the clock
+by hand. This causes <tt>ntpd</tt> to exit with a panic message to
+the system log. The <tt>-g</tt> option overrides this check and the
+clock will be set to the server time regardless of the chip time.
+However, and to protect against broken hardware, such as when the
+CMOS battery fails or the clock counter becomes defective, once the
+clock has been set, an error greater than 1000s will cause <tt>
+ntpd</tt> to exit anyway.</p>
+
+<p>Under ordinariy conditions, <tt>ntpd</tt> adjusts the clock in
+small steps so that the timescale is effectively continuous and
+without discontinuities. Under conditions of extreme network
+congestion, the roundtrip delay jitter can exceed three seconds and
+the synchronization distance, which is equal to one-half the
+roundtrip delay plus error budget terms, can become very large. The
+<tt>ntpd</tt> algorithms discard sample offsets exceeding 128 ms,
+unless the interval during which no sample offset is less than 128
+ms exceeds 900s. The first sample after that, no matter what the
+offset, steps the clock to the indicated time. In practice this
+reduces the false alarm rate where the clock is stepped in error to
+a vanishingly low incidence.</p>
+
+<p>As the result of this behavior, once the clock has been set, it
+very rarely strays more than 128 ms, even under extreme cases of
+network path congestion and jitter. Sometimes, in particular when
+<tt>ntpd</tt> is first started, the error might exceed 128 ms. This
+may on occasion cause the clock to be set backwards if the local
+clock time is more than 128 s in the future relative to the server.
+In some applications, this behavior may be unacceptable. If the
+<tt>-x</tt> option is included on the command line, the clock will
+never be stepped and only slew corrections will be used.</p>
+
+<p>The issues should be carefully explored before deciding to use
+the <tt>-x</tt> option. The maximum slew rate possible is limited
+to 500 parts-per-million (PPM) as a consequence of the correctness
+principles on which the NTP protocol and algorithm design are
+based. As a result, the local clock can take a long time to
+converge to an acceptable offset, about 2,000 s for each second the
+clock is outside the acceptable range. During this interval the
+local clock will not be consistent with any other network clock and
+the system cannot be used for distributed applications that require
+correctly synchronized network time.</p>
+
+<p>In spite of the above precautions, sometimes when large
+frequency errors are present the resulting time offsets stray
+outside the 128-ms range and an eventual step or slew time
+correction is required. If following such a correction the
+frequency error is so large that the first sample is outside the
+acceptable range, <tt>ntpd</tt> enters the same state as when the
+<tt>ntp.drift</tt> file is not present. The intent of this behavior
+is to quickly correct the frequency and restore operation to the
+normal tracking mode. In the most extreme cases
+(<tt>time.ien.it</tt> comes to mind), there may be occasional
+step/slew corrections and subsequent frequency corrections. It
+helps in these cases to use the <tt>burst</tt> keyword when
+configuring the server.</p>
+
+<h4>Frequency Discipline</h4>
+
+<p>The <tt>ntpd</tt> behavior at startup depends on whether the
+frequency file, usually <tt>ntp.drift</tt>, exists. This file
+contains the latest estimate of clock frequency error. When the
+<tt>ntpd</tt> is started and the file does not exist, the <tt>
+ntpd</tt> enters a special mode designed to quickly adapt to the
+particular system clock oscillator time and frequency error. This
+takes approximately 15 minutes, after which the time and frequency
+are set to nominal values and the <tt>ntpd</tt> enters normal mode,
+where the time and frequency are continuously tracked relative to
+the server. After one hour the frequency file is created and the
+current frequency offset written to it. When the <tt>ntpd</tt> is
+started and the file does exist, the <tt>ntpd</tt> frequency is
+initialized from the file and enters normal mode immediately. After
+that the current frequency offset is written to the file at hourly
+intervals.</p>
+
+<h4>Operating Modes</h4>
+
+<p><tt>ntpd</tt> can operate in any of several modes, including
+symmetric active/passive, client/server broadcast/multicast and
+manycast, as described in the <a href="assoc.htm">Association
+Management</a> page. It normally operates continuously while
+monitoring for small changes in frequency and trimming the clock
+for the ultimate precision. However, it can operate in a one-time
+mode where the time is set from an external server and frequency is
+set from a previously recorded frequency file. A
+broadcast/multicast or manycast client can discover remote servers,
+compute server-client propagation delay correction factors and
+configure itself automatically. This makes it possible to deploy a
+fleet of workstations without specifying configuration details
+specific to the local environment.</p>
-<p>The mushroom knows all the command line options.
-<br clear=left><hr>
+<p>By default, <tt>ntpd</tt> runs in continuous mode where each of
+possibly several external servers is polled at intervals determined
+by an intricate state machine. The state machine measures the
+incidental roundtrip delay jitter and oscillator frequency wander
+and determines the best poll interval using a heuristic algorithm.
+Ordinarily, and in most operating environments, the state machine
+will start with 64s intervals and eventually increase in steps to
+1024s. A small amount of random variation is introduced in order to
+avoid bunching at the servers. In addition, should a server become
+unreachable for some time, the poll interval is increased in steps
+to 1024s in order to reduce network overhead.</p>
-<h4>Synopsis</h4>
+<p>In some cases it may not be practical for <tt>ntpd</tt> to run
+continuously. A common workaround has been to run the <tt>
+ntpdate</tt> program from a <tt>cron</tt> job at designated times.
+However, this program does not have the crafted signal processing,
+error checking and mitigation algorithms of <tt>ntpd</tt>. The <tt>
+-q</tt> option is intended for this purpose. Setting this option
+will cause <tt>ntpd</tt> to exit just after setting the clock for
+the first time. The procedure for initially setting the clock is
+the same as in continuous mode; most applications will probably
+want to specify the <tt>iburst</tt> keyword with the <tt>
+server</tt> configuration command. With this keyword a volley of
+messages are exchanged to groom the data and the clock is set in
+about a minute. If nothing is heard after a couple of minutes, the
+daemon times out and exits. After a suitable period of mourning,
+the <tt>ntpdate</tt> program may be retired.</p>
-<TT>ntpd [ -aAbdm ] [ -c <I>conffile</I> ] [ -f <I>driftfile</I> ] [ -g
-] [ -k <I>keyfile</I> ] [ -l <I>logfile</I> ] [ -N high ] [ -p
-<I>pidfile</I> ] [ -r <I>broadcastdelay</I> ] [ -s <I>statsdir</I> ] [
--t <I>key</I> ] [ -v <I>variable</I> ] [ -V <I>variable</I> ] [ -x
-]</TT>
-
-<H4>Description</H4>
-
-<TT>ntpd</TT> is an operating system daemon which sets and maintains the
-system time-of-day in synchronism with Internet standard time servers.
-<TT>ntpd</TT> is a complete implementation of the Network Time Protocol
-(NTP) version 4, but also retains compatibility with version 3, as
-defined by RFC-1305, and version 1 and 2, as defined by RFC-1059 and
-RFC-1119, respectively. <TT>ntpd</TT> does most computations in 64-bit
-floating point arithmetic and does relatively clumsy 64-bit fixed point
-operations only when necessary to preserve the unltimate precision,
-about 232 picoseconds. While the ultimate precision, is not achievable
-with ordinary workstations and networks of today, it may be required
-with future nanosecond CPU clocks and gigabit LANs.
-
-<P>The daemon can operate in any of several modes, including symmetric
-active/passive, client/server broadcast/multicast and manycast. A
-broadcast/multicast or manycast client can discover remote servers,
-compute server-client propagation delay correction factors and configure
-itself automatically. This makes it possible to deploy a fleet of
-workstations without specifying configuration details specific to the
-local environment.
+<p>When kernel support is available to discipline the clock
+frequency, which is the case for stock Solaris, Tru64, Linux and
+FreeBSD, a useful feature is available to discipline the clock
+frequency. First, <tt>ntpd</tt> is run in continuous mode with
+selected servers in order to measure and record the intrinsic clock
+frequency offset in the frequency file. It may take some hours for
+the frequency and offset to settle down. Then the <tt>ntpd</tt> is
+stopped and run in one-time mode as required. At each startup, the
+frequency is read from the file and initializes the kernel
+frequency.</p>
+
+<h4>Notes</h4>
+
+<p>If NetInfo support is built into <tt>ntpd</tt>, then <tt>
+ntpd</tt> will attempt to read its configuration from the NetInfo
+if the default ntp.conf file cannot be read and no file is
+specified by the <tt>-c</tt> option.</p>
+
+<p>Various internal <tt>ntpd</tt> variables can be displayed and
+configuration options altered while the <tt>ntpd</tt> is running
+using the <tt><a href="ntpq.htm">ntpq</a></tt> and <tt><a href=
+"ntpdc.htm">ntpdc</a></tt> utility programs.</p>
+
+<p>When <tt>ntpd</tt> starts it looks at the value of <tt>
+umask</tt>, and if zero <tt>ntpd</tt> will set the <tt>umask</tt>
+to <tt>022</tt>.</p>
+
+<h4>Command Line Options</h4>
+
+<dl>
+<dt><tt>-a</tt></dt>
+
+<dd>Enable authentication mode (default).</dd>
+
+<dt><tt>-A</tt></dt>
+
+<dd>Disable authentication mode.</dd>
+
+<dt><tt>-b</tt></dt>
+
+<dd>Synchronize using NTP broadcast messages.</dd>
+
+<dt><tt>-c <i>conffile</i></tt></dt>
+
+<dd>Specify the name and path of the configuration file. (Disable
+netinfo?)</dd>
+
+<dt><tt>-d</tt></dt>
+
+<dd>Specify debugging mode. This flag may occur multiple times,
+with each occurrence indicating greater detail of display.</dd>
+
+<dt><tt>-D <i>level</i></tt></dt>
+
+<dd>Specify debugging level directly.</dd>
+
+<dt><tt>-f <i>driftfile</i></tt></dt>
+
+<dd>Specify the name and path of the drift file.</dd>
+
+<dt><tt>-g</tt></dt>
+
+<dd>Normally, the <tt>ntpd</tt> exits if the offset exceeds a
+1000-s sanity limit. This option overrides this limit and allows
+the time to be set to any value without restriction; however, this
+can happen only once. After that, the <tt>ntpd</tt> will exit if
+the limit is exceeded. This option can be used with the <tt>-q</tt>
+option.</dd>
+
+<dt><tt>-k <i>keyfile</i></tt></dt>
+
+<dd>Specify the name and path of the file containing the NTP
+authentication keys.</dd>
+
+<dt><tt>-l <i>logfile</i></tt></dt>
+
+<dd>Specify the name and path of the log file. The default is the
+system log facility.</dd>
+
+<dt><tt>-L</tt></dt>
+
+<dd>Listen to virtual IPs.</dd>
+
+<dt><tt>-m</tt></dt>
+
+<dd>Synchronize using NTP multicast messages on the IP multicast
+group address 224.0.1.1 (requires multicast kernel).</dd>
+
+<dt><tt>-n</tt></dt>
+
+<dd>Don't fork.</dd>
+
+<dt><tt>-N <i>priority</i></tt></dt>
+
+<dd>To the extent permitted by the operating system, run the <tt>
+ntpd</tt> at a high priority.</dd>
+
+<dt><tt>-p <i>pidfile</i></tt></dt>
+
+<dd>Specify the name and path to record the <tt>ntpd</tt>'s process
+ID.</dd>
+
+<dt><tt>-P</tt></dt>
+
+<dd>Override the priority limit set by the operating system. Not
+recommended for sissies.</dd>
+
+<dt><tt>-q</tt></dt>
+
+<dd>Exit the <tt>ntpd</tt> just after the first time the clock is
+set. This behavior mimics that of the <tt>ntpdate</tt> program,
+which is to be retired. The <tt>-g</tt> and <tt>-x</tt> options can
+be used with this option.</dd>
+
+<dt><tt>-r <i>broadcastdelay</i></tt></dt>
+
+<dd>Specify the default propagation delay from the
+broadcast/multicast server and this computer. This is necessary
+only if the delay cannot be computed automatically by the
+protocol.</dd>
+
+<dt><tt>-s <i>statsdir</i></tt></dt>
+
+<dd>Specify the directory path for files created by the statistics
+facility.</dd>
+
+<dt><tt>-t <i>key</i></tt></dt>
+
+<dd>Add a key number to the trusted key list.</dd>
+
+<dt><tt>-v <i>variable</i></tt></dt>
+
+<dt><tt>-V <i>variable</i></tt></dt>
+
+<dd>Add a system variable listed by default.</dd>
+
+<dt><tt>-x</tt></dt>
+
+<dd>Ordinarily, if the time is to be adjusted more than 128 ms, it
+is stepped, not gradually slewed. This option forces the time to be
+slewed in all cases. Note: Since the slew rate is limited to 0.5
+ms/s, each second of adjustment requires an amortization interval
+of 2000 s. Thus, an adjustment of many seconds can take hours or
+days to amortize. This option can be used with the <tt>-q</tt>
+option.</dd>
+</dl>
+
+<h4>The Configuration File</h4>
+
+<p>Ordinarily, <tt>ntpd</tt> reads the <tt>ntp.conf</tt>
+configuration file at startup time in order to determine the
+synchronization sources and operating modes. It is also possible to
+specify a working, although limited, configuration entirely on the
+command line, obviating the need for a configuration file. This may
+be particularly useful when the local host is to be configured as a
+broadcast/multicast client, with all peers being determined by
+listening to broadcasts at run time.</p>
+
+<p>Usually, the configuration file is installed in the <tt>
+/etc</tt> directory, but could be installed elsewhere (see the <tt>
+-c <i>conffile</i></tt> command line option). The file format is
+similar to other Unix configuration files - comments begin with a
+<tt>#</tt> character and extend to the end of the line; blank lines
+are ignored.</p>
+
+<p>Configuration commands consist of an initial keyword followed by
+a list of arguments, some of which may be optional, separated by
+whitespace. Commands may not be continued over multiple lines.
+Arguments may be host names, host addresses written in numeric,
+dotted-quad form, integers, floating point numbers (when specifying
+times in seconds) and text strings. Optional arguments are
+delimited by <tt>[ ]</tt> in the following descriptions, while
+alternatives are separated by <tt>|</tt>. The notation <tt>[ ...
+]</tt> means an optional, indefinite repetition of the last item
+before the <tt>[ ... ]</tt>.</p>
+
+<p><a href="confopt.htm">Configuration Options</a><br>
+<a href="authopt.htm">Authentication Options</a><br>
+<a href="monopt.htm">Monitoring Options</a><br>
+<a href="accopt.htm">Access Control Options</a><br>
+<a href="clockopt.htm">Reference Clock Options</a><br>
+<a href="miscopt.htm">Miscellaneous Options</a></p>
+
+<h4>Files</h4>
+
+<tt>/etc/ntp.conf</tt> - the default name of the configuration file
+<br>
+<tt>/etc/ntp.drift</tt> - the default name of the drift file <br>
+<tt>/etc/ntp.keys</tt> - the default name of the key file
+
+<h4>Bugs</h4>
+
+<tt>ntpd</tt> has gotten rather fat. While not huge, it has gotten
+larger than might be desirable for an elevated-priority <tt>
+ntpd</tt> running on a workstation, particularly since many of the
+fancy features which consume the space were designed more with a
+busy primary server, rather than a high stratum workstation in
+mind.
-<P>Ordinarily, <TT>ntpd</TT> reads the <TT>ntp.conf</TT> configuration
-file at startup time in order to determine the synchronization sources
-and operating modes. It is also possible to specify a working, although
-limited, configuration entirely on the command line, obviating the need
-for a configuration file. This may be particularly appropriate when the
-local host is to be configured as a broadcast/multicast client or
-manycast client, with all peers being determined by listening to
-broadcasts at run time.
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
-<P>If NetInfo support is built into <TT>ntpd</TT>, then <TT>ntpd</TT>
-will attempt to read its configuration from the NetInfo if the default
-ntp.conf file cannot be read and no file is specified by the <TT>-c</TT>
-option.
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<P>Various internal <TT>ntpd</TT> variables can be displayed and
-configuration options altered while the daemon is running using the
-<TT><A HREF="ntpq.htm">ntpq</A></TT> and <TT><A
-HREF="ntpdc.htm">ntpdc</A></TT> utility programs.
-
-<P>When <TT>ntpd</TT> starts it looks at the value of <TT>umask</TT>,
-and if it's zero <TT>ntpd</TT> will set the <TT>umask</TT> to
-<TT>022</TT>.
-
-<H4>Command Line Options</H4>
-
-<DL>
-
-<DT><TT>-a</TT></DT>
-<DD>Enable authentication mode (default).</DD>
-
-<DT><TT>-A</TT></DT>
-<DD>Disable authentication mode.</DD>
-
-<DT><TT>-b</TT></DT>
-<DD>Synchronize using NTP broadcast messages.</DD>
-
-<DT><TT>-c <I>conffile</I></TT></DT>
-<DD>Specify the name and path of the configuration file.
-(Disable netinfo?)</DD>
-
-<DT><TT>-d</TT></DT>
-<DD>Specify debugging mode. This flag may occur multiple times, with
-each occurrence indicating greater detail of display.</DD>
-
-<DT><TT>-D <I>level</I></TT></DT>
-<DD>Specify debugging level directly.</DD>
-
-<DT><TT>-f <I>driftfile</I></TT></DT>
-<DD>Specify the name and path of the drift file.</DD>
-
-<DT><TT>-g</TT></DT>
-<DD>Normally, the daemon exits if the offset exceeds a 1000-s sanity
-limit. This option overrides this limit and allows the time to be set to
-any value without restriction; however, this can happen only once. After
-that, the daemon will exit if the limit is exceeded.
-
-<DT><TT>-k <I>keyfile</I></TT></DT>
-<DD>Specify the name and path of the file containing the NTP
-authentication keys.</DD>
-
-<DT><TT>-l <I>logfile</I></TT></DT>
-<DD>Specify the name and path of the log file. The default is the system
-log facility.</DD>
-
-<DT><TT>-L</TT></DT>
-<DD>Listen to virtual IPs.</DD>
-
-<DT><TT>-m</TT></DT>
-<DD>Synchronize using NTP multicast messages on the IP multicast group
-address 224.0.1.1 (requires multicast kernel).</DD>
-
-<DT><TT>-n</TT></DT>
-<DD>Don't fork.</DD>
-
-<DT><TT>-N high</TT></DT>
-<DD>To the extent permitted by the operating system, run the daemon at a
-high priority.</DD>
-
-<DT><TT>-p <I>pidfile</I></TT></DT>
-<DD>Specify the name and path to record the daemon's process ID.</DD>
-
-<DT><TT>-P</TT></DT>
-<DD>Override the priority limit set by the operating system. Not
-recommended for sissies.</DD>
-
-<DT><TT>-r <I>broadcastdelay</I></TT></DT>
-<DD>Specify the default propagation delay from the broadcast/multicast
-server and this computer. This is necessary only if the delay cannot be
-computed automatically by the protocol.</DD>
-
-<DT><TT>-s <I>statsdir</I></TT></DT>
-<DD>Specify the directory path for files created by the statistics
-facility.</DD>
-
-<DT><TT>-t <I>key</I></TT></DT>
-<DD>Add a key number to the trusted key list.</DD>
-
-<DT><TT>-v <I>variable</I></TT></DT>
-<DT><TT>-V <I>variable</I></TT></DT>
-<DD>Add a system variable listed by default.</DD>
-
-<DT><TT>-x</TT></DT>
-<DD>Ordinarily, if the time is to be adjusted more than 128 ms, it is
-stepped, not gradually slewed. This option forces the time to be slewed
-in all cases. Note: Since the slew rate is limited to 0.5 ms/s, each
-second of adjustment requires an amortization interval of 2000 s. Thus,
-an adjustment of many seconds can take hours or days to amortize.</DD>
-</DL>
-
-<H4>The Configuration File</H4>
-
-The <TT>ntpd</TT> configuration file is read at initial startup in order
-to specify the synchronization sources, modes and other related
-information. Usually, it is installed in the <TT>/etc</TT> directory,
-but could be installed elsewhere (see the <TT>-c <I>conffile</I></TT>
-command line option). The file format is similar to other Unix
-configuration files - comments begin with a <TT>#</TT> character and
-extend to the end of the line; blank lines are ignored. Configuration
-commands consist of an initial keyword followed by a list of arguments,
-some of which may be optional, separated by whitespace. Commands may not
-be continued over multiple lines. Arguments may be host names, host
-addresses written in numeric, dotted-quad form, integers, floating
-point numbers (when specifying times in seconds) and text strings.
-Optional arguments are delimited by <TT>[ ]</TT> in the following
-descriptions, while alternatives are separated by <TT>|</TT>. The
-notation <TT>[ ... ]</TT> means an optional, indefinite repetition of
-the last item before the <TT>[ ... ]</TT>.
-
-<P>See the following pages for configuration and control options. While
-there is a rich set of options available, the only required option is
-one or more <TT>server, peer,</TT> <TT>broadcast</TT> or
-<TT>manycastclient </TT>commands described in the Configuration Options
-page. The <A HREF="notes.htm">Notes on Configuring NTP and Setting up a
-NTP Subnet </A>page contains an extended discussion of these options.
-
-<P><A HREF="confopt.htm">Configuration Options</A>
-<BR><A HREF="authopt.htm">Authentication Options</A>
-<BR><A HREF="monopt.htm">Monitoring Options</A>
-<BR><A HREF="accopt.htm">Access Control Options</A>
-<BR><A HREF="clockopt.htm">Reference Clock Options</A>
-<BR><A HREF="miscopt.htm">Miscellaneous Options</A>
-
-<H4>Files</H4>
-
-<TT>/etc/ntp.conf</TT> - the default name of the configuration file
-<BR><TT>/etc/ntp.drift</TT> - the default name of the drift file
-<BR><TT>/etc/ntp.keys</TT> - the default name of the key file
-
-<H4>Bugs</H4>
-
-<TT>ntpd</TT> has gotten rather fat. While not huge, it has gotten
-larger than might be desireable for an elevated-priority daemon running
-on a workstation, particularly since many of the fancy features which
-consume the space were designed more with a busy primary server, rather
-than a high stratum workstation, in mind.
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
-<html><head><title>
-<tt>ntpdate</tt> - set the date and time via NTP
-</title></head><body><h3>
-<tt>ntpdate</tt> - set the date and time via NTP
-</h3>
-
-<img align=left src=pic/rabbit.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>I told you it was eyeball and wristwatch.
-<br clear=left><hr>
-
-<H4>
-Synopsis</H4>
-<TT>ntpdate [ -bBdoqsuv ] [ -a <I>key</I> ] [ -e <I>authdelay</I> ] [ -k
-<I>keyfile</I> ] [ -o <I>version</I> ] [ -p <I>samples</I> ] [ -t <I>timeout</I>
-] <I>server</I> [ ... ]</TT>
-<H4>
-Description</H4>
-<TT>ntpdate</TT> sets the local date and time by polling the Network Time
-Protocol (NTP) server(s) given as the <I>server</I> arguments to determine
-the correct time. It must be run as root on the local host. A number of
-samples are obtained from each of the servers specified and a subset of
-the NTP clock filter and selection algorithms are applied to select the
-best of these. Note that the accuracy and reliability of <TT>ntpdate</TT>
-depends on the number of servers, the number of polls each time it is run
-and the interval between runs.
-
-<P><TT>ntpdate</TT> can be run manually as necessary to set the host clock,
-or it can be run from the host startup script to set the clock at boot
-time. This is useful in some cases to set the clock initially before starting
-the NTP daemon <TT>ntpd</TT>. It is also possible to run <TT>ntpdate</TT>
-from a <TT>cron</TT> script. However, it is important to note that <TT>ntpdate</TT>
-with contrived <TT>cron</TT> scripts is no substitute for the NTP daemon,
-which uses sophisticated algorithms to maximize accuracy and reliability
-while minimizing resource use. Finally, since <TT>ntpdate</TT> does not
-discipline the host clock frequency as does <TT>ntpd</TT>, the accuracy
-using <TT>ntpdate</TT> is limited.
-
-<P>Time adjustments are made by <TT>ntpdate</TT> in one of two ways. If
-<TT>ntpdate</TT> determines the clock is in error more than 0.5 second
-it will simply step the time by calling the system <TT>settimeofday()</TT>
-routine. If the error is less than 0.5 seconds, it will slew the time by
-calling the system <TT>adjtime()</TT> routine. The latter technique is
-less disruptive and more accurate when the error is small, and works quite
-well when <TT>ntpdate</TT> is run by <TT>cron</TT> every hour or two.
-
-<P><TT>ntpdate</TT> will decline to set the date if an NTP server daemon
-(e.g., <TT>ntpd</TT>) is running on the same host. When running <TT>ntpdate</TT>
-on a regular basis from <TT>cron</TT> as an alternative to running a daemon,
-doing so once every hour or two will result in precise enough timekeeping
-to avoid stepping the clock.
-
-<P>If NetInfo support is compiled into <TT>ntpdate</TT>, then the
-<TT>server</TT> argument is optional if <TT>ntpdate</TT> can find a time
-server in the NetInfo configuration for <TT>ntpd</TT>.
-
-<H4>
-Command Line Options</H4>
-
-<DL>
-<DT>
-<TT>-a <I>key</I></TT></DT>
-
-<DD>
-Enable the authentication function and specify the key identifier to be
-used for authentication as the argument <I>key</I><TT>ntpdate</TT>. The
-keys and key identifiers must match in both the client and server key files.
-The default is to disable the authentication function.</DD>
-
-<DT>
-<TT>-B</TT></DT>
-
-<DD>
-Force the time to always be slewed using the adjtime() system call, even
-if the measured offset is greater than +-128 ms. The default is to step
-the time using settimeofday() if the offset is greater than +-128 ms. Note
-that, if the offset is much greater than +-128 ms in this case, that it
-can take a long time (hours) to slew the clock to the correct value. During
-this time. the host should not be used to synchronize clients.</DD>
-
-<DT>
-<TT>-b</TT></DT>
-
-<DD>
-Force the time to be stepped using the settimeofday() system call, rather
-than slewed (default) using the adjtime() system call. This option should
-be used when called from a startup file at boot time.</DD>
-
-<DT>
-<TT>-d</TT></DT>
-
-<DD>
-Enable the debugging mode, in which <TT>ntpdate</TT> will go through all
-the steps, but not adjust the local clock. Information useful for general
-debugging will also be printed.</DD>
-
-<DT>
-<TT>-e <I>authdelay</I></TT></DT>
-
-<DD>
-Specify the processing delay to perform an authentication function as the
-value <I>authdelay</I>, in seconds and fraction (see <TT>ntpd</TT> for
-details). This number is usually small enough to be negligible for most
-purposes, though specifying a value may improve timekeeping on very slow
-CPU's.</DD>
-
-<DT>
-<TT>-k <I>keyfile</I></TT></DT>
-
-<DD>
-Specify the path for the authentication key file as the string <I>keyfile</I>.
-The default is <TT>/etc/ntp.keys</TT>. This file should be in the format
-described in <TT>ntpd</TT>.</DD>
-
-<DT>
-<TT>-o <I>version</I></TT></DT>
-
-<DD>
-Specify the NTP version for outgoint packets as the integer <I>version</I>,
-which can be 1 or 2. The default is 3. This allows <TT>ntpdate</TT> to
-be used with older NTP versions.</DD>
-
-<DT>
-<TT>-p <I>samples</I></TT></DT>
-
-<DD>
-Specify the number of samples to be acquired from each server as the integer
-<I>samples</I>, with values from 1 to 8 inclusive. The default is 4.</DD>
-
-<DT>
-<I><TT>-q</TT></I></DT>
-
-<DD>
-Query only - don't set the clock.</DD>
-
-<DT>
-<TT>-s</TT></DT>
-
-<DD>
-Divert logging output from the standard output (default) to the system
-<TT>syslog</TT> facility. This is designed primarily for convenience of
-<TT>cron</TT> scripts.</DD>
-
-<DT>
-<TT>-t <I>timeout</I></TT></DT>
-
-<DD>
-Specify the maximum time waiting for a server response as the value <I>timeout</I>,
-in seconds and fraction. The value is is rounded to a multiple of 0.2 seconds.
-The default is 1 second, a value suitable for polling across a LAN.</DD>
-
-<DT>
-<TT>-u</TT></DT>
-
-<DD>
-Direct <TT>ntpdate</TT> to use an unprivileged port or outgoing packets.
-This is most useful when behind a firewall that blocks incoming traffic
-to privileged ports, and you want to synchronise with hosts beyond the
-firewall. Note that the <TT>-d</TT> option always uses unprivileged ports.</DD>
-
-<DT>
-<TT>-<I>v</I></TT></DT>
-
-<DD>
-Be verbose. This option will cause <TT>ntpdate</TT>'s version identification
-string to be logged.</DD>
-</DL>
-
-<H4>
-Files</H4>
-<TT>/etc/ntp.keys</TT> - encryption keys used by <TT>ntpdate</TT>.
-<H4>
-Bugs</H4>
-The slew adjustment is actually 50% larger than the measured offset, since
-this (it is argued) will tend to keep a badly drifting clock more accurate.
-This is probably not a good idea and may cause a troubling hunt for some
-values of the kernel variables <TT>tick</TT> and <TT>tickadj</TT>.
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntpdate - set the date and time via NTP</title>
+</head>
+<body>
+<h3><tt>ntpdate</tt> - set the date and time via NTP</h3>
+
+<img align="left" src="pic/rabbit.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>I told you it was eyeball and wristwatch.<br clear="left">
+</p>
+
+<hr>
+<p>Disclaimer: The functionality of this program is now available
+in the <tt>ntpd</tt> program. See the <tt>-q</tt> command line
+option in the <a href="ntpd.htm"><tt>ntpd</tt> - Network Time
+Protocol (NTP) daemon</a> page. After a suitable period of
+mourning, the <tt>ntpdate</tt> program is to be retired from this
+distribution</p>
+
+<h4>Synopsis</h4>
+
+<tt>ntpdate [ -bBdoqsuv ] [ -a <i>key</i> ] [ -e <i>authdelay</i> ]
+[ -k <i>keyfile</i> ] [ -o <i>version</i> ] [ -p <i>samples</i> ] [
+-t <i>timeout</i> ] <i>server</i> [ ... ]</tt>
+
+<h4>Description</h4>
+
+<tt>ntpdate</tt> sets the local date and time by polling the
+Network Time Protocol (NTP) server(s) given as the <i>server</i>
+arguments to determine the correct time. It must be run as root on
+the local host. A number of samples are obtained from each of the
+servers specified and a subset of the NTP clock filter and
+selection algorithms are applied to select the best of these. Note
+that the accuracy and reliability of <tt>ntpdate</tt> depends on
+the number of servers, the number of polls each time it is run and
+the interval between runs.
+
+<p><tt>ntpdate</tt> can be run manually as necessary to set the
+host clock, or it can be run from the host startup script to set
+the clock at boot time. This is useful in some cases to set the
+clock initially before starting the NTP daemon <tt>ntpd</tt>. It is
+also possible to run <tt>ntpdate</tt> from a <tt>cron</tt> script.
+However, it is important to note that <tt>ntpdate</tt> with
+contrived <tt>cron</tt> scripts is no substitute for the NTP
+daemon, which uses sophisticated algorithms to maximize accuracy
+and reliability while minimizing resource use. Finally, since <tt>
+ntpdate</tt> does not discipline the host clock frequency as does
+<tt>ntpd</tt>, the accuracy using <tt>ntpdate</tt> is limited.</p>
+
+<p>Time adjustments are made by <tt>ntpdate</tt> in one of two
+ways. If <tt>ntpdate</tt> determines the clock is in error more
+than 0.5 second it will simply step the time by calling the system
+<tt>settimeofday()</tt> routine. If the error is less than 0.5
+seconds, it will slew the time by calling the system <tt>
+adjtime()</tt> routine. The latter technique is less disruptive and
+more accurate when the error is small, and works quite well when
+<tt>ntpdate</tt> is run by <tt>cron</tt> every hour or two.</p>
+
+<p><tt>ntpdate</tt> will decline to set the date if an NTP server
+daemon (e.g., <tt>ntpd</tt>) is running on the same host. When
+running <tt>ntpdate</tt> on a regular basis from <tt>cron</tt> as
+an alternative to running a daemon, doing so once every hour or two
+will result in precise enough timekeeping to avoid stepping the
+clock.</p>
+
+<p>If NetInfo support is compiled into <tt>ntpdate</tt>, then the
+<tt>server</tt> argument is optional if <tt>ntpdate</tt> can find a
+time server in the NetInfo configuration for <tt>ntpd</tt>.</p>
+
+<h4>Command Line Options</h4>
+
+<dl>
+<dt><tt>-a <i>key</i></tt></dt>
+
+<dd>Enable the authentication function and specify the key
+identifier to be used for authentication as the argument <i>
+key</i><tt>ntpdate</tt>. The keys and key identifiers must match in
+both the client and server key files. The default is to disable the
+authentication function.</dd>
+
+<dt><tt>-B</tt></dt>
+
+<dd>Force the time to always be slewed using the adjtime() system
+call, even if the measured offset is greater than +-128 ms. The
+default is to step the time using settimeofday() if the offset is
+greater than +-128 ms. Note that, if the offset is much greater
+than +-128 ms in this case, that it can take a long time (hours) to
+slew the clock to the correct value. During this time. the host
+should not be used to synchronize clients.</dd>
+
+<dt><tt>-b</tt></dt>
+
+<dd>Force the time to be stepped using the settimeofday() system
+call, rather than slewed (default) using the adjtime() system call.
+This option should be used when called from a startup file at boot
+time.</dd>
+
+<dt><tt>-d</tt></dt>
+
+<dd>Enable the debugging mode, in which <tt>ntpdate</tt> will go
+through all the steps, but not adjust the local clock. Information
+useful for general debugging will also be printed.</dd>
+
+<dt><tt>-e <i>authdelay</i></tt></dt>
+
+<dd>Specify the processing delay to perform an authentication
+function as the value <i>authdelay</i>, in seconds and fraction
+(see <tt>ntpd</tt> for details). This number is usually small
+enough to be negligible for most purposes, though specifying a
+value may improve timekeeping on very slow CPU's.</dd>
+
+<dt><tt>-k <i>keyfile</i></tt></dt>
+
+<dd>Specify the path for the authentication key file as the string
+<i>keyfile</i>. The default is <tt>/etc/ntp.keys</tt>. This file
+should be in the format described in <tt>ntpd</tt>.</dd>
+
+<dt><tt>-o <i>version</i></tt></dt>
+
+<dd>Specify the NTP version for outgoint packets as the integer <i>
+version</i>, which can be 1 or 2. The default is 3. This allows
+<tt>ntpdate</tt> to be used with older NTP versions.</dd>
+
+<dt><tt>-p <i>samples</i></tt></dt>
+
+<dd>Specify the number of samples to be acquired from each server
+as the integer <i>samples</i>, with values from 1 to 8 inclusive.
+The default is 4.</dd>
+
+<dt><i><tt>-q</tt></i></dt>
+
+<dd>Query only - don't set the clock.</dd>
+
+<dt><tt>-s</tt></dt>
+
+<dd>Divert logging output from the standard output (default) to the
+system <tt>syslog</tt> facility. This is designed primarily for
+convenience of <tt>cron</tt> scripts.</dd>
+
+<dt><tt>-t <i>timeout</i></tt></dt>
+
+<dd>Specify the maximum time waiting for a server response as the
+value <i>timeout</i>, in seconds and fraction. The value is is
+rounded to a multiple of 0.2 seconds. The default is 1 second, a
+value suitable for polling across a LAN.</dd>
+
+<dt><tt>-u</tt></dt>
+
+<dd>Direct <tt>ntpdate</tt> to use an unprivileged port or outgoing
+packets. This is most useful when behind a firewall that blocks
+incoming traffic to privileged ports, and you want to synchronise
+with hosts beyond the firewall. Note that the <tt>-d</tt> option
+always uses unprivileged ports.</dd>
+
+<dt><tt>-<i>v</i></tt></dt>
+
+<dd>Be verbose. This option will cause <tt>ntpdate</tt>'s version
+identification string to be logged.</dd>
+</dl>
+
+<h4>Files</h4>
+
+<tt>/etc/ntp.keys</tt> - encryption keys used by <tt>ntpdate</tt>.
+
+<h4>Bugs</h4>
+
+The slew adjustment is actually 50% larger than the measured
+offset, since this (it is argued) will tend to keep a badly
+drifting clock more accurate. This is probably not a good idea and
+may cause a troubling hunt for some values of the kernel variables
+<tt>tick</tt> and <tt>tickadj</tt>.
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
-<html><head><title>
-ntpdc - special NTP query program
-</title></head><body><h3>
-<tt>ntpdc</tt> - special NTP query program
-</h3>
-
-<img align=left src=pic/alice31.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>This program is a big puppy.
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntpdc - special NTP query program</title>
+</head>
+<body>
+<h3><tt>ntpdc</tt> - special NTP query program</h3>
+
+<img align="left" src="pic/alice31.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>This program is a big puppy.<br clear="left">
+</p>
+
+<hr>
<h4>Synopsis</h4>
-<tt>ntpdc [ -ilnps ] [ -c <i>command</i> ] [ <i>host</i> ] [ ... ]</tt>
+<tt>ntpdc [ -ilnps ] [ -c <i>command</i> ] [ <i>host</i> ] [ ...
+]</tt>
<h4>Description</h4>
-<tt>ntpdc</tt> is used to query the <tt>ntpd</tt> daemon about its current state and to request changes in that state. The program may be run either in interactive mode or controlled using command line arguments. Extensive state and statistics information is available through the <tt>ntpdc</tt> interface. In addition, nearly all the configuration options which can be specified at startup using ntpd's configuration file may also be specified at run time using <tt>ntpdc</tt>.
-
-<p>If one or more request options are included on the command line when <tt>ntpdc</tt> is executed, each of the requests will be sent to the NTP servers running on each of the hosts given as command line arguments, or on localhost by default. If no request options are given, <tt>ntpdc</tt> will attempt to read commands from the standard input and execute these on the NTP server running on the first host given on the command line, again defaulting to localhost when no other host is specified. <tt>ntpdc</tt> will prompt for commands if the standard input is a terminal device.
-
-<p><tt>ntpdc</tt> uses NTP mode 7 packets to communicate with the NTP server, and hence can be used to query any compatable server on the network which permits it. Note that since NTP is a UDP protocol this communication will be somewhat unreliable, especially over large distances in terms of network topology. <tt>ntpdc</tt> makes no attempt to retransmit requests, and will time requests out if the remote host is not heard from within a suitable timeout time.
-
-<p>The operation of <tt>ntpdc</tt> are specific to the particular implementation of the <tt>ntpd</tt> daemon and can be expected to work only with this and maybe some previous versions of the daemon. Requests from a remote <tt>ntpdc</tt> program which affect the state of the local server must be authenticated, which requires both the remote program and local server share a common key and key identifier.
+<tt>ntpdc</tt> is used to query the <tt>ntpd</tt> daemon about its
+current state and to request changes in that state. The program may
+be run either in interactive mode or controlled using command line
+arguments. Extensive state and statistics information is available
+through the <tt>ntpdc</tt> interface. In addition, nearly all the
+configuration options which can be specified at startup using
+ntpd's configuration file may also be specified at run time using
+<tt>ntpdc</tt>.
+
+<p>If one or more request options are included on the command line
+when <tt>ntpdc</tt> is executed, each of the requests will be sent
+to the NTP servers running on each of the hosts given as command
+line arguments, or on localhost by default. If no request options
+are given, <tt>ntpdc</tt> will attempt to read commands from the
+standard input and execute these on the NTP server running on the
+first host given on the command line, again defaulting to localhost
+when no other host is specified. <tt>ntpdc</tt> will prompt for
+commands if the standard input is a terminal device.</p>
+
+<p><tt>ntpdc</tt> uses NTP mode 7 packets to communicate with the
+NTP server, and hence can be used to query any compatable server on
+the network which permits it. Note that since NTP is a UDP protocol
+this communication will be somewhat unreliable, especially over
+large distances in terms of network topology. <tt>ntpdc</tt> makes
+no attempt to retransmit requests, and will time requests out if
+the remote host is not heard from within a suitable timeout
+time.</p>
+
+<p>The operation of <tt>ntpdc</tt> are specific to the particular
+implementation of the <tt>ntpd</tt> daemon and can be expected to
+work only with this and maybe some previous versions of the daemon.
+Requests from a remote <tt>ntpdc</tt> program which affect the
+state of the local server must be authenticated, which requires
+both the remote program and local server share a common key and key
+identifier.</p>
<h4>Command Line Options</h4>
-Specifying a command line option other than <tt>-i</tt> or <tt>-n</tt> will cause the specified query (queries) to be sent to the indicated host(s) immediately. Otherwise, <tt>ntpdc</tt> will attempt to read interactive format commands from the standard input.
+Specifying a command line option other than <tt>-i</tt> or <tt>
+-n</tt> will cause the specified query (queries) to be sent to the
+indicated host(s) immediately. Otherwise, <tt>ntpdc</tt> will
+attempt to read interactive format commands from the standard
+input.
<dl>
-
<dt><tt>-c <i>command</i></tt></dt>
-<dd>The following argument is interpreted as an interactive format command and is added to the list of commands to be executed on the specified host(s). Multiple -c options may be given.</dd>
+
+<dd>The following argument is interpreted as an interactive format
+command and is added to the list of commands to be executed on the
+specified host(s). Multiple -c options may be given.</dd>
<dt><tt>-i</tt></dt>
-<dd>Force <tt>ntpdc</tt> to operate in interactive mode. Prompts will be written to the standard output and commands read from the standard input.</dd>
+
+<dd>Force <tt>ntpdc</tt> to operate in interactive mode. Prompts
+will be written to the standard output and commands read from the
+standard input.</dd>
<dt><tt>-l</tt></dt>
-<dd>Obtain a list of peers which are known to the server(s). This switch is equivalent to <tt>-c listpeers</tt>.</dd>
+
+<dd>Obtain a list of peers which are known to the server(s). This
+switch is equivalent to <tt>-c listpeers</tt>.</dd>
<dt><tt>-n</tt></dt>
-<dd>Output all host addresses in dotted-quad numeric format rather than converting to the canonical host names.</dd>
+
+<dd>Output all host addresses in dotted-quad numeric format rather
+than converting to the canonical host names.</dd>
<dt><tt>-p</tt></dt>
-<dd>Print a list of the peers known to the server as well as a summary of their state. This is equivalent to <tt>-c peers</tt>.</dd>
+
+<dd>Print a list of the peers known to the server as well as a
+summary of their state. This is equivalent to <tt>-c
+peers</tt>.</dd>
<dt><tt>-s</tt></dt>
-<dd>Print a list of the peers known to the server as well as a summary of their state, but in a slightly different format than the -p switch. This is equivalent to <tt>-c dmpeers</tt>.</dd>
+<dd>Print a list of the peers known to the server as well as a
+summary of their state, but in a slightly different format than the
+-p switch. This is equivalent to <tt>-c dmpeers</tt>.</dd>
</dl>
<h4>Interactive Commands</h4>
-Interactive format commands consist of a keyword followed by zero to four arguments. Only enough characters of the full keyword to uniquely identify the command need be typed. The output of a command is normally sent to the standard output, but optionally the output of individual commands may be sent to a file by appending a <tt><</tt>, followed by a file name, to the command line.
+Interactive format commands consist of a keyword followed by zero
+to four arguments. Only enough characters of the full keyword to
+uniquely identify the command need be typed. The output of a
+command is normally sent to the standard output, but optionally the
+output of individual commands may be sent to a file by appending a
+<tt><</tt>, followed by a file name, to the command line.
-<p>A number of interactive format commands are executed entirely within the <tt>ntpdc</tt> program itself and do not result in NTP mode 7 requests being sent to a server. These are described following.
+<p>A number of interactive format commands are executed entirely
+within the <tt>ntpdc</tt> program itself and do not result in NTP
+mode 7 requests being sent to a server. These are described
+following.</p>
<dl>
+<dt><tt>? [ <i>command_keyword</i> ]</tt><br>
+<tt>help [ <i>command_keyword</i> ]</tt></dt>
-<dt><tt>? [ <i>command_keyword</i> ]</tt></dt>
-<BR><tt>helpl [ <i>command_keyword</i> ]</tt>
-<dd>A <tt>?</tt> by itself will print a list of all the command keywords known to this incarnation of <tt>ntpq</tt>. A <tt>?</tt> followed by a command keyword will print funcation and usage information about the command. This command is probably a better source of information about <tt>ntpq</tt> than this manual page.</dd>
+<dd>A <tt>?</tt> by itself will print a list of all the command
+keywords known to this incarnation of <tt>ntpq</tt>. A <tt>?</tt>
+followed by a command keyword will print funcation and usage
+information about the command. This command is probably a better
+source of information about <tt>ntpq</tt> than this manual
+page.</dd>
<dt><tt>delay <i>milliseconds</i></tt></dt>
-<dd>Specify a time interval to be added to timestamps included in requests which require authentication. This is used to enable (unreliable) server reconfiguration over long delay network paths or between machines whose clocks are unsynchronized. Actually the server does not now require timestamps in authenticated requests, so this command may be obsolete.</dd>
+
+<dd>Specify a time interval to be added to timestamps included in
+requests which require authentication. This is used to enable
+(unreliable) server reconfiguration over long delay network paths
+or between machines whose clocks are unsynchronized. Actually the
+server does not now require timestamps in authenticated requests,
+so this command may be obsolete.</dd>
<dt><tt>host <i>hostname</i></tt></dt>
-<dd>Set the host to which future queries will be sent. Hostname may be either a host name or a numeric address.</dd>
+
+<dd>Set the host to which future queries will be sent. Hostname may
+be either a host name or a numeric address.</dd>
<dt><tt>hostnames [ yes | no ]</tt></dt>
-<dd>If <tt>yes</tt> is specified, host names are printed in information displays. If <tt>no</tt> is specified, numeric addresses are printed instead. The default is <tt>yes</tt>, unless modified using the command line <tt>-n</tt> switch.</dd>
+
+<dd>If <tt>yes</tt> is specified, host names are printed in
+information displays. If <tt>no</tt> is specified, numeric
+addresses are printed instead. The default is <tt>yes</tt>, unless
+modified using the command line <tt>-n</tt> switch.</dd>
<dt><tt>keyid <i>keyid</i></tt></dt>
-<dd>This command allows the specification of a key number to be used to authenticate configuration requests. This must correspond to a key number the server has been configured to use for this purpose.</dd>
+
+<dd>This command allows the specification of a key number to be
+used to authenticate configuration requests. This must correspond
+to a key number the server has been configured to use for this
+purpose.</dd>
<dt><tt>quit</tt></dt>
+
<dd>Exit <tt>ntpdc</tt>.</dd>
<dt><tt>passwd</tt></dt>
-<dd>This command prompts you to type in a password (which will not be echoed) which will be used to authenticate configuration requests. The password must correspond to the key configured for use by the NTP server for this purpose if such requests are to be successful.</dd>
+
+<dd>This command prompts you to type in a password (which will not
+be echoed) which will be used to authenticate configuration
+requests. The password must correspond to the key configured for
+use by the NTP server for this purpose if such requests are to be
+successful.</dd>
<dt><tt>timeout <i>millseconds</i></tt></dt>
-<dd>Specify a timeout period for responses to server queries. The default is about 8000 milliseconds. Note that since <tt>ntpdc</tt> retries each query once after a timeout, the total waiting time for a timeout will be twice the timeout value set.</dd>
+<dd>Specify a timeout period for responses to server queries. The
+default is about 8000 milliseconds. Note that since <tt>ntpdc</tt>
+retries each query once after a timeout, the total waiting time for
+a timeout will be twice the timeout value set.</dd>
</dl>
<h4>Control Message Commands</h4>
-Query commands result in NTP mode 7 packets containing requests for information being sent to the server. These are read-only commands in that they make no modification of the server configuration state.
+Query commands result in NTP mode 7 packets containing requests for
+information being sent to the server. These are read-only commands
+in that they make no modification of the server configuration
+state.
<dl>
-
<dt><tt>listpeers</tt></dt>
-<dd>Obtains and prints a brief list of the peers for which the server is maintaining state. These should include all configured peer associations as well as those peers whose stratum is such that they are considered by the server to be possible future synchonization candidates.</dd>
+
+<dd>Obtains and prints a brief list of the peers for which the
+server is maintaining state. These should include all configured
+peer associations as well as those peers whose stratum is such that
+they are considered by the server to be possible future
+synchonization candidates.</dd>
<dt><tt>peers</tt></dt>
-<dd>Obtains a list of peers for which the server is maintaining state, along with a summary of that state. Summary information includes the address of the remote peer, the local interface address (0.0.0.0 if a local address has yet to be determined), the stratum of the remote peer (a stratum of 16 indicates the remote peer is unsynchronized), the polling interval, in seconds, the reachability register, in octal, and the current estimated delay, offset and dispersion of the peer, all in seconds. In addition, the character in the left margin indicates the mode this peer entry is operating in. A <tt>+</tt> denotes symmetric active, a <tt>-</tt> indicates symmetric passive, a <tt>=</tt> means the remote server is being polled in client mode, a <tt>^</tt> indicates that the server is broadcasting to this address, a <tt>~</tt> denotes that the remote peer is sending broadcasts and a <tt>*</tt> marks the peer the server is currently synchonizing to.</dd>
-<p>The contents of the host field may be one of four forms. It may be a host name, an IP address, a reference clock implementation name with its parameter or <tt>REFCLK(<i>implementation number</i>, <i>parameter</i>)</tt>. On <tt>hostnames no</tt> only IP-addresses will be displayed.
+<dd>Obtains a list of peers for which the server is maintaining
+state, along with a summary of that state. Summary information
+includes the address of the remote peer, the local interface
+address (0.0.0.0 if a local address has yet to be determined), the
+stratum of the remote peer (a stratum of 16 indicates the remote
+peer is unsynchronized), the polling interval, in seconds, the
+reachability register, in octal, and the current estimated delay,
+offset and dispersion of the peer, all in seconds.
+
+<p>The character in the left margin indicates the mode this peer
+entry is operating in. A <tt>+</tt> denotes symmetric active, a
+<tt>-</tt> indicates symmetric passive, a <tt>=</tt> means the
+remote server is being polled in client mode, a <tt>^</tt>
+indicates that the server is broadcasting to this address, a <tt>
+~</tt> denotes that the remote peer is sending broadcasts and a
+<tt>*</tt> marks the peer the server is currently synchonizing
+to.</p>
+
+<p>The contents of the host field may be one of four forms. It may
+be a host name, an IP address, a reference clock implementation
+name with its parameter or <tt>REFCLK(<i>implementation number</i>,
+<i>parameter</i>)</tt>. On <tt>hostnames no</tt> only IP-addresses
+will be displayed.</p>
+</dd>
<dt><tt>dmpeers</tt></dt>
-<dd>A slightly different peer summary list. Identical to the output of the <tt>peers</tt> command, except for the character in the leftmost column. Characters only appear beside peers which were included in the final stage of the clock selection algorithm. A <tt>.</tt> indicates that this peer was cast off in the falseticker detection, while a <tt>+</tt> indicates that the peer made it through. A <tt>*</tt> denotes the peer the server is currently synchronizing with.</dd>
-<dt><tt>showpeer <i>peer_address</i> [...]</tt></dt>
-<dd>Shows a detailed display of the current peer variables for one or more peers. Most of these values are described in the NTP Version 2 specification.</dd>
+<dd>A slightly different peer summary list. Identical to the output
+of the <tt>peers</tt> command, except for the character in the
+leftmost column. Characters only appear beside peers which were
+included in the final stage of the clock selection algorithm. A
+<tt>.</tt> indicates that this peer was cast off in the falseticker
+detection, while a <tt>+</tt> indicates that the peer made it
+through. A <tt>*</tt> denotes the peer the server is currently
+synchronizing with.</dd>
-<dt><tt>pstats <i>peer_address</i> [...]</tt></dt>
-<dd>Show per-peer statistic counters associated with the specified peer(s).</dd>
+<dt><tt>showpeer <i>peer_address</i> [...]</tt></dt>
-<dt><tt>clockinfo <i>clock_peer_address</i> [...]</tt></dt>
-<dd>Obtain and print information concerning a peer clock. The values obtained provide information on the setting of fudge factors and other clock performance information.</dd>
+<dd>Shows a detailed display of the current peer variables for one
+or more peers. Most of these values are described in the NTP
+Version 2 specification.</dd>
-<dt>
-<tt>kerninfo</tt></dt>
+<dt><tt>pstats <i>peer_address</i> [...]</tt></dt>
-<dd>
-Obtain and print kernel phase-lock loop operating parameters. This information
-is available only if the kernel has been specially modified for a precision
-timekeeping function.</dd>
+<dd>Show per-peer statistic counters associated with the specified
+peer(s).</dd>
-<dt><tt>loopinfo [ oneline | multiline ]</tt></dt>
-<dd>Print the values of selected loop filter variables. The loop filter is the part of NTP which deals with adjusting the local system clock. The <tt>offset</tt> is the last offset given to the loop filter by the packet processing code. The <tt>frequency</tt> is the frequency error of the local clock in parts-per-million (ppm). The <tt>time_const</tt> controls the stiffness of the phase-lock loop and thus the speed at which it can adapt to oscillator drift. The <tt>watchdog timer</tt> value is the number of seconds which have elapsed since the last sample offset was given to the loop filter. The <tt>oneline</tt> and <tt>multiline</tt> options specify the format in which this information is to be printed, with <tt>multiline</tt> as the default.</dd>
+<dt><tt>clockinfo <i>clock_peer_address</i> [...]</tt></dt>
-<dt><tt>sysinfo</tt></dt>
-<dd>Print a variety of system state variables, i.e., state related to the local server. All except the last four lines are described in the NTP Version 3 specification, RFC-1305.</dd>
+<dd>Obtain and print information concerning a peer clock. The
+values obtained provide information on the setting of fudge factors
+and other clock performance information.</dd>
-<dl>
+<dt><tt>kerninfo</tt></dt>
-<dd>The <tt>system flags</tt> show various system flags, some of which can be set and cleared by the <tt>enable</tt> and <tt>disable</tt> configuration commands, respectively. These are the <tt>auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>, <tt>pps</tt> and <tt>stats</tt> flags. See the <tt>ntpd</tt> documentation for the meaning of these flags. There are two additional flags which are read only, the <tt>kernel_pll</tt> and <tt>kernel_pps</tt>. These flags indicate the synchronization status when the precision time kernel modifications are in use. The <tt>kernel_pll</tt> indicates that the local clock is being disciplined by the kernel, while the kernel_pps indicates the kernel discipline is provided by the PPS signal.</dd>
+<dd>Obtain and print kernel phase-lock loop operating parameters.
+This information is available only if the kernel has been specially
+modified for a precision timekeeping function.</dd>
-<dd>The <tt>stability</tt> is the residual frequency error remaining afterthe system frequency correction is applied and is intended for maintenance and debugging. In most architectures, this value will initially decrease from as high as 500 ppm to a nominal value in the range .01 to 0.1 ppm. If it remains high for some time after starting the daemon, something may be wrong with the local clock, or the value of the kernel variable <tt>tick</tt> may be incorrect.</dd>
+<dt><tt>loopinfo [ oneline | multiline ]</tt></dt>
-<dd>The <tt>broadcastdelay</tt> shows the default broadcast delay, as set by the <tt>broadcastdelay</tt> configuration command.</dd>
+<dd>Print the values of selected loop filter variables. The loop
+filter is the part of NTP which deals with adjusting the local
+system clock. The <tt>offset</tt> is the last offset given to the
+loop filter by the packet processing code. The <tt>frequency</tt>
+is the frequency error of the local clock in parts-per-million
+(ppm). The <tt>time_const</tt> controls the stiffness of the
+phase-lock loop and thus the speed at which it can adapt to
+oscillator drift. The <tt>watchdog timer</tt> value is the number
+of seconds which have elapsed since the last sample offset was
+given to the loop filter. The <tt>oneline</tt> and <tt>
+multiline</tt> options specify the format in which this information
+is to be printed, with <tt>multiline</tt> as the default.</dd>
-<dd>The <tt>authdelay</tt> shows the default authentication delay, as set by the <tt>authdelay</tt> configuration command.</dd>
+<dt><tt>sysinfo</tt></dt>
-</dl>
+<dd>Print a variety of system state variables, i.e., state related
+to the local server. All except the last four lines are described
+in the NTP Version 3 specification, RFC-1305.
+
+<p>The <tt>system flags</tt> show various system flags, some of
+which can be set and cleared by the <tt>enable</tt> and <tt>
+disable</tt> configuration commands, respectively. These are the
+<tt>auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>,
+<tt>pps</tt> and <tt>stats</tt> flags. See the <tt>ntpd</tt>
+documentation for the meaning of these flags. There are two
+additional flags which are read only, the <tt>kernel_pll</tt> and
+<tt>kernel_pps</tt>. These flags indicate the synchronization
+status when the precision time kernel modifications are in use. The
+<tt>kernel_pll</tt> indicates that the local clock is being
+disciplined by the kernel, while the kernel_pps indicates the
+kernel discipline is provided by the PPS signal.</p>
+
+<p>The <tt>stability</tt> is the residual frequency error remaining
+afterthe system frequency correction is applied and is intended for
+maintenance and debugging. In most architectures, this value will
+initially decrease from as high as 500 ppm to a nominal value in
+the range .01 to 0.1 ppm. If it remains high for some time after
+starting the daemon, something may be wrong with the local clock,
+or the value of the kernel variable <tt>tick</tt> may be
+incorrect.</p>
+
+<p>The <tt>broadcastdelay</tt> shows the default broadcast delay,
+as set by the <tt>broadcastdelay</tt> configuration command.</p>
+
+<p>The <tt>authdelay</tt> shows the default authentication delay,
+as set by the <tt>authdelay</tt> configuration command.</p>
+</dd>
<dt><tt>sysstats</tt></dt>
-<dd>Print statistics counters maintained in the protocol module.</dd>
+
+<dd>Print statistics counters maintained in the protocol
+module.</dd>
<dt><tt>memstats</tt></dt>
-<dd>Print statistics counters related to memory allocation code.</dd>
+
+<dd>Print statistics counters related to memory allocation
+code.</dd>
<dt><tt>iostats</tt></dt>
-<dd>Print statistics counters maintained in the input-output module.</dd>
+
+<dd>Print statistics counters maintained in the input-output
+module.</dd>
<dt><tt>timerstats</tt></dt>
-<dd>Print statistics counters maintained in the timer/event queue support code.</dd>
+
+<dd>Print statistics counters maintained in the timer/event queue
+support code.</dd>
<dt><tt>reslist</tt></dt>
-<dd>Obtain and print the server's restriction list. This list is (usually) printed in sorted order and may help to understand how the restrictions are applied.</dd>
+
+<dd>Obtain and print the server's restriction list. This list is
+(usually) printed in sorted order and may help to understand how
+the restrictions are applied.</dd>
<dt><tt>monlist [ <i>version</i> ]</tt></dt>
-<dd>Obtain and print traffic counts collected and maintained by the monitor facility. The version number should not normally need to be specified.</dd>
+
+<dd>Obtain and print traffic counts collected and maintained by the
+monitor facility. The version number should not normally need to be
+specified.</dd>
<dt><tt>clkbug <i>clock_peer_address</i> [...]</tt></dt>
-<dd>Obtain debugging information for a reference clock driver. This information is provided only by some clock drivers and is mostly undecodable without a copy of the driver source in hand.</dd>
+<dd>Obtain debugging information for a reference clock driver. This
+information is provided only by some clock drivers and is mostly
+undecodable without a copy of the driver source in hand.</dd>
</dl>
<h4>Runtime Configuration Requests</h4>
-All requests which cause state changes in the server are authenticated by the server using a configured NTP key (the facility can also be disabled by the server by not configuring a key). The key number and the corresponding key must also be made known to xtnpdc. This can be done using the keyid and passwd commands, the latter of which will prompt at the terminal for a password to use as the encryption key. You will also be prompted automatically for both the key number and password the first time a command which would result in an authenticated request to the server is given. Authentication not only provides verification that the requester has permission to make such changes, but also gives an extra degree of protection again transmission errors.
-
-<p>Authenticated requests always include a timestamp in the packet data, which is included in the computation of the authentication code. This timestamp is compared by the server to its receive time stamp. If they differ by more than a small amount the request is rejected. This is done for two reasons. First, it makes simple replay attacks on the server, by someone who might be able to overhear traffic on your LAN, much more difficult. Second, it makes it more difficult to request configuration changes to your server from topologically remote hosts. While the reconfiguration facility will work well with a server on the local host, and may work adequately between time-synchronized hosts on the same LAN, it will work very poorly for more distant hosts. As such, if reasonable passwords are chosen, care is taken in the distribution and protection of keys and appropriate source address restrictions are applied, the run time reconfiguration facility should provide an adequate level of security.
-
-<p>The following commands all make authenticated requests.
+All requests which cause state changes in the server are
+authenticated by the server using a configured NTP key (the
+facility can also be disabled by the server by not configuring a
+key). The key number and the corresponding key must also be made
+known to xtnpdc. This can be done using the keyid and passwd
+commands, the latter of which will prompt at the terminal for a
+password to use as the encryption key. You will also be prompted
+automatically for both the key number and password the first time a
+command which would result in an authenticated request to the
+server is given. Authentication not only provides verification that
+the requester has permission to make such changes, but also gives
+an extra degree of protection again transmission errors.
+
+<p>Authenticated requests always include a timestamp in the packet
+data, which is included in the computation of the authentication
+code. This timestamp is compared by the server to its receive time
+stamp. If they differ by more than a small amount the request is
+rejected. This is done for two reasons. First, it makes simple
+replay attacks on the server, by someone who might be able to
+overhear traffic on your LAN, much more difficult. Second, it makes
+it more difficult to request configuration changes to your server
+from topologically remote hosts. While the reconfiguration facility
+will work well with a server on the local host, and may work
+adequately between time-synchronized hosts on the same LAN, it will
+work very poorly for more distant hosts. As such, if reasonable
+passwords are chosen, care is taken in the distribution and
+protection of keys and appropriate source address restrictions are
+applied, the run time reconfiguration facility should provide an
+adequate level of security.</p>
+
+<p>The following commands all make authenticated requests.</p>
<dl>
+<dt><tt>addpeer <i>peer_address</i> [ <i>keyid</i> ] [ <i>
+version</i> ] [ <i>prefer</i> ]</tt></dt>
+
+<dd>Add a configured peer association at the given address and
+operating in symmetric active mode. Note that an existing
+association with the same peer may be deleted when this command is
+executed, or may simply be converted to conform to the new
+configuration, as appropriate. If the optional <tt>keyid</tt> is a
+nonzero integer, all outgoing packets to the remote server will
+have an authentication field attached encrypted with this key. If
+the value is 0 (or not given) no authentication will be done. The
+<tt>version#</tt> can be 1, 2 or 3 and defaults to 3. The <tt>
+prefer</tt> keyword indicates a preferred peer (and thus will be
+used primarily for clock synchronisation if possible). The
+preferred peer also determines the validity of the PPS signal - if
+the preferred peer is suitable for synchronisation so is the PPS
+signal.</dd>
+
+<dt><tt>addserver <i>peer_address</i> [ <i>keyid</i> ] [ <i>
+version</i> ] [ <i>prefer</i> ]</tt></dt>
+
+<dd>Identical to the addpeer command, except that the operating
+mode is client.</dd>
+
+<dt><tt>broadcast <i>peer_address</i> [ <i>keyid</i> ] [ <i>
+version</i> ] [ <i>prefer</i> ]</tt></dt>
+
+<dd>Identical to the addpeer command, except that the operating
+mode is broadcast. In this case a valid key identifier and key are
+required. The <tt>peer_address</tt> parameter can be the broadcast
+address of the local network or a multicast group address assigned
+to NTP. If a multicast address, a multicast-capable kernel is
+required.</dd>
-<dt><tt>addpeer <i>peer_address</i> [ <i>keyid</i> ] [ <i>version</i> ] [ <i>prefer</i> ]</tt></dt>
-
-<dd>Add a configured peer association at the given address and operating in symmetric active mode. Note that an existing association with the same peer may be deleted when this command is executed, or may simply be converted to conform to the new configuration, as appropriate. If the optional <tt>keyid</tt> is a nonzero integer, all outgoing packets to the remote server will have an authentication field attached encrypted with this key. If the value is 0 (or not given) no authentication will be done. The <tt>version#</tt> can be 1, 2 or 3 and defaults to 3. The <tt>prefer</tt> keyword indicates a preferred peer (and thus will be used primarily for clock synchronisation if possible). The preferred peer also determines the validity of the PPS signal - if the preferred peer is suitable for synchronisation so is the PPS signal.</dd>
-
-<dt><tt>addserver <i>peer_address</i> [ <i>keyid</i> ] [ <i>version</i> ] [ <i>prefer</i> ]</tt></dt>
-
-<dd>Identical to the addpeer command, except that the operating mode is client.</dd>
-
-<dt><tt>broadcast <i>peer_address</i> [ <i>keyid</i> ] [ <i>version</i> ] [ <i>prefer</i> ]</tt></dt>
+<dt><tt>unconfig <i>peer_address</i> [...]</tt></dt>
-<dd>Identical to the addpeer command, except that the operating mode is broadcast. In this case a valid key identifier and key are required. The <tt>peer_address</tt> parameter can be the broadcast address of the local network or a multicast group address assigned to NTP. If a multicast address, a multicast-capable kernel is required.</dd>
+<dd>This command causes the configured bit to be removed from the
+specified peer(s). In many cases this will cause the peer
+association to be deleted. When appropriate, however, the
+association may persist in an unconfigured mode if the remote peer
+is willing to continue on in this fashion.</dd>
-<dt><tt>unconfig <i>peer_address</i> [...]</tt></dt>
-<dd>This command causes the configured bit to be removed from the specified peer(s). In many cases this will cause the peer association to be deleted. When appropriate, however, the association may persist in an unconfigured mode if the remote peer is willing to continue on in this fashion.</dd>
+<dt><tt>fudge <i>peer_address</i> [ <i>time1</i> ] [ <i>time2</i> ]
+[ <i>stratum</i> ] [ <i>refid</i> ]</tt></dt>
-<dt><tt>fudge <i>peer_address</i> [ <i>time1</i> ] [ <i>time2</i> ] [ <i>stratum</i> ] [ <i>refid</i> ]</tt></dt>
+<dd>This command provides a way to set certain data for a reference
+clock. See the source listing for further information.</dd>
-<dd>This command provides a way to set certain data for a reference clock. See the source listing for further information.</dd>
+<dt><tt>enable [ <i>flag</i> ] [ ... ]</tt><br>
+<tt>disable [ <i>flag</i> ] [ ... ]</tt></dt>
-<dt><tt>enable [ <i>flag</i> ] [ ... ]</tt></dt>
-<BR><tt>disable [ <i>flag</i> ] [ ... ]</tt>
-<dd>These commands operate in the same way as the <tt>enable</tt> and <tt>disable</tt> configuration file commands of <tt>ntpd</tt>. Following is a description of the flags. Note that only the <tt>auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>, <tt>pps</tt> and <tt>stats</tt> flags can be set by <tt>ntpdc</tt>; the <tt>pll_kernel</tt> and <tt>pps_kernel</tt> flags are read-only.</dd>
+<dd>These commands operate in the same way as the <tt>enable</tt>
+and <tt>disable</tt> configuration file commands of <tt>ntpd</tt>.
+Following is a description of the flags. Note that only the <tt>
+auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>, <tt>
+pps</tt> and <tt>stats</tt> flags can be set by <tt>ntpdc</tt>; the
+<tt>pll_kernel</tt> and <tt>pps_kernel</tt> flags are
+read-only.</dd>
+<dd>
<dl>
-
<dt><tt>auth</tt></dt>
-<dd>Enables the server to synchronize with unconfigured peers only if the peer has been correctly authenticated using a trusted key and key identifier. The default for this flag is enable.</dd>
+
+<dd>Enables the server to synchronize with unconfigured peers only
+if the peer has been correctly authenticated using a trusted key
+and key identifier. The default for this flag is enable.</dd>
<dt><tt>bclient</tt></dt>
-<dd>Enables the server to listen for a message from a broadcast or multicast server, as in the <tt>multicastclient</tt> command with default address. The default for this flag is disable.</dd>
+
+<dd>Enables the server to listen for a message from a broadcast or
+multicast server, as in the <tt>multicastclient</tt> command with
+default address. The default for this flag is disable.</dd>
<dt><tt>monitor</tt></dt>
-<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program and the <tt>monlist</tt> command or further information. The default for this flag is enable.</dd>
+
+<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program
+and the <tt>monlist</tt> command or further information. The
+default for this flag is enable.</dd>
<dt><tt>pll</tt></dt>
-<dd>Enables the server to adjust its local clock by means of NTP. If disabled, the local clock free-runs at its intrinsic time and frequency offset. This flag is useful in case the local clock is controlled by some other device or protocol and NTP is used only to provide synchronization to other clients. In this case, the local clock driver is used. See the <A HREF="refclock.htm">Reference Clock Drivers </A>page for further information. The default for this flag is enable.</dd>
+
+<dd>Enables the server to adjust its local clock by means of NTP.
+If disabled, the local clock free-runs at its intrinsic time and
+frequency offset. This flag is useful in case the local clock is
+controlled by some other device or protocol and NTP is used only to
+provide synchronization to other clients. In this case, the local
+clock driver is used. See the <a href="refclock.htm">Reference
+Clock Drivers</a> page for further information. The default for
+this flag is enable.</dd>
<dt><tt>pps</tt></dt>
-<dd>Enables the pulse-per-second (PPS) signal when frequency and time is disciplined by the precision time kernel modifications. See the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping </A>page for further information. The default for this flag is disable.</dd>
+
+<dd>Enables the pulse-per-second (PPS) signal when frequency and
+time is disciplined by the precision time kernel modifications. See
+the <a href="kern.htm">A Kernel Model for Precision Timekeeping</a>
+page for further information. The default for this flag is
+disable.</dd>
<dt><tt>stats</tt></dt>
-<dd>Enables the statistics facility. See the <A HREF="monopt.htm">Monitoring Options </A>page for further information. The default for this flag is enable.</dd>
+
+<dd>Enables the statistics facility. See the <a href="monopt.htm">
+Monitoring Options</a> page for further information. The default
+for this flag is enable.</dd>
<dt><tt>pll_kernel</tt></dt>
-<dd>When the precision time kernel modifications are installed, this indicates the kernel controls the clock discipline; otherwise, the daemon controls the clock discipline.</dd>
+
+<dd>When the precision time kernel modifications are installed,
+this indicates the kernel controls the clock discipline; otherwise,
+the daemon controls the clock discipline.</dd>
<dt><tt>pps_kernel</tt></dt>
-<dd>When the precision time kernel modifications are installed and a pulse-per-second (PPS) signal is available, this indicates the PPS signal controls the clock discipline; otherwise, the daemon or kernel controls the clock discipline, as indicated by the <tt>pll_kernel</tt> flag.</dd>
+<dd>When the precision time kernel modifications are installed and
+a pulse-per-second (PPS) signal is available, this indicates the
+PPS signal controls the clock discipline; otherwise, the daemon or
+kernel controls the clock discipline, as indicated by the <tt>
+pll_kernel</tt> flag.</dd>
</dl>
+</dd>
<dt><tt>restrict <i>address mask flag</i> [ <i>flag</i> ]</tt></dt>
-<dd>This command operates in the same way as the <tt>restrict</tt> configuration file commands of <tt>ntpd</tt>.</dd>
-<dt><tt>unrestrict <i>address mask flag</i> [ <i>flag</i> ]</tt></dt>
+<dd>This command operates in the same way as the <tt>restrict</tt>
+configuration file commands of <tt>ntpd</tt>.</dd>
+
+<dt><tt>unrestrict <i>address mask flag</i> [ <i>flag</i>
+]</tt></dt>
+
<dd>Unrestrict the matching entry from the restrict list.</dd>
<dt><tt>delrestrict <i>address mask [ ntpport ]</i></tt></dt>
+
<dd>Delete the matching entry from the restrict list.</dd>
<dt><tt>readkeys</tt></dt>
-<dd>Causes the current set of authentication keys to be purged and a new set to be obtained by rereading the keys file (which must have been specified in the <tt>ntpd</tt> configuration file). This allows encryption keys to be changed without restarting the server.</dd>
+
+<dd>Causes the current set of authentication keys to be purged and
+a new set to be obtained by rereading the keys file (which must
+have been specified in the <tt>ntpd</tt> configuration file). This
+allows encryption keys to be changed without restarting the
+server.</dd>
<dt><tt>trustedkey <i>keyid</i> [...]</tt></dt>
+
<dt><tt>untrustedkey <i>keyid</i> [...]</tt></dt>
-<dd>These commands operate in the same way as the <tt>trustedkey</tt> and <tt>untrustedkey</tt> configuration file commands of <tt>ntpd</tt>.</dd>
+
+<dd>These commands operate in the same way as the <tt>
+trustedkey</tt> and <tt>untrustedkey</tt> configuration file
+commands of <tt>ntpd</tt>.</dd>
<dt><tt>authinfo</tt></dt>
-<dd>Returns information concerning the authentication module, including known keys and counts of encryptions and decryptions which have been done.</dd>
+
+<dd>Returns information concerning the authentication module,
+including known keys and counts of encryptions and decryptions
+which have been done.</dd>
<dt><tt>traps</tt></dt>
-<dd>Display the traps set in the server. See the source listing for further information.</dd>
-<dt><tt>addtrap [ <i>address</i> [ <i>port</i> ] [ <i>interface</i> ]</tt></dt>
-<dd>Set a trap for asynchronous messages. See the source listing for further information.</dd>
+<dd>Display the traps set in the server. See the source listing for
+further information.</dd>
-<dt><tt>clrtrap [ <i>address</i> [ <i>port</i> ] [ <i>interface</i>]</tt></dt>
-<dd>Clear a trap for asynchronous messages. See the source listing for further information.</dd>
+<dt><tt>addtrap [ <i>address</i> [ <i>port</i> ] [ <i>interface</i>
+]</tt></dt>
+
+<dd>Set a trap for asynchronous messages. See the source listing
+for further information.</dd>
+
+<dt><tt>clrtrap [ <i>address</i> [ <i>port</i> ] [ <i>
+interface</i>]</tt></dt>
+
+<dd>Clear a trap for asynchronous messages. See the source listing
+for further information.</dd>
<dt><tt>reset</tt></dt>
-<dd>Clear the statistics counters in various modules of the server. See the source listing for further information.</dd>
+<dd>Clear the statistics counters in various modules of the server.
+See the source listing for further information.</dd>
</dl>
<h4>Bugs</h4>
-<tt>ntpdc</tt> is a crude hack. Much of the information it shows is deadly boring and could only be loved by its implementer. The program was designed so that new (and temporary) features were easy to hack in, at great expense to the program's ease of use. Despite this, the program is occasionally useful.
+<tt>ntpdc</tt> is a crude hack. Much of the information it shows is
+deadly boring and could only be loved by its implementer. The
+program was designed so that new (and temporary) features were easy
+to hack in, at great expense to the program's ease of use. Despite
+this, the program is occasionally useful.
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
-<html><head><title>
-ntpq - standard NTP query program
-</title></head><body><h3>
-<tt>ntpq</tt> - standard NTP query program
-</h3>
-
-<img align=left src=pic/bustardfly.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
-
-<p>A typical NTP monitoring packet.
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntpq - standard NTP query program</title>
+</head>
+<body>
+<h3><tt>ntpq</tt> - standard NTP query program</h3>
+
+<img align="left" src="pic/bustardfly.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
+Walt Kelly</a>
+
+<p>A typical NTP monitoring packet.<br clear="left">
+</p>
+
+<hr>
<h4>Synopsis</h4>
-<tt>ntpq [-inp] [-c <i>command</i>] [<i>host</i>] [...]</tt>
+<tt>ntpq [-inp] [-c <i>command</i>] [<i>host</i>] [...]</tt>
<h4>Description</h4>
-The <tt>ntpq</tt> utility program is used to query NTP servers which
-implement the recommended NTP mode 6 control message format about
-current state and to request changes in that state. The program may be
-run either in interactive mode or controlled using command line
-arguments. Requests to read and write arbitrary variables can be
-assembled, with raw and pretty-printed output options being available.
-<tt>ntpq</tt> can also obtain and print a list of peers in a common
-format by sending multiple queries to the server.
-
-<p>If one or more request options is included on the command line when
-<tt>ntpq</tt> is executed, each of the requests will be sent to the NTP
-servers running on each of the hosts given as command line arguments, or
-on localhost by default. If no request options are given, <tt>ntpq</tt>
-will attempt to read commands from the standard input and execute these
-on the NTP server running on the first host given on the command line,
-again defaulting to localhost when no other host is specified.
-<tt>ntpq</tt>will prompt for commands if the standard input is a
-terminal device.
-
-<p><tt>ntpq</tt> uses NTP mode 6 packets to communicate with the NTP
-server, and hence can be used to query any compatible server on the
-network which permits it. Note that since NTP is a UDP protocol this
-communication will be somewhat unreliable, especially over large
-distances in terms of network topology. <tt>ntpq</tt> makes one attempt
-to retransmit requests, and will time requests out if the remote host is
-not heard from within a suitable
-timeout time.
-
-<p>For examples and usage, see the <a href=debug.htm>NTP Debugging
-Techniques</a> page.
-
-<p>Command line options are described following. Specifying a command
-line option other than <tt>-i</tt> or <tt>-n</tt> will cause the
-specified query (queries) to be sent to the indicated host(s)
-immediately. Otherwise, <tt>ntpq</tt> will attempt to read interactive
-format commands from the standard input.
+The <tt>ntpq</tt> utility program is used to query NTP servers
+which implement the recommended NTP mode 6 control message format
+about current state and to request changes in that state. The
+program may be run either in interactive mode or controlled using
+command line arguments. Requests to read and write arbitrary
+variables can be assembled, with raw and pretty-printed output
+options being available. <tt>ntpq</tt> can also obtain and print a
+list of peers in a common format by sending multiple queries to the
+server.
+
+<p>If one or more request options is included on the command line
+when <tt>ntpq</tt> is executed, each of the requests will be sent
+to the NTP servers running on each of the hosts given as command
+line arguments, or on localhost by default. If no request options
+are given, <tt>ntpq</tt> will attempt to read commands from the
+standard input and execute these on the NTP server running on the
+first host given on the command line, again defaulting to localhost
+when no other host is specified. <tt>ntpq</tt>will prompt for
+commands if the standard input is a terminal device.</p>
+
+<p><tt>ntpq</tt> uses NTP mode 6 packets to communicate with the
+NTP server, and hence can be used to query any compatible server on
+the network which permits it. Note that since NTP is a UDP protocol
+this communication will be somewhat unreliable, especially over
+large distances in terms of network topology. <tt>ntpq</tt> makes
+one attempt to retransmit requests, and will time requests out if
+the remote host is not heard from within a suitable timeout
+time.</p>
+
+<p>For examples and usage, see the <a href="debug.htm">NTP
+Debugging Techniques</a> page.</p>
+
+<p>Command line options are described following. Specifying a
+command line option other than <tt>-i</tt> or <tt>-n</tt> will
+cause the specified query (queries) to be sent to the indicated
+host(s) immediately. Otherwise, <tt>ntpq</tt> will attempt to read
+interactive format commands from the standard input.</p>
<dl>
-
<dt><tt>-c</tt></dt>
+
<dd>The following argument is interpreted as an interactive format
command and is added to the list of commands to be executed on the
specified host(s). Multiple <tt>-c</tt> options may be given.</dd>
<dt><tt>-i</tt></dt>
-<dd>Force <tt>ntpq</tt> to operate in interactive mode. Prompts will be
-written to the standard output and commands read from the standard
-input.</dd>
+
+<dd>Force <tt>ntpq</tt> to operate in interactive mode. Prompts
+will be written to the standard output and commands read from the
+standard input.</dd>
<dt><tt>-n</tt></dt>
-<dd>Output all host addresses in dotted-quad numeric format rather than
-converting to the canonical host names.</dd>
+
+<dd>Output all host addresses in dotted-quad numeric format rather
+than converting to the canonical host names.</dd>
+
<dt><tt>-p</tt></dt>
-<dd>Print a list of the peers known to the server as well as a summary
-of their state. This is equivalent to the <tt>peers</tt> interactive
-command.</dd>
+<dd>Print a list of the peers known to the server as well as a
+summary of their state. This is equivalent to the <tt>peers</tt>
+interactive command.</dd>
</dl>
<h4>Internal Commands</h4>
-Interactive format commands consist of a keyword followed by zero to
-four arguments. Only enough characters of the full keyword to uniquely
-identify the command need be typed. The output of a command is normally
-sent to the standard output, but optionally the output of individual
-commands may be sent to a file by appending a <tt><</tt>, followed by
-a file name, to the command line. A number of interactive format
-commands are executed entirely within the <tt>ntpq</tt> program itself
-and do not result in NTP mode 6 requests being sent to a server. These
-are described following.
+Interactive format commands consist of a keyword followed by zero
+to four arguments. Only enough characters of the full keyword to
+uniquely identify the command need be typed. The output of a
+command is normally sent to the standard output, but optionally the
+output of individual commands may be sent to a file by appending a
+<tt><</tt>, followed by a file name, to the command line. A
+number of interactive format commands are executed entirely within
+the <tt>ntpq</tt> program itself and do not result in NTP mode 6
+requests being sent to a server. These are described following.
<dl>
-
-<dt><tt>? [<i>command_keyword</i>]</tt></dt>
-<BR><tt>helpl [<i>command_keyword</i>]</tt>
-<dd>A <tt>?</tt> by itself will print a list of all the command keywords
-known to this incarnation of <tt>ntpq</tt>. A <tt>?</tt> followed by a
-command keyword will print function and usage information about the
-command. This command is probably a better source of information about
-<tt>ntpq</tt> than this manual page.</dd>
-
-<dt><tt>addvars <i>variable_name</i> [ = <i>value</i>] [...]</tt></dt>
-<BR><tt>rmvars <i>variable_name</i> [...]</tt>
-<BR><tt>clearvars</tt>
-<dd>The data carried by NTP mode 6 messages consists of a list of items
-of the form <tt><i>variable_name</i> = <i>value</i></tt>, where the <tt>
-= <i>value</i></tt> is ignored, and can be omitted, in requests to the
-server to read variables. <tt>ntpq</tt> maintains an internal list in
-which data to be included in control messages can be assembled, and sent
-using the <tt>readlist</tt> and <tt>writelist</tt> commands described
-below. The <tt>addvars</tt> command allows variables and their optional
-values to be added to the list. If more than one variable is to be
-added, the list should be comma-separated and not contain white space.
-The <tt>rmvars</tt> command can be used to remove individual variables
-from the list, while the <tt>clearlist</tt> command removes all
-variables from the list.</dd>
+<dt><tt>? [<i>command_keyword</i>]</tt><br>
+<tt>helpl [<i>command_keyword</i>]</tt></dt>
+
+<dd>A <tt>?</tt> by itself will print a list of all the command
+keywords known to this incarnation of <tt>ntpq</tt>. A <tt>?</tt>
+followed by a command keyword will print function and usage
+information about the command. This command is probably a better
+source of information about <tt>ntpq</tt> than this manual
+page.</dd>
+
+<dt><tt>addvars <i>variable_name</i> [ = <i>value</i>]
+[...]</tt><br>
+<tt>rmvars <i>variable_name</i> [...]</tt><br>
+<tt>clearvars</tt></dt>
+
+<dd>The data carried by NTP mode 6 messages consists of a list of
+items of the form <tt><i>variable_name</i> = <i>value</i></tt>,
+where the <tt>= <i>value</i></tt> is ignored, and can be omitted,
+in requests to the server to read variables. <tt>ntpq</tt>
+maintains an internal list in which data to be included in control
+messages can be assembled, and sent using the <tt>readlist</tt> and
+<tt>writelist</tt> commands described below. The <tt>addvars</tt>
+command allows variables and their optional values to be added to
+the list. If more than one variable is to be added, the list should
+be comma-separated and not contain white space. The <tt>rmvars</tt>
+command can be used to remove individual variables from the list,
+while the <tt>clearlist</tt> command removes all variables from the
+list.</dd>
<dt><tt>authenticate yes | no</tt></dt>
-<dd>Normally <tt>ntpq</tt> does not authenticate requests unless they
-are write requests. The command <tt>authenticate yes</tt> causes
-<tt>ntpq</tt> to send authentication with all requests it makes.
-Authenticated requests causes some servers to handle requests slightly
-differently, and can occasionally melt the CPU in fuzzballs if you turn
-authentication on before doing a <tt>peer</tt> display. [I didn't know
-that - Ed.]</dd>
+
+<dd>Normally <tt>ntpq</tt> does not authenticate requests unless
+they are write requests. The command <tt>authenticate yes</tt>
+causes <tt>ntpq</tt> to send authentication with all requests it
+makes. Authenticated requests causes some servers to handle
+requests slightly differently, and can occasionally melt the CPU in
+fuzzballs if you turn authentication on before doing a <tt>
+peer</tt> display. [I didn't know that - Ed.]</dd>
<dt><tt>cooked</tt></dt>
-<dd>Causes output from query commands to be "cooked", so that variables
-which are recognized by <tt>ntpq</tt> will have their values reformatted
-for human consumption. Variables which <tt>ntpq</tt> thinks should have
-a decodable value but didn't are marked with a trailing
-<tt>?</tt>.</dd>
+
+<dd>Causes output from query commands to be "cooked", so that
+variables which are recognized by <tt>ntpq</tt> will have their
+values reformatted for human consumption. Variables which <tt>
+ntpq</tt> thinks should have a decodable value but didn't are
+marked with a trailing <tt>?</tt>.</dd>
<dt><tt>debug more | less | off</tt></dt>
+
<dd>Turns internal query program debugging on and off.</dd>
<dt><tt>delay <i>milliseconds</i></tt></dt>
+
<dd>Specify a time interval to be added to timestamps included in
requests which require authentication. This is used to enable
-(unreliable) server reconfiguration over long delay network paths or
-between machines whose clocks are unsynchronized. Actually the server
-does not now require timestamps in authenticated requests, so this
-command may be obsolete.</dd>
+(unreliable) server reconfiguration over long delay network paths
+or between machines whose clocks are unsynchronized. Actually the
+server does not now require timestamps in authenticated requests,
+so this command may be obsolete.</dd>
<dt><tt>host <i>hostname</i></tt></dt>
-<dd>Set the host to which future queries will be sent. Hostname may be
-either a host name or a numeric address.</dd>
+
+<dd>Set the host to which future queries will be sent. Hostname may
+be either a host name or a numeric address.</dd>
<dt><tt>hostnames [yes | no]</tt></dt>
-<dd>If <tt>yes</tt> is specified, host names are printed in information
-displays. If <tt>no</tt> is specified, numeric addresses are printed
-instead. The default is <tt>yes</tt>, unless modified using the command
-line <tt>-n</tt> switch.</dd>
+
+<dd>If <tt>yes</tt> is specified, host names are printed in
+information displays. If <tt>no</tt> is specified, numeric
+addresses are printed instead. The default is <tt>yes</tt>, unless
+modified using the command line <tt>-n</tt> switch.</dd>
<dt><tt>keyid <i>keyid</i></tt></dt>
-<dd>This command allows the specification of a key number to be used to
-authenticate configuration requests. This must correspond to a key
-number the server has been configured to use for this purpose.</dd>
+
+<dd>This command allows the specification of a key number to be
+used to authenticate configuration requests. This must correspond
+to a key number the server has been configured to use for this
+purpose.</dd>
<dt><tt>ntpversion 1 | 2 | 3 | 4</tt></dt>
-<dd>Sets the NTP version number which <tt>ntpq</tt> claims in packets.
-Defaults to 3, Note that mode 6 control messages (and modes, for that
-matter) didn't exist in NTP version 1. There appear to be no servers
-left which demand version 1.</dd>
+
+<dd>Sets the NTP version number which <tt>ntpq</tt> claims in
+packets. Defaults to 3, Note that mode 6 control messages (and
+modes, for that matter) didn't exist in NTP version 1. There appear
+to be no servers left which demand version 1.</dd>
<dt><tt>quit</tt></dt>
+
<dd>Exit <tt>ntpq</tt>.</dd>
<dt><tt>passwd</tt></dt>
-<dd>This command prompts you to type in a password (which will not be
-echoed) which will be used to authenticate configuration requests. The
-password must correspond to the key configured for use by the NTP server
-for this purpose if such requests are to be successful.</dd>
+
+<dd>This command prompts you to type in a password (which will not
+be echoed) which will be used to authenticate configuration
+requests. The password must correspond to the key configured for
+use by the NTP server for this purpose if such requests are to be
+successful.</dd>
<dt><tt>raw</tt></dt>
-<dd>Causes all output from query commands is printed as received from
-the remote server. The only formating/interpretation done on the data is
-to transform nonascii data into a printable (but barely understandable)
-form.</dd>
+
+<dd>Causes all output from query commands is printed as received
+from the remote server. The only formating/interpretation done on
+the data is to transform nonascii data into a printable (but barely
+understandable) form.</dd>
<dt><tt>timeout <i>millseconds</i></tt></dt>
+
<dd>Specify a timeout period for responses to server queries. The
default is about 5000 milliseconds. Note that since <tt>ntpq</tt>
-retries each query once after a timeout, the total waiting time for a
-timeout will be twice the timeout value set.</dd>
-
+retries each query once after a timeout, the total waiting time for
+a timeout will be twice the timeout value set.</dd>
</dl>
<h4>Control Message Commands</h4>
Each peer known to an NTP server has a 16 bit integer association
identifier assigned to it. NTP control messages which carry peer
-variables must identify the peer the values correspond to by including
-its association ID. An association ID of 0 is special, and indicates the
-variables are system variables, whose names are drawn from a separate
-name space.
-
-<p>Control message commands result in one or more NTP mode 6 messages
-being sent to the server, and cause the data returned to be printed in
-some format. Most commands currently implemented send a single message
-and expect a single response. The current exceptions are the peers
-command, which will send a preprogrammed series of messages to obtain
-the data it needs, and the mreadlist and mreadvar commands, which will
-iterate over a range of associations.
+variables must identify the peer the values correspond to by
+including its association ID. An association ID of 0 is special,
+and indicates the variables are system variables, whose names are
+drawn from a separate name space.
+
+<p>Control message commands result in one or more NTP mode 6
+messages being sent to the server, and cause the data returned to
+be printed in some format. Most commands currently implemented send
+a single message and expect a single response. The current
+exceptions are the peers command, which will send a preprogrammed
+series of messages to obtain the data it needs, and the mreadlist
+and mreadvar commands, which will iterate over a range of
+associations.</p>
+
<dl>
<dt><tt>associations</tt></dt>
<dd>Obtains and prints a list of association identifiers and peer
statuses for in-spec peers of the server being queried. The list is
printed in columns. The first of these is an index numbering the
-associations from 1 for internal use, the second the actual association
-identifier returned by the server and the third the status word for the
-peer. This is followed by a number of columns containing data decoded
-from the status word See the peers command for a decode of the
-<tt>condition</tt> field. Note that the data returned by the
-<tt>associations"</tt> command is cached internally in <tt>ntpq</tt>.
-The index is then of use when dealing with stupid servers which use
-association identifiers which are hard for humans to type, in that for
-any subsequent commands which require an association identifier as an
-argument, the form and index may be used as an alternative.</dd>
-
-<dt><tt>clockvar [<i>assocID</i>] [<i>variable_name</i> [ = <i>value</i>
-[...]] [...]</tt></dt>
-
-<dt><tt>cv [<i>assocID</i>] [<i>variable_name</i> [ = <i>value</i> [...]
-][...]</tt></dt>
+associations from 1 for internal use, the second the actual
+association identifier returned by the server and the third the
+status word for the peer. This is followed by a number of columns
+containing data decoded from the status word See the peers command
+for a decode of the <tt>condition</tt> field. Note that the data
+returned by the <tt>associations"</tt> command is cached internally
+in <tt>ntpq</tt>. The index is then of use when dealing with stupid
+servers which use association identifiers which are hard for humans
+to type, in that for any subsequent commands which require an
+association identifier as an argument, the form and index may be
+used as an alternative.</dd>
+
+<dt><tt>clockvar [<i>assocID</i>] [<i>variable_name</i> [ = <i>
+value</i> [...]] [...]</tt></dt>
+
+<dt><tt>cv [<i>assocID</i>] [<i>variable_name</i> [ = <i>value</i>
+[...] ][...]</tt></dt>
+
<dd>Requests that a list of the server's clock variables be sent.
-Servers which have a radio clock or other external synchronization will
-respond positively to this. If the association identifier is omitted or
-zero the request is for the variables of the <tt>system clock</tt> and
-will generally get a positive response from all servers with a clock. If
-the server treats clocks as pseudo-peers, and hence can possibly have
-more than one clock connected at once, referencing the appropriate peer
-association ID will show the variables of a particular clock. Omitting
-the variable list will cause the server to return a default variable
-display.</dd>
+Servers which have a radio clock or other external synchronization
+will respond positively to this. If the association identifier is
+omitted or zero the request is for the variables of the <tt>system
+clock</tt> and will generally get a positive response from all
+servers with a clock. If the server treats clocks as pseudo-peers,
+and hence can possibly have more than one clock connected at once,
+referencing the appropriate peer association ID will show the
+variables of a particular clock. Omitting the variable list will
+cause the server to return a default variable display.</dd>
<dt><tt>lassocations</tt></dt>
+
<dd>Obtains and prints a list of association identifiers and peer
-statuses for all associations for which the server is maintaining state.
-This command differs from the <tt>associations</tt> command only for
-servers which retain state for out-of-spec client associations (i.e.,
-fuzzballs). Such associations are normally omitted from the display when
-the <tt>associations</tt> command is used, but are included in the
-output of <tt>lassociations</tt>.</dd>
+statuses for all associations for which the server is maintaining
+state. This command differs from the <tt>associations</tt> command
+only for servers which retain state for out-of-spec client
+associations (i.e., fuzzballs). Such associations are normally
+omitted from the display when the <tt>associations</tt> command is
+used, but are included in the output of <tt>
+lassociations</tt>.</dd>
<dt><tt>lpassociations</tt></dt>
+
<dd>Print data for all associations, including out-of-spec client
associations, from the internally cached list of associations. This
command differs from <tt>passociations</tt> only when dealing with
fuzzballs.</dd>
<dt><tt>lpeers</tt></dt>
-<dd>Like R peers, except a summary of all associations for which the
-server is maintaining state is printed. This can produce a much longer
-list of peers from fuzzball servers.</dd>
-
-<dt><tt>mreadlist <i>assocID</i> <i>assocID</i></tt></dt>
-<BR><tt>mrl <i>assocID</i> <i>assocID</i></tt>
-<dd>Like the <tt>readlist</tt> command, except the query is done for
-each of a range of (nonzero) association IDs. This range is determined
-from the association list cached by the most recent
-<tt>associations</tt> command.</dd>
-
-<dt><tt>mreadvar <i>assocID</i> <i>assocID</i> [ <i>variable_name</i> [
-= <i>value</i>[ ... ]</tt></dt>
-<BR><tt>mrv <i>assocID</i> <i>assocID</i> [ <i>variable_name</i> [ =
-<i>value</i>[ ... ]</tt>
-<dd>Like the <tt>readvar</tt> command, except the query is done for each
-of a range of (nonzero) association IDs. This range is determined from
-the association list cached by the most recent <tt>associations</tt>
-command.</dd>
+
+<dd>Like R peers, except a summary of all associations for which
+the server is maintaining state is printed. This can produce a much
+longer list of peers from fuzzball servers.</dd>
+
+<dt><tt>mreadlist <i>assocID</i> <i>assocID</i></tt><br>
+<tt>mrl <i>assocID</i> <i>assocID</i></tt></dt>
+
+<dd>Like the <tt>readlist</tt> command, except the query is done
+for each of a range of (nonzero) association IDs. This range is
+determined from the association list cached by the most recent <tt>
+associations</tt> command.</dd>
+
+<dt><tt>mreadvar <i>assocID</i> <i>assocID</i> [ <i>
+variable_name</i> [ = <i>value</i>[ ... ]</tt><br>
+<tt>mrv <i>assocID</i> <i>assocID</i> [ <i>variable_name</i> [ =
+<i>value</i>[ ... ]</tt></dt>
+
+<dd>Like the <tt>readvar</tt> command, except the query is done for
+each of a range of (nonzero) association IDs. This range is
+determined from the association list cached by the most recent <tt>
+associations</tt> command.</dd>
<dt><tt>opeers</tt></dt>
+
<dd>An old form of the <tt>peers</tt> command with the reference ID
replaced by the local interface address.</dd>
<dt><tt>passociations</tt></dt>
+
<dd>Displays association data concerning in-spec peers from the
internally cached list of associations. This command performs
-identically to the <tt>associations</tt> except that it displays the
-internally stored data rather than making a new query.</dd>
+identically to the <tt>associations</tt> except that it displays
+the internally stored data rather than making a new query.</dd>
<dt><tt>peers</tt></dt>
-<dd>Obtains a current list peers of the server, along with a summary of
-each peer's state. Summary information includes the address of the
-remote peer, the reference ID (0.0.0.0 if this is unknown), the stratum
-of the remote peer, the type of the peer (local, unicast, multicast or
-broadcast), when the last packet was received, the polling interval, in
-seconds, the reachability register, in octal, and the current estimated
-delay, offset and dispersion of the peer, all in milliseconds.</dd>
-
-<dd>The character in the left margin indicates the fate of this peer in
-the clock selection process. Following is a list of these characters,
-the
-pigeon used in the <tt>rv</tt> command, and a short explanation of the
-condition revealed.</dd>
+<dd>Obtains a current list peers of the server, along with a
+summary of each peer's state. Summary information includes the
+address of the remote peer, the reference ID (0.0.0.0 if this is
+unknown), the stratum of the remote peer, the type of the peer
+(local, unicast, multicast or broadcast), when the last packet was
+received, the polling interval, in seconds, the reachability
+register, in octal, and the current estimated delay, offset and
+dispersion of the peer, all in milliseconds.</dd>
+
+<dd>The character in the left margin indicates the fate of this
+peer in the clock selection process. Following is a list of these
+characters, the pigeon used in the <tt>rv</tt> command, and a short
+explanation of the condition revealed.</dd>
+
+<dd>
<dl>
-
<dt><tt>space reject</tt></dt>
-<dd>The peer is discarded as unreachable, synchronized to this server
-(synch loop) or outrageous synchronization distance.</dd>
+
+<dd>The peer is discarded as unreachable, synchronized to this
+server (synch loop) or outrageous synchronization distance.</dd>
<dt><tt>x falsetick</tt></dt>
+
<dd>The peer is discarded by the intersection algorithm as a
falseticker.</dd>
<dt><tt>. excess</tt></dt>
-<dd>The peer is discarded as not among the first ten peers sorted by
-synchronization distance and so is probably a poor candidate for further
-consideration.</dd>
+
+<dd>The peer is discarded as not among the first ten peers sorted
+by synchronization distance and so is probably a poor candidate for
+further consideration.</dd>
<dt><tt>- outlyer</tt></dt>
+
<dd>The peer is discarded by the clustering algorithm as an
outlyer.</dd>
<dt><tt>+ candidat</tt></dt>
+
<dd>The peer is a survivor and a candidate for the combining
algorithm.</dd>
<dt><tt># selected</tt></dt>
-<dd>The peer is a survivor, but not among the first six peers sorted by
-synchronization distance. If the assocation is ephemeral, it may be
-demobilized to conserve resources.</dd>
+
+<dd>The peer is a survivor, but not among the first six peers
+sorted by synchronization distance. If the assocation is ephemeral,
+it may be demobilized to conserve resources.</dd>
<dt><tt>* sys.peer</tt></dt>
-<dd>The peer has been declared the system peer and lends its variables
-to the system variables.</dd>
+
+<dd>The peer has been declared the system peer and lends its
+variables to the system variables.</dd>
<dt><tt>o pps.peer</tt></dt>
-<dd>The peer has been declared the system peer and lends its variables
-to thesystem variables. However, the actual system synchronization is
-derived from a pulse-per-second (PPS) signal, either indirectly via the
-PPS reference clock driver or directly via kernel interface.</dd>
+<dd>The peer has been declared the system peer and lends its
+variables to thesystem variables. However, the actual system
+synchronization is derived from a pulse-per-second (PPS) signal,
+either indirectly via the PPS reference clock driver or directly
+via kernel interface.</dd>
</dl>
-<p><dd>The <tt>flash</tt> variable is a valuable debugging aid. It
-displays the results of the original sanity checks defined in the NTP
-specification RFC-1305 and additional ones added in NTP Version 4. There
-are eleven tests called <tt>TEST1</tt> through <tt>TEST11</tt>. The
-tests are performed in a certain order designed to gain maximum
-diagnostic information while protecting against accidental or malicious
-errors. The <tt>flash</tt> variable is first initialized to zero. If
-after each set of tests one or more bits are set, the packet is
-discarded.
-
-<p>Tests <tt>TEST4</tt> and <tt>TEST5</tt> check the access permissions
-and cryptographic message digest. If any bits are set after that, the
-packet is discarded. Tests <tt>TEST10</tt> and <tt>TEST11</tt> check the
-authentication state using Autokey public-key cryptography, as described
-in the <a href=authopt.htm>Authentication Options</a> page. If any bits
-are set and the association has previously been marked reachable, the
-packet is discarded; otherwise, the originate and receive timestamps are
-saved, as required by the NTP protocol, and processing continues.
+</dd>
+
+<dd>The <tt>flash</tt> variable is a valuable debugging aid. It
+displays the results of the original sanity checks defined in the
+NTP specification RFC-1305 and additional ones added in NTP Version
+4. There are eleven tests called <tt>TEST1</tt> through <tt>
+TEST11</tt>. The tests are performed in a certain order designed to
+gain maximum diagnostic information while protecting against
+accidental or malicious errors. The <tt>flash</tt> variable is
+first initialized to zero. If after each set of tests one or more
+bits are set, the packet is discarded.
+
+<p>Tests <tt>TEST4</tt> and <tt>TEST5</tt> check the access
+permissions and cryptographic message digest. If any bits are set
+after that, the packet is discarded. Tests <tt>TEST10</tt> and <tt>
+TEST11</tt> check the authentication state using Autokey public-key
+cryptography, as described in the <a href="authopt.htm">
+Authentication Options</a> page. If any bits are set and the
+association has previously been marked reachable, the packet is
+discarded; otherwise, the originate and receive timestamps are
+saved, as required by the NTP protocol, and processing
+continues.</p>
<p>Tests <tt>TEST1</tt> through <tt>TEST3</tt> check the packet
-timestamps from which the offset and delay are calculated. If any bits
-are set, the packet is discarded; otherwise, the packet header variables
-are saved. Tests <tt>TEST6</tt> through <tt>TEST8</tt> check the health
-of the server. If any bits are set, the packet is discarded; otherwise,
-the offset and delay relative to the server are calculated and saved.
-Test <tt>TEST9</tt> checks the health of the association itself. If any
-bits are set, the packet is discarded; otherwise, the saved variables
-are passed to the clock filter and mitigation algorithms.
-
-<p>The <tt>flash</tt> bits for each test read in increasing order from
-the least significant bit are defined as follows.</dd>
-
+timestamps from which the offset and delay are calculated. If any
+bits are set, the packet is discarded; otherwise, the packet header
+variables are saved. Tests <tt>TEST6</tt> through <tt>TEST8</tt>
+check the health of the server. If any bits are set, the packet is
+discarded; otherwise, the offset and delay relative to the server
+are calculated and saved. Test <tt>TEST9</tt> checks the health of
+the association itself. If any bits are set, the packet is
+discarded; otherwise, the saved variables are passed to the clock
+filter and mitigation algorithms.</p>
+
+<p>The <tt>flash</tt> bits for each test read in increasing order
+from the least significant bit are defined as follows.</p>
+</dd>
+
+<dd>
<dl>
-
<dt><tt>TEST1</tt></dt>
-<dd>Duplicate packet. The packet is at best a casual retransmission and
-at worst a malicious replay.</dd>
+
+<dd>Duplicate packet. The packet is at best a casual retransmission
+and at worst a malicious replay.</dd>
<dt><tt>TEST2</tt></dt>
+
<dd>Bogus packet. The packet is not a reply to a message previously
sent. This can happen when the NTP daemon is restarted and before
somebody else notices.</dd>
<dt><tt>TEST3</tt></dt>
+
<dd>Unsynchronized. One or more timestamp fields are invalid. This
-normally happens when the first packet from a peer is received.</dd>
+normally happens when the first packet from a peer is
+received.</dd>
<dt><tt>TEST4</tt></dt>
-<dd>Access is denied. See the <A HREF="accopt.htm">Access Control
-Options</A> page.</dd>
+
+<dd>Access is denied. See the <a href="accopt.htm">Access Control
+Options</a> page.</dd>
<dt><tt>TEST5</tt></dt>
-<dd>Cryptographic authentication fails. See the <A
-HREF="authopt.htm">Authentication Options</A> page.</dd>
+
+<dd>Cryptographic authentication fails. See the <a href=
+"authopt.htm">Authentication Options</a> page.</dd>
<dt><tt>TEST6</tt></dt>
+
<dd>The server is unsynchronized. Wind up its clock first.</dd>
<dt><tt>TEST7</tt></dt>
+
<dd>The server stratum is at the maximum than 15. It is probably
unsynchronized and its clock needs to be wound up.</dd>
<dt><tt>TEST8</tt></dt>
+
<dd>Either the root delay or dispersion is greater than one second,
-which is highly unlikely unless the peer is synchronized to Mars.</dd>
+which is highly unlikely unless the peer is synchronized to
+Mars.</dd>
+
<dt><tt>TEST9</tt></dt>
+
<dd>Either the peer delay or dispersion is greater than one second,
which is higly unlikely unless the peer is on Mars.</dd>
<dt><tt>TEST10</tt></dt>
-<dd>The autokey protocol has detected an authentication failure. See the
-<A HREF="authopt.htm">Authentication Options</A> page.</dd>
+
+<dd>The autokey protocol has detected an authentication failure.
+See the <a href="authopt.htm">Authentication Options</a> page.</dd>
<dt><tt>TEST11</tt></dt>
-<dd>The autokey protocol has not verified the server or peer is
-authentic and has valid public key credentials. See the <A
-HREF="authopt.htm">Authentication Options</A> page.</dd>
-</dl>
+<dd>The autokey protocol has not verified the server or peer is
+authentic and has valid public key credentials. See the <a href=
+"authopt.htm">Authentication Options</a> page.</dd>
-<p><dd>Additional system variables used by the NTP Version 4 Autokey
-support include the following:
+<dt>Additional system variables used by the NTP Version 4 Autokey
+support include the following:</dt>
+<dd>
<dl>
+<dt><tt>certificate <i>filestamp</i></tt></dt>
-<dt><tt>leaptable <i>filestamp</i></tt>/<dt>
-<dd>Shows the NTP seconds when the NIST leapsecond table file was
+<dd>Shows the NTP seconds when the certificate file was
created.</dd>
-<dt><tt>hostname <i>host</i></tt>/<dt>
-<dd>Shows the name of the host as returned by the Unix
-<tt>gethostname()</tt> library function.</dd>
+<dt><tt>hostname <i>host</i></tt></dt>
+
+<dd>Shows the name of the host as returned by the Unix <tt>
+gethostname()</tt> library function.</dd>
+
+<dt><tt>flags <i>hex</i></tt></dt>
+
+<dd>Shows the current flag bits, where the <tt><i>hex</i></tt> bits
+are interpreted as follows:</dd>
+
+<dd>
+<dl>
+<dt><tt>0x01</tt></dt>
+
+<dd>autokey enabled</dd>
+
+<dt><tt>0x02</tt></dt>
-<dt><tt>params <i>filestamp</i></tt>/<dt>
-<dd>Shows the NTP seconds when the Diffie-Hellman agreement parameter
-file was created.</dd>
+<dd>RSA public/private key files present</dd>
-<dt><tt>publickey <i>filestamp</i></tt>/<dt>
-<dd>Shows the NTP seconds when the RSA public/private key files were
+<dt><tt>0x04</tt></dt>
+
+<dd>PKI certificate file present</dd>
+
+<dt><tt>0x08</tt></dt>
+
+<dd>Diffie-Hellman parameters file present</dd>
+
+<dt><tt>0x10</tt></dt>
+
+<dd>NIST leapseconds table file present</dd>
+</dl>
+</dd>
+
+<dt><tt>leapseconds <i>filestamp</i></tt></dt>
+
+<dd>Shows the NTP seconds when the NIST leapseconds table file was
created.</dd>
-<dt><tt>refresh <i>timestamp</i></tt>/<dt>
+<dt><tt>params <i>filestamp</i></tt></dt>
+
+<dd>Shows the NTP seconds when the Diffie-Hellman agreement
+parameter file was created.</dd>
+
+<dt><tt>publickey <i>filestamp</i></tt></dt>
+
+<dd>Shows the NTP seconds when the RSA public/private key files
+were created.</dd>
+
+<dt><tt>refresh <i>timestamp</i></tt></dt>
+
<dd>Shows the NTP seconds when the public cryptographic values were
refreshed and signed.</dd>
+<dt><tt>tai <i>offset</i></tt></dt>
+
+<dd>Shows the TAI-UTC offset in seconds obtained from the NIST
+leapseconds table.</dd>
</dl>
+</dd>
-<p><dd>Additional peer variables used by the NTP Version 4 Autokey
-support include the following:
+<dt>Additional peer variables used by the NTP Version 4 Autokey
+support include the following:</dt>
+<dd>
<dl>
+<dt><tt>certificate <i>filestamp</i></tt></dt>
+
+<dd>Shows the NTP seconds when the certificate file was
+created.</dd>
+
+<dt><tt>flags <i>hex</i></tt></dt>
+
+<dd>Shows the current flag bits, where the <i>hex</i> bits are
+interpreted as in the system variable of the same name. The bits
+are set in the first autokey message received from the server and
+then reset as the associated data are obtained from the server and
+stored.</dd>
+
+<dt><tt>hcookie <i>hex</i></tt></dt>
-<dt><tt>hcookie <i>hex</i></tt>/<dt>
<dd>Shows the host cookie used in the key agreement algorithm.</dd>
-<dt><tt>initkey <i>key</i></tt>/<dt>
-<dd>Shows the initial key used by the key list generator in the autokey
-protocol.</dd>
+<dt><tt>initkey <i>key</i></tt></dt>
+
+<dd>Shows the initial key used by the key list generator in the
+autokey protocol.</dd>
+
+<dt><tt>initsequence <i>index</i></tt></dt>
-<dt><tt>initsequence <i>index</i></tt>/<dt>
<dd>Shows the initial index used by the key list generator in the
autokey protocol.</dd>
-<dt><tt>pcookie <i>hex</i></tt>/<dt>
-<dd>Specifies the peer cookie used in the key agreement algorithm.</dd>
+<dt><tt>pcookie <i>hex</i></tt></dt>
+
+<dd>Specifies the peer cookie used in the key agreement
+algorithm.</dd>
+
+<dt><tt>timestamp <i>time</i></tt></dt>
-<dt><tt>timestamp <i>time</i></tt>/<dt>
-<dd>Shows the NTP seconds when the last autokey key list was generated
-and signed.</dd>
+<dd>Shows the NTP seconds when the last autokey key list was
+generated and signed.</dd>
</dl>
+</dd>
+</dl>
+</dd>
+
<dt><tt>pstatus <i>assocID</i></tt></dt>
-<dd>Sends a read status request to the server for the given association.
-The names and values of the peer variables returned will be printed.
-Note that the status word from the header is displayed preceding the
-variables, both in hexidecimal and in pidgeon English.</dd>
-
-<dt><tt>readlist [ <i>assocID</i> ]</tt></dt>
-<BR><tt>rl [ <i>assocID</i> ]</tt>
-<dd>Requests that the values of the variables in the internal variable
-list be returned by the server. If the association ID is omitted or is 0
-the variables are assumed to be system variables. Otherwise they are
-treated as peer variables. If the internal variable list is empty a
-request is sent without data, which should induce the remote server to
-return a default display.</dd>
-
-<dt><tt>readvar <i>assocID</i> <i>variable_name</i> [ = <i>value</i> ] [
-...]</tt></dt>
-<BR><tt>rv <i>assocID</i> [ <i>variable_name</i> [ = <i>value</i> ] [
-...]</tt>
-<dd>Requests that the values of the specified variables be returned by
-the server by sending a read variables request. If the association ID is
-omitted or is given as zero the variables are system variables,
-otherwise they are peer variables and the values returned will be those
-of the corresponding peer. Omitting the variable list will send a
-request with no data which should induce the server to return a default
-display.</dd>
-
-<dt><tt>writevar <i>assocID</i> <i>variable_name</i> [ = <i>value</i> [
+
+<dd>Sends a read status request to the server for the given
+association. The names and values of the peer variables returned
+will be printed. Note that the status word from the header is
+displayed preceding the variables, both in hexidecimal and in
+pidgeon English.</dd>
+
+<dt><tt>readlist [ <i>assocID</i> ]</tt><br>
+<tt>rl [ <i>assocID</i> ]</tt></dt>
+
+<dd>Requests that the values of the variables in the internal
+variable list be returned by the server. If the association ID is
+omitted or is 0 the variables are assumed to be system variables.
+Otherwise they are treated as peer variables. If the internal
+variable list is empty a request is sent without data, which should
+induce the remote server to return a default display.</dd>
+
+<dt><tt>readvar <i>assocID</i> <i>variable_name</i> [ = <i>
+value</i> ] [ ...]</tt><br>
+<tt>rv <i>assocID</i> [ <i>variable_name</i> [ = <i>value</i> ] [
...]</tt></dt>
-<dd>Like the readvar request, except the specified variables are written
-instead of read.</dd>
-<dt><tt>writelist [ <i>assocID</i> ]</tt></dt>
-<dd>Like the readlist request, except the internal list variables are
+<dd>Requests that the values of the specified variables be returned
+by the server by sending a read variables request. If the
+association ID is omitted or is given as zero the variables are
+system variables, otherwise they are peer variables and the values
+returned will be those of the corresponding peer. Omitting the
+variable list will send a request with no data which should induce
+the server to return a default display.</dd>
+
+<dt><tt>writevar <i>assocID</i> <i>variable_name</i> [ = <i>
+value</i> [ ...]</tt></dt>
+
+<dd>Like the readvar request, except the specified variables are
written instead of read.</dd>
+<dt><tt>writelist [ <i>assocID</i> ]</tt></dt>
+
+<dd>Like the readlist request, except the internal list variables
+are written instead of read.</dd>
</dl>
<h4>Bugs</h4>
<p>The peers command is non-atomic and may occasionally result in
-spurious
-error messages about invalid associations occurring and terminating the
-command. The timeout time is a fixed constant, which means you wait a
-long time for timeouts since it assumes sort of a worst case. The
-program should improve the timeout estimate as it sends queries to a
-particular host, but doesn't.
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+spurious error messages about invalid associations occurring and
+terminating the command. The timeout time is a fixed constant,
+which means you wait a long time for timeouts since it assumes sort
+of a worst case. The program should improve the timeout estimate as
+it sends queries to a particular host, but doesn't.</p>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
-<HTML><HEAD><TITLE>
-ntptime - read kernel time variables
-</TITLE></HEAD><BODY><H3>
-<TT>ntptime</TT> - read kernel time variables
-</H3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntptime - read kernel time variables</title>
+</head>
+<body>
+<h3><tt>ntptime</tt> - read kernel time variables</h3>
+<img align="left" src="pic/pogo5.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
+Walt Kelly</a>
-<img align=left src=pic/pogo5.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>from <i>Pogo</i>, Walt Kelly</a>
+<p>The turtle is been swimming in the kernel.<br clear="left">
+</p>
-<p>The turtle is been swimming in the kernel.
-<br clear=left><hr>
+<hr>
+<h4>Synopsis</h4>
-<h4>Synopsis</H4>
+<tt>ntptime [ -chr ] [ -e <i>est_error</i> ] [ -f <i>frequency</i>
+] [ -m <i>max_error</i> ] [ -o <i>offset</i> ] [ -s <i>status</i> ]
+[ -t <i>time_constant</i>]</tt>
-<TT>ntptime [ -chr ] [ -e <I>est_error</I> ] [ -f <I>frequency</I> ] [ -m <I>max_error</I> ] [ -o <I>offset</I> ] [ -s <I>status</I> ] [ -t <I>time_constant</I>]</TT>
+<h4>Description</h4>
-<H4>Description</H4>
+This program is useful only with special kernels described in the
+<a href="kern.htm">A Kernel Model for Precision Timekeeping</a>
+page. It reads and displays time-related kernel variables using the
+<tt>ntp_gettime()</tt> system call. A similar display can be
+obtained using the <tt>ntpdc</tt> program and <tt>kerninfo</tt>
+command.
-This program is useful only with special kernels described in the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping </A>page. It reads and displays time-related kernel variables using the <TT>ntp_gettime()</TT> system call. A similar display can be obtained using the <TT>ntpdc</TT> program and <TT>kerninfo</TT> command.
+<h4>Options</h4>
-<H4>Options</H4>
+<dl>
+<dt><tt>-c</tt></dt>
-<DL>
+<dd>Display the execution time of <tt>ntptime</tt> itself.</dd>
-<DT><TT>-c</TT></DT>
-<DD>Display the execution time of <TT>ntptime</TT> itself.</DD>
+<dt><tt>-e <i>est_error</i></tt></dt>
-<DT><TT>-e <I>est_error</I></TT></DT>
-<DD>Specify estimated error, in microseconds.</DD>
+<dd>Specify estimated error, in microseconds.</dd>
-<DT><TT>-f <I>frequency</I></TT></DT>
-<DD>Specify frequency offset, in parts per million.</DD>
+<dt><tt>-f <i>frequency</i></tt></dt>
-<DT><TT>-h</TT></DT>
-<DD>Display help information.</DD>
+<dd>Specify frequency offset, in parts per million.</dd>
-<DT><TT>-m <I>max_error</I></TT></DT>
-<DD>Specify max possible errors, in microseconds.</DD>
+<dt><tt>-h</tt></dt>
-<DT><TT>-o <I>offset</I></TT></DT>
-<DD>Specify clock offset, in microseconds.</DD>
+<dd>Display help information.</dd>
-<DT><TT>-r</TT></DT>
-<DD>Display Unix and NTP times in raw format.</DD>
+<dt><tt>-m <i>max_error</i></tt></dt>
-<DT><TT>-s <I>status</I></TT></DT>
-<DD>Specify clock status. Better know what you are doing.</DD>
+<dd>Specify max possible errors, in microseconds.</dd>
-<DT><TT>-t <I>time_constant</I></TT></DT>
-<DD>Specify time constant, an integer in the range 0-10.</DD>
+<dt><tt>-o <i>offset</i></tt></dt>
-</DL>
+<dd>Specify clock offset, in microseconds.</dd>
+
+<dt><tt>-r</tt></dt>
+
+<dd>Display Unix and NTP times in raw format.</dd>
+
+<dt><tt>-s <i>status</i></tt></dt>
+
+<dd>Specify clock status. Better know what you are doing.</dd>
+
+<dt><tt>-t <i>time_constant</i></tt></dt>
+
+<dd>Specify time constant, an integer in the range 0-10.</dd>
+</dl>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu>David L. Mills <mills@udel.edu></a></address></a></body></html>
-<html><head><title>
-<tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source
-</title></head><body><h3>
-<tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source
-</h3>
-
-<img align=left src=pic/alice13.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>The rabbit knows the way back.
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>ntptrace - trace a chain of NTP servers back to the primary
+source</title>
+</head>
+<body>
+<h3><tt>ntptrace</tt> - trace a chain of NTP servers back to the
+primary source</h3>
+
+<img align="left" src="pic/alice13.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The rabbit knows the way back.<br clear="left">
+</p>
+
+<hr>
<h4>Synopsis</h4>
-<tt>ntptrace [ -vdn ] [ -r <I>retries</I> ] [ -t <I>timeout</I> ] [ <I>server</I>
-]</tt>
+<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><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><pre>% ntptrace
+<pre>
+% ntptrace
localhost: stratum 4, offset 0.0019529, synch distance 0.144135
server2ozo.com: stratum 2, offset 0.0124263, synch distance 0.115784
usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid
-'WWVB'</pre>
-
-On each line, the fields are (left to right): the host name, the host stratum, the time offset between that host and the local host (as measured by <tt>ntptrace</tt>; this is why it is not always zero for "<tt>localhost</tt>"), the host synchronization distance, and (only for stratum-1 servers) the reference clock ID. All times are given in seconds. Note that the stratum is the server hop count to the primary source, while the synchronization distance is the estimated error relative to the primary source. These terms are precisely defined in RFC-1305.
+'WWVB'
+</pre>
+
+On each line, the fields are (left to right): the host name, the
+host stratum, the time offset between that host and the local host
+(as measured by <tt>ntptrace</tt>; this is why it is not always
+zero for "<tt>localhost</tt>"), the host synchronization distance,
+and (only for stratum-1 servers) the reference clock ID. All times
+are given in seconds. Note that the stratum is the server hop count
+to the primary source, while the synchronization distance is the
+estimated error relative to the primary source. These terms are
+precisely defined in RFC-1305.
<h4>Options</h4>
<dl>
-
<dt><tt>-d</tt></dt>
+
<dd>Turns on some debugging output.</dd>
<dt><tt>-n</tt></dt>
-<dd>Turns off the printing of host names; instead, host IP addresses are given. This may be useful if a nameserver is down.</dd>
-<dt><tt>-r <I>retries</I></tt></dt>
-<dd>Sets the number of retransmission attempts for each host (default = 5).</dd>
+<dd>Turns off the printing of host names; instead, host IP
+addresses are given. This may be useful if a nameserver is
+down.</dd>
-<dt><tt>-t <I>timeout</I></tt></dt>
-<dd>Sets the retransmission timeout (in seconds) (default = 2).</dd>
+<dt><tt>-r <i>retries</i></tt></dt>
+
+<dd>Sets the number of retransmission attempts for each host
+(default = 5).</dd>
+
+<dt><tt>-t <i>timeout</i></tt></dt>
+
+<dd>Sets the retransmission timeout (in seconds) (default =
+2).</dd>
<dt><tt>-v</tt></dt>
-<dd>Prints verbose information about the NTP servers.</dd>
+<dd>Prints verbose information about the NTP servers.</dd>
</dl>
<h4>Bugs</h4>
-This program makes no attempt to improve accuracy by doing multiple samples.
+This program makes no attempt to improve accuracy by doing multiple
+samples.
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
-<html><head><title>
-Pulse-per-second (PPS) Signal Interfacing
-</title></head><body><h3>
-Pulse-per-second (PPS) Signal Interfacing
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Pulse-per-second (PPS) Signal Interfacing</title>
+</head>
+<body>
+<h3>Pulse-per-second (PPS) Signal Interfacing</h3>
-<img align=left src=pic/alice32.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+<img align="left" src="pic/alice32.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
-<p>Alice is trying to find the PPS signal connector.
-<br clear=left><hr>
+<p>Alice is trying to find the PPS signal connector.<br clear=
+"left">
+</p>
-<p>Some radio clocks and related timekeeping gear have a pulse-per-second (PPS) signal that can be used to discipline the local clock oscillator 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. 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. Connection via a serial port may require signal conversion and regeneration to RS232 levels, which can be done using a circuit such as described in the <A HREF=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</A> page. Note that NTP no longer supports connection via the data leads of a serial port.
+<hr>
+<p>Some radio clocks and related timekeeping gear have a
+pulse-per-second (PPS) signal that can be used to discipline the
+local clock oscillator 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. 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.
+Connection via a serial port may require signal conversion and
+regeneration to RS232 levels, which can be done using a circuit
+such as described in the <a href="gadget.htm">Gadget Box PPS Level
+Converter and CHU Modem</a> page. Note that NTP no longer supports
+connection via the data leads of a serial port.</p>
-<p>Both the serial and parallel port connection require operating system support, which is available in only a few operating systems, including Linux, FreeBSD and latest Solaris. Support on an experimental basis is available for several older systems, including SunOS, Digital RISC and HP-UX, and in current Digital Tru64 (Alpha). The PPS application program interface defined in RFC-2783 (PPSAPI) 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>Both the serial and parallel port connection require operating
+system support, which is available in only a few operating systems,
+including Linux, FreeBSD and latest Solaris beginning with 2.7.
+Support on an experimental basis is available for several older
+systems, including SunOS, Digital RISC and HP-UX, and in current
+Digital Tru64 (Alpha). The PPS application program interface
+defined in RFC-2783 (PPSAPI) 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>In the preferred mode of operation, PPS signals are processed by the <a href=driver22.htm>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.
+<p>The PPSAPI inerface requires a <tt>/usr/include/ppstime.h</tt>
+header file. This file is included in Linux and FreeBSD
+distributions, but not in other distributions or standard
+workstation products at this time. Header files for other systems,
+including Solaris, can be found in the <tt>nanokernel.tar.gz</tt>
+distribution, which can be found via the Collaboration Resources
+link at www.ntp.org. The top level directory contains a number of
+subdirectories for each architecture, including Solaris. The <tt>
+ppstime.h</tt> file for each architecture can be found in the
+subdirectory of the same name.</p>
-<p>The PPS driver operates in conjunction with a preferred peer, as described in the <A HREF=prefer.htm>Mitigation Rules and the <tt>prefer</tt> Keyword </A>page. One of the drivers described in the <A HREF=refclock.htm>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>In the preferred mode of operation, PPS signals are processed by
+the <a href="driver22.htm">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.</p>
-<p>For the utmost time quality, some Unix system kernels support a PPS signal directly, as described in the <A HREF=kern.htm>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.
+<p>The PPS driver operates in conjunction with a preferred peer, as
+described in the <a href="prefer.htm">Mitigation Rules and the <tt>
+prefer</tt> Keyword</a> page. One of the drivers described in the
+<a href="refclock.htm">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 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>For the utmost time quality, some Unix system kernels support a
+PPS signal directly, as described in the <a href="kern.htm">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.</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>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a><br>
+<br>
+
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a> </address></a></body></html>
-<html><head><title>
-Quick Start
-</title></head><body><h3>
-Quick Start
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Quick Start</title>
+</head>
+<body>
+<h3>Quick Start</h3>
-<img align=left src=pic/panda.gif>FAX test image for SATNET (1979).
+<img align="left" src="pic/panda.gif" alt="gif">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/~mills/database/papers/fuzz.ps>Fuzzball </A>. As it happened, this was also the first Internet multimedia presentation and the first to use NTP in regular operation. The image was widely copied and used for testing purpose throughout much of the 1980s.
-<br clear=left><hr>
+<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/~mills/database/papers/fuzz.ps">
+Fuzzball</a> . As it happened, this was also the first Internet
+multimedia presentation and the first to use NTP in regular
+operation. The image was widely copied and used for testing purpose
+throughout much of the 1980s.<br clear="left">
+</p>
-<p>This page describes what to expect when the NTP daemon <tt>ntpd</tt> is started for the first time. The discussion presumes the programs in this distribution have been compiled and installed as described in the <a href=build.htm>Building and Installing the Distribution</a> page.
+<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.htm">Building and Installing the
+Distribution</a> page describes how to do this.</p>
-<p>When the daemon is started, whether for the first or subsequent times, a number of roundtrip samples are required to accumulate reliable measurements of network path delay and clock offset relative to the server(s). Normally, this takes about four minutes, after which the local clock is synchronized to the server. The daemon behavior at startup depends on whether a drift file <tt>ntp.drift</tt> exists. This file contains the latest estimate of local clock frequency error. When the daemon is started for the first time, this file is created after about one hour of operation and updated once each hour after that. When the daemon is started and the file does not exist, the daemon enters a special mode designed to quickly adapt to the particular system clock oscillator time and frequency error. This takes approximately 15 minutes, after which the time and frequency are set to nominal values and the daemon enters normal mode, where the time and frequency are continuously tracked relative to the server.
+<p>While it is possible that certain configurations do not need a
+configuration file, most do require one. Strictly speaking, the
+file need only contain one line specifying a remote server, for
+instance</p>
-<p>As a practical matter, once the local clock has been set, it very rarely strays more than 128 ms relative to the server, even under extreme cases of network path congestion and jitter. Sometimes, in particular when the daemon is first started, the relative clock offset exceeds 128 ms. In such cases the normal behavior of the daemon is to set the clock directly, rather than rely on gradual corrections. This may cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the <tt>-x</tt> option is included on the command line that starts the daemon, the clock will never be stepped and only slew corrections will be used.
+<p><tt>server foo.bar.com</tt></p>
-<p>The issues should be carefully explored before deciding to use the <tt>-x</tt> option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.
+<p>Choosing an appropriate remote server is somewhat of a black
+art, but a suboptimal choice is seldom a problem. Links to public
+time servers operated by National Institutes of Science and
+Technology (NIST), US Naval Observatory (USNO), Canadian Metrology
+Centre (CMC) and many others are given in the home page of this
+document collection. 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>There may be an occasional outlyer, where an individual measurement exceeds 128 ms. When the frequency of occurrence of these outlyers is low, the measurement is discarded and operation continues with the next one. However, if the outlyers persist for an interval longer than about 15 minutes, the next value is believed and the clock stepped or slewed as determined by the <tt>-x</tt> option. The usual reason for this behavior is when a leap second has occurred, but the reference clock receiver has not synchronized to it. When leap second support is implemented in the kernel, the kernel implements it as directed by the NTP daemon. If this happens and the reference clock source resynchronizes correctly within 15 minutes, the transient misbehavior of the source is transparent.
+<p>During operation <tt>ntpd</tt> measures and corrects for
+incidental clock frequency error and writes the current value to a
+file if enabled. If the <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. Thus, for most applications an additional line should be
+added to the file of the form</p>
-<p>It has been observed that, as the result of extreme network congestion, the roundtrip delays can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus the error budget terms, can become very large. When the synchronization distance exceeds one second, the offset measurement is discarded. If this condition persists for several poll intervals, the server may be declared unreachable. Sometimes the large jitter results in large frequency errors which result in straying outside the acceptable offset range and an eventual step or slew time correction. If following such a correction the frequency error is so large that the first sample is outside the acceptable range, the daemon enters the same state as when the <tt>ntp.drift</tt> file is not present. The intent of this behavior is to quickly correct the frequency and restore operation to the normal tracking mode. In the most extreme cases (<tt>time.ien.it</tt> comes to mind), there may be occasional step/slew corrections and subsequent frequency corrections. It helps in these cases to use burst mode when configuring the server.
+<p><tt>driftfile /etc/ntp.drift</tt></p>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
+<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.htm"><tt>ntpq</tt></a> utility, although the <a href=
+"ntpdc.htm"><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.htm">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.htm">Notes on Configuring NTP and Setting up a NTP
+Subnet</a> page contains an extended discussion of these
+options.</p>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
<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.htm>Audio Drivers</a> page.
+<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=driver1.htm>Undisciplined Local Clock</a> page and respect the stratum limit.
+
<h4>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=qth.htm>Stations, Frequencies and Geographic Coordinates</a> page. Receiver coordinates can be obtained or estimated from various sources. The actual calculations are beyond the scope of this document.
-<html><head><title>
-NTP Version 4 Release Notes
-</title></head><body><h3>
-NTP Version 4 Release Notes
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>NTP Version 4 Release Notes</title>
+</head>
+<body>
+<h3>NTP Version 4 Release Notes</h3>
-<img align=left src=pic/hornraba.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+<img align="left" src="pic/hornraba.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
-<p>The rabbit toots to make sure you read thie.
-<br clear=left><hr>
+<p>The rabbit toots to make sure you read this.<br clear="left">
+</p>
-<p>This document was last updated 31 December 2000
+<hr>
+<p>This document was last updated 31 December 2000</p>
<h4>NTP Version 4 Release Notes</h4>
-<p>This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions. The NTPv4 version has been under development for quite a while and isn't finished yet. In fact, quite a number of NTPv4 features have already been retrofitted in the current NTPv3, although this version is not actively maintained by the NTPv4 developer's group.
-
-<p>The primary purpose of this release is to verify the remaining new code compiles and runs in the various architectures, operating systems and hardware complement that can't be verified here. Of particular interest are Windows 2000, VMS and various reference clock drivers. As always, corrections and bugfixes are warmly received, especially in the form of context diffs.
-
-<p>This note summarizes the differences between this software release of NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called xntp3-5.x.x. Additional information on protocol compatibility details is in the <a href=biblio.htm>Protocol Conformance Statement</a> page.
+<p>This release of the NTP Version 4 (NTPv4) daemon for Unix
+incorporates new features and refinements to the NTP Version 3
+(NTPv3) algorithms. However, it continues the tradition of
+retaining backwards compatibility with older versions. The NTPv4
+version has been under development for quite a while and isn't
+finished yet. In fact, quite a number of NTPv4 features have
+already been retrofitted in the current NTPv3, although this
+version is not actively maintained by the NTPv4 developer's
+group.</p>
+
+<p>The primary purpose of this release is to verify the remaining
+new code compiles and runs in the various architectures, operating
+systems and hardware complement that can't be verified here. Of
+particular interest are Windows 2000, VMS and various reference
+clock drivers. As always, corrections and bugfixes are warmly
+received, especially in the form of context diffs.</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. Additional information on protocol
+compatibility details is in the <a href="biblio.htm">Protocol
+Conformance Statement</a> page.</p>
<ol>
-
-<p><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>
-
-<p><li>The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow an increase in poll intervals to well over one day with only moderate sacrifice in accuracy. The NTPv4 design allows servers to increase the poll intervals even when synchronized directly to the peer. In NTPv3 the poll interval in such cases was clamped to the minimum, usually 64 s. For those servers with hundreds of clients, the new design can dramatically reduce the network load.</li>
-
-<p><li>This release includes support for the <a href=http://www.eecis.udel.edu/~mills/resource.htm><i>nanokernel</i></a> precision time kernel support, which is now in stock Linux and FreeBSD 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 less than one microsecond. The older precision time kernel for the Alpha continues to be supported.
-
-<p><li>This release includes support for Autokey public-key cryptography, which is the preferred scheme for authenticating servers to clients. It uses NTP header extensions fields documented in: Mills, D.L. Public-Key cryptography for the Network Time Protocol. Internet Draft draft-ietf-stime-ntpauth-00.txt, University of Delaware, June 2000, 36 pp. <a href=http://www.eecis.udel.edu/~mills/database/memos/draft-ietf-stime-ntpauth-00.txt>ASCII</a> and implemented in this release. The design provides for orderly key refreshment and does not require public keys and related media to be copied from one machine to another. Specific information about Autokey cryptography is contained in the <a href=authopt.htm>Authentication Options</a> page and links from there.</li>
-
-<p><li>NTPv4 includes two new association modes which in most applications can avoid per-host configuration altogether. Both of these are based on IP multicast technology and Autokey cryptography. They provide for automatic discovery and configuration 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. Upon receiving the message, a client exchanges several messages with the server in order to calibrate the multicast propagation delay between the client and server. In 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 in ordinary client/server operation. The manycast scheme can provide somewhat better accuracy than the multicast scheme at the price of additional network overhead. See the <a href=assoc.htm>Association Management</a> page for further information.</li>
-
-<p><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 rocedure. See the <a href=assoc.htm>Association Management</a> page for further information.</li>
-
-<p><li>The reference clock driver interface is smaller, more rational and more accurate. Support for pulse-per-second (PPS) signals has been extended to all drivers as an intrinsic function. Most of the drivers in NTPv3 have been converted to this interface, but some, including the PARSE subinterface, have yet to be overhauled. New drivers have been added for several GPS receivers now on the market for a total of 37 drivers. Drivers for the Canadian standard time and frequency station CHU, the US standard time and frequency stations WWV/H and for IRIG signals have been updated and capabilities added to allow direct connection of these signals to the Sun audio port <tt>/dev/audio</tt>.</li>
-
-<p><li>In all except a very few cases, all timing intervals are randomized, so that the tendency for NTPv3 to self-synchronize and bunch messages, especially with a large number of configured associations, is minimized.</li>
-
-<p><li>In NTPv3 a large number of weeds and useless code had grown over the years since the original NTPv1 code was implemented almost 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>
-
-<p><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.</li>
-
+<li>
+<p>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.</p>
+</li>
+
+<li>
+<p>The clock discipline algorithm has been redesigned to improve
+accuracy, reduce the impact of network jitter and allow an increase
+in poll intervals to well over one day with only moderate sacrifice
+in accuracy. The NTPv4 design allows servers to increase the poll
+intervals even when synchronized directly to the peer. In NTPv3 the
+poll interval in such cases was clamped to the minimum, usually 64
+s. For those servers with hundreds of clients, the new design can
+dramatically reduce the network load.</p>
+</li>
+
+<li>
+<p>This release includes support for the <a href=
+"http://www.eecis.udel.edu/~mills/resource.htm"><i>
+nanokernel</i></a> precision time kernel support, which is now in
+stock Linux and FreeBSD 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 less than one microsecond.
+The older precision time kernel for the Alpha continues to be
+supported.</p>
+</li>
+
+<li>
+<p>This release includes support for Autokey public-key
+cryptography, which is the preferred scheme for authenticating
+servers to clients. It uses NTP header extensions fields documented
+in: Mills, D.L. Public-Key cryptography for the Network Time
+Protocol. Internet Draft draft-ietf-stime-ntpauth-00.txt,
+University of Delaware, June 2000, 36 pp. <a href=
+"http://www.eecis.udel.edu/~mills/database/memos/draft-ietf-stime-ntpauth-00.txt">
+ASCII</a> and implemented in this release. The design provides for
+orderly key refreshment and does not require public keys and
+related media to be copied from one machine to another. Specific
+information about Autokey cryptography is contained in the <a href=
+"authopt.htm">Authentication Options</a> page and links from
+there.</p>
+</li>
+
+<li>
+<p>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 for automatic discovery and
+configuration 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. Upon receiving the message, a
+client exchanges several messages with the server in order to
+calibrate the multicast propagation delay between the client and
+server. In 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 in
+ordinary client/server operation. The manycast scheme can provide
+somewhat better accuracy than the multicast scheme at the price of
+additional network overhead. See the <a href="assoc.htm">
+Association Management</a> page for further information.</p>
+</li>
+
+<li>
+<p>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.htm">Association Management</a> page for further
+information.</p>
+</li>
+
+<li>
+<p>The reference clock driver interface is smaller, more rational
+and more accurate. Support for pulse-per-second (PPS) signals has
+been extended to all drivers as an intrinsic function. Most of the
+drivers in NTPv3 have been converted to this interface, but some,
+including the PARSE subinterface, have yet to be overhauled. New
+drivers have been added for several GPS receivers now on the market
+for a total of 37 drivers. Drivers for the Canadian standard time
+and frequency station CHU, the US standard time and frequency
+stations WWV/H and for IRIG signals have been updated and
+capabilities added to allow direct connection of these signals to
+the Sun audio port <tt>/dev/audio</tt>.</p>
+</li>
+
+<li>
+<p>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.</p>
+</li>
+
+<li>
+<p>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.</p>
+</li>
+
+<li>
+<p>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.</p>
+</li>
</ol>
<h4>Nasty Surprises</h4>
-There are a few things different about this release that have changed since the latest NTP Version 3 release. Following are a few things to worry about:
+There are a few things different about this release that have
+changed since the latest NTP Version 3 release. Following are a few
+things to worry about:
<ol>
-
-<p><li>As required by Defense Trade Regulations (DTR), the cryptographic routines supporting the Data Encryption Standard (DES) have been removed from the base distribution. These routines are readily available in most countries from RSA Laboratories. Directions for their use are in the <a href=build.htm>Building and Installing the Distribution</a> page.</li>
-
-<p><li>As the result of the above, the <tt>./authstuff</tt> directory, intended as a development and testing aid for porting cryptographic routines to exotic architectures, has been removed. Developers should note the NTP authentication routines use the interface defined in the <tt>rsaref2.0</tt> package available from RSA laboratories.</li>
-
-<p><li>The enable and disable commands have a few changes in their arguments see the <tt>ntpd</tt> <a href=confopt.htm>Configuration Options</a> page for details.</li>
-
-<p><li>The <tt>ppsclock</tt> line discipline/streams module is no longer supported. This function is now handled by the <a href=driver22.htm>PPS Clock Discipline</a> driver, which uses the new PPSAPI application program interface proposed by the IETF.</li>
-
+<li>
+<p>As required by Defense Trade Regulations (DTR), the
+cryptographic routines supporting the Data Encryption Standard
+(DES) have been removed from the base distribution. These routines
+are readily available in most countries from RSA Laboratories.
+Directions for their use are in the <a href="build.htm">Building
+and Installing the Distribution</a> page.</p>
+</li>
+
+<li>
+<p>As the result of the above, the <tt>./authstuff</tt> directory,
+intended as a development and testing aid for porting cryptographic
+routines to exotic architectures, has been removed. Developers
+should note the NTP authentication routines use the interface
+defined in the <tt>rsaref2.0</tt> package available from RSA
+laboratories.</p>
+</li>
+
+<li>
+<p>The enable and disable commands have a few changes in their
+arguments see the <tt>ntpd</tt> <a href="confopt.htm">Configuration
+Options</a> page for details.</p>
+</li>
+
+<li>
+<p>The <tt>ppsclock</tt> line discipline/streams module is no
+longer supported. This function is now handled by the <a href=
+"driver22.htm">PPS Clock Discipline</a> driver, which uses the new
+PPSAPI application program interface proposed by the IETF.</p>
+</li>
+
+<li>
+<p>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. It is possible to operate the daemon
+in a one-time mode similar to <tt>ntpdate</tt>, which program is
+headed for retirement. See the documentation page for the new
+features.</p>
+</li>
</ol>
<h4>Caveats</h4>
-This release has been compiled and tested on several systems, including SunOS 4.1.3, Solaris 2.5.1-2.8, Alpha 4.0, Ultrix 4.4, Linux, FreeBSD 3.4 and HP-UX 10.02. It has been compiled and tested on Windows NT, but not yet on any other Windows version or for VMS. We are relying on the NTP volunteer corps to do that. Known problems are summarized below:
+This release has been compiled and tested on several systems,
+including SunOS 4.1.3, Solaris 2.5.1-2.8, Alpha 4.0, Ultrix 4.4,
+Linux, FreeBSD and HP-UX 10.02. It has been compiled and tested on
+Windows NT, but not yet on any other Windows version or for VMS. We
+are relying on the NTP volunteer corps to do that. Known problems
+are summarized below:
<ol>
+<li>
+<p>The latest NTPv4 <tt>ntpdc</tt> does not work with previous
+versions of <tt>ntpd</tt> and previous versions of <tt>ntpdc</tt>
+do not work with latest <tt>ntpd</tt>. This situation is
+regrettable and may be fixed in future; however, it is necessary in
+order for the autokey function to retrieve canonical names and
+certificates from directory services such as Secure DNS.</p>
+</li>
+
+<li>
+<p>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 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>.</p>
+</li>
+
+<li>
+<p>The HTML documentation has been partially updated. However, most
+of the NTPv3 documentation continues to apply to NTPv4. Until the
+update happens, what you see is what you get. We are always happy
+to accept comments, corrections and bug reports. However, we are
+most thrilled upon receipt of patches to fix the dang bugs.</p>
+</li>
+</ol>
-<p><li>The latest NTPv4 <tt>ntpdc</tt> does not work with previous versions of <tt>ntpd</tt> and previous versions of <tt>ntpdc</tt> do not work with latest <tt>ntpd</tt>. This situation is regrettable and may be fixed in future; however, it is necessary in order for the autokey function to retrieve canonical names and certificates from directory services such as Secure DNS.
-
-<p><li>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 kernel discipline has been disabled by default. For testing, the kernel can be enabled using the <tt>enable kernel</tt> command either in the configuration file or via <tt>ntpdc</tt>.</li>
-
-<p><li>The HTML documentation has been partially updated. However, most of the NTPv3 documentation continues to apply to NTPv4. Until the update happens, what you see is what you get. We are always happy to accept comments, corrections and bug reports. However, we are most thrilled upon receipt of patches to fix the dang bugs.</li>
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
-</ol>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
-<HTML><HEAD><TITLE>
-<TT>tickadj</TT> - set time-related kernel variables
-</TITLE></HEAD><BODY><H3>
-<TT>tickadj</TT> - set time-related kernel variables
-</H3><HR>
-
-<H4>Synopsis</H4>
-
-<TT>tickadj [ -Aqs ] [ -a <I>tickadj</I> ] [ -t <I>tick</I> ]</TT>
-
-<H4>Description</H4>
-
-The <TT>tickadj</TT> program reads, and optionally modifies, several
-timekeeping-related variables in the running kernel in some machines,
-via <TT>/dev/kmem</TT>. The particular variables it is concerned with
-are <TT>tick</TT>, which is the number of microseconds added to the
-system time during 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>Note that this program does NOT work in some kernels, in particular
-Solaris 2.6 or later. See the <A HREF="solaris-dosynctodr.html">
-report</A>.
-
-<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>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.
-<H4>
-Command Line Options</H4>
-
-<DL>
-
-<DT><TT>-a <I>tickadj</I></TT></DT>
-<DD>Set the kernel variable <TT>tickadj</TT> to the value
-<I><TT>tickadj</TT></I>specified.</DD>
-
-<DT><TT>-A</TT></DT>
-<DD>Set the kernel variable <TT>tickadj</TT> to an internally computed
-"optimal" value.</DD>
-
-<DT><TT>-t <I>tick</I></TT></DT>
-<DD>Set the kernel variable <TT>tick</TT> to the value
-<I><TT>tick</TT></I> specified.</DD>
-
-<DT><TT>-s</TT></DT>
-<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.</DD>
-
-<DT><TT>-q</TT></DT>
-<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.</DD>
-
-</DL>
-
-<H4>Files</H4>
-
-<PRE>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>tickadj - set time-related kernel variables</title>
+</head>
+<body>
+<h3><tt>tickadj</tt> - set time-related kernel variables</h3>
+
+<hr>
+<h4>Synopsis</h4>
+
+<tt>tickadj [ -Aqs ] [ -a <i>tickadj</i> ] [ -t <i>tick</i> ]</tt>
+
+<h4>Description</h4>
+
+The <tt>tickadj</tt> program reads, and optionally modifies,
+several timekeeping-related variables in the running kernel in some
+machines, via <tt>/dev/kmem</tt>. The particular variables it is
+concerned with are <tt>tick</tt>, which is the number of
+microseconds added to the system time during 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>Note that this program does NOT work in some kernels, in
+particular Solaris 2.6 or later. See the <a href=
+"solaris-dosynctodr.html">report</a>.</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>
+
+<dl>
+<dt><tt>-a <i>tickadj</i></tt></dt>
+
+<dd>Set the kernel variable <tt>tickadj</tt> to the value <i><tt>
+tickadj</tt></i>specified.</dd>
+
+<dt><tt>-A</tt></dt>
+
+<dd>Set the kernel variable <tt>tickadj</tt> to an internally
+computed "optimal" value.</dd>
+
+<dt><tt>-t <i>tick</i></tt></dt>
+
+<dd>Set the kernel variable <tt>tick</tt> to the value <i><tt>
+tick</tt></i> specified.</dd>
+
+<dt><tt>-s</tt></dt>
+
+<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.</dd>
+
+<dt><tt>-q</tt></dt>
+
+<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.</dd>
+</dl>
+
+<h4>Files</h4>
+
+<pre>
/vmunix
/unix
-/dev/kmem</PRE>
+/dev/kmem
+</pre>
-<H4>Bugs</H4>
+<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><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+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>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
-<html><head<title>
-Network Time Protocol Year 2000 Conformance Statement
-</title></head><body><h3>
-Network Time Protocol Year 2000 Conformance Statement
-</h3>
-
-<img align=left src=pic/alice15.gif><a href=http://www.eecis.udel.edu/~mills/pictures.htm>
-from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>The Mad Hatter and the March Hare are discussing whether the Teapot
-serial number should have two or four digits.
-
-<br clear=left><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+&lt;html>
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Network Time Protocol Year 2000 Conformance
+Statement</title>
+</head>
+<body>
+<h3>Network Time Protocol Year 2000 Conformance Statement</h3>
+
+<img align="left" src="pic/alice15.gif" alt="gif"><a href=
+"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
+Carroll</a>
+
+<p>The Mad Hatter and the March Hare are discussing whether the
+Teapot serial number should have two or four digits.<br clear=
+"left">
+</p>
+
+<hr>
<h4>Introduction</h4>
By the year 2000, the Network Time Protocol (NTP) will have been in
-use for over two decades and remain the longest running, continuously
-operating application protocol in the Internet. There is some concern,
-especially in government and financial institutions, that NTP might
-cause Internet applications to misbehave in terrible ways on the epoch
-of the next century. This document presents an analysis of the various
-hazards that might result in incorrect time values upon this epoch. It
-concludes that incorrect time values due to the NTP timescale, protocol
-design and reference implementation are highly unlikely. However, it is
+use for over two decades and remain the longest running,
+continuously operating application protocol in the Internet. There
+is some concern, especially in government and financial
+institutions, that NTP might cause Internet applications to
+misbehave in terrible ways on the epoch of the next century. This
+document presents an analysis of the various hazards that might
+result in incorrect time values upon this epoch. It concludes that
+incorrect time values due to the NTP timescale, protocol design and
+reference implementation are highly unlikely. However, it is
possible that external reference time sources used by NTP could
-misbehave and cause NTP servers to distribute incorrect time values to
-significant portions of the Internet. Note that, while this document
-addresses the issues specifically with respect to Unix systems, the
-issues are equally applicable to Windows and VMS systems.
+misbehave and cause NTP servers to distribute incorrect time values
+to significant portions of the Internet. Note that, while this
+document addresses the issues specifically with respect to Unix
+systems, the issues are equally applicable to Windows and VMS
+systems.
<h4>The NTP Timescale</h4>
-It will be helpful in understanding the issues raised in this document
-to consider the concept of a universal timescale. The conventional civil
-timescale used in most parts of the world is based on Universal
-Coordinated Time (UTC sic), formerly known as Greenwich Mean Time (GMT).
-UTC is based on International Atomic Time (TAI sic), which is derived
-from hundreds of cesium clocks in the national standards laboratories of
-many countries. Deviations of UTC from TAI are implemented in the form
-of leap seconds, which occur on average every eighteen months. For
-almost every computer application today, UTC represents the universal
-timescale extending into the indefinite past and indefinite future. We
-know of course that the UTC timescale did not exist prior to 1972, the
-Gregorian calendar did not exist prior to 1582, the Julian calendar did
-not exist prior to 54 BC and we cannot predict exactly when the next
-leap second will occur. Nevertheless, most folks would prefer that, even
-if we can't get future seconds numbering right beyond the next leap
-second, at least we can get the days numbering right until the end of
-reason.
-
-<p>The universal timescale can be implemented using a binary counter of
-indefinite width and with the unit seconds bit placed somewhere in the
-middle. The counter is synchronized to UTC such that it runs at the same
-rate and the units increment coincides with the UTC seconds tick. The
-NTP timescale is constructed from 64 bits of this counter, of which 32
-bits number the seconds and 32 bits represent the fraction. With this
-design, the counter runs in 136-year cycles, called eras, the latest of
-which began with a counter value of zero at 0h 1 January 1900. The
-design assumption is that further low order bits, if required, are
-provided by local interpolation, while further high order bits, when
-required, are provided by external means. The important point to be made
-here is that the high order bits must ultimately be provided by
-astronomers and disseminated to the population by international means.
-Ultimately, should a need exist to align a particular NTP era to the
-current calendar, the operating system in which NTP is embedded must
-provide the necessary high order bits, most conveniently from the file
-system or flash memory.
+It will be helpful in understanding the issues raised in this
+document to consider the concept of a universal timescale. The
+conventional civil timescale used in most parts of the world is
+based on Universal Coordinated Time (UTC sic), formerly known as
+Greenwich Mean Time (GMT). UTC is based on International Atomic
+Time (TAI sic), which is derived from hundreds of cesium clocks in
+the national standards laboratories of many countries. Deviations
+of UTC from TAI are implemented in the form of leap seconds, which
+occur on average every eighteen months. For almost every computer
+application today, UTC represents the universal timescale extending
+into the indefinite past and indefinite future. We know of course
+that the UTC timescale did not exist prior to 1972, the Gregorian
+calendar did not exist prior to 1582, the Julian calendar did not
+exist prior to 54 BC and we cannot predict exactly when the next
+leap second will occur. Nevertheless, most folks would prefer that,
+even if we can't get future seconds numbering right beyond the next
+leap second, at least we can get the days numbering right until the
+end of reason.
+
+<p>The universal timescale can be implemented using a binary
+counter of indefinite width and with the unit seconds bit placed
+somewhere in the middle. The counter is synchronized to UTC such
+that it runs at the same rate and the units increment coincides
+with the UTC seconds tick. The NTP timescale is constructed from 64
+bits of this counter, of which 32 bits number the seconds and 32
+bits represent the fraction. With this design, the counter runs in
+136-year cycles, called eras, the latest of which began with a
+counter value of zero at 0h 1 January 1900. The design assumption
+is that further low order bits, if required, are provided by local
+interpolation, while further high order bits, when required, are
+provided by external means. The important point to be made here is
+that the high order bits must ultimately be provided by astronomers
+and disseminated to the population by international means.
+Ultimately, should a need exist to align a particular NTP era to
+the current calendar, the operating system in which NTP is embedded
+must provide the necessary high order bits, most conveniently from
+the file system or flash memory.</p>
<h4>The Year 2000 Era</h4>
-With respect to the year 2000 issue, the most important thing to observe
-about the NTP timescale is that it knows nothing about days, years or
-centuries, only the seconds since the beginning of the latest era, the
-current one of which began on 1 January 1900. On 1 January 1970 when
-Unix life began, the NTP timescale showed 2,208,988,800 and on 1 January
-1972 when UTC life began, it showed 2,272,060,800. On the last second of
-year 1999, the NTP timescale will show 3,155,672,599 and one second
-later on the first second of the next century will show 3,155,672,600.
-Other than this observation, the NTP timescale has no knowledge of or
-provision for any of these eclectic seconds.
+With respect to the year 2000 issue, the most important thing to
+observe about the NTP timescale is that it knows nothing about
+days, years or centuries, only the seconds since the beginning of
+the latest era, the current one of which began on 1 January 1900.
+On 1 January 1970 when Unix life began, the NTP timescale showed
+2,208,988,800 and on 1 January 1972 when UTC life began, it showed
+2,272,060,800. On the last second of year 1999, the NTP timescale
+will show 3,155,673,599 and one second later on the first second of
+the next century will show 3,155,673,600. Other than this
+observation, the NTP timescale has no knowledge of or provision for
+any of these eclectic seconds.
<p>The NTP timescale is almost never used directly by system or
-application programs. The generic Unix kernel keeps time in seconds and
-microseconds (or nanoseconds) to provide both time of day and interval
-timer functions. In order to synchronize the Unix clock, NTP must
-convert to and from its representation and Unix representation. Unix
-kernels implement the time of day function using two 32-bit counters,
-one representing the seconds since Unix life began and the other the
-microseconds or nanoseconds of the second. In principle, the seconds
-counter will wrap around in 136-year eras, the next of which will begin
-in 2106. How the particular Unix semantics interprets the counter values
-is of concern, but is beyond the scope of discussion here.
-
-<p>While incorrect time values due to the NTP timescale and protocol
-design or reference implementation upon the epoch of the next century
-are highly unlikely, hazards remain due to incorrect software external
-to NTP. These hazards include the Unix kernel and library routines which
-convert Unix time to and from conventional civil time in seconds,
-minutes, hours, days and years. Although NTP uses these routines to
-format monitoring data displays, they are not used to read or set the
-NTP clock. They may in fact cause problems with certain application
-programs, but this is not an issue which concerns NTP correctness.
-
-<p>While it is extremely unlikely that NTP will produce incorrect time
-values upon the epoch, it is possible that some external source to which
-NTP synchronizes may produce a discontinuity which could then induce a
-NTP discontinuity. The NTP primary (stratum 1) time servers, which are
-the ultimate time references for the entire NTP population, obtain time
-from various sources, including radio and satellite receivers and
-telephone modems. Not all sources provide year information and not all
-of these provide time in four-digit form. In point of fact, the NTP
-reference implementation does not use the year information, even if
-available. Instead, the year information is provided from the file
-system, which itself depends on the Unix clock.
-
-<p>The NTP protocol specification requires the apparent NTP time derived
-from external servers to be compared to the file system time before the
-clock is set. If the discrepancy is over 1000 seconds, an error alarm is
-raised requiring manual intervention. This makes it very unlikely that
-even a clique of seriously corrupted NTP servers will result in
-incorrect time values. In the case of embedded computers with no file
-system, the design assumption is that the current era be established
-from flash memory or a clock chip previously set by manual means.
-
-<p>It is essential that any clock synchronization protocol, including
-NTP, include provisions for multiple-server redundancy and multiple-
-route diversity. Past experience has demonstrated the wisdom of this
-approach, which protects clients against hardware and software faults,
-as well as incorrectly operating reference sources and sometimes even
-buggy software. For the most reliable service, we recommend multiple
-reference sources for primary servers, including a backup radio or
-satellite receiver or telephone modem. We also recommend that primary
-servers run NTP with other primary servers to provide additional
-redundancy and mutual backup should the reference sources themselves
-fail or operate incorrectly.
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+application programs. The generic Unix kernel keeps time in seconds
+and microseconds (or nanoseconds) to provide both time of day and
+interval timer functions. In order to synchronize the Unix clock,
+NTP must convert to and from its representation and Unix
+representation. Unix kernels implement the time of day function
+using two 32-bit counters, one representing the seconds since Unix
+life began and the other the microseconds or nanoseconds of the
+second. In principle, the seconds counter will wrap around in
+136-year eras, the next of which will begin in 2106. How the
+particular Unix semantics interprets the counter values is of
+concern, but is beyond the scope of discussion here.</p>
+
+<p>While incorrect time values due to the NTP timescale and
+protocol design or reference implementation upon the epoch of the
+next century are highly unlikely, hazards remain due to incorrect
+software external to NTP. These hazards include the Unix kernel and
+library routines which convert Unix time to and from conventional
+civil time in seconds, minutes, hours, days and years. Although NTP
+uses these routines to format monitoring data displays, they are
+not used to read or set the NTP clock. They may in fact cause
+problems with certain application programs, but this is not an
+issue which concerns NTP correctness.</p>
+
+<p>While it is extremely unlikely that NTP will produce incorrect
+time values upon the epoch, it is possible that some external
+source to which NTP synchronizes may produce a discontinuity which
+could then induce a NTP discontinuity. The NTP primary (stratum 1)
+time servers, which are the ultimate time references for the entire
+NTP population, obtain time from various sources, including radio
+and satellite receivers and telephone modems. Not all sources
+provide year information and not all of these provide time in
+four-digit form. In point of fact, the NTP reference implementation
+does not use the year information, even if available. Instead, the
+year information is provided from the file system, which itself
+depends on the Unix clock.</p>
+
+<p>The NTP protocol specification requires the apparent NTP time
+derived from external servers to be compared to the file system
+time before the clock is set. If the discrepancy is over 1000
+seconds, an error alarm is raised requiring manual intervention.
+This makes it very unlikely that even a clique of seriously
+corrupted NTP servers will result in incorrect time values. In the
+case of embedded computers with no file system, the design
+assumption is that the current era be established from flash memory
+or a clock chip previously set by manual means.</p>
+
+<p>It is essential that any clock synchronization protocol,
+including NTP, include provisions for multiple-server redundancy
+and multiple- route diversity. Past experience has demonstrated the
+wisdom of this approach, which protects clients against hardware
+and software faults, as well as incorrectly operating reference
+sources and sometimes even buggy software. For the most reliable
+service, we recommend multiple reference sources for primary
+servers, including a backup radio or satellite receiver or
+telephone modem. We also recommend that primary servers run NTP
+with other primary servers to provide additional redundancy and
+mutual backup should the reference sources themselves fail or
+operate incorrectly.</p>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"home"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
projects / thirdparty / ntp.git / commitdiff
