<body>
<h3>Access Control Options</h3>
- <img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The skunk watches for intruders and sprays.</p>
<h4>Related Links</h4>
<p>
<body>
<h3>Association Management</h3>
- <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
<h4>Related Links</h4>
<p>
<body>
<h3>Authentication Options</h3>
- <img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
<li class="inline"><a href="#symm">Symmetric Key Cryptography</a>
<li class="inline"><a href="#pub">Public Key Cryptography</a>
<li class="inline"><a href="#auto">Autokey Dances</a>
- <li class="inline"><a href="#inter">Interoperability</a>
+ <li class="inline"><a href="#inter">Operation</a>
<li class="inline"><a href="#key">Key Management</a>
<li class="inline"><a href="#rand">Random Seed File</a>
<li class="inline"><a href="#cmd">Authentication Commands</a>
<p>NTPv4 retains the NTPv3 scheme, properly described as symmetric key cryptography and, in addition, provides a new Autokey scheme based on public key cryptography. Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on 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. Public key management is based on X.509 certificates, which can be provided by commercial services or produced by utility programs in the OpenSSL software library or the NTPv4 distribution.</p>
<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> subcommand on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> configuration commands as described in the <a href="confopt.html">Configuration Options</a> page. The authentication options described below specify the suite of keys, select the key for each configured association and manage the configuration operations. In addition, if public key cryptography is enabled, the commands specify the message digest and signature encryption scheme.</p>
<p>Authentication is always enabled, although ineffective if not configured as described below. If a NTP packet arrives including a message authentication code (MAC), only if it passes all cryptographic checks is it accepted for further processing. The checks require correct key ID, key value and message digest. If the packet has been modified in any way or replayed by an intruder, it will fail one or more of these checks and be discarded. Furthermore, the Autokey scheme requires a preliminary protocol exchange to obtain the server public key, verify its credentials and compute a private session key.</p>
- <p>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running in another machine. If this flag is enabled, which is the default case, new broadcast/manycast 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 with the <tt>auth</tt> disabled invites a significant vulnerability where a rogue hacker can seriously disrupt system timekeeping. It is important to note that this flag has no purpose other than to allow or disallow a new association in response to new broadcast and symmetric active messages and remote configuration commands and, in particular, the flag has no effect on the authentication process itself.</p>
- <p>An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers as described in the <a href="assoc.html">Association Management</a> page. Either symmetric key or public key cryptographic authentication can be used in this mode. The principle advantage of 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>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running in another machine. If this flag is enabled, which is the default case, new broadcast/manycast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric key or public key cryptography. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating with the <tt>auth</tt> disabled invites a significant vulnerability where a rogue hacker can seriously disrupt system timekeeping. It is important to note that this flag has no purpose other than to allow or disallow a new association in response to new broadcast and symmetric active messages and remote configuration commands and, in particular, the flag has no effect on the authentication process itself.</p>
+ <p>An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers as described in the <a href="manyopt.html">Automatic NTP Configuration Options</a> page. Either symmetric key or public key cryptographic authentication can be used in this mode. The principle advantage of 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>While the algorithms for symmetric key cryptography are included in the NTPv4 distribution, public key cryptography requires the OpenSSL software library to be installed before building the NTP distribution. Directions for doing that are on the <a href="build.html">Building and Installing the Distribution</a> page.</p>
<p>The security model and protocol schemes for both symmetric key and public key cryptography are summarized below; further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
<h4 id="#symm">Symmetric Key Cryptography</h4>
The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.
<p>When <tt>ntpd</tt> is first started, it reads the key file specified in the <tt>keys</tt> configuration command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trusted</tt> command before use. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using <tt>ntpdc</tt>. This also provides a revocation capability that can be used if a key becomes compromised. The <tt>requestkey</tt> command selects the key used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key used as the password for the <tt>ntpq</tt> utility.</p>
<h4 id="#pub">Public Key Cryptography</h4>
- <p>NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. The Autokey Version 2 protocol verifies packet integrity using MD5 message digests and verifies the source with digital signatures and any of several digest/signature schemes. Optional identification schemes based on cryptographic challenge/response algorithms are also available. Using all of these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.</p>
+ <p>NTPv4 supports the original NTPv3 symmetric key scheme described in RFC-1305 and in addition the Autokey protocol, which is based on public key cryptography. The Autokey Version 2 protocol verifies packet integrity using MD5 message digests and verifies the source with digital signatures and any of several digest/signature schemes. Optional identity schemes based on cryptographic challenge/response algorithms are also available. Using all of these schemes provides strong security against replay with or without modification, spoofing, masquerade and most forms of clogging attacks.</p>
<p>The cryptographic means necessary for all Autokey operations provided by the OpenSSL software library. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the interface routines required.</p>
- <p>The Autokey protocol has several modes of operation corresponding to the various NTP modes supported. Most modes use a special cookie which can be computed independently by the client and server, but encrypted in transmission. All modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. These schemes are described along with an executive summary, current status, briefing slides and reading list, on the <a href="http://www.eecis.udel.edu/%7emills/autokey.htm">Autonomous Authentication</a> page.</p>
- <p>The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links. This includes a required host key file, required certificate file and optional sign key file, leapsecond file and identi
fication scheme files. The digest/signature scheme is specified in the X.509 certificate along with the matching sign key. There are several schemes available in the OpenSSL software library, each identified by a specific string such as <tt>md5WithRSAEncryption</tt>, which stands for the MD5 message digest with RSA encryption scheme. The current NTP distribution supports all the schemes in the OpenSSL library, including those based on RSA and DSA digital signatures. The schemes currently available are described in the <a href="genkeys.html"><tt>ntp-keygen</tt></a> page.</p>
+ <p>The Autokey protocol has several modes of operation corresponding to the various NTP modes supported. Most modes use a special cookie which can be computed independently by the client and server, but encrypted in transmission. All modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. These schemes are described along with an executive summary, current status, briefing slides and reading list, on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
+ <p>The specific cryptographic environment used by Autokey servers and clients is determined by a set of files and soft links. This includes a required host key file, required certificate file and optional sign key file, leapsecond file and identi
ty scheme files. The digest/signature scheme is specified in the X.509 certificate along with the matching sign key. There are several schemes available in the OpenSSL software library, each identified by a specific string such as <tt>md5WithRSAEncryption</tt>, which stands for the MD5 message digest with RSA encryption scheme. The current NTP distribution supports all the schemes in the OpenSSL library, including those based on RSA and DSA digital signatures. The schemes currently available are described in the <a href="genkeys.html"><tt>ntp-keygen</tt></a> page.</p>
<p>The digest/signature scheme and certificate are provided to dependent clients in the Autokey protocol. Different client or peer associations can use different schemes; each of two symmetric peers can use different schemes. Note that the digest/signature scheme is separate and distinct from the NTP message digest used to construct the packet MAC. The only requirement is that the server sign key and signature algorithm must match the public key and verification algorithm specified in the certificate.</p>
<h4 id="#auto">Autokey Dances</h4>
- <p>The Autokey protocol is somewhat intricate and a detailed explanation of the subprotocols, called dances, is beyond the scope of this page. Detailed information and briefings can be found via the NTP project page at <a href="html://www.ntp.org">www.ntp.org</a>. Briefly, the dances start when a client requests the server name and status word. Next, the client requests the server host certificate used to verify the signature of subsequent data supplied by the server.</p>
- <p>Next comes the identification procedure which confirms the server group membership. There are four schemes to prove identification: one using private certificates (PC), a second using trusted certificates (TC), a third using a modified Schnorr algorithm (IFF aka Identify Friend or Foe) and the fourth using a modified Guillou-Quisquater (GQ) algorithm. The particular scheme and required parameters and certificates are selected during operation of the <tt>ntp-keygen</tt> utility.</p>
- <p>The PC scheme uses a private certificate as group key. The certificate is distributed to all other group members by secret means and never revealed outside the group. The TC scheme involves a conventional certificate trail and a sequence of certificates, each signed by an issuer one stratum level lower than the client and terminating on a self signed trusted certificate, as described in RFC-2510.</p>
+ <p>The Autokey protocol is somewhat intricate and a detailed explanation of the subprotocols, called dances, is beyond the scope of this page. Detailed information and briefings can be found via the NTP project page at <a href="html://www.ntp.org">www.ntp.org</a>. Briefly, the dances start when a client requests the server name and status word. Next, the client requests the server certificate containing the public key used to sign subsequent messages. If the issuer of that certificate is not the server, the issuer certificate is requested. This process continues until a trusted, self-signed certificate is obtained.</p>
+ <p>Next comes the optional identity scheme which confirms the server group membership. A group is a clique of client and server hosts conforming to the following:
+ <ol>
+ <li>Each group member holds a private group key generated by a trusted member of the group.
+ <li>A group member is trusted if it operates at the lowest stratum in the group, has a trusted, self-signed certificate, and has generated the current group key.
+ <li>Clients and servers are configured so that each has an unbroken certificate trail to the trusted member.
+ </ol>
+ <p>A host can be a member of two or more groups if the above are satisfied for each group. This provides a mechanism for building multiple interlocking security compartments in the same way that such compartments are built with multiple symmetric keys.
+ <p>There are four schemes to prove identity: one using private certificates (PC), a second using trusted certificates (TC), a third using a modified Schnorr algorithm (IFF aka Identify Friend or Foe) and the fourth using a modified Guillou-Quisquater (GQ) algorithm. The particular scheme and required parameters and certificates are selected using the <tt>ntp-keygen</tt> utility. All but the TC sheme use password-encrypted private values generated by a trusted host and distribted to all other members of the group. The means required to distribute secret passwords are beyond the scope of this page.</p>
+ <p>The PC scheme uses a private certificate as group key. The certificate is generated by a trusted host and distributed to all other group members as a private value. The TC scheme involves a conventional certificate trail and a sequence of certificates, each signed by an issuer one stratum level lower than the client and terminating on a self signed trusted certificate, as described in RFC-2510.</p>
<p>The two remaining schemes involve a cryptographically strong challenge-response exchange. Both the IFF and GQ schemes start when the client sends a nonce to the server, which then rolls its own nonce, performs a mathematical operation and sends the results along with a message digest to the client. The client performs a second mathematical operation to produce a digest that must match the one included in the message.</p>
- <p>The next steps retrieve the cryptographic values needed in the particular dance, including the cookie, autokey values and leapsecond table. As a required step in the TC identification scheme, the client presents the server with its certificate and asks that it be signed using the server private key. The server response is saved for future dependent clients to walk the certificate trail.</p>
- <h4 id="#inter">Interoperability</h4>
- <p>A specific combination of authentication scheme (none, symmetric key, public key) and identification scheme (PC, TC, IFF, GQ) is called a cryptotype, although not all combinations are legal. There may be management configurations where the clients, servers and peers may not all support the same cryptotypes. A secure NTPv4 subnet can be configured in several ways while keeping in mind the principles explained in this section. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice.</p>
- <p>The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when a message of appropriate cryptotype arrives. When mobilized by a <tt>server</tt> or <tt>peer</tt> configuration command and no <tt>key</tt> or <tt>autokey</tt> subcommands are present, the association is not authenticated; if the <tt>key</tt> subcommand is present, the association is authenticated using the symmetric key ID given as argument; if the <tt>autokey</tt> subcommand is present, the association is authenticated using Autokey.</p>
- <p>When multiple identification schemes are supported in the Autokey protocol, the first message exchange determines which one is used. The client request message contains bits corresponding to which schemes it has available. The server response message contains bits corresponding to which schemes it has available. Both server and client match the received bits with their own and select the common scheme judged most secure. For this purpose the order from most secure to least is GC, IFF, TC. Note that PC does not interoperate with any of the rest, since they require the server certificate which a PC server will not reveal.</p>
+ <p>The next step in the Autokey dance retrieves the cryptographic values needed in the particular dance, including the cookie, autokey values and leapsecond table. Finally, in all but the PC scheme, the client presents the server with its certificate and asks that it be signed using the server private key. The server response is saved for future dependent clients to hike the certificate trail.</p>
+ <h4 id="#inter">Operation</h4>
+ <p>A specific combination of authentication scheme (none, symmetric key, public key) and identity scheme (PC, TC, IFF, GQ) is called a cryptotype, although not all combinations are compatible. There may be management configurations where the clients, servers and peers may not all support the same cryptotypes. A secure NTPv4 subnet can be configured in several ways while keeping in mind the principles explained above and in this section. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice.</p>
+ <p>The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when a message of appropriate cryptotype arrives. When mobilized by a <tt>server</tt> or <tt>peer</tt> configuration command and no <tt>key</tt> or <tt>autokey</tt> subcommands are present, the association is not authenticated; if the <tt>key</tt> subcommand is present, the association is authenticated using the symmetric key ID specified; if the <tt>autokey</tt> subcommand is present, the association is authenticated using Autokey.</p>
+ <p>When multiple identity schemes are supported in the Autokey protocol, the first message exchange determines which one is used. The client request message contains bits corresponding to which schemes it has available. The server response message contains bits corresponding to which schemes it has available. Both server and client match the received bits with their own and select the common scheme judged most secure. For this purpose the order from most secure to least is GC, IFF, TC. Note that PC does not interoperate with any of the rest, since they require the server certificate which a PC server will not reveal.</p>
<p>Following the principle that time is a public value, a server responds to any client packet that matches its cryptotype capabilities. Thus, a server receiving an unauthenticated packet will respond with an unauthenticated packet, while the same server receiving a packet of a cryptotype it supports will respond with packets of that cryptotype. However, unconfigured broadcast or manycast client associations or symmetric passive associations will not be mobilized unless the server supports a cryptotype compatible with the first packet received. By default, unauthenticated associations will not be mobilized unless overridden in a decidedly dangerous way.</p>
<p>Some examples may help to reduce confusion. Client Alice has no specific cryptotype selected. Server Bob has both a symmetric key file and minimal Autokey files. Alice's unauthenticated messages arrive at Bob, who replies with unauthenticated messages. Cathy has a copy of Bob's symmetric key file and has selected key ID 4 in messages to Bob. Bob verifies the message with his key ID 4. If it's the same key and the message is verified, Bob sends Cathy a reply authenticated with that key. If verification fails, Bob sends Cathy a thing called a crypto-NAK, which tells her something broke. She can see the evidence using the <tt>ntpq</tt> program.</p>
- <p>Denise has rolled her own host key and certificate. She also uses one of the identification schemes as Bob. She sends the first Autokey message to Bob and they both dance the protocol authentication and identification steps. If all comes out okay, Denise and Bob continue as described above and in the Internet Draft cited earlier.</p>
- <p>It should be clear from the above that Bob can support all the girls at the same time, as long as he has compatible authentication and identification credentials. Now, Bob can act just like the girls in his own choice of servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful). But, wise security policy might preclude some cryptotype combinations; for instance, running an identification scheme with one server and no authentication with another might not be wise.</p>
+ <p>Denise has rolled her own host key and certificate. She also uses one of the identity schemes as Bob. She sends the first Autokey message to Bob and they both dance the protocol authentication and identity steps. If all comes out okay, Denise and Bob continue as described above.</p>
+ <p>It should be clear from the above that Bob can support all the girls at the same time, as long as he has compatible authentication and identity credentials. Now, Bob can act just like the girls in his own choice of servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful). But, wise security policy might preclude some cryptotype combinations; for instance, running an identity scheme with one server and no authentication with another might not be wise.</p>
<h4 id="#key">Key Management</h4>
- <p>The cryptographic values used by the Autokey protocol are incorporated as a set of files generated by the <a href="genkeys.html"><tt>ntp-keygen</tt></a> utility program, including symmetric keys, required host key and public certificate files and optional sign key, identification parameters and leapseconds files. Alternatively, host and sign key files and certificates can be generated by the OpenSSL utilities and certificates can be imported from public certificate authorities. The symmetric keys file is necessary for the <tt>ntpq</tt> and <tt>ntpdc</tt> utility programs. The remaining files are necessary only for the Autokey protocol. The files incorporate cryptographic values generated by the OpenSSL library algorithms and are in printable PEM-encoded ASCII format. Further information about these files and how they are generated and installed is on the <tt>ntp-keygen</tt> page.</p>
- <p>Certificates imported from OpenSSL or public certificate authorities have certian limitations. The certificate should be in ASN.1 syntax, X.509 Version 3 format and encoded in PEM, which is the same format used by OpenSSL. The overall length of the certificate encoded in ASN.1 must not exceed 1024 bytes. The subject distinguished name field (<tt>CN</tt>) is the fully qualified name of the host on which it is used; the remaining subject fields are ignored. The certificate extension fields must not contain either a subject key identifier or a issuer key identifier field; however, an extended key usage field must be included with value <tt>trustRoot</tt>;. Other extension fields are ignored.</p>
+ <p>The cryptographic values used by the Autokey protocol are incorporated as a set of files generated by the <a href="genkeys.html"><tt>ntp-keygen</tt></a> utility program, including symmetric key, required host key and public certificate files, as well as optional sign key, group keys and leapseconds files. Alternatively, host and sign keys and certificate files can be generated by the OpenSSL utilities and certificates can be imported from public certificate authorities. Note that symmetric keys are necessary for the <tt>ntpq</tt> and <tt>ntpdc</tt> utility programs. The remaining files are necessary only for the Autokey protocol. The files incorporate cryptographic values generated by the OpenSSL library algorithms and are in printable PEM-encoded ASCII format. Files containing private values can be password-encrypted. These files are transmitted and stored in encrypted form and decrypted only when loaded by the <tt>ntpd</tt> daemon. Further information about these files and how they are generated and installed is on the <tt>ntp-keygen</tt> page.</p>
+ <p>Certificates imported from OpenSSL or public certificate authorities have certian limitations. The certificate should be in ASN.1 syntax, X.509 Version 3 format and encoded in PEM, which is the same format used by OpenSSL. The overall length of the certificate encoded in ASN.1 must not exceed 1024 bytes. The subject distinguished name field (<tt>CN</tt>) is the fully qualified name of the host on which it is used; the remaining subject fields are ignored. The certificate extension fields must not contain either a subject key identifier or a issuer key identifier field; however, an extended key usage field for a trusted host must contain the value <tt>trustRoot</tt>;. Other extension fields are ignored.</p>
<h4 id="#rand">Random Seed File</h4>
<p>All cryptographically sound key generation schemes must have means to randomize the entropy seed used to initialize the internal pseudo-random number generator used by the library routines. It is important to understand that entropy must be evolved for each generation, for otherwise the random number sequence would be predictable. Various means dependent on external events, such as keystroke intervals, can be used to do this and some systems have built-in entropy sources. Suitable means are described in the OpenSSL software documentation, but are outside the scope of this page.</p>
<p>The entropy seed used by the OpenSSL library is contained in a file, usually called <tt>.rnd</tt>, which must be available when starting the NTP daemon or the <tt>ntp-keygen</tt> program. The NTP daemon will first look for the file using the path specified by the <tt>randfile</tt> subcommand of the <tt>crypto</tt> command. If not specified in this way, or when starting the <tt>ntp-keygen</tt> program, the OpenSSL library will look for the file using the path specified by the <tt>RANDFILE</tt> environment variable in the user home directory, whether root or some other user. If the <tt>RANDFILE</tt> environment variable is not present, the library will look for the <tt>.rnd</tt> file in the user home directory. If the file is not available or cannot be written, the daemon exits with a message to the system log and the <tt>ntp-keygen</tt> program exits with a suitable error message.</p>
<dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol. Note that the size of the key list for each association depends on this interval and the current poll interval. The default value is 12 (4096 s or about 1.1 hours). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.
<dt><tt>controlkey <i>key</i></tt>
<dd>Specifies the key identifier to use with the <a href="ntpq.html"><tt>ntpq</tt></a> utility, which uses the standard protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the key identifier for a trusted key, where the value can be in the range 1 to 65,534, inclusive.
- <dt><tt>crypto [cert <i>file</i>] [leap <i>file</i>] [randfile <i>file</i>] [host <i>file</i>] [sign <i>file</i>] [gq <i>file</i>] [gqpar <i>file</i>] [iff <i>file</i>]</tt>
+ <dt><tt>crypto [cert <i>file</i>] [leap <i>file</i>] [randfile <i>file</i>] [host <i>file</i>] [sign <i>file</i>] [gq <i>file</i>] [gqpar <i>file</i>] [iff <i>file</i>] [pw <i>password</i>]</tt>
<dd>This command requires the OpenSSL library. It activates public key cryptography, selects the message digest and signature encryption scheme and loads the required private and public values described above. If one or more files are left unspecified, the default names are used as described above. Following are the subcommands:
<dd>
<dl>
<dd>The leapseconds table is missing, corrupted or bogus.
<dt>113 (bad or missing certificate)
<dd>The certificate is missing, corrupted or bogus.
- <dt>114 (bad or missing identification)
- <dd>The identification key is missing, corrupt or bogus.
+ <dt>114 (bad or missing identity)
+ <dd>The identity key is missing, corrupt or bogus.
</dl>
<h4 id="#file">Files</h4>
<p>See the <a href="genkeys.html"><tt>ntp-keygen</tt></a> page.</p>
<body>
<h3>Building and Installing the Distribution</h3>
- <img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/beaver.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>For putting out compiler fires.</p>
<h4>Related Links</h4>
<p>
<dd>Does the work of <tt>make distclean</tt>, but constructs compressed tar files for distribution. You must have GNU automake to perform this function.
</dl>
<h4 id="#win">Building and Installing under Windows NT</h4>
- <p>See <tt><a href="hints/winnt.htm">hints/winnt.htm</a></tt> for directions to compile the sources and install the executables.</p>
+ <p>See <tt><a href="hints/winnt.html">hints/winnt.htm</a></tt> for directions to compile the sources and install the executables.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>Reference Clock Options</h3>
- <img src="pic/stack1a.jpg" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/stack1a.jpg" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>See the radios, all in a row.</p>
<h4>Related Links</h4>
<p>
<body>
<h3>Configuration Options</h3>
- <img src="pic/pogo3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>Gnu autoconfigure tools are in the backpack.<br clear="left">
</p>
<h4>Table of Contents</h4>
<body>
<h3>Server Options</h3>
- <img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The chicken is getting configuration advice.</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
<body>
<h3>NTP Debugging Techniques</h3>
- <img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We make house calls and bring our own bugs.<br clear="left">
</p>
<hr>
<p>In extreme cases with elusive bugs, the daemon can operate in two modes, depending on the presence of the <tt>-d</tt> command-line debug switch. If not present, the daemon detaches from the controlling terminal and proceeds autonomously. If one or more <tt>-d</tt> switches are present, the daemon does not detach and generates special output useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single <tt>-d</tt> does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles. With a little experience, the volume of output can be reduced by piping the output to <tt>grep</tt> and specifying the keyword of the trace you want to see.</p>
<p>Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix <tt>/etc/services</tt> file (or equivalent in some systems). <b>Note that NTP does not use TCP in any form.</b> Other problems are apparent in the system log file. The log file should show the startup banner, some cryptic initialization data and the computed precision value. The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the Unix <tt>ping</tt> command.</p>
<p>When first started, the daemon normally polls the servers listed in the configuration file at 64-s intervals. In order to allow a sufficient number of samples for the NTP algorithms to reliably discriminate between truechimer servers and possible falsetickers, at least four valid messages from at least one server or peer listed in the configuration file is required before the daemon can set the local clock. However, if the difference between the client time and server time is greater than the panic threshold, which defaults to 1000 s, the daemon will send a message to the system log and shut down without setting the clock. It is necessary to set the local clock to within the panic threshold first, either manually by eyeball and wristwatch and the Unix <tt>date</tt> command, or by the <tt>ntpdate</tt> or <tt>ntpd -q</tt> commands. The panic threshold can be changed by the <tt>tinker panic</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> page. The panic threshold can be disabled entirely by the <tt>-g</tt> command line option described on the <a href="ntpd.html">ntpd</a> page.</p>
- <p>If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. The step threshold can be changed by the <tt>tinker step</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> page. The step threshold can be disabled entirely by the <tt>-x</tt> command line option described on the <a href="ntpd.html">ntpd</a> page. In this case the clock will never be stepped; however, users should understand the implications for doing this in a distributed data network where all processing must be tightly synchronized. See the <a href="http://www.eecis.udel.edu/%7emills/leap.htm">NTP Timescale and Leap Seconds</a> page for further information. If a step adjustment is made, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.</p>
+ <p>If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. The step threshold can be changed by the <tt>tinker step</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> page. The step threshold can be disabled entirely by the <tt>-x</tt> command line option described on the <a href="ntpd.html">ntpd</a> page. In this case the clock will never be stepped; however, users should understand the implications for doing this in a distributed data network where all processing must be tightly synchronized. See the <a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a> page for further information. If a step adjustment is made, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.</p>
<p>The clock discipline algorithm is designed to avoid large noise spikes that might occur on a congested network or access line. If an offset sample exceeds the step threshold, it is ignored and a timer started. If a later sample is below the step threshold, the counter is reset. However, if the counter is greater than the stepout interval, which defaults to 900 s, the next sample will step or slew the time as directed. The stepout threshold can be changed by the <tt>tinker stepout</tt> command discribed on the <a href="miscopt.html">Miscellaneous Options</a> page.</p>
<p>If for some reason the hardware clock oscillator frequency error is very large, the time offset when the daemon is started for the first time may increase over time until exceeding the step threshold, which requires a frequency adjustment and another step correction. However, due to provisions that reduce vulnerability to noise spikes, the second correction will not be done until after the stepout threshold. When the frequency error is very large, it may take a number of cycles like this until converging on the nominal frequency correction. If the frequency error is over 500 PPM, convergence will never occur and occasional resets will occur indefinitely. After converging, and at one-hour intervals after that, the correction is written to the <tt>ntp.drift</tt> file, which is read upon subsequent restarts, so the herky-jerky cycles should not recur.</p>
<h4>Verifying Correct Operation</h4>
<p>This format is an ITU-R Recommendation (ITU-R TF583.4) and is now available from the primary timing centres of the following countries: Austria, Belgium, Germany, Italy, The Netherlands, Poland, Portugal, Romania, Spain, Sweden, Switzerland, Turkey, United Kingdom. Some examples are:</p>
<ul>
<li>In Germany by Physikalisch-Technische Bundesanstalt (PTB)'s timecode service. Phone number: +49 5 31 51 20 38.
- <p>For more detail, see <a href="http://www.ptb.de/english/org/4/43/433/disse.htm">http://www.ptb.de/english/org/4/43/433/disse.htm</a></p>
+ <p>For more detail, see <a href="http://www.ptb.de/english/org/4/43/433/disse.html">http://www.ptb.de/english/org/4/43/433/disse.htm</a></p>
<li>In the UK by National Physical Laboratory (NPL)'s TRUETIME service. Phone number: 0891 516 333
<p>For more detail, see <a href="http://www.npl.co.uk/npl/ctm/truetime.html">http://www.npl.co.uk/npl/ctm/truetime.html</a></p>
<li>In Italy by Istituto Elettrotecnico Nazionale "Galileo Ferrais" (IEN)'s CTD service. Phone number: 166 11 46 15
<p>For more detail, see <a href="http://www.ien.it/tf/time/Pagina42.html">http://www.ien.it/tf/time/Pagina42.html</a></p>
<li>In Switzerland by Swiss Federal Office of Metrology 's timecode service. Phone number: 031 323 32 25
<p>For more detail, see <a href="http://www.ofmet.admin.ch/de/labors/4/Zeitvert.html%20">http://www.ofmet.admin.ch/de/labors/4/Zeitvert.html </a></p>
- <li>In Sweden by SP Swedish National Testing and Research Institute 's timecode service. Phone number: +46 33 415783
- <p>For more detail, see <a href="http://www.sp.se/pne/ElectricalMetrology/ElMeteng/frameset.htm">http://www.sp.se/pne/ElectricalMetrology/ElMeteng/frameset.htm</a><br>
+ <li>In Sweden by SP Swedish National Testing and Research Institute 's timecode service. Phone number: +46 33 415783.
+ <p>For more detail, see <a href="http://www.sp.se/metrology/timefreq/eng/tandf.htm">http://www.sp.se/metrology/timefreq/eng/tandf.htm</a><br>
</p>
</ul>
<h4>Fudge Factors</h4>
<p>This code has been significantly slimmed down since the V1.0 version, roughly halving the memory footprint of its code and data.</p>
<p>This driver is designed to allow the unit to run from batteries as designed, for something approaching the 2.5 years expected in the usual stand-alone mode, but no battery-life measurements have been taken.</p>
<p>Much of this code is originally from the other refclock driver files with thanks. The code was originally made to work with the clock by <a href="mailto:derek@toybox.demon.co.uk">Derek Mulcahy</a>, with modifications by <a href="mailto:d@hd.org">Damon Hart-Davis</a>. Thanks also to <a href="mailto:lyndond@sentinet.co.uk">Lyndon David</a> for some of the specifications of the clock.</p>
- <p>There is support for a Tcl/Tk monitor written by Derek Mulcahy that examines the output stats; see the <a href="http://www2.exnet.com/NTP/ARC/ARC.htm">ARC Rugby MSF Receiver</a> page for more details and the code.</p>
+ <p>There is support for a Tcl/Tk monitor written by Derek Mulcahy that examines the output stats; see the <a href="http://www2.exnet.com/NTP/ARC/ARC.html">ARC Rugby MSF Receiver</a> page for more details and the code.</p>
<p>Look at the notes at the start of the code for further information; some of the more important details follow.</p>
<p>The driver interrogates the clock at each poll (ie every 64s by default) for a timestamp. The clock responds at the start of the next second (with the start bit of the first byte being on-time). The time is in `local' format, including the daylight savings adjustment when it is in effect. The driver code converts the time back to UTC.</p>
<p>The clock claims to be accurate to within about 20ms of the MSF-broadcast time, and given the low data transmission speed from clock to host, and the fact that the clock is not in continuous sync with MSF, it seems sensible to set the `precision' of this clock to -5 or -4, -4 being used in this code, which builds in a reported dispersion of over 63ms (ie says ``This clock is not very good.''). You can improve the reported precision to -4 (and thus reduce the base dispersion to about 31ms) by setting the fudge <tt>flag3</tt> to <tt>1</tt>.</p>
</dl>
<h4>Additional Information</h4>
<p><a href="refclock.html">Reference Clock Drivers</a><br>
- <a href="http://www2.exnet.com/NTP/ARC/ARC.htm">ARC Rugby MSF Receiver</a></p>
+ <a href="http://www2.exnet.com/NTP/ARC/ARC.html">ARC Rugby MSF Receiver</a></p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
This driver synchronizes the computer time using data encoded in shortwave radio transmissions from NIST time/frequency stations WWV in Ft. Collins, CO, and WWVH in Kauai, HI. Transmissions are made continuously on 2.5, 5, 10, 15 and 20 MHz. 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 by the driver as propagation conditions change throughout the day and night. The performance of this driver when tracking one of the stations is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking either station.
- <p>The demodulation and decoding algorithms used by this driver are based on a machine language program developed for the TAPR DSP93 DSP unit, which uses the TI 320C25 DSP chip. The analysis, design and performance of the program running on this unit is described in: Mills, D.L. A precision radio clock for WWV transmissions. Electrical Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp. Available from <a href="http://www.eecis.udel.edu/%7emills/reports.htm">www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver, the original program was rebuilt in the C language and adapted to the NTP driver interface. The algorithms have been modified somewhat to improve performance under weak signal conditions and to provide an automatic station identification feature.</p>
+ <p>The demodulation and decoding algorithms used by this driver are based on a machine language program developed for the TAPR DSP93 DSP unit, which uses the TI 320C25 DSP chip. The analysis, design and performance of the program running on this unit is described in: Mills, D.L. A precision radio clock for WWV transmissions. Electrical Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp. Available from <a href="http://www.eecis.udel.edu/%7emills/reports.html">www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver, the original program was rebuilt in the C language and adapted to the NTP driver interface. The algorithms have been modified somewhat to improve performance under weak signal conditions and to provide an automatic station identification feature.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>The WWV signal format is described in NIST Special Publication 432 (Revised 1990). It consists of three elements, a 5-ms, 1000-Hz pulse, which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse, which occurs at the beginning of each minute, and a pulse-width modulated 100-Hz subcarrier for the data bits, one bit per second. The WWVH format is identical, except that the 1000-Hz pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for the time of century plus seven bits for the daylight savings time (DST) indicator, leap warning indicator and DUT1 correction.</p>
<h4>Program Architecture</h4>
Driver ID: <tt>GPS</tt><br>
Parallel Port: <tt>/dev/fgclock<i>u</i></tt></p>
<h4>Description</h4>
- <p>This driver supports the Forum Graphic GPS Dating station sold by <a href="http://www.emr.fr/gpsclock.htm">EMR company</a>.</p>
+ <p>This driver supports the Forum Graphic GPS Dating station sold by <a href="http://www.emr.fr/gpsclock.html">EMR company</a>.</p>
<p>Unfortunately sometime FG GPS start continues reporting of the same date. The only way to fix this problem is GPS power cycling and ntpd restart after GPS power-up.</p>
<p>After Jan,10 2000 my FG GPS unit start send a wrong answer after 10:00am till 11:00am. It repeat hour value in result string twice. I wroite a small code to avoid such problem. Unfortunately I have no second FG GPS unit to evaluate this problem. Please let me know if your GPS has no problems after Y2K.</p>
<p></p>
<h4>Description</h4>
<p>This driver supports the following JJY receivers sold in Japan.</p>
<ul>
- <li>Tristate Ltd. JJY01 <a href="http://www.tristate.ne.jp/rf-clock.htm">http://www.tristate.ne.jp/rf-clock.htm</a> (Japanese only)<br>
+ <li>Tristate Ltd. JJY01 <a href="http://www.tristate.ne.jp/rf-clock.html">http://www.tristate.ne.jp/rf-clock.htm</a> (Japanese only)<br>
<dl>
<dt>Time code format
<dd><br>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>Radio CHU Audio Demodulator/Decoder</title><link href="scripts/style.css" type="text/css" rel="stylesheet">
-
+ <title>Radio CHU Audio Demodulator/Decoder</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
<h4>Description</h4>
<p>This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. It replaces an earlier one, built by Dennis Ferguson in 1988, which required a special line discipline to preprocessed the signal. The new driver includes more powerful algorithms implemented directly in the driver and requires no preprocessing.</p>
<p>CHU transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.</p>
- <p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described in the <a href="gadget.html">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>
+ <p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described on the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The driver can use the modem to receive the radio signal and demodulate the data or, if available, the driver can use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone on line input port.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h), although this can be changed with configuration commands. As long as the clock is set or verified at least once during this interval, the NTP algorithms will consider the source reachable and selectable to discipline the system clock. However, if this does not happen for eight poll intervals, the algorithms will consider the source unreachable and some other source will be chosen (if available) to discipline the system clock.</p>
<p>The decoding algorithms process the data using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.</p>
<a href="refclock.html">Reference Clock Drivers</a><br>
<a href="audio.html">Reference Clock Audio Drivers</a>
<hr>
- <script language="javascript" type="text/javascript" src="scripts/footer.txt"></script>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
\ No newline at end of file
<p>The pictures below refer to the respective clock and where taken from the vendors web pages. They are linked to the respective vendors.</p>
<ul>
<li><b><tt>server 127.127.8.0-3 mode 0</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg </a>PZF535/<a href="http://www.meinberg.de/english/products/pzf509.htm">PZF509 receiver</a> (FM demodulation/TCXO / 50us)</tt></b><br>
+ <p><b><tt><a href="http://www.meinberg.de">Meinberg </a>PZF535/<a href="http://www.meinberg.de/english/products/pzf509.html">PZF509 receiver</a> (FM demodulation/TCXO / 50us)</tt></b><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 1</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg </a>PZF535/<a href="http://www.meinberg.de/english/products/pzf509.htm">PZF509 receiver</a> (FM demodulation/OCXO / 50us)</tt></b><br>
- <a href="http://www.meinberg.de/english/products/pzf509.htm"><img src="pic/pzf509.jpg" alt="BILD PZF509" height="300" width="260" align="TEXTTOP"></a><br>
+ <p><b><tt><a href="http://www.meinberg.de">Meinberg </a>PZF535/<a href="http://www.meinberg.de/english/products/pzf509.html">PZF509 receiver</a> (FM demodulation/OCXO / 50us)</tt></b><br>
+ <a href="http://www.meinberg.de/english/products/pzf509.htm
l"><img src="pic/pzf509.jpg" alt="BILD PZF509" height="300" width="260" align="TEXTTOP"></a><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 2</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg </a>DCF U/A 31/<a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver</a> (AM demodulation / 4ms)</tt></b><br>
- <a href="http://www.meinberg.de/english/products/c51.htm"><img src="pic/c51.jpg" alt="BILD C51" height="180" width="330" align="TEXTTOP"></a><br>
+ <p><b><tt><a href="http://www.meinberg.de">Meinberg </a>DCF U/A 31/<a href="http://www.meinberg.de/english/products/c51.html">DCF C51 receiver</a> (AM demodulation / 4ms)</tt></b><br>
+ <a href="http://www.meinberg.de/english/products/c51.htm
l"><img src="pic/c51.jpg" alt="BILD C51" height="180" width="330" align="TEXTTOP"></a><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 3</tt></b>
<p><b><tt><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</tt></b><br>
<p><b><tt>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</tt></b><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 7</tt></b>
- <p><b><tt><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/gps167.htm">GPS166/GPS167 receiver</a> (GPS / <<1us)</tt></b><br>
- <a href="http://www.meinberg.de/english/products/gps167.htm"><img src="pic/gps167.jpg" alt="BILD GPS167" height="300" width="280" align="TEXTTOP"></a><br>
+ <p><b><tt><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/gps167.html">GPS166/GPS167 receiver</a> (GPS / <<1us)</tt></b><br>
+ <a href="http://www.meinberg.de/english/products/gps167.htm
l"><img src="pic/gps167.jpg" alt="BILD GPS167" height="300" width="280" align="TEXTTOP"></a><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 8</tt></b>
- <p><b><tt><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.htm">clock</a></tt></b><br>
- <a href="http://www.igel.de/eigelmn.htm"><img src="pic/igclock.gif" height="174" width="200"></a><br>
+ <p><b><tt><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></tt></b><br>
+ <a href="http://www.igel.de/eigelmn.htm
l"><img src="pic/igclock.gif" height="174" width="200"></a><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 9</tt></b>
- <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm">SVeeSix GPS receiver</a>TAIP protocol (GPS / <<1us)</tt></b><br>
+ <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a>TAIP protocol (GPS / <<1us)</tt></b><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 10</tt></b>
- <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1us) (no kernel support yet)</tt></b><br>
- <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm"><img src="pic/pd_om011.gif" alt="SVeeSix-CM3" height="100" width="420" align="TEXTTOP" border="0"></a><br>
- <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.htm"><img src="pic/pd_om006.gif" alt="Lassen-SK8" height="100" width="420" border="0"></a><br>
+ <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1us) (no kernel support yet)</tt></b><br>
+ <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.htm
l"><img src="pic/pd_om011.gif" alt="SVeeSix-CM3" height="100" width="420" align="TEXTTOP" border="0"></a><br>
+ <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.htm
l"><img src="pic/pd_om006.gif" alt="Lassen-SK8" height="100" width="420" border="0"></a><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 11</tt></b>
<p><b><tt>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </tt></b><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 12</tt></b>
- <p><b><tt><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.htm">Funkuhr 6021</a></tt></b><br>
- <a href="http://www.hopf-time.com/engl/kart6021.htm"><img src="pic/fg6021.gif" alt="DCF77-Interface Board" height="207" width="238" align="TEXTTOP"></a><br>
+ <p><b><tt><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></tt></b><br>
+ <a href="http://www.hopf-time.com/engl/kart6021.htm
l"><img src="pic/fg6021.gif" alt="DCF77-Interface Board" height="207" width="238" align="TEXTTOP"></a><br>
</p>
<li><b><tt>server 127.127.8.0-3 mode 13</tt></b>
<p><b><tt>Diem's Computime Radio Clock</tt></b><br>
Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 baud, 8-bits, no parity<br>
Features: <tt>ppsclock</tt> (required)
<h4>Description</h4>
- <p>This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. It requires the <tt>ppsclock</tt> line discipline or streams module described in the <a href="ldisc.html">Line Disciplines and Streams Modules</a> page. It also requires a
<a href="gadget.html">gadget box</a> and 1-PPS level converter, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
+ <p>This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. It requires the <tt>ppsclock</tt> line discipline or streams module described in the <a href="ldisc.html">Line Disciplines and Streams Modules</a> page. It also requires a
level converter such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
<p>This driver supports all compatible receivers such as the 6-channel MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.</p>
<p><a href="http://www.leica-gps.com/"><img src="pic/9400n.jpg" alt="Leica MX9400N Navigator" height="143" width="180" align="left"></a> <a href="http://www.leica-gps.com/">Leica Geosystems</a> acquired the Magnavox commercial GPS technology business in February of 1994. They now market and support former Magnavox GPS products such as the MX4200 and its successors.</p>
<br clear="LEFT">
<body>
<h3><tt>ntp-keygen</tt> - generate public and private keys</h3>
- <img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice23.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Alice holds the key.</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
<h4 id="#synop">Synopsis</h4>
<tt>ntp-keygen</tt>
<h4 id="#desc">Description</h4>
- <p>This program generates cryptographic data files used by the NTPv4 authentication and identification schemes. It generates key files for the MD5 keyed message digest algorithm, which uses symmetric key cryptography. In addition, if the OpenSSL software library has been installed, the program generates key, certificate and parameter files for the Autokey protocol, which uses public key cryptography. These files are used for cookie encryption, digital signature and challenge/response identification algorithms, as well as for Internet standard security infrastructure applications. While a large number of authentication and identification scheme combinations are supported, the work of generating and maintaining the files is minimal, since the key generation and update process is largely automated.</p>
- <p>All files are in PEM-encoded printable ASCII format, so they can be embedded as MIME attachments in mail to other sites and certificate authorities. Optionally, files containing private keys can be encrypted for transmission as MIME attachments. File names begin with the prefix <tt>ntpkey_</tt> and end with the postfix <tt><i>hostname.filestamp</i></tt>, where <tt><i>hostname</i></tt> is the name returned by the Unix <tt>gethostname()</tt> routine and <tt><i>filestamp</i></tt> is the NTP seconds when the file was generated, in decimal digits. This both guarantees uniqueness and simplifies maintenance procedures, since all files can be quickly removed by a <tt>rm ntpkey*</tt> command or all files generated at a specific time can be removed by a <tt>rm *<i>filestamp</i></tt> command. To further reduce the risk of misconfiguration, the first two lines of a file contain the file name and generation date and time as comments.</p>
- <p>All files are installed by default in <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks. The default can be overridden by the <tt>keysdir</tt> configuration command. The actual location of each file can be overridden by the <tt>crypto</tt> configuration command, but this is not recommended. Normally, the files for each machine are generated by that machine and used only by that machine, although exceptions exist as documented later on this page. However, the files for a machine can be put in a more private place, such as <tt>/etc</tt> if necessary.</p>
- <p>Normally, files containing private values, including the host key, sign key and identification parameters, are permitted root read/write-only; while others containing public values are permitted world readable. Alternatively, files containing private values can be encrypted with a chosen password and all files permitted world readable, which simplifies maintenance in shared file systems.</p>
- <p>Since uniqueness is insured by the hostname and file name extensions, the files for a NFS server and dependent clients can all be installed in the same directory. This is different than the original Autokey Version 1 support, which required the private key to be installed separately for each client.</p>
- <p>The recommended practice is to keep the file name extensions when installing a file and to install a soft link from the generic names specified in the <tt>ntp-keygen</tt> page to the generated files. 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 filestamp and sends it along with the public key and host name when requested. This allows clients to verify that the file and generation times are always current.</p>
- <p>All cryptographic keys and related values should be regenerated on a periodic and automatic basis, like once per month. The <tt>ntp-keygen</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 host key and certificate must be generated by every server and peer, the certificates 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.</p>
+ <p>This program generates cryptographic data files used by the NTPv4 authentication and identification schemes. It generates MD5 key files used in symmetric key cryptography. In addition, if the OpenSSL software library has been installed, it generates key, certificate and parameter files used in public key cryptography. These files are used for cookie encryption, digital signature and challenge/response identification algorithms compatible with the Internet standard security infrastructure.</p>
+ <p>All files are in PEM-encoded printable ASCII format, so they can be embedded as MIME attachments in mail to other sites and certificate authorities. Files containing private values can be password encrypted. File names begin with the prefix <tt>ntpkey_</tt> and end with the postfix <tt><i>hostname.filestamp</i></tt>, where <tt><i>hostname</i></tt> is the owner name, usually the string returned by the Unix <tt>gethostname()</tt> routine, and <tt><i>filestamp</i></tt> is the NTP seconds when the file was generated, in decimal digits. This both guarantees uniqueness and simplifies maintenance procedures, since all files can be quickly removed by a <tt>rm ntpkey*</tt> command or all files generated at a specific time can be removed by a <tt>rm *<i>filestamp</i></tt> command. To further reduce the risk of misconfiguration, the first two lines of a file contain the file name and generation date and time as comments.</p>
+ <p>All files are installed by default in the keys directory <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks. The actual location of the keys directory or each file can be overridden by configuration commands, but this is not recommended. Normally, the files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.</p>
+ <p>Normally, files containing private values, including the host key, sign key and identification parameters, are permitted root read/write-only; while others containing public values are permitted world readable. Alternatively, files containing private values can be encrypted with a chosen password and all files permitted world readable, which simplifies maintenance in shared file systems. Since uniqueness is insured by the hostname and file name extensions, the files for a NFS server and dependent clients can all be installed in the same directory.</p>
+ <p>The recommended practice is to keep the file name extensions when installing a file and to install a soft link from the generic names specified elsewhere on this page to the generated files. 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 filestamp and sends it along with the public key and host name when requested. This allows clients to verify that the file and generation times are always current. The <tt>ntp-keygen</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.</p>
<p>As explained in the <a href="authopt.html">Authentication Options</a> page, all cryptographically sound key generation schemes must have means to randomize the entropy seed used to initialize the internal random number generator. The OpenSSL library uses a designated random seed file for this purpose. The file must be available when starting the NTP daemon and <tt>ntp-keygen</tt> program. If a site supports OpenSSL or its companion OpenSSH, it is very likely that means to do this are already available.</p>
<h4 id="#run">Running the program</h4>
- <p>The NTP security model requires private cryptographic data used by a host to be generated only by that host, although exceptions exist as described later. The safest way to run the <tt>ntp-keygen</tt> program is logged in directly as root. The recommended procedure is change to the keys directory, usually <tt>/ust/local/etc</tt> then run the program. When run for the first time, or if all NTP files have been removed, the program generates a RSA host key file and matching RSA-MD5 certificate file, which is all that is necessary in many cases. The program also generates soft links from the generic names to the respective files. If run again, the program uses the same host key file, but generates a new certificate file and link.</p>
+ <p>The safest way to run the <tt>ntp-keygen</tt> program is logged in directly as root. The recommended procedure is change to the keys directory, usually <tt>/ust/local/etc</tt>, then run the program. When run for the first time, or if all <tt>ntpkey</tt> files have been removed, the program generates a RSA host key file and matching RSA-MD5 certificate file, which is all that is necessary in many cases. The program also generates soft links from the generic names to the respective files. If run again, the program uses the same host key file, but generates a new certificate file and link.</p>
<p>The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. When necessary, a different sign key can be specified and this can be either RSA or DSA type. By default, the message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified.</p>
<p>Running the program as other than root and using the Unix <tt>su</tt> command to assume root may not work properly, since by default the OpenSSL library looks for the random seed file <tt>.rnd</tt> in the user home directory. However, there should be only one <tt>.rnd</tt>, most conveniently in the root directory, so it is convenient to define the <tt>$RANDFILE</tt> environment variable used by the OpenSSL library as the path to <tt>/.rnd</tt>.</p>
<p>Installing the keys as root might not work in NFS-mounted shared file systems, as NFS clients may not be able to write to the shared keys directory, even as root. In this case, NFS clients can specify the files in another directory such as <tt>/etc</tt> using the <tt>keysdir</tt> command. There is no need for one client to read the keys and certificates of other clients or servers, as these data are obtained automatically by the Autokey protocol.</p>
+ <p>Ordinarily, cryptographic files are generated by the host that uses them, but it is possible for a trusted host to generate these files for other hosts; however, in such cases the private values should always be password-encrypted. The password is supplied as an option to the <tt>ntp-keygen</tt> command and as the <tt>pw</tt> subcommand in the <tt>ntpd</tt> cofiguration file. It is convenient to designate the owner name and trusted name as the subject and issuer fields, respectivily, of the certificate. The owner name is also used for the host and sign key files, while the trusted name is used for the identity files.</p>
<h4 id="#exam">Examples</h4>
- <p>Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as explained in the<a href="authopt.html"> Authentication Options</a> page. The default cryptotype uses RSA encryption, MD5 message digest and TC identification. First, configure a NTP subnet including a number of low-stratum time servers from which all other subnet members derive synchronization directly or indirectly. These servers are considered trusted and will have trusted certificates. All others will automatically and dynamically build authoritative certificate trails to these servers.</p>
- <p>On each trusted server as root, change to the keys directory. To insure a fresh fileset, remove all <tt>ntpkey</tt> files. Then run <tt>ntp-keygen -T</tt> to generate keys and trusted certificates for the TC identification scheme. On all other machines do the same, but leave off the <tt>-T</tt> flag to generate keys and nontrusted certificates. When complete, start <tt>ntpd</tt> starting from the lowest stratum and working up the tree. It may take some time for Autokey to instantiate the certificate trails throughout the subnet, but setting up the environment is completely automatic.</p>
- <p>After setting up the environment it is advisable to update certificates from time to time, if only to extend the validity interval. Simply run <tt>ntp-keygen</tt> without flags to generate new certificates using existing keys. The next time the daemon is started, it will load the new certificate and restart the protocol. Since the keys have not changed, other dependent machines will continue as usual until signatures are refreshed and the protocol is restarted, which occurs about once per day.</p>
- <p>As mentioned elsewhere, the TC identification scheme is vulnerable to a middleman attack. If this is of concern, select the PC (<tt>-P</tt> option), IFF (<tt>-I</tt> option) or GQ (<tt>-G</tt> option) schemes. These schemes all require at least one file to be securely distributed to all subnet machines. The PC scheme is set up as follows. On one subnet machine <i>alice</i> run <tt>ntp-keygen -P</tt> to generate the keys and private certificate. If the <tt>-p <i>password</i></tt> option is included, files containing private data are encrypted so they can be transmitted over unsecure facilities. The <tt>ntp-keygen</tt> program prompts for the password if it reads an encrypted file and the <tt>-p <i>password</i></tt> option is not present.</p>
- <p>Then, using secure means, copy the host key file <tt>ntpkey_RSAkey_alice</tt> and certificate file <tt>ntpkey_RSA-MD5_cert_alice</tt> to all other subnet machines. On each machine <i>bob</i> install a soft link from the generic name <tt>ntpkey_host_bob</tt> to <tt>ntpkey_RSAkey_alice</tt> and soft link <tt>ntpkey_cert_bob</tt> to <tt>ntpkey_RSA-MD5_cert_alice</tt>. Note the generic links must match the host name, but point to a file generated by another host. Finally, proceed as in the TC scheme. Note that it is not possible to change either the keys or certificates in any machine without refreshing the entire subnet.</p>
- <p>For the IFF scheme proceed as in the TC scheme, except use the <tt>-I</tt> flag instead of <tt>-P</tt>. Then, using secure means, copy the IFF parameter file <tt>ntpkeys_IFFpar_alice</tt> to all other subnet machines. On each machine <i>bob</i> install a soft link from the generic <tt>ntpkey_iffpar_bob</tt> to this file. Finally, proceed as in the TC scheme. As the IFF scheme does not use certificates, keys and certificates can be regenerated as needed.</p>
- <p>For the GQ scheme proceed as in the TC scheme, except use the <tt>-G</tt> flag instead of <tt>-P</tt>. Then, using secure means, copy the GQ parameters file <tt>ntpkeys_GQpar_alice</tt> to all other subnet machines. On each machine <i>bob</i> install a soft link from the generic <tt>ntpkey_gqpar_bob</tt> to this file. If the <tt>ntp-keygen</tt> program is run on <i>bob</i> before these steps are complete, then run the program again on <i>bob</i> to generate the GQ keys file <tt>ntpkeys_GQkey_bob</tt> and link unique to <i>bob</i>. Finally, proceed as in the TC scheme. As the GQ scheme generates both the GQ key file and certificate at the same time, but leaving the GQ parameter file intact, keys and certificates can be regenerated as needed.</p>
+ <p>Each cryptographic configuration involves selection of a signature scheme and identification scheme, called a cryptotype, as explained in the <a href="authopt.html">Authentication Options</a> page. The default cryptotype uses RSA encryption, MD5 message digest and default (TC) identification. First, configure a NTP subnet including a number of low-stratum time servers from which all other subnet members derive synchronization directly or indirectly. These servers are considered trusted and will have trusted certificates. All others will automatically and dynamically build authoritative certificate trails to these servers.</p>
+ <p>On each trusted server as root, change to the keys directory. To insure a fresh fileset, remove all <tt>ntpkey</tt> files. Then run <tt>ntp-keygen -T</tt> to generate keys and a trusted certificate for the TC identification scheme. On all other hosts do the same, but leave off the <tt>-T</tt> flag to generate keys and nontrusted certificates. When complete, start <tt>ntpd</tt> starting from the lowest stratum and working up the tree. It may take some time for Autokey to instantiate the certificate trails throughout the subnet, but setting up the environment is completely automatic.</p>
+ <p>After setting up the environment it is advisable to update certificates from time to time, if only to extend the validity interval. Simply run <tt>ntp-keygen</tt> with the same flags as before to generate new certificates using existing keys. The next time <tt>ntpd</tt> is started, it will load the new certificate and restart the protocol. Since the keys have not changed, other dependent hosts will continue as usual until signatures are refreshed and the protocol is restarted, which occurs about once per day.</p>
+ <p>As mentioned on the Authentication Options page, the TC identity scheme is vulnerable to a middleman attack. However, there are more secure identity schemes available, including PC, IFF and GQ. These schemes are based on a trusted host and a group of hosts deriving trust from that host. Group membership is defined by private values generated by the trusted host and distributed by secure means to all other hosts in the group.</p>
+ <p>The PC scheme is set up as follows. On trusted host <i>alice</i> run <tt>ntp-keygen -P -p <i>password</i></tt> to generate the encrypted host key and private certificate. Note that, as with all encrypted files, the <tt>ntp-keygen</tt> program prompts for the password if it reads an encrypted file and the <tt>-p</tt> option is not present.</p>
+ <p>Copy the host key file <tt>ntpkey_RSAkey_<i>alice.filestamp</i></tt> and certificate file <tt>ntpkey_RSA-MD5_cert_<i>alice.filestamp</i></tt> to all other hosts in the group. On each host <i>bob</i> install a soft link from the generic name <tt>ntpkey_host_bob</tt> to the host key file and soft link <tt>ntpkey_cert_bob</tt> to the certificate file. Note the generic links are from host <i>bob</i>, but point to files generated by trusted host <i>alice</i>. Note that it is not possible to change either the keys or certificates in any host without refreshing all other hosts in the group.</p>
+ <p>For the IFF scheme proceed as in the TC scheme to generate keys and certificates for all hosts, including the trusted host. On the trusted host use the <tt>-I -p <i>password</i></tt> options. Then, copy the IFF parameters file <tt>ntpkeys_IFFpar_<i>alice.filestamp</i></tt> to all other hosts in the group. On each host <i>bob</i> install a soft link from the generic <tt>ntpkey_iffpar_<i>alice</i></tt> to this file and a soft link from the generic <tt>ntpkey_iffpar_<i>bob</i></tt> to the same file. As the IFF scheme is independent of keys and certificates, these files can be regenerated as needed.</p>
+ <p>For the GQ scheme proceed as in the TC scheme to generate keys and certificates for all hosts, including the trusted host. On the trusted host use the <tt>-G -p <i>password</i></tt> options. Then, copy the GQ parameters file <tt>ntpkeys_GQpar_<i>alice.filestamp</i></tt> to all other hosts in the group. On each host <i>bob</i> install a soft link from the generic <tt>ntpkey_gqpar_<i>alice</i></tt> to this file and a soft link from the generic <tt>ntpkey_gqpar_<i>bob</i></tt> to the same file. If the <tt>ntp-keygen</tt> program is run on <i>bob</i> before these steps are complete, then run the program again on to generate the GQ keys file <tt>ntpkeys_GQkey_bob</tt> and link. As the GQ scheme generates both the GQ key file and certificate at the same time, but leaving the GQ parameter file intact, keys and certificates can be regenerated as needed.</p>
<p>If it is necessary to use a different sign key or different digest/signature scheme than the default, run <tt>ntp-keygen</tt> with the <tt>-S</tt> option and either <tt>RSA</tt> or <tt>DSA</tt> argument as needed. The most often need to do this is when a DSA-signed certificate is used. If <tt>ntp-keygen</tt> is run again without the option, it will generate a new certificate using the existing sign key. If it is necessary to use a different certificate scheme than the default, run <tt>ntp-keygen</tt> with the <tt>-c</tt> option and selected scheme as needed. If <tt>ntp-keygen</tt> is run again without the option, it will generate a new certificate using the same scheme and existing sign key.</p>
<h4 id="#cmd">Command Line Options</h4>
<dl>
<dd>Generate new host keys, obsoleting any that may exist.
<dt><tt>-I</tt>
<dd>Generate parameters for the IFF identification scheme, obsoleting any that may exist.
+ <dt><tt>-i <i>name</i></tt>
+ <dd>Set the trusted name to <i>name</i>. This is used as the subject field in certificates and the file name in host and sign keys.
<dt><tt>-M</tt>
<dd>Generate MD5 keys, obsoleting any that may exist.
<dt><tt>-P</tt>
<dd>Encrypt generated files containing private data with the designated <tt><i>password</i></tt> and the DES-CBC algorithm.
<dt><tt>-S [ RSA | DSA ]</tt>
<dd>Generate a new sign key of the designated type, obsoleting any that may exist. By default, the program uses the host key as the sign key.
- <dt><tt>-t</tt>
+ <dt><tt>-s <i>name</i></tt>
+ <dd>Set the trusted name to <i>name</i>. This is used for the issuer field in certificates and the file name for identity files.
+ <dt><tt>-T</tt>
<dd>Generate a trusted certificate. By default, the program generates a non-trusted certificate.
+ <dt><tt>-V <i>nkeys</i></tt>
+ <dd>Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
</dl>
<h4 id="#symkey">Symmetric Key File</h4>
- <p>The <tt>ntp-keygen</tt> program generates a MD5 symmetric keys file <tt>ntpkey_MD5key_<i>hostname.filestamp</i></tt>. Since the file contains private shared keys, it should be visible only to root and distributed by secure means to other subnet
machines. The NTP daemon loads the file <tt>ntp.keys</tt>, so <tt>ntp-keygen</tt> installs a soft link from this name to the generated file. Subsequently, similar soft links must be installed by manual or automated means on the other subnet machines. While this file is not used with the Autokey Version 2 protocol, it is needed to authenticate some remote configuration commands used by the <a href="ntpdc.html"><tt>ntpq</tt></a> and <a href="ntpq.html"><tt>ntpdc</tt></a> utilities.</p>
+ <p>The <tt>ntp-keygen</tt> program generates a MD5 symmetric keys file <tt>ntpkey_MD5key_<i>hostname.filestamp</i></tt>. Since the file contains private shared keys, it should be visible only to root and distributed by secure means to other subnet
hosts. The NTP daemon loads the file <tt>ntp.keys</tt>, so <tt>ntp-keygen</tt> installs a soft link from this name to the generated file. Subsequently, similar soft links must be installed by manual or automated means on the other subnet hosts. While this file is not used with the Autokey Version 2 protocol, it is needed to authenticate some remote configuration commands used by the <a href="ntpdc.html"><tt>ntpq</tt></a> and <a href="ntpq.html"><tt>ntpdc</tt></a> utilities.</p>
<p>The symmetric key file contains 16 MD5 keys. Each key consists of 16 characters randomized over the ASCII 93-character printing subset. The file is read by the daemon at the location specified by the <tt>keys</tt> configuration file command. Additional keys consisting of easily remembered passwords should be added by hand for use with the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. While the key identifiers for MD5 keys must be in the range 1-65,535, inclusive, the <tt>ntp-keygen</tt> program uses only the identifiers from 1 to 16. The key identifier for each association is specified as the <tt>key</tt> subcommand with the <tt>server</tt> or <tt>peer</tt> configuration command.</p>
<h4 id="#priv">Private Key Files</h4>
- <p>The Autokey protocol requires every host to have a private/public host key pair and an optional private/public sign key pair. The <tt>ntp-keygen</tt> program generates a private key file <tt>ntpkey_<i>keyname</i>key_<i>hostname.filestamp</i></tt>, where <i>keyname</i> is the name of the public key algorithm type, either <tt>RSA</tt> or <tt>DSA</tt>. Since the host key is used to encrypt some data, it must be RSA type; the sign key file can be a RSA or DSA type. Since these files contain both the private unshared key and public shared key, they are useful only to the machine that generates them, so should be visible only to root and never shared with any other system or application program. The NTP daemon loads the host key file <tt>ntpkey_host_<i>hostname</i></tt> and the sign key file <tt>ntpkey_sign_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct these names to the generated files.</p>
+ <p>The Autokey protocol requires every host to have a private/public host key pair and an optional private/public sign key pair. The <tt>ntp-keygen</tt> program generates a private key file <tt>ntpkey_<i>keyname</i>key_<i>hostname.filestamp</i></tt>, where <i>keyname</i> is the name of the public key algorithm type, either <tt>RSA</tt> or <tt>DSA</tt>. Since the host key is used to encrypt some data, it must be RSA type; the sign key file can be a RSA or DSA type. These files contain private values, so should be encrypted or visible only to root. The NTP daemon loads the host key file <tt>ntpkey_host_<i>hostname</i></tt> and the sign key file <tt>ntpkey_sign_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct these names to the generated files.</p>
<h4 id="#ident">Identification Parameter Files</h4>
- <p>Of the four identification schemes implemented in Autokey, the IFF and GQ schemes require special parameters used as group keys, while the GQ scheme requires in addition a private/public key pair as well as a special certificate with the public key included in an X509v3 extension field. In both schemes parameter files are generated once only on a designated subnet machine, then securely distributed to all other subnet machines. On Unix machines, a convenient way to do this might be the <tt>sdist</tt> facility often used to update the latest software within the administrative domain.</p>
- <p>The <tt>ntp-keygen</tt> program with the <tt>-I</tt> flag generates an IFF parameter file <tt>ntpkey_IFFpar_<i>hostname.filestamp</i></tt> and with the <tt>-G</tt> flag generates a GQ parameter file <tt>ntpkey_GQpar_<i>hostname.filestamp</i></tt>. The NTP daemon loads the IFF parameter file <tt>ntpkey_IFFpar_<i>hostname</i></tt> and the GQ parameter file <tt>ntpkey_GQpar_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct these names to the generated files. Subsequently, similar soft links must be installed by manual or automated means on the other subnet machines.</p>
+ <p>Of the four identification schemes implemented in Autokey, the IFF and GQ schemes require special parameters used as group keys, while the GQ scheme requires in addition a private/public key pair as well as a special certificate with the public key included in an X509v3 extension field. In both schemes parameter files are generated by a trusted host, then securely distributed to all other hosts in the group. These files contain private values, so should be encrypted or visible only to root. On Unix machines, a convenient way to do this might be the <tt>sdist</tt> facility often used to update the latest software within the administrative domain.</p>
+ <p>The <tt>ntp-keygen</tt> program with the <tt>-I</tt> flag generates an IFF parameter file <tt>ntpkey_IFFpar_<i>hostname.filestamp</i></tt> and with the <tt>-G</tt> flag generates a GQ parameter file <tt>ntpkey_GQpar_<i>hostname.filestamp</i></tt>. The NTP daemon loads the IFF parameter file <tt>ntpkey_IFFpar_<i>hostname</i></tt> and the GQ parameter file <tt>ntpkey_GQpar_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct these names to the generated files. Subsequently, similar soft links must be installed by manual or automated means on the other hosts in the group.</p>
<p>When a certificate is generated for the GQ scheme, the <tt>ntp-keygen</tt> also generates a GQ key file <tt>ntpkey_GQkey_<i>hostname.filestamp</i></tt>. The NTP daemon loads the GQ key file <tt>ntpkey_gq_<i>hostname</i></tt>, so the program installs a soft link to direct this name to the generated file. At the same time the program generates a special certificate with the public key component saved in the "X509v3 Subject Key Identifier" extension field. It is important to note that the GQ keys and certificates are generated at the same time and that they can be regenerated from time to time without requiring new GQ parameters.</p>
- <p>Identification schemes are selected during operation depending on the presence or absence of the respective files. The default when no files are present is TC; if the IFF parameter file is present, then that scheme is used; if the GQ parameter file is present, then that scheme is used; if both are present, the GQ scheme is used.</p>
<h4 id="#cert">Certificates</h4>
<p>The Internet security infrastructure requires every host to have a digitally signed public certificate. Security procedures require the public key and host credentials, such as host name, responsible person, mail address, etc., to be provided in the form of a X.509 certificate request to a trusted certificate authority or CA. The CA attaches a digital signature to the request and returns the certificate with signature to the requesting party. The integrity of these procedures depend on the certificate trail that ultimately must end on a self-signed certificate provided by a trusted CA. The OpenSSL software library provides routines that can automate this process.</p>
- <p>Normally, the <tt>ntp-keygen</tt> program generates certificates which contain only public values, so they can be transmitted and stored without cryptographic protection. With the <tt>-p</tt> option the program generates a certificate including a "X509v3 "Extended Key Usage" extension field with value <tt>private</tt> The intent when this field is present is never to disclose the certificate outside the machine on which it is installed. Certificates generated without this option do not contain this field and are by default public.</p>
- <p>The Autokey TC identification scheme automates the certificate trail construction and verification process with each server at stratum <i>n</i> operating as a CA for clients at stratum <i>n</i> + 1. The <tt>ntp-keygen</tt> program generates a self-signed X.509v3 public certificate <tt>ntpkey_<i>digestname</i>cert_<i>hostname.filestamp</i></tt>, where <i>digestname</i> is the name of the digest/signature scheme. The NTP daemon loads the certificate <tt>ntpkey_cert_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct this name to the generated file. The ntp-keygen program with he <tt>-T</tt> flag generates a trusted certificate including a "X509v3 Extended Key Usage" extension field with value <tt>trustRoot</tt>. Certificates generated without this option do not contain this field and are by default non-trusted.</p>
+ <p>Normally, the <tt>ntp-keygen</tt> program generates certificates which contain only public values, so they can be transmitted and stored without cryptographic protection. With the <tt>-P</tt> option the program generates a certificate including a "X509v3 "Extended Key Usage" extension field with value <tt>private</tt> The intent when this field is present is never to disclose the certificate outside the host on which it is installed. Certificates generated without this option do not contain this field and are by default public.</p>
+ <p>The Autokey TC identification scheme automates the certificate trail construction and verification process with each server at stratum <i>n</i> operating as a CA for clients at stratum <i>n</i> + 1. The <tt>ntp-keygen</tt> program generates a self-signed X.509v3 public certificate <tt>ntpkey_<i>digestname</i>cert_<i>hostname.filestamp</i></tt>, where <i>digestname</i> is the name of the digest/signature scheme. The NTP daemon loads the certificate <tt>ntpkey_cert_<i>hostname</i></tt>, so <tt>ntp-keygen</tt> installs soft links to direct this name to the generated file. The <tt>ntp-keygen</tt> program with the <tt>-T</tt> flag generates a trusted certificate including a "X509v3 Extended Key Usage" extension field with value <tt>trustRoot</tt>. Certificates generated without this option do not contain this field and are by default non-trusted.</p>
<p>Public certificates contain only public values and can be freely transmitted and stored anywhere without further cryptographic protection, although this is rarely necessary. The Autokey protocol retrieves the server certificate and requests the server sign and return the client certificate. Where security considerations require, certificates can be transmitted to an outside trusted certificate authority (CA) and returned as a signed public certificate for use in the Autokey protocol.</p>
<p>The Autokey protocol supports all digest/signature schemes available in the OpenSSL library, including those using the MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms. However, the scheme specified in the certificate must be compatible with the sign key. Certificates using any digest algorithm are compatible with RSA sign keys; however, only SHA and SHA1 certificates are compatible with DSA sign keys.</p>
<h4 id="#leap">Leapseconds Table</h4>
<body>
<h3>Hints and Kinks</h3>
- <img src="pic/alice35.gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice35.gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Mother in law has all the answers.<br clear="left">
</p>
<hr>
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
<HTML>
<HEAD>
<TITLE>SCO Unix hints</title><link href="scripts/style.css" type="text/css" rel="stylesheet">
-<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.7 [en] (WinNT; I) [Netscape]">
- <title>NTP on Windows NT</title><link href="scripts/style.css" type="text/css" rel="stylesheet">
-
-</head>
-<body>
-
-<h1>
-NTP 4.x for Windows NT</h1>
-
-<h2>
-Do not try to compile NTP-4.0.99i under WINNT, it will not work.
-Fixed NTP-4.0.99i; look for next release to be functional.
-Sven - May 11 2000
-</h2>
-
-<h2>
-Download NTP-4.0.99g for the last stable WINNT port.
-I am working on adapting the major changes starting with 99i
-and getting things running again. Sven - April 25 2000
-</h2>
-
-<h2>
-Introduction</h2>
-The NTP 4 distribution runs as service on (i386) Windows NT 4.0 and Windows
-2000. The binaries work on dual processor systems. This port has not been
-tested on the Alpha platform.
-<p>Refer to System Requirements and Instructions for how to compile the
-program.
-<h2>
-Reference Clocks</h2>
-Refernce clock support under Windows NT is tricky because the IO functions
-are so much different. The following reference clocks are supported by
-Windows NT:
-<p><a href="../driver1.htm">Type 1</a> Undisciplined Local Clock (LOCAL)
-<br><a href="../driver29.htm">Type 29</a> Trimble Navigation Palisade GPS
-(GPS_PALISADE)
-<h2>
-Functions Supported</h2>
-All NTP functions are supported with some constraints. See the TODO list
-below.
-<h2>
-Accuracy</h2>
-Greg Brackley has implemented a fantastic interpolation scheme that improves
-the precision of the NTP clock using a realtime thread (is that poetic
-or what!) which captures a tick count from the 8253 counter after each
-OS tick. The count is used to interpolate the time between operating system
-ticks.
-<p>On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds
-and synchronizes the clock to +/-500 microseconds using the <a href="http://www.trimble.com/products/ntp">Trimble
-Palisade</a> as UTC reference. This allows distributed applications to
-use the 10 milliseconds ticks available to them with high confidence.
-<h2>
-Binaries</h2>
-Recent InstallShield based executable versions of NTP for Windows NT (i386)
-are available from:
-<br><a href="http://www.trimble.com/oem/ntp">http://www.trimble.com/oem/ntp</a>
-and <a href="http://www.five-ten-sg.com/">http://www.five-ten-sg.com/</a>
-<h2>
-ToDo</h2>
-
-<ul>
-<li>
-MD5 authentication causes problems with DNS. If you use encryption/authentication,
-you have to use IP numbers in <tt>ntp.conf.</tt>
-
-<li>
-NMEA refclock support is in development.
-
-<li>
-See if precision can be improved by using CPU cycle counter for tick interpolation.
-
-<li>
-Make precision time available to applications using NTP_GETTIME API
-</ul>
-
-<h2>
-Compiling Requirements</h2>
-
-<ul>
-<li>
-<tt>Windows NT 4.0 or 5.0 (2000)</tt>
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<li>
-<tt>Microsoft Visual C++ 6.0</tt>
-
-<li>
-Some version of the archiving program <tt>ZIP</tt>.
-</ul>
-
-<h2>
-Compiling Instructions</h2>
-
-<ol>
-<li>
-Unpack the NTP-4.x.tar.gz
-
-<li>
-Open the .\ports\winnt\ntp.dsw Visual C workspace
-
-<li>
-Batch build all projects
-</ol>
-
-<h2>
-Configuration File</h2>
-The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\.
-</tt>(%SystemRoot%
-is an environmental variable that can be determined by typing "set" at
-the "Command Prompt" or from the "System" icon in the "Control Panel").
-<br>Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt>
-file in the directory corresponding to your system installation.
-<br><tt>The older <WINDIR>\ntp.conf </tt>is still supported but you
-will get a log entry reporting that the first file wasn't found.
-<h2>
-Installation Instructions</h2>
-The <tt>instsrv</tt> program in the instsrv subdirectory of the distribution
-can be used to install 'ntpd' as a service and start automatically at boot
-time. Instsrv is automatically compiled with the rest of the distribution
-if you followed the steps above.
-<ol>
-<li>
-Start a command prompt and enter "instsrv.exe <pathname_for_ntpd.exe>"
-
-<li>
-Clicking on the "Services" icon in the "Control Panel" will display the
-list of currently installed services in a dialog box. The NetworkTimeProtocol
-service should show up in this list. Select it in the list and hit the
-"Start" button in the dialog box. The NTP service should start.
-
-<li>
-View the event log by clicking on the "Event Viewer" icon in the "Administrative
-Tools" group, there should be several successful startup messages from
-NTP. NTP will keep running and restart automatically when the machine is
-rebooted.
-</ol>
-You can change the start mode (automatic/manual) and other startup parameters
-correponding to the NTP service (eg. location of conf file) also in the
-"Services" dialog box if you wish.
-<h2>
-Removing NTP</h2>
-You can also use <tt>instsrv</tt> to delete the NTP service by entering:
-"instsrv.exe remove"
-<h2>
-Command Line Parameters and Registry Entries</h2>
-Unlike the Unix environment, there is no clean way to run 'ntpdate' and
-reset the clock before starting 'ntpd' at boot time.
-<br>NTP will step the clock up to 1000 seconds by default. While there
-is no reason that the system clock should be that much off during bootup
-if 'ntpd' was running before, you may wish to override this default and/or
-pass other command line directives.
-<p>Use the registry editor to edit the value for the ntpd executable under
-LocalMachine\System\CurrentControlSet\Services\NTP.
-<p>Add the -g option to the ImagePath key, behind "%INSTALLDIR>\ntpd.exe".
-This will force NTP to accept large time errors (including 1.1.1980 00:00)
-<h2>
-Bug Reports</h2>
-Send bug reports to <a href="news://comp.protocols.time.ntp">news://comp.protocols.time.ntp</a>
-and Sven_Dietrich@Trimble.COM
-<h2>
-Change Log</h2>
-
-<h3>
-Last revision 16 February 1999 Version 4.0.99e.</h3>
-<b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
-<p><b>Significant Changes:</b>
-<ul>
-<li>
-Perl 5 is no longer needed to compile NTP. The configuration script which
-creates version.c with the current date and time was modified by Frederick
-Czajka [w2k@austin.rr.com] so that Perl is no longer required.
-</ul>
-
-<h3>
-Last revision 15 November 1999 Version 4.0.98f.</h3>
-<b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
-<p><b>Significant Changes:</b>
-<ul>
-<li>
-Fixed I/O problem delaying packet responses which resulted in no-replys
-to NTPQ and others.
-
-<li>
-The default configuration file path is <tt><WINDIR>\system32\drivers\etc\ntp.conf.
-The old <WINDIR>\ntp.conf </tt>is still supported but you will get a
-log entry reporting that the first file wasn't found. The NTP 3.x legacy
-<tt>ntp.ini</tt>
-file is no longer supported.
-</ul>
-<b>Known Problems / TODO:</b>
-<ul>
-<li>
-MD5 and name resolution do not yet get along. If you define MD5, you cannot
-use DNS names, only IP numbers.
-</ul>
+<html>
-<h3>
-Last revision 27 July 1999 Version 4.0.95.</h3>
-This version compiles under WINNT with Visual C 6.0.
-<p>Greg Brackley and Sven Dietrich
-<p>Significant changes:
-<br>-Visual Studio v6.0 support
-<br>-Winsock 2.0 support
-<br>-Use of I/O completion ports for sockets and comm port I/O
-<br>-Removed the use of multimedia timers (from ntpd, others need removing)
-<br>-Use of waitable timers (with user mode APC) and performance counters
-to fake getting a better time
-<br>-Trimble Palisade NTP Reference Clock support
-<br>-General cleanup, prototyping of functions
-<br>-Moved receiver buffer code to a separate module (removed unused members
-from the recvbuff struct)
-<br>-Moved io signal code to a separate module
-<h3>
-Last revision: 20-Oct-1996</h3>
-This version corrects problems with building the XNTP
-<br>version 3.5-86 distribution under Windows NT.
-<p>The following files were modified:
-<br> blddbg.bat
-<br> bldrel.bat
-<br> include\ntp_machine.h
-<br> xntpd\ntp_unixclock.c
-<br> xntpd\ntp_refclock.c
-<br> scripts\wininstall\build.bat
-<br> scripts\wininstall\setup.rul
-<br> scripts\wininstall\readme.nt
-<br> scripts\wininstall\distrib\ntpog.wri
-<br> html\hints\winnt (this file)
-<p>In order to build the entire Windows NT distribution you
-<br>need to modify the file scripts\wininstall\build.bat
-<br>with the installation directory of the InstallShield
-<br>software. Then, simply type "bldrel" for non-debug
-<br>or "blddbg" for debug executables.
-<p>Greg Schueman
-<br> <schueman@acm.org>
-<h3>
-Last revision: 07-May-1996</h3>
-This set of changes fixes all known bugs, and it includes
-<br>several major enhancements.
-<p>Many changes have been made both to the build environment as
-<br>well as the code. There is no longer an ntp.mak file, instead
-<br>there is a buildntall.bat file that will build the entire
-<br>release in one shot. The batch file requires Perl. Perl
-<br>is easily available from the NT Resource Kit or on the Net.
-<p>The multiple interface support was adapted from Larry Kahn's
-<br>work on the BIND NT port. I have not been able to test it
-<br>adequately as I only have NT servers with one network
-<br>interfaces on which to test.
-<p>Enhancements:
-<br>* Event Logging now works correctly.
-<br>* Version numbers now work (requires Perl during build)
-<br>* Support for multiple network interface cards (untested)
-<br>* NTP.CONF now default, but supports ntp.ini if not found
-<br>* Installation procedure automated.
-<br>* All paths now allow environment variables such as %windir%
-<p>Bug fixes:
-<br>* INSTSRV replaced, works correctly
-<br>* Cleaned up many warnings
-<br>* Corrected use of an uninitialized variable in XNTPD
-<br>* Fixed ntpdate -b option
-<br>* Fixed ntpdate to accept names as well as IP addresses
-<br> (Winsock WSAStartup was
-called after a gethostbyname())
-<br>* Fixed problem with "longjmp" in xntpdc/ntpdc.c that
-<br> caused a software exception
-on doing a Control-C in xntpdc.
-<br> A Cntrl-C now terminates the program.
-<p>See below for more detail:
-<p> Note: SIGINT is not supported for any
-Win32 application including
-<br> Windows NT and Windows 95. When a CTRL+C
-interrupt occurs, Win32
-<br> operating systems generate a new thread
-to specifically handle that
-<br> interrupt. This can cause a single-thread
-application such as UNIX,
-<br> to become multithreaded, resulting in
-unexpected behavior.
-<br>
-<p>Possible enhancements and things left to do:
-<br>* Reference clock drivers for NT (at least Local Clock support)
-<br>* Control Panel Applet
-<br>* InstallShield based installation, like NT BIND has
-<br>* Integration with NT Performance Monitor
-<br>* SNMP integration
-<br>* Fully test multiple interface support
-<br>
-<p>Known problems:
-<br>* bug in ntptrace - if no Stratum
-1 servers are available,
-<br>
-such as on an IntraNet, the application crashes.
-<h3>
-Last revision: 12-Apr-1995</h3>
-This NTPv3 distribution includes a sample configuration file and the project
-<br>makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0
-compiler.
-<br>Also included is a small routine to install the NTP daemon as a "service"
-<br>on a WindowsNT box. Besides xntpd, the utilities that have been ported
-are
-<br>ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using
-a Bancomm
-<br>TimeServe2000 GPS receiver clock that acts as a strata 1 NTP server
-with no
-<br>authentication (it has not been tested with any refclock drivers compiled
-in).
-<br>Following are the known flaws in this port:
-<br>1) currently, I do not know of a way in NT to get information about
-multiple
-<br> network interface cards. The current port uses just one
-socket bound to
-<br> INADDR_ANY address. Therefore when dealing with a multihomed
-NT time server,
-<br> clients should point to the default address on the server
-(otherwise the
-<br> reply is not guaranteed to come from the same interface
-to which the
-<br> request was sent). Working with Microsoft to get this
-resolved.
-<br>2) There is some problem with "longjmp" in xntpdc/ntpdc.c that causes
-a
-<br> software exception on doing a Control-C in xntpdc. Be
-patient!
-<br>3) The error messages logged by xntpd currently contain only the numerical
-<br> error code. Corresponding error message string has to
-be looked up in
-<br> "Books Online" on Visual C++ 2.0 under the topic "Numerical
-List of Error
-<br> Codes".
-<p>Last HTML Update: November 17, 1999
-<br><a href="mailto://sven_dietrich@trimble.com">Sven_Dietrich@Trimble.COM</a>
-</body>
-</html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.7 [en] (WinNT; I) [Netscape]">
+ <title>NTP on Windows NT</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h1>NTP 4.x for Windows NT</h1>
+ <h2>Do not try to compile NTP-4.0.99i under WINNT, it will not work. Fixed NTP-4.0.99i; look for next release to be functional. Sven - May 11 2000</h2>
+ <h2>Download NTP-4.0.99g for the last stable WINNT port. I am working on adapting the major changes starting with 99i and getting things running again. Sven - April 25 2000</h2>
+ <h2>Introduction</h2>
+ The NTP 4 distribution runs as service on (i386) Windows NT 4.0 and Windows 2000. The binaries work on dual processor systems. This port has not been tested on the Alpha platform.
+ <p>Refer to System Requirements and Instructions for how to compile the program.</p>
+ <h2>Reference Clocks</h2>
+ Refernce clock support under Windows NT is tricky because the IO functions are so much different. The following reference clocks are supported by Windows NT:
+ <p><a href="../driver1.html">Type 1</a> Undisciplined Local Clock (LOCAL)<br>
+ <a href="../driver29.html">Type 29</a> Trimble Navigation Palisade GPS (GPS_PALISADE)</p>
+ <h2>Functions Supported</h2>
+ All NTP functions are supported with some constraints. See the TODO list below.
+ <h2>Accuracy</h2>
+ Greg Brackley has implemented a fantastic interpolation scheme that improves the precision of the NTP clock using a realtime thread (is that poetic or what!) which captures a tick count from the 8253 counter after each OS tick. The count is used to interpolate the time between operating system ticks.
+ <p>On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds and synchronizes the clock to +/-500 microseconds using the <a href="http://www.trimble.com/products/ntp">Trimble Palisade</a> as UTC reference. This allows distributed applications to use the 10 milliseconds ticks available to them with high confidence.</p>
+ <h2>Binaries</h2>
+ Recent InstallShield based executable versions of NTP for Windows NT (i386) are available from:<br>
+ <a href="http://www.trimble.com/oem/ntp">http://www.trimble.com/oem/ntp</a> and <a href="http://www.five-ten-sg.com/">http://www.five-ten-sg.com/</a>
+ <h2>ToDo</h2>
+ <ul>
+ <li>MD5 authentication causes problems with DNS. If you use encryption/authentication, you have to use IP numbers in <tt>ntp.conf.</tt>
+ <li>NMEA refclock support is in development.
+ <li>See if precision can be improved by using CPU cycle counter for tick interpolation.
+ <li>Make precision time available to applications using NTP_GETTIME API
+ </ul>
+ <h2>Compiling Requirements</h2>
+ <ul>
+ <li><tt>Windows NT 4.0 or 5.0 (2000)</tt>
+ <li><tt>Microsoft Visual C++ 6.0</tt>
+ <li>Some version of the archiving program <tt>ZIP</tt>.
+ </ul>
+ <h2>Compiling Instructions</h2>
+ <ol>
+ <li>Unpack the NTP-4.x.tar.gz
+ <li>Open the .\ports\winnt\ntp.dsw Visual C workspace
+ <li>Batch build all projects
+ </ol>
+ <h2>Configuration File</h2>
+ The default NTP configuration file path is %SystemRoot%<tt>\system32\drivers\etc\. </tt>(%SystemRoot% is an environmental variable that can be determined by typing "set" at the "Command Prompt" or from the "System" icon in the "Control Panel").<br>
+ Refer to your system environment and <tt>c</tt>reate your<tt> ntp.conf</tt> file in the directory corresponding to your system installation.<br>
+ <tt>The older <WINDIR>\ntp.conf </tt>is still supported but you will get a log entry reporting that the first file wasn't found.
+ <h2>Installation Instructions</h2>
+ The <tt>instsrv</tt> program in the instsrv subdirectory of the distribution can be used to install 'ntpd' as a service and start automatically at boot time. Instsrv is automatically compiled with the rest of the distribution if you followed the steps above.
+ <ol>
+ <li>Start a command prompt and enter "instsrv.exe <pathname_for_ntpd.exe>"
+ <li>Clicking on the "Services" icon in the "Control Panel" will display the list of currently installed services in a dialog box. The NetworkTimeProtocol service should show up in this list. Select it in the list and hit the "Start" button in the dialog box. The NTP service should start.
+ <li>View the event log by clicking on the "Event Viewer" icon in the "Administrative Tools" group, there should be several successful startup messages from NTP. NTP will keep running and restart automatically when the machine is rebooted.
+ </ol>
+ You can change the start mode (automatic/manual) and other startup parameters correponding to the NTP service (eg. location of conf file) also in the "Services" dialog box if you wish.
+ <h2>Removing NTP</h2>
+ You can also use <tt>instsrv</tt> to delete the NTP service by entering: "instsrv.exe remove"
+ <h2>Command Line Parameters and Registry Entries</h2>
+ Unlike the Unix environment, there is no clean way to run 'ntpdate' and reset the clock before starting 'ntpd' at boot time.<br>
+ NTP will step the clock up to 1000 seconds by default. While there is no reason that the system clock should be that much off during bootup if 'ntpd' was running before, you may wish to override this default and/or pass other command line directives.
+ <p>Use the registry editor to edit the value for the ntpd executable under LocalMachine\System\CurrentControlSet\Services\NTP.</p>
+ <p>Add the -g option to the ImagePath key, behind "%INSTALLDIR>\ntpd.exe". This will force NTP to accept large time errors (including 1.1.1980 00:00)</p>
+ <h2>Bug Reports</h2>
+ Send bug reports to <a href="news://comp.protocols.time.ntp">news://comp.protocols.time.ntp</a> and Sven_Dietrich@Trimble.COM
+ <h2>Change Log</h2>
+ <h3>Last revision 16 February 1999 Version 4.0.99e.</h3>
+ <b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
+ <p><b>Significant Changes:</b></p>
+ <ul>
+ <li>Perl 5 is no longer needed to compile NTP. The configuration script which creates version.c with the current date and time was modified by Frederick Czajka [w2k@austin.rr.com] so that Perl is no longer required.
+ </ul>
+ <h3>Last revision 15 November 1999 Version 4.0.98f.</h3>
+ <b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
+ <p><b>Significant Changes:</b></p>
+ <ul>
+ <li>Fixed I/O problem delaying packet responses which resulted in no-replys to NTPQ and others.
+ <li>The default configuration file path is <tt><WINDIR>\system32\drivers\etc\ntp.conf. The old <WINDIR>\ntp.conf </tt>is still supported but you will get a log entry reporting that the first file wasn't found. The NTP 3.x legacy <tt>ntp.ini</tt> file is no longer supported.
+ </ul>
+ <b>Known Problems / TODO:</b>
+ <ul>
+ <li>MD5 and name resolution do not yet get along. If you define MD5, you cannot use DNS names, only IP numbers.
+ </ul>
+ <h3>Last revision 27 July 1999 Version 4.0.95.</h3>
+ This version compiles under WINNT with Visual C 6.0.
+ <p>Greg Brackley and Sven Dietrich</p>
+ <p>Significant changes:<br>
+ -Visual Studio v6.0 support<br>
+ -Winsock 2.0 support<br>
+ -Use of I/O completion ports for sockets and comm port I/O<br>
+ -Removed the use of multimedia timers (from ntpd, others need removing)<br>
+ -Use of waitable timers (with user mode APC) and performance counters to fake getting a better time<br>
+ -Trimble Palisade NTP Reference Clock support<br>
+ -General cleanup, prototyping of functions<br>
+ -Moved receiver buffer code to a separate module (removed unused members from the recvbuff struct)<br>
+ -Moved io signal code to a separate module</p>
+ <h3>Last revision: 20-Oct-1996</h3>
+ This version corrects problems with building the XNTP<br>
+ version 3.5-86 distribution under Windows NT.
+ <p>The following files were modified:<br>
+ blddbg.bat<br>
+ bldrel.bat<br>
+ include\ntp_machine.h<br>
+ xntpd\ntp_unixclock.c<br>
+ xntpd\ntp_refclock.c<br>
+ scripts\wininstall\build.bat<br>
+ scripts\wininstall\setup.rul<br>
+ scripts\wininstall\readme.nt<br>
+ scripts\wininstall\distrib\ntpog.wri<br>
+ html\hints\winnt (this file)</p>
+ <p>In order to build the entire Windows NT distribution you<br>
+ need to modify the file scripts\wininstall\build.bat<br>
+ with the installation directory of the InstallShield<br>
+ software. Then, simply type "bldrel" for non-debug<br>
+ or "blddbg" for debug executables.</p>
+ <p>Greg Schueman<br>
+ <schueman@acm.org></p>
+ <h3>Last revision: 07-May-1996</h3>
+ This set of changes fixes all known bugs, and it includes<br>
+ several major enhancements.
+ <p>Many changes have been made both to the build environment as<br>
+ well as the code. There is no longer an ntp.mak file, instead<br>
+ there is a buildntall.bat file that will build the entire<br>
+ release in one shot. The batch file requires Perl. Perl<br>
+ is easily available from the NT Resource Kit or on the Net.</p>
+ <p>The multiple interface support was adapted from Larry Kahn's<br>
+ work on the BIND NT port. I have not been able to test it<br>
+ adequately as I only have NT servers with one network<br>
+ interfaces on which to test.</p>
+ <p>Enhancements:<br>
+ * Event Logging now works correctly.<br>
+ * Version numbers now work (requires Perl during build)<br>
+ * Support for multiple network interface cards (untested)<br>
+ * NTP.CONF now default, but supports ntp.ini if not found<br>
+ * Installation procedure automated.<br>
+ * All paths now allow environment variables such as %windir%</p>
+ <p>Bug fixes:<br>
+ * INSTSRV replaced, works correctly<br>
+ * Cleaned up many warnings<br>
+ * Corrected use of an uninitialized variable in XNTPD<br>
+ * Fixed ntpdate -b option<br>
+ * Fixed ntpdate to accept names as well as IP addresses<br>
+ (Winsock WSAStartup was called after a gethostbyname())<br>
+ * Fixed problem with "longjmp" in xntpdc/ntpdc.c that<br>
+ caused a software exception on doing a Control-C in xntpdc.<br>
+ A Cntrl-C now terminates the program.</p>
+ <p>See below for more detail:</p>
+ <p> Note: SIGINT is not supported for any Win32 application including<br>
+ Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32<br>
+ operating systems generate a new thread to specifically handle that<br>
+ interrupt. This can cause a single-thread application such as UNIX,<br>
+ to become multithreaded, resulting in unexpected behavior.<br>
+ </p>
+ <p>Possible enhancements and things left to do:<br>
+ * Reference clock drivers for NT (at least Local Clock support)<br>
+ * Control Panel Applet<br>
+ * InstallShield based installation, like NT BIND has<br>
+ * Integration with NT Performance Monitor<br>
+ * SNMP integration<br>
+ * Fully test multiple interface support<br>
+ </p>
+ <p>Known problems:<br>
+ * bug in ntptrace - if no Stratum 1 servers are available,<br>
+ such as on an IntraNet, the application crashes.</p>
+ <h3>Last revision: 12-Apr-1995</h3>
+ This NTPv3 distribution includes a sample configuration file and the project<br>
+ makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0 compiler.<br>
+ Also included is a small routine to install the NTP daemon as a "service"<br>
+ on a WindowsNT box. Besides xntpd, the utilities that have been ported are<br>
+ ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using a Bancomm<br>
+ TimeServe2000 GPS receiver clock that acts as a strata 1 NTP server with no<br>
+ authentication (it has not been tested with any refclock drivers compiled in).<br>
+ Following are the known flaws in this port:<br>
+ 1) currently, I do not know of a way in NT to get information about multiple<br>
+ network interface cards. The current port uses just one socket bound to<br>
+ INADDR_ANY address. Therefore when dealing with a multihomed NT time server,<br>
+ clients should point to the default address on the server (otherwise the<br>
+ reply is not guaranteed to come from the same interface to which the<br>
+ request was sent). Working with Microsoft to get this resolved.<br>
+ 2) There is some problem with "longjmp" in xntpdc/ntpdc.c that causes a<br>
+ software exception on doing a Control-C in xntpdc. Be patient!<br>
+ 3) The error messages logged by xntpd currently contain only the numerical<br>
+ error code. Corresponding error message string has to be looked up in<br>
+ "Books Online" on Visual C++ 2.0 under the topic "Numerical List of Error<br>
+ Codes".
+ <p>Last HTML Update: November 17, 1999<br>
+ <a href="mailto://sven_dietrich@trimble.com">Sven_Dietrich@Trimble.COM</a></p>
+ </body>
+
+</html>
\ No newline at end of file
<body>
<h3>How to Write a Reference Clock Driver</h3>
- <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>You need a little magic.
</p>
<h4>Related Links</h4>
<p>The audio drivers are designed to look like a typical external radio in that the reference oscillator is derived from the audio codec oscillator and separate from the system clock oscillator. In the WWV and IRIG drivers, the codec oscillator is disciplined in frequency to the standard timescale via radio or local sources and can be assumed to have the same reliability and accuracy as an external radio. In these cases the driver continues to provide updates to the clock filter even if the WWV or IRIG signals are lost. However, the interface is provided the last reference time when the signals were received and increases the dispersion as expected with an ordinary peer.</p>
<p>The best way to understand how the clock drivers work is to study the <tt>ntp_refclock.c</tt> module and one of the drivers already implemented, such as <tt>refclock_wwvb.c</tt>. Routines <tt>refclock_transmit()</tt> and <tt>refclock_receive()</tt> maintain the peer variables in a state analogous to a network peer and pass received data on through the clock filters. Routines <tt>refclock_peer()</tt> and <tt>refclock_unpeer()</tt> initialize and terminate reference clock associations, should this ever be necessary. A set of utility routines is included to open serial devices, process sample data, edit input lines to extract embedded timestamps and to perform various debugging functions.</p>
<p>The main interface used by these routines is the <tt>refclockproc</tt> structure, which contains for most drivers the decimal equivalents of the year, day, month, hour, second and nanosecond decoded from the radio timecode. Additional information includes the receive timestamp, reference timestamp, exception reports, statistics tallies, etc. The support routines are passed a pointer to the <tt>peer</tt> structure, which is used for all peer-specific processing and contains a pointer to the <tt>refclockproc</tt> structure, which in turn contains a pointer to the unit structure, if used. For legacy purposes, a table <tt>typeunit[type][unit]</tt> contains the peer structure pointer for each configured clock type and unit. This structure should not be used for new implementations.</p>
- <p>The reference clock interface supports auxiliary functions to support in-stream timestamping, pulse-per-second (PPS) interfacing and precision time kernel support. In most cases the drivers do not need to be aware of them, since they are detected at autoconfigure time and loaded automatically when the device is opened. These include the <tt>tty_clk</tt> STREAMS module and <tt>ppsapi</tt> PPS interface described in the <a href="ldisc.html">Line Disciplines and Streams Modules</a> page. The <tt>tty_clk</tt> module reduces latency errors due to the operating system and serial port code in slower systems. The <tt>ppsapi</tt> PPS interface replaces the <tt>ppsclock</tt> STREAMS module and is expected to become the IETF standard cross-platform interface for PPS signals. In either case, the PPS signal can be connected via a level converter/pulse generator described in the <a href="gadget.html">Gadget Box PPS Level Converter and CHU Modem</a> page.</p>
+ <p>The reference clock interface supports auxiliary functions to support in-stream timestamping, pulse-per-second (PPS) interfacing and precision time kernel support. In most cases the drivers do not need to be aware of them, since they are detected at autoconfigure time and loaded automatically when the device is opened. These include the <tt>tty_clk</tt> STREAMS module and <tt>ppsapi</tt> PPS interface described in the <a href="ldisc.html">Line Disciplines and Streams Modules</a> page. The <tt>tty_clk</tt> module reduces latency errors due to the operating system and serial port code in slower systems. The <tt>ppsapi</tt> PPS interface replaces the <tt>ppsclock</tt> STREAMS module and is expected to become the IETF standard cross-platform interface for PPS signals. In either case, the PPS signal can be connected via a level converter/pulse generator described in the <a href=pps.html>Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
<p>Radio and modem reference clocks by convention have addresses in the form <tt>127.127.<i>t</i>.<i>u</i></tt>, where <i>t</i> is the clock type and <i>u</i> in the range 0-3 is used to distinguish multiple instances of clocks of the same type. Most clocks require a serial or parallel port or special bus peripheral. The particular device is normally specified by adding a soft link <tt>/dev/device<i>d</i>d</tt> to the particular hardware device involved, where <tt><i>d</i></tt> corresponds to the unit number.</p>
<p>By convention, reference clock drivers are named in the form <tt>refclock_<i>xxxx</i>.c</tt>, where <i>xxxx</i> is a unique string. Each driver is assigned a unique type number, long-form driver name, short-form driver name and device name. The existing assignments are in the <a href="refclock.html">Reference Clock Drivers</a> page and its dependencies. All drivers supported by the particular hardware and operating system are automatically detected in the autoconfigure phase and conditionally compiled. They are configured when the daemon is started according to the configuration file, as described in the <a href="config.html">Configuration Options</a> page.</p>
<p>The standard clock driver interface includes a set of common support routines some of which do such things as start and stop the device, open the serial port, and establish special functions such as PPS signal support. Other routines read and write data to the device and process time values. Most drivers need only a little customizing code to, for instance, transform idiosyncratic timecode formats to standard form, poll the device as necessary, and handle exception conditions. A standard interface is available for remote debugging and monitoring programs, such as <tt>ntpq</tt> and <tt>ntpdc</tt>, as well as the <tt>filegen</tt> facility, which can be used to record device status on a continuous basis.</p>
<body>
<h3>The Network Time Protocol (NTP) Distribution</h3>
- <img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.</p>
<h4>Related Links</h4>
<p>
<br clear="left">
<h4>Table of Contents</h4>
<ul>
- <li class=inline><a href=#intro>Introduction</a>
- <li class=inline><a href=#build>Building and Installing NTP</a>
- <li class=inline><a href=#conf>Configuring Clients and Servers</a>
- <li class=inline><a href=#conf>Configuring Clients and Servers</a>
- <li class=inline><a href=#prog>Program Manual Pages</a>
- <li class=inline><a href=#docs>Supporting Documentation</a>
- <li class=inline><a href=#back>Background Information</a>
- <li class=inline><a href=#app>Application Notes</a>
-
-
+ <li class="inline"><a href="#intro">Introduction</a>
+ <li class="inline"><a href="#build">Building and Installing NTP</a>
+ <li class="inline"><a href="#conf">Configuring Clients and Servers</a>
+ <li class="inline"><a href="#conf">Configuring Clients and Servers</a>
+ <li class="inline"><a href="#prog">Program Manual Pages</a>
+ <li class="inline"><a href="#docs">Supporting Documentation</a>
+ <li class="inline"><a href="#back">Background Information</a>
+ <li class="inline"><a href="#app">Application Notes</a>
</ul>
<hr>
- <h4 id=#intro>Introduction</h4>
- <p>Note: The software contained in this distribution is available without charge under the conditions set forth in the <a href="copyright.html">Copyright Notice</a>.
+ <h4 id="#intro">Introduction</h4>
+ <p>Note: The software contained in this distribution is available without charge under the conditions set forth in the <a href="copyright.html">Copyright Notice</a>.</p>
<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically 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.</p>
<p>This software release implements NTP Version 4 (NTPv4), but is in general backwards compatible with previous versions, except NTP Version 1, support for which is no longer viable. NTPv4 includes support for both symmetric key and public key cryptography to prevent accidental or malicious protocol attacks, as well as automatic server discovery using IP multicast means. This release includes full support for the IPv6 address family, where the operating system sypports it, as well as the default IPv4 address family. Either or both families can be used at the same time on the same machine.</p>
- <p>Background information on computer network time synchronization can be found on the <a href="http://www.eecis.udel.edu/%7emills/exec.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="http://www.eecis.udel.edu/%7emills/biblio.htm">Protocol Conformance Statement</a> page. Discussion on how NTP reckons the time can be found in the <a href="http://www.eecis.udel.edu/%7emills/leap.htm">NTP Timescale and Leap Seconds</a> page. Background information, bibliography and briefing slides suitable for presentations can be found in the <a href="http://www.eecis.udel.edu/%7emills/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 id=#build>Building and Installing NTP</h4>
- <p>NTP supports Unix and Windows (NT4 and 2000) systems. The <a href="build.html">Building and Installing the Distribution</a> page presents an overview of the procedures for compiling the distribution and installing it on a typical client or server. The build procedures inspect the system hardware and software environment and automatically select the appropriate options for that environment. While these procedures work with most computers and operating systems marketed today, exceptions requiring manual intervention do exist, as documented in the <a href="config.html">Configuration Options</a> and <a href="release.html">Release Notes</a> pages.
+ <p>Background information on computer network time synchronization can be found on the <a href="http://www.eecis.udel.edu/%7emills/exec.htm
l">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="http://www.eecis.udel.edu/%7emills/biblio.html">Protocol Conformance Statement</a> page. Discussion on how NTP reckons the time can be found in the <a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a> page. Background information, bibliography and briefing slides suitable for presentations can be found in the <a href="http://www.eecis.udel.edu/%7emills/ntp.html">Network Time Synchronization Project</a> page. Additional information can be found at the NTP web site <a href="http://www.ntp.org">www.ntp.org</a>. Please send bug reports to <a href="mailto:bugs@mail.ntp.org"><bugs@mail.ntp.org></a>.</p>
+ <h4 id="#build">Building and Installing NTP</h4>
+ <p>NTP supports Unix and Windows (NT4 and 2000) systems. The <a href="build.html">Building and Installing the Distribution</a> page presents an overview of the procedures for compiling the distribution and installing it on a typical client or server. The build procedures inspect the system hardware and software environment and automatically select the appropriate options for that environment. While these procedures work with most computers and operating systems marketed today, exceptions requiring manual intervention do exist, as documented in the <a href="config.html">Configuration Options</a> and <a href="release.html">Release Notes</a> pages.</p>
<p>Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for some forty radio and satellite clocks and modem services. A list of supported drivers is given in the <a href="refclock.html">Reference Clock Drivers</a> page. It is also possible to use an otherwise undisciplined machine as a primary or backup server, as described on the <a href="driver1.html">Undisciplined Local Clock</a> page. For most popular workstations marketed by Sun, Silicon Graphics and Hewlett Packard, as well as widely available Unix clones such as FreeBSD and Linux, the automatic build procedures select all drivers that run on the target machine. While this increases the size of the executable binary somewhat, individual drivers can be included or excluded using the configure utility documented in the Configuration Options page.</p>
<p>Some programs included in this distribution use cryptographic algorithms to verify authenticity and credentials. Where local security policy permits relatively weak symmetric key cryptography, the required software is included in this distribution. However, where local policy requires stronger public key cryptography, additional software not in this distribution is required. This distribution uses the OpenSSL library available from <a href="http://www.openssl.org">http://www.openssl.org</a>. This library is also used by the Secure Shell facility, so is often already installed on Unix workstations and servers. It includes support for most message digest and digital signature algorithms used in the industry, as well as X.509 certificate generation, signing and verification.</p>
- <p>While public key cryptography is optional but highly recommended for all NTP operations, it is required for the NTPv4 Autokey protocol described on the <a href="http://www.eecis.udel.edu/%7emills/autokey.htm">Autonomous Authentication</a> page and is an integral component of the generic automatic configuration scheme described on the <a href="http://www.eecis.udel.edu/%7emills/autocfg.htm">Autonomous Configuration</a> page. Manycast mode, which is an adaptation of this scheme to NTPv4, is described below.</p>
- <h4 id=#conf>Configuring Clients and Servers</h4>
+ <p>While public key cryptography is optional but highly recommended for all NTP operations, it is required for the NTPv4 Autokey protocol described on the <a href="http://www.eecis.udel.edu/%7emills/autokey.html">Autonomous Authentication</a> page and is an integral component of the generic automatic configuration scheme described on the <a href="http://www.eecis.udel.edu/%7emills/autocfg.html">Autonomous Configuration</a> page. Manycast mode, which is an adaptation of this scheme to NTPv4, is described below.</p>
+ <h4 id="#conf">Configuring Clients and Servers</h4>
<p>NTP is by its very nature a complex distributed network application and can be configured and used for a great many widely divergent timekeeping scenarios. The documentation presented on these pages attempts to cover the entire suite of configuration, operation and maintenance facilities which this distribution supports. However, most applications will need only a few of these facilities. If this is the case, the <a href="quick.html">Quick Start</a> page may be useful to get a simple workstation on the air with an existing server.</p>
<p>However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called <tt>ntp.conf</tt>, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the <a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a> page. However, in many common cases involving simple network topologies and workstations, the configuration data can be specified entirely on the command line for the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>.</p>
<p>The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. A discussion on the available modes is on the <a href="assoc.html">Association Management</a> page. NTP support for one or more computers is normally engineered as part of the existing 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>Configuring a corporate or campus NTP subnet can be an engineering challenge. NTP contains many features designed to survive system and network failures, software bugs, clock errors and hacker attacks. Surviving these hazards requires intricate design of the timekeeping network using good principles of server redundancy and path diversity. The Manycast mode, new to NTPv4, is designed to track the current server and network states and adjust the client/server configuration for the best available accuracy and reliability. More information on the Manycast mode is on the <a href="authopt.html">Athentication Options</a> and <a href="manyopt.html">Automatic NTP Configuration Options</a> pages.</p>
- <p>The NTP subnet in late 2002 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/%7emills/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 against 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 id=#porb>Resolving Problems</h4>
+ <p>The NTP subnet in late 2002 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/%7emills/ntp/index.html">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 against 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 id="#porb">Resolving Problems</h4>
<p>Like other things Internet, the NTP synchronization subnets tend to be large and devilishly intricate, with many opportunities for misconfiguration and network problems. The NTP engineering model is specifically designed to help isolate and repair such problems using an integrated management protocol, together with a suite of monitoring and debugging tools. There is an optional data recording facility which can be used to record normal and aberrant operation, log problems to the system log facility, and retain records of client access. The <a href="debug.html">NTP Debugging Techniques</a> and <a href="hints.html">Hints and Kinks</a> pages contain useful information for identifying problems and devising solutions.</p>
<p>Users are requested to report bugs, offer suggestions and contribute additions to this distribution. The <a href="patches.html">Patching Procedures</a> page suggests procedures which greatly simplify distribution updates, while the <a href="porting.html">Porting Hints</a> page suggest ways to make porting this code to new hardware and operating systems easier. Additional information on reference clock driver construction and debugging can be found in the <a href="refclock.html">Reference Clock Drivers</a> page. Further information on NTP in the Internet can be found in the <a href="http://www.eecis.udel.edu/%7entp">NTP web page</a>.</p>
- <h4 id=#prog>Program Manual Pages</h4>
+ <h4 id="#prog">Program Manual Pages</h4>
<ul>
- <li class=
inline><a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>
- <li class=
inline><a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>
- <li class=
inline><a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>
- <li class=
inline><a href="ntpdate.html"><tt>ntpdate</tt> - set the date and time via NTP</a>
- <li class=
inline><a href="ntptrace.html"><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a>
- <li class=
inline><a href="tickadj.html"><tt>tickadj</tt> - set time-related kernel variables</a>
- <li class=
inline><a href="ntptime.html"><tt>ntptime</tt> - read kernel time variables</a>
- <li class=
inline><a href="genkeys.html"><tt>ntp-genkeys</tt> - generate public and private keys</a>
+ <li class=
"inline"><a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>
+ <li class=
"inline"><a href="ntpq.html"><tt>ntpq</tt> - standard NTP query program</a>
+ <li class=
"inline"><a href="ntpdc.html"><tt>ntpdc</tt> - special NTP query program</a>
+ <li class=
"inline"><a href="ntpdate.html"><tt>ntpdate</tt> - set the date and time via NTP</a>
+ <li class=
"inline"><a href="ntptrace.html"><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</a>
+ <li class=
"inline"><a href="tickadj.html"><tt>tickadj</tt> - set time-related kernel variables</a>
+ <li class=
"inline"><a href="ntptime.html"><tt>ntptime</tt> - read kernel time variables</a>
+ <li class=
"inline"><a href="genkeys.html"><tt>ntp-genkeys</tt> - generate public and private keys</a>
</ul>
- <h4 id=#docs>Supporting Documentation</h4>
+ <h4 id="#docs">Supporting Documentation</h4>
<ul>
- <li class=
inline><a href="copyright.html">Copyright Notice</a>
- <li class=
inline><a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a>
- <li class=
inline><a href="release.html">NTP Version 4 Release Notes</a>
- <li class=
inline><a href="build.html">Building and Installing the Distribution</a>
- <li class=
inline><a href="config.html">Configuration Options</a>
- <li class=
inline><a href="debug.html">NTP Debugging Techniques</a>
- <li class=
inline><a href="refclock.html">Reference Clock Drivers</a>
- <li class=
inline><a href="patches.html">Patching Procedures</a>
- <li class=
inline><a href="hints.html">Hints and Kinks</a>
- <li class=
inline><a href="porting.html">Porting Hints</a>
+ <li class=
"inline"><a href="copyright.html">Copyright Notice</a>
+ <li class=
"inline"><a href="notes.html">Notes on Configuring NTP and Setting up a NTP Subnet</a>
+ <li class=
"inline"><a href="release.html">NTP Version 4 Release Notes</a>
+ <li class=
"inline"><a href="build.html">Building and Installing the Distribution</a>
+ <li class=
"inline"><a href="config.html">Configuration Options</a>
+ <li class=
"inline"><a href="debug.html">NTP Debugging Techniques</a>
+ <li class=
"inline"><a href="refclock.html">Reference Clock Drivers</a>
+ <li class=
"inline"><a href="patches.html">Patching Procedures</a>
+ <li class=
"inline"><a href="hints.html">Hints and Kinks</a>
+ <li class=
"inline"><a href="porting.html">Porting Hints</a>
</ul>
- <h4 id=#back>Background Information</h4>
+ <h4 id="#back">Background Information</h4>
<ul>
- <li class=inline><a href="http://www.eecis.udel.edu/%7emills/ntp.htm">NTP Project and Reference Library</a>
- <li class=inline><a href="http://www.eecis.udel.edu/%7emills/exec.htm">Executive Summary - Computer Network Time Synchronization</a>
- <li class=inline><a href="http://www.eecis.udel.edu/%7emills/y2k.htm">The Network Time Protocol Timescale and Era Numbering</a>
- <li class=inline><a href="http://www.eecis.udel.edu/%7emills/leap.htm">NTP Timescale and Leap Seconds</a>
- <li class=inline><a href="http://www.eecis.udel.edu/%7emills/biblio.htm">Protocol Conformance Statement</a>
+ <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/ntp.html">NTP Project and Reference Library</a>
+ <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/exec.html">Executive Summary - Computer Network Time Synchronization</a>
+ <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/y2k.html">The Network Time Protocol Timescale and Era Numbering</a>
+ <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/leap.html">NTP Timescale and Leap Seconds</a>
+ <li class="inline"><a href="http://www.eecis.udel.edu/%7emills/biblio.html">Protocol Conformance Statement</a>
</ul>
- <h4 id=#app>Application Notes</h4>
+ <h4 id="#app">Application Notes</h4>
<ul>
- <li class=inline><a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a>
- <li class=inline><a href="assoc.html">Association Management</a>
- <li class=inline><a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a>
- <li class=inline><a href="gadget.html">Gadget Box PPS Level Converter and CHU Modem</a>
- <li class=inline><a href="measure.html">Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</a>
- <li class=inline><a href="kern.html">Kernel Model for Precision Timekeeping</a>
- <li class=inline><a href="kernpps.html">Kernel Programming Interface for Precision Time Signals</a>
+ <li class="inline"><a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a>
+ <li class="inline"><a href="assoc.html">Association Management</a>
+ <li class="inline"><a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a>
+ <li class="inline"><a href="measure.html">Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</a>
+ <li class="inline"><a href="kern.html">Kernel Model for Precision Timekeeping</a>
</ul>
<hr>
<div align="center">
<body>
<h3>Kernel Model for Precision Timekeeping</h3>
- <p><img src="pic/alice61.gif" alt="gif" align="left">
- <a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
- <p>Alice touched the kernel and it exploded.
- </p>
- <h4>Related Links</h4>
+ <p><img src="pic/alice61.gif" alt="gif" align="left"> <a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a></p>
+ <p>Alice touched the kernel and it exploded.</p>
+ <h4>Related Links</h4>
<p>
<script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
<br clear="left">
</p>
- <hr>
- <p>The technical report [2], which is a major revision and update of an earlier report [3], describes an engineering model for a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators using phase-lock loops (PLL) and frequency-lock loops (FLL) often found in the engineering literature. The model uses a hybrid PLL/FLL discipline algorithm implemented in the kernel. The hybrid loop provides automatic time and frequency steering with update intervals from a few seconds to over one day.</p>
- <p>The hybrid PLL/FLL has been implemented in the Unix kernels for several operating systems, including FreeBSD and Linux and those made by Sun Microsystems, Digital/Compaq and Hewlett Packard. The modifications are currently included in the licensed kernels for Digital Unix 4.0 (aka Tru64) and Sun Solaris 2.8. Since the modifications involve proprietary kernel interface code, they cannot be provided for other licensed kernels directly. Inquiries should be directed to the manufacturer's representatives. The software and documentation, including a simulator with code segments almost identical to the implementations, but not involving licensed code, is called <tt>nanokernel.tar.gz</tt> and available via the web at <a href="http://www.ntp.org">www.ntp.org</a> or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp/software</tt> directory.</p>
- <p>Recently [1], the model has been re-implemented to support a nanosecond system clock. The <tt>/usr/include/sys/timex.h</tt> header file defines the applications programming interface (API) routines and data structures. Implementations are available for Linux, FreeBSD, SunOS and Tru64; however, only the Linux and FreeBSD implementations, which are included in recent system versions, are directly available. The software and documentation, including a simulator with code segments almost identical to the implementations, but not involving licensed code, is called <tt>nanokernel.tar.gz</tt> and available via the web at <a href="http://www.ntp.org">www.ntp.org</a> or by anonymous FTP from ftp.udel.edu in the <tt>pub/ntp/software</tt> directory.</p>
- <p>The model changes the way the system clock is adjusted in time and frequency, as well as provides mechanisms to discipline its time and frequency to an external precision timing source, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The model incorporates a generic system call interface for use with the NTP or similar time synchronization protocol. The NTP software daemons for Version 3 <tt>xntpd</tt> and Version 4 <tt>ntpd</tt> use this API to provide synchronization limited in principle only by the accuracy and stability of the external timing source. There are two new system calls defined in <tt>timex.h</tt>, <tt>ntp_gettime()</tt>, which returns a structure including the current time, estimated error and maximum error, and <tt>ntp_adjtime()</tt>, which provides a means to adjust kernel variables, including the current time and frequency offsets.</p>
- <p>These kernel modifications are normally used in conjunction with a kernel hardware interface such as described in the <a href="kernpps.html">Kernel Programming Interface for Precision Time Signals</a> page.</p>
+ <hr>
+ <p>The technical report [2], which is a major revision and update of RFC-1589 [3], describes an engineering model for a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators using phase-lock loops (PLL) and frequency-lock loops (FLL) often found in the engineering literature. The model uses a hybrid PLL/FLL discipline algorithm implemented in the kernel. The algorithm, which is very similar to the algorithm implemented in the NTP daemon, provides automatic time and frequency steering with update intervals from a few seconds to tens of minutes.</p>
+ <p>The hybrid PLL/FLL code described in [2] is included in Solaris and Digital/Compaq/HP Tru64. It includes two system calls <tt>ntp_gettime()</tt> and <tt>ntp_adjtime()</tt> and can discipline the system clock with microsecond resolution. However, newer hardware and kernels with the same system calls can discipline the clock with nanosecond resolution. The new code described in [1] is available for Linux, FreeBSD, SunOS and Tru64; however, only the Linux and FreeBSD implementations, which do not include licensed code, are readily available. The software and documentation, including a simulator used to verify correct behavior, but not involving licensed code, is available at <a href=ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz>nanokernel.tar.gz</a>.</p>
+ <p>The model also changes the way the system clock is adjusted in time and frequency relative to an external precision timing source, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The NTP software daemon uses the PPS to provide synchronization limited in principle only by the accuracy and stability of the external timing source.</p>
<h4>References</h4>
<ol>
- <li>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.pdf">PDF</a>, Slides: <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.htm">HTML</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ppt">PowerPoint</a>
+ <li>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.pdf">PDF</a>, Slides: <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.htm
l">HTML</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ppt">PowerPoint</a>
<li>Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kerna.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kerna.pdf">PDF</a>, Body: <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kernb.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kernb.pdf">PDF</a>
<li>Mills, D.L. A kernel model for precision timekeeping. Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1589.txt">ASCII</a>
</ol>
</p>
<hr>
<h4>Description</h4>
- <p>Most radio and modem clocks used for a primary (stratum-1) NTP server utilize serial ports operating at speeds of 9600 baud or greater. The intrinsic delay and jitter contributed by the serial port hardware and software driver can accumulate up to a millisecond in newer Unix systems and tens of milliseconds in older ones. In order to reduce the effects of delay and jitter, a set of special line disciplines, stream modules and operating system calls (ioctls) can be configured in some Unix kernels. These routines intercept special characters or signals provided by the radio or modem clock and save a timestamp for later processing.</p>
+ <p>Most radio and modem clocks used for a primary (stratum-1) NTP server utilize serial ports operating at speeds of 9600 baud or greater. The intrinsic delay and jitter contributed by the serial port hardware and software driver can accumulate up to a millisecond in newer Unix systems and tens of milliseconds in older ones. In order to reduce the effects of delay and jitter, a set of special line disciplines, stream modules and operating system calls (<tt>ioctls</tt>) can be configured in some Unix kernels. These routines intercept special characters or signals provided by the radio or modem clock and save a timestamp for later processing.</p>
<p>The routines provide two important functions. Some insert a timestamp in the receive data stream upon occurance of a designated character or characters at the serial interface. This can be used to timestamp an on-time character produced by a radio clock, for example. Other routines support an application program interface for pulse-per-second (PPS) signals generated by some radio clocks and laboratory instruments. These routines are normally accessed through the PPSAPI application program interface described below.</p>
<p>The routines can be compiled in the kernel in older BSD-derived systems, or installed as System V streams modules and either compiled in the kernel or dynamically loaded when required. In either case, they require minor changes in some kernel files and in the NTP daemon <tt>ntpd</tt>. The streams modules can be pushed and popped from the streams stack using conventional System V streams program primitives. Note that some Unix kernels do not support line disciplines and some do not support System V streams. The routines described here are known to work correctly with the Unix kernels called out in the descriptions, but have not been tested for other kernels.</p>
- <h4>PPSAPI Application Program Interface</h4>
- <p>Pulse-per-second (PPS) signals are normally processed as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The <a href="driver22.html">PPS Clock Discipline</a> driver uses the PPSAPI application program interface to capture PPS signal transitions used to fine-tune the system clock. This interface, defined in RFC-2783, is the only PPS interface supported in NTP. While older PPS interfaces based on the ioctls described below continue to be supported, they are used only in the special header file <tt>/usr/include/sys/timepps.h</tt>, which implements the PPSAPI specific to each archeticture and operating system.</p>
- <p>It is the intent of the evolving design to remove all PPS support from the various clock drivers and utilize only the PPS driver for PPS support. This allows the required sanity checks and signal grooming to be provided and maintained in one place and avoids cluttering up the drivers with duplicate functionality. Since the PPS signal samples are processed by the entire suite of NTP grooming, selection and clustering algorithms, noisy PPS signals and signals outside specific time and frequency tolerances are excluded.</p>
- <p>The PPSAPI interface provides the following functions:</p>
- <dl>
- <dt><tt>time_pps_create</tt>
- <dd>Creates a PPS interface instance and returns a handle to it.
- <dt><tt>time_pps_destroy</tt>
- <dd>Destroys a PPS interface and returns the resources used.
- <dt><tt>time_pps_setparams</tt>
- <dd>Sets the parameters associated with a PPS interface instance, including offsets to be automatically added to captured timestamps.
- <dt><tt>time_pps_getparams</tt>
- <dd>Returns the parameters associated with a PPS interface instance.
- <dt><tt>time_pps_getcap</tt>
- <dd>Returns the capabilities of the current interface and kernel implementation.
- <dt><tt>time_pps_fetch</tt>
- <dd>Returns the current timestamps associated with a PPS interface instance in either nanoseconds and nanoseconds (Unix <tt>timespec</tt>) or seconds and fraction (NTP) format.
- <dt><tt>time_pps_kcbind</tt>
- <dd>If kernel PPS processing is supported, this binds the support to the associated PPS interface instance.
- </dl>
- <p>The entire PPS interface functionality is currently provided by inline code in the <tt>timepps.h</tt> header files implemented for SunOS, Solaris, FreeBSD, Linux and Tru64. While not all implementations support the full PPSAPI specification, they do support all the functions required for the PPS driver. The FreeBSD, Linux and Solaris implementations can be used with the stock kernels provided with those systems; however, the Tru64 and SunOS kernels require additional functions not provided in the stock kernels. Solaris users are cautioned that these ioctls function improperly in Solaris versions prior to 2.8 with patch Generic_108528-02.</p>
+
<h4><tt>tty_clk</tt> Line Discipline/Streams Module</h4>
<p>This routine intercepts characters received from the serial port and passes unchanged all except a set of designated characters to the generic serial port discipline. For each of the exception characters, the character is inserted in the receiver buffer followed by a local timestamp in Unix <tt>timeval</tt> format. Both <tt>select()</tt> and <tt>SIGIO</tt> are supported by the routine. Support for this routine is automatically detected during the NTP build process and interface code compiled as necessary.</p>
<p>There are two versions of the <tt>tty_clk</tt> routine. The <tt>tty_clk.c</tt> line discipline is designed for older BSD systems and is compiled in the kernel. The <tt>tty_clk_STREAMS.c</tt> is designed for System V streams, in which case it can be either compiled in the kernel or dynamically loaded. Since these programs are small, unobtrusive, and do nothing unless specifically enabled by an application program, it probably doesn't matter which version is chosen. Instructions on how to configure and build a kernel supporting either of these routines is in the <tt>README</tt> file in the <tt>./kernel</tt> directory.</p>
<p>The <tt>tty_clk</tt> routine defines a new ioctl <tt>CLK_SETSTR</tt>, which takes a pointer to a string of no more than 32 characters. Until the first <tt>CLK_SETSTR</tt> is performed, the routine will simply pass through characters. Once it is passed a string by <tt>CLK_SETSTR</tt>, any character in that string will be immediately followed by a timestamp in Unix <tt>timeval</tt> format. You can change the string whenever you want by doing another <tt>CLK_SETSTR</tt>. The character must be an exact, 8 bit match. The character '\000' cannot, be used, as it is the string terminator. Passing an empty string to <tt>CLK_SETSTR</tt> turns off timestamping. Passing <tt>NULL</tt> may produce surprising results.</p>
- <p></p>
<h4><tt>TIOCDCDTIMESTAMP</tt> ioctl in FreeBSD</h4>
<p>This ioctl is included in FreeBSD 2.2 and later. It causes a timestamp to be inserted in the serial port receive data stream when the data carrier detect (DCD) signal is asserted. This is useful for those radio clocks that indicate the on-time epoch by means of a modem control signal. It is not recommended that this be used for PPS timestamps, as this function is available using the PPS application program interface included in FreeBSD 3.4 and later.</p>
<p>The <tt>TIOCDCDTIMESTAMP</tt> ioctl() is detected and compiled automatically on FreeBSD systems if available. With FreeBSD 2.2 the measured delay between activation of the DCD signal and the time the timestamp is captured on a 66MHz 486DX2 is 19 <font face="Symbol">m</font>s and on a 100MHz Pentium is 6 <font face="Symbol">m</font>s.</p>
- <h4><tt>ppsclock</tt>Streams Module</h4>
- <p>This routine is a streams module which causes a timestamp to be captured when the DCD signal is asserted. It is normally used in connection with a PPS signal generated by some radio clocks. However, it is normally used only by the PPSAPI interface and should be avoided in other contexts. Instructions on how to configure and build a kernel supporting either of these routines is in the <tt>README</tt> file in the <tt>./kernel</tt> directory.</p>
+ <h4><tt>ppsclock</tt>Streams Module (depredated)</h4>
+ <p>This routine is a streams module which causes a timestamp to be captured when the DCD signal is asserted. It is normally used in connection with a PPS signal generated by some radio clocks. However, it is normally used only by the PPSAPI interface and SunOS 4.1.3 and should be avoided in other contexts. Instructions on how to configure and build a kernel supporting either of these routines is in the <tt>README</tt> file in the <tt>./kernel</tt> directory.</p>
<p>The ppsclock streams module implements the <tt>CIOGETEV</tt> ioctl, which takes a pointer to the structure</p>
<pre>
struct ppsclockev {
<body>
<h3>Automatic NTP Configuration Options</h3>
- <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
<body>
<h3>Miscellaneous Options</h3>
- <img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We have three, now looking for more.</p>
<h4>Related Links</h4>
<p>
<body>
<h3>Monitoring Options</h3>
- <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The pig watches the logs.</p>
<h4>Related Links</h4>
<p>
<p>This document is a collection of notes concerning the use of ntpd and related programs, and on coping with the Network Time Protocol (NTP) in general. It is a major rewrite and update of an earlier document written by Dennis Ferguson of the University of Toronto and includes many changes and additions resulting from the NTP Version 3 specification and new Version 4 implementation features. It supersedes earlier documents, which should no longer be used for new configurations.</p>
<p><tt>ntpd</tt> includes a complete implementation of the NTP Version 3 specification, as defined in:</p>
<ul>
- <li>
- <p>Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305a.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305a.pdf">PDF</a>, Body: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305b.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305b.pdf">PDF</a>, Appendices: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.pdf">PDF</a></p>
+ <li>Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305a.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305a.pdf">PDF</a>, Body: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305b.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305b.pdf">PDF</a>, Appendices: <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1305/rfc1305c.pdf">PDF</a>
</ul>
<p>Additional features have are described for <a href="release.html">NTP Version 4 Release Notes</a>. It also retains compatibility with both NTP Version 2, as defined in RFC-1119, and NTP Version 1, as defined in RFC-1059, although this compatibility is sometimes strained and only semiautomatic. In order to support in principle the ultimate precision of about 232 picoseconds in the NTP specification, <tt>ntpd</tt> uses NTP timestamp format for external communication and double precision floating point arithmetic internally. <tt>ntpd</tt> fully implements NTP Versions 2 and 3 authentication and in addition Version 4 autokey. It supports the NTP mode-6 control message facility along with a private mode-7 control- message facility used to remotely reconfigure the system and monitor a considerable amount of internal detail. As extensions to the specification, a flexible address-and-mask restriction facility has been included.</p>
<p>The code is biased towards the needs of a busy time server with numerous, often hundreds, of clients and other servers. Tables are hashed to allow efficient handling of many associations, though at the expense of additional overhead when the number of associations is small. Many fancy features have been included to permit efficient management and monitoring of a busy primary server, features which are probably excess baggage for a high stratum client. In such cases, a stripped-down version of the protocol, the Simple Network Time Protocol (SNTP) can be used. SNTP and NTP servers and clients can interwork in most situations, as described in: Mills, D.L. Simple Network Time Protocol (SNTP). Network Working Group Report RFC-2030, University of Delaware, October 1996, 14 pp. <a href="http://www.eecis.udel.edu/%7emills/database/rfc2030.txt">(ASCII)</a>.</p>
<p>The code was written with near demonic attention to details which can affect precision and as a consequence should be able to make good use of high performance, special purpose hardware such as precision oscillators and radio clocks. The present code supports a number of radio clocks, including those for the WWV, CHU, WWVB, MSF, DCF77, GOES and GPS radio and satellite time services and USNO, ACTS and PTB modem time services. It also supports the IRIG-B and IRIG-E signal format connected via an audio codec. The server methodically avoids the use of Unix-specific library routines where possible by implementing local versions, in order to aid in porting the code to perverse Unix and non-Unix platforms.</p>
- <p>While this implementation conforms in most respects to the NTP Version 3 specification RFC-1305, a number of improvements have been made which are described in the conformance statement in the <a href="http://www.eecis.udel.edu/%7emills/biblio.htm">NTP Protocol Conformance Statement</a> page. It has been specifically tuned to achieve the highest accuracy possible on whatever hardware and operating-system platform is available. In general, its precision and stability are limited only by the characteristics of the onboard clock source used by the hardware and operating system, usually an uncompensated crystal oscillator. On modern RISC-based processors connected directly to radio clocks via serial-asynchronous interfaces, the accuracy is usually limited by the radio clock and interface to the order of a millisecond or less. The code includes special features to support a pulse-per-second (PPS) signal and/or an IRIG-B signal generated by some radio clocks. When used in conjunction with a suitable hardware level converter, the accuracy can be improved to a few tens of microseconds. Further improvement is possible using an outboard, stabilized frequency source, in which the accuracy and stability are limited only by the characteristics of that source.</p>
+ <p>While this implementation conforms in most respects to the NTP Version 3 specification RFC-1305, a number of improvements have been made which are described in the conformance statement in the <a href="http://www.eecis.udel.edu/%7emills/biblio.html">NTP Protocol Conformance Statement</a> page. It has been specifically tuned to achieve the highest accuracy possible on whatever hardware and operating-system platform is available. In general, its precision and stability are limited only by the characteristics of the onboard clock source used by the hardware and operating system, usually an uncompensated crystal oscillator. On modern RISC-based processors connected directly to radio clocks via serial-asynchronous interfaces, the accuracy is usually limited by the radio clock and interface to the order of a millisecond or less. The code includes special features to support a pulse-per-second (PPS) signal and/or an IRIG-B signal generated by some radio clocks. When used in conjunction with a suitable hardware level converter, the accuracy can be improved to a few tens of microseconds. Further improvement is possible using an outboard, stabilized frequency source, in which the accuracy and stability are limited only by the characteristics of that source.</p>
<p>The NTP Version 4 distribution includes, in addition to the daemon itself (<tt><a href="ntpd.html">ntpd</a></tt>), several utility programs, including two remote-monitoring programs (<a href="ntpq.html"><tt>ntpq</tt></a>, <tt><a href="ntpdc.html">ntpdc</a></tt>), a remote clock-setting program similar to the Unix rdate program (<tt>ntpdate</tt>), a traceback utility u seful to discover suitable synchronization sources (<tt>ntptrace</tt>), and various programs used to configure the local platform and calibrate the intrinsic errors. NTP has been ported to a large number of platforms, including most RISC and CISC workstations and mainframes manufactured today. Example configuration files for many models of these machines are included in the distribution. While in most cases the standard version of the implementation runs with no hardware or operating system modifications, not all features of the distribution are available on all platforms. For instance, a special feature allowing Sun workstations to achieve accuracies in the order of 100 microseconds requires some minor changes and additions to the kernel and input/output support.</p>
<p>There are, however, several drawbacks to all of this. <tt>ntpd</tt> is quite fat. This is rotten if your intended platform for the daemon is memory limited. <tt>ntpd</tt> uses <tt>SIGIO</tt> for all input, a facility which appears to not enjoy universal support and whose use seems to exercise the parts of your vendors' kernels which are most likely to have been done poorly. The code is unforgiving in the face of kernel problems which affect performance, and generally requires that you repair the problems in order to achieve acceptable performance. The code has a distinctly experimental flavour and contains features which could charitably be termed failed experiments, but which have not been completely hacked out. Much was learned from the addition of support for a variety of radio clocks, with the result that some radio clock drivers could use some rewriting.</p>
<h4>How NTP Works</h4>
This section considers issues in providing precision time synchronization in NTP subnets which need the highest quality time available in the present technology. These issues are important in subnets supporting real-time services such as distributed multimedia conferencing and wide-area experiment control and monitoring.
<p>In the Internet of today synchronization paths often span continents and oceans with moderate to high variations in delay due to traffic spasms. NTP is specifically designed to minimize timekeeping jitter due to delay variations using intricately crafted filtering and selection algorithms; however, in cases where these variations are as much as a second or more, the residual jitter following these algorithms may still be excessive. Sometimes, as in the case of some isolated NTP subnets where a local source of precision time is available, such as a PPS signal produced by a calibrated cesium clock, it is possible to remove the jitter and retime the local clock oscillator of the NTP server. This has turned out to be a useful feature to improve the synchronization quality of time distributed in remote places where radio clocks are not available. In these cases special features of the distribution are used together with the PPS signal to provide a jitter-free timing signal, while NTP itself is used to provide the coarse timing and resolve the seconds numbering.</p>
<p>Most available radio clocks can provide time to an accuracy in the order of milliseconds, depending on propagation conditions, local noise levels and so forth. However, as a practical matter, all clocks can occasionally display errors significantly exceeding nominal specifications. Usually, the algorithms used by NTP for ordinary network peers, as well as radio clock peers will detect and discard these errors as discrepancies between the disciplined local clock oscillator and the decoded time message produced by the radio clock. Some radio clocks can produce a special PPS signal which can be interfaced to the server platform in a number of ways and used to substantially improve the (disciplined) clock oscillator jitter and wander characteristics by at least an order of magnitude. Using these features it is possible to achieve accuracies in the order of a few tens of microseconds with a fast RISC- based platform.</p>
- <p>There are three ways to implement PPS support, depending on the radio clock model, platform model and serial line interface. These are described in detail in the application notes mentioned in the <a href="index.html">The Network Time Protocol (NTP) Distribution</a> document page. Each of these requires circuitry to convert the TTL signal produced by most clocks to the EIA levels used by most serial interfaces. The <a href="gadget.html">Gadget Box PPS Level Converter and CHU Modem</a> document page describes a device designed to do this. Besides being useful for this purpose, this device includes an inexpensive modem designed for use with the Canadian CHU time/frequency radio station.</p>
+ <p>There are three ways to implement PPS support, depending on the radio clock model, platform model and serial line interface. These are described in detail in the application notes mentioned in the <a href="index.html">The Network Time Protocol (NTP) Distribution</a> document page. Each of these requires circuitry to convert the TTL signal produced by most clocks to the EIA levels used by most serial interfaces. The <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page describes a device designed to do this. Besides being useful for this purpose, this device includes an inexpensive modem designed for use with the Canadian CHU time/frequency radio station.</p>
<p>In order to select the appropriate implementation, it is important to understand the underlying PPS mechanism used by ntpd. The PPS support depends on a continuous source of PPS pulses used to calculate an offset within +-500 milliseconds relative to the local clock. The serial timecode produced by the radio or the time determined by NTP in absence of the radio is used to adjust the local clock within +-128 milliseconds of the actual time. As long as the local clock is within this interval the PPS support is used to discipline the local clock and the timecode used only to verify that the local clock is in fact within the interval. Outside this interval the PPS support is disabled and the timecode used directly to control the local clock.</p>
<h4>Parting Shots</h4>
There are several undocumented programs which can be useful in unusual cases. They can be found in the <tt>./clockstuff</tt> and <tt>./authstuff</tt> directories of the distribution. One of these is the <tt>propdelay</tt> program, which can compute high frequency radio propagation delays between any two points whose latitude and longitude are known. The program understands something about the phenomena which allow high frequency radio propagation to occur, and will generally provide a better estimate than a calculation based on the great circle distance. Other programs of interest include <tt>clktest</tt>, which allows one to exercise the generic clock line discipline, and <tt>chutest</tt>, which runs the basic reduction algorithms used by the daemon on data received from a serial port.
<body>
<h3><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</h3>
- <img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The mushroom knows all the command line options.</p>
<h4>Related Links</h4>
<p>
<h4 id="#descr">Description</h4>
<p>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.</p>
<h4 id="#op">How 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.html">Configuration Options</a> page.</p>
+ <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
a few seconds. 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.html">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>
<body>
<h3><tt>ntpdate</tt> - set the date and time via NTP</h3>
- <img src="pic/rabbit.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/rabbit.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>I told you it was eyeball and wristwatch.<br clear="left">
</p>
<hr>
<body>
<h3><tt>ntpdc</tt> - special NTP query program</h3>
- <img src="pic/alice31.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice31.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>This program is a big puppy.<br clear="left">
</p>
<hr>
<body>
<h3><tt>ntpq</tt> - standard NTP query program</h3>
- <img src="pic/bustardfly.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/bustardfly.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>A typical NTP monitoring packet.<br clear="left">
</p>
<hr>
<body>
<h3><tt>ntptime</tt> - read kernel time variables</h3>
- <img src="pic/pogo5.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <img src="pic/pogo5.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The turtle has been swimming in the kernel.<br clear="left">
</p>
<hr>
<body>
<h3><tt>ntptrace</tt> - trace a chain of NTP servers back to the primary source</h3>
- <img src="pic/alice13.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice13.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The rabbit knows the way back.<br clear="left">
</p>
<hr>
<body>
<h3>Patching Procedures</h3>
- <img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm"> rom <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> rom <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The Mad Hatter needs patches.<br clear="left">
</p>
<hr>
<body>
<h3>Porting Hints</h3>
- <img src="pic/wingdorothy.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
+ <img src="pic/wingdorothy.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
<p>Porting Dorothy in Oz.<br clear="left">
</p>
<hr>
<body>
<h3>Pulse-per-second (PPS) Signal Interfacing</h3>
- <img src="pic/alice32.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>Alice is trying to find the PPS signal connector.
- </p>
+ <img src="pic/alice32.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>Alice is trying to find the PPS signal connector.</p>
<h4>Related Links</h4>
<p>
<script type="text/javascript" language="javascript" src="scripts/links11.txt"></script>
<br clear="left">
</p>
<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.html">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 beginning with 2.7. Support on an experimental basis is available for several older systems, including SunOS, Digital Ultrix 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>The PPSAPI inerface requires a <tt>/usr/include/sys/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>Some radio clocks and related timekeeping gear have a pulse-per-second (PPS) signal that can be used to discipline the system clock to a high degree of precision, typically to the order less than 10 <font face="Symbol">m</font>s in time and 0.01 parts-per-million (PPM) in frequency. This page describes the hardware and software necessar for NTP to use this signal.</p>
+ <img src="pic/gadget.jpg" alt="gif" align="left">A Gadget Box built by Chuck Hanavin<br clear="left">
+ <h4>Gadget Box</h4>
+ <p>The PPS signal can be connected in either of two ways: via the data carrier detector (DCD) pin of a serial port or via the acknowledge (ACK) pin of a parallel port, depending on the hardware and operating system. Note that NTP no longer supports connection via the data leads of a serial port. However, the PPS signal levels are usually incompatible with serial port levels. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional modem designed to decode the radio timecode signals transmitted by Canadian time and frequency station CHU. This can be used with the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a>. A complete set of schematics, PCB artwork and drill templates can be obrtained via the web at <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
+ <h4>Operating System Support </h4>
+ <p>Both the serial and parallel port connection require operating system support, which is available in only a few operating systems, including FreeBSD, Linux (with PPSkit patch) and Solaris. Support on an experimental basis is available for several other systems, including SunOS and HP/Compaq/Digital Tru64. The PPSAPI application program interface defined in [1] is the only interface currently supported. Older PPS interfaces based on the <tt>ppsclock</tt> and <tt>tty_clk</tt> streams modules are no longer supported. As the PPSAPI is expected to become an IETF cross-platform standard, it should be used by new applications.</p>
+ <p>The entire PPS interface functionality is currently provided by inline code in the <tt>timepps.h</tt> header file. While not all implementations support the full PPSAPI specification, they do support all the functions required for the PPS driver described next. The FreeBSD, Linux and Solaris implementations can be used with the stock kernels provided with those systems; however, the Tru64 and SunOS kernels require additional functions not provided in the stock kernels. Solaris users are cautioned that these functions operate improperly in Solaris versions prior to 2.8 with patch Generic_108528-02. Header files for other systems can be found via the web at <a href="ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz">nanokernel.tar.gz</a>.</p>
+ <h4>PPS Driver</h4>
<p>In the preferred mode of operation, PPS signals are processed by the <a href="driver22.html">PPS Clock Discipline</a> driver and other clock drivers which might be involved need not know or care about them. In some cases where there is no other driver, time might be obtained from remote NTP servers via the network and local PPS signals, for instance from a calibrated cesium oscillator, used to stabilize the frequency and remove network jitter. Note that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p>
<p>The PPS driver operates in conjunction with a preferred peer, as described in the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page. One of the drivers described in the <a href="refclock.html">Reference Clock Drivers</a> page or another NTP server furnishes the coarse timing and disambiguates the seconds numbering of the PPS signal itself. The NTP daemon mitigates between the clock driver or NTP server and the PPS driver as described in that page in order to provide the most accurate time, while respecting the various types of equipment failures that could happen.</p>
<p>Some Unix system kernels support a PPS signal directly, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. Specifically, the PPS driver can be used to direct the PPS signal to the kernel for use as a discipline source for both time and frequency. The presence of the kernel support is automatically detected during the NTP build process and supporting code automatically compiled. Note that the PPS driver does not normally enable the PPS kernel code, since performance is generally better without it. However, this code can be enabled by a driver fudge flag if necessary.</p>
<p>Some configurations may include multiple radio clocks with individual PPS outputs. In some PPSAPI designs multiple PPS signals can be connected to multiple instances of the PPS driver. In such cases the NTP mitigation and grooming algorithms operate with all the radio timecodes and PPS signals to develop the highest degree of redundancy and survivability.</p>
+ <h4>Reference</h4>
+ <ol>
+ <li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. <a href="http://www.eecis.udel.edu/mills/database/rfc/rfc2783.txt">ASCII</a>
+ </ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>Mitigation Rules and the <tt>prefer</tt> Keyword</h3>
- <img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Listen carefully to what I say; it is very complicated.
</p>
<h4>Related Links</h4>
<p>For the rank amateur the sheer volume of the documentation collection must be intimidating. However, it doesn't take much to fly the <tt>ntpd</tt> daemon with a simple configuration where a workstation needs to synchronize to some server elsewhere in the Internet. The first thing that needs to be done is to build the distribution for the particular workstation and install in the usual place. The <a href="build.html">Building and Installing the Distribution</a> page describes how to do this.</p>
<p>While it is possible that certain configurations do not need a configuration file, most do require one. Strictly speaking, the file need only contain one line specifying a remote server, for instance</p>
<p><tt>server foo.bar.com</tt></p>
- <p>Choosing an appropriate remote server is somewhat of a black art, but a suboptimal choice is seldom a problem. There are about two dozen public time servers operated by National Institutes of Science and Technology (NIST), US Naval Observatory (USNO), Canadian Metrology Centre (CMC) and many others available on the Internet. Lists of public primary and secondary NTP servers maintained on the <a href="http://www.eecis.udel.edu/%7emills/ntp/index.htm">Information on Time and Frequency Services</a> page, which is updated frequently.The lists are sorted by country and, in the case of the US, by state. Usually, the best choice is the nearest in geographical terms, but the terms of engagement specified in each list entry should be carefully respected.</p>
- <p>During operation <tt>ntpd</tt> measures and corrects for incidental clock frequency error and writes the current value to a file 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>Choosing an appropriate remote server is somewhat of a black art, but a suboptimal choice is seldom a problem. There are about two dozen public time servers operated by National Institutes of Science and Technology (NIST), US Naval Observatory (USNO), Canadian Metrology Centre (CMC) and many others available on the Internet. Lists of public primary and secondary NTP servers maintained on the <a href="http://www.eecis.udel.edu/%7emills/ntp/index.html">Information on Time and Frequency Services</a> page, which is updated frequently.The lists are sorted by country and, in the case of the US, by state. Usually, the best choice is the nearest in geographical terms, but the terms of engagement specified in each list entry should be carefully respected.</p>
+ <p>During operation <tt>ntpd</tt> measures and corrects for incidental clock frequency error and writes the current value to a file, if specified. If <tt>ntpd</tt> is stopped and restarted, it initializes the frequency from this file. In this way the potentially lengthy interval to relearn the frequency error is avoided. Thus, for most applications an additional line should be added to the file of the form</p>
<p><tt>driftfile /etc/ntp.drift</tt></p>
<p>That's all there is to it, unless some problem in network connectivity or local operating system configuration occurs. The most common problem is some firewall between the workstation and server. System administrators should understand NTP uses UDP port 123 as both the source and destination port and that NTP does not involve any operating system interaction other than to set the system clock. While almost all modern Unix systems have included NTP and UDP port 123 defined in the services file, this should be checked if <tt>ntpd</tt> fails to come up at all.</p>
<p>The best way to confirm NTP is working is using the <a href="ntpq.html"><tt>ntpq</tt></a> utility, although the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility may be useful in extreme cases. See the documentation pages for further information. In the most extreme cases the <tt>-d</tt> option on the <tt>ntpd</tt> command line results in a blow-by-blow trace of the daemon operations. While the trace output can be cryptic, to say the least, it gives a general idea of what the program is doing and, in particular, details the arriving and departing packets and detected errors, if present.</p>
<body>
<h3>Debugging Hints for Reference Clock Drivers</h3>
- <img src="pic/oz2.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
+ <img src="pic/oz2.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
<p>Call the girls and the'll sweep your bugs.
</p>
<h4>Related Links</h4>
<body>
<h3>Reference Clock Drivers</h3>
- <img src="pic/stack1a.jpg" alt="gif" align="left">Master Time Facility at the <a href="http://www.eecis.udel.edu/%7emills/lab.htm">UDel Internet Research Laboratory</a>
+ <img src="pic/stack1a.jpg" alt="gif" align="left">Master Time Facility at the <a href="http://www.eecis.udel.edu/%7emills/lab.html">UDel Internet Research Laboratory</a>
<h4>Related Links</h4>
<p>
<script type="text/javascript" language="javascript" src="scripts/links10.txt"></script>
<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.html">Undisciplined Local Clock</a> page and respect the stratum limit.</p>
<p>The local clock driver also supports an external synchronization source such as a high resolution counter disciplined by a GPS receiver, for example. Further information is on the <a href="extern.html">External Clock Discipline and the Local Clock Driver</a> page.</p>
<h4 id="#cal">Driver Calibration</h4>
- <p>Some drivers depending on longwave and shortwave radio services need to know the radio propagation time from the transmitter to the receiver, which can amount to some tens of milliseconds. This must be calculated for each specific receiver location and requires the geographic coordinates of both the transmitter and receiver. The transmitter coordinates for various radio services are given in the <a href="http://www.eecis.udel.edu/%7emills/qth.htm">Time and Frequency Standard Station Information</a> page. Receiver coordinates can be obtained or estimated from various sources. The actual calculations are beyond the scope of this document.</p>
+ <p>Some drivers depending on longwave and shortwave radio services need to know the radio propagation time from the transmitter to the receiver, which can amount to some tens of milliseconds. This must be calculated for each specific receiver location and requires the geographic coordinates of both the transmitter and receiver. The transmitter coordinates for various radio services are given in the <a href="http://www.eecis.udel.edu/%7emills/qth.html">Time and Frequency Standard Station Information</a> page. Receiver coordinates can be obtained or estimated from various sources. The actual calculations are beyond the scope of this document.</p>
<p>When more than one clock driver is supported, it is often the case that each shows small systematic offset differences relative to the rest. To reduce the effects of jitter when switching from one driver to the another, it is useful to calibrate the drivers to a common ensemble offset. The <tt>enable calibrate</tt> configuration command in the <a href="miscopt.html">Miscellaneous Options</a> page is useful for this purpose. The calibration function can also be enabled and disabled using the <tt>ntpdc</tt> program utility.</p>
<p>Most clock drivers use the <tt>time1</tt> value specified in the <tt>fudge</tt> configuration command to provide the calibration correction when this cannot be provided by the clock or interface. When the calibration function is enabled, the <tt>time1</tt> value is automatically adjusted to match the offset of the remote server or local clock driver selected for synchronization. Ordinarily, the NTP selection algorithm chooses the best from among all sources, usually the best radio clock determined on the basis of stratum, synchronization distance and jitter. The calibration function adjusts the <tt>time1</tt> values for all clock drivers except this source so that their indicated offsets tend to zero. If the selected source is the kernel PPS discipline, the <tt>fudge time1</tt> values for all clock drivers are adjusted.</p>
<p>The adjustment function is an exponential average designed to improve accuracy, so the function takes some time to converge. The recommended procedure is to enable the function, let it run for an hour or so, then edit the configuration file using the <tt>time1</tt> values displayed by the <tt>ntpq</tt> utility and <tt>clockvar</tt> command. Finally, disable the calibration function to avoid possible future disruptions due to misbehaving clocks or drivers.</p>
<body>
<h3>NTP Version 4 Release Notes</h3>
- <img src="pic/hornraba.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <img src="pic/hornraba.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>The rabbit toots to make sure you read this.<br clear="left">
</p>
<hr>
<p>This release of the NTP Version 4 (NTPv4) daemon for Unix, VMS and Windows incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions, including NTPv3 and NTPv2, but not NTPv1. Support for NTPv1 has been discontinued because of certain security vulnerabilities. The NTPv4 version has been under development for quite a while and isn't finished yet. In fact, quite a number of NTPv4 features have already been retrofitted in the older NTPv3, although this version is not actively maintained by the NTPv4 developer corps.</p>
<p>The code compiles and runs properly in all test host configurations available to the developer corps, including Sun Microsystems, Digital/Compaq, Hewlett Packard, FreeBSD and Linux. Other volunteers have verified it works in IRIX and certain versions of Windows NT and several others. We invite comments and corrections about the various architectures, operating systems and hardware complement that can't be verified by the developer corps. Of particular interest are Windows, VMS and various reference clock drivers. As always, corrections and bugfixes are warmly received, especially in the form of context diffs sent to <a href="mailto:bugs@ntp.org"><bugs@ntp.org>></a>.</p>
<p>This release has been compiled and tested on many systems, including SunOS 4.1.3, Solaris 2.5.1-2.8, Alpha Tru64 4.0-5.1, Ultrix 4.4, Linux 2.4.2, FreeBSD 4.5 and HP-UX 10.02. It has been compiled and tested by others on Windows NT4, 2000 and XP, but not yet on other Windows versions or for VMS. There are several new features apparently incompatible with Linux systems, including some modes used with the Autokey protocol. The developers corps looks for help elsewhere to resolve these differences. We are relying on the NTP volunteer corps to do that.</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 on the <a href="http://www.eecis.udel.edu/%7emills/biblio.htm">Protocol Conformance Statement</a> page.</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 on the <a href="http://www.eecis.udel.edu/%7emills/biblio.html">Protocol Conformance Statement</a> page.</p>
<h4>New Features</h4>
<ol>
<li>
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<html>
+
+ <head>
+ <title>Simple Network Time Protocol (SNTP) Client</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
+
+ <body>
+ <h3>Simple Network Time Protocol (SNTP) Client</h3>
+ <hr>
+ <h4>Synopsis</h4>
+ <tt>sntp [{-h --help -?}][{ -v -V -W }][{-r -a}][-P <i>prompt</i>][-e <i>minerr</i>][-E <i>maxerr</i>][-c <i>count</i>][-d <i>delay</i>][address(es)]</tt>
+ <h4>Description</h4>
+ <p>This program is a Simple Network Time Protocol (SNTP) client that can be used to query a Network TIme Protocol (NTP) server and display the time offset of the system clock relative to the server clock. Run as root it can correct the system clock to this offset as well. It can be run as an interactive command or from a script by a <tt>cron</tt> job. The program implements the SNTP protocol defined in RFC-2030, which is a subset of the NTP protocol defined in RFC-1305, but does not provide the sanity checks, access controls, security functions and mitigation algorithms as in the full NTP implementation.</p>
+ <p>While this program can do other things, including operation as a primitive server, some of these things are truly dangerous in a ubiquitous public time server network. A full disclosure is in the man page in the <tt>./sntp</tt> directory, but be truly advised RFC-2030 specifically <b>forbids</b> a SNTP client to operate as a server for other NTP or SNTP clients. If such operation is contemplated, do <b>not</b> allow access by clients on the public Internet.</p>
+ <p>By default, <tt>sntp</tt> writes the local date and time (i.e., not UTC) to the standard output in the format</p>
+ <p><tt>1996 Oct 15 20:17:25.123 + 4.567 +/- 0.089 secs</tt>,</p>
+ <p>where the <tt>+ 4.567 +/- 0.089 secs</tt> indicates the time offset and error bound of the system clock relative to the server clock.</p>
+ <p>If a NTP server <i>address</i> is explicitly specified, the program sends a single message to the server and waits up to <i>delay</i> seconds for a unicast server message. Otherwise, it sends no message and waits up to <i>delay</i> seconds for a broadcast server message.</p>
+ <h4>Options</h4>
+ <p><tt>sntp</tt> recognizes the following options:</p>
+ <dl>
+ <dt><tt>-h, --help</tt>
+ <dd>displays usage information.
+ <dt><tt>-v</tt>
+ <dd>writes diagnostic messages and a limited amount of tracing to standard error. The <tt>-v, -V</tt> and <tt>-W</tt> give increasing levels of detail.
+ <dt><tt>-r</tt>
+ <dd>steps the system clock to the correct time by the Unix <tt>settimeofday</tt> system call. Requires root priviledge.
+ <dt><tt>-a</tt>
+ <dd>slews the system clock to the correct time by the Unix <tt>adjtime</tt> system call. Requires root priviledge.
+ <dt><tt>-e <i>minerr</i></tt>
+ <dd>sets the minimum offset to <tt><i>minerr</i></tt> seconds. Measured offsets less than this are ignored. Acceptable values are from 0.001 to 1 with default 0.1 if unicast mode and 0.5 for broadcast mode.
+ <dt><tt>-E <i>maxerr</i></tt>
+ <dd>sets the maximum offset to <tt><i>maxerr</i></tt> seconds. Measured offsets greater than this are ignored. Acceptable values are from 1 to 60 with default 5.
+ <dt><tt>-P <i>prompt</i></tt>
+ <dd>sets the maximum automatic offset to <tt><i>maxerr</i></tt> seconds. Acceptable values are from 1 to 3600 or <tt>no</tt>, with default 30. If the program is being run interactively, measured offsets greater than this will prompt the user for confirmation. Specifying <tt>no</tt> will disable this and the correction will be made regardless.
+ <dt><tt>-c <i>count</i></tt>
+ <dd>sets the maximum number of NTP packets required to <i>count</i>. Acceptable values are from 1 to 25 in unicast mode and 5 to 25 in broadcast mode. The default is 5 in either mode.
+ <dt><tt>-d <i>delay</i></tt>
+ <dd>sets the maximum waiting time in broadcast mode to <i>delay</i> seconds. Acceptable values are from 1 to 3600, with default 15 in unicast mode and 300 in broadcast mode.
+ </dl>
+ <h4>Return Value</h4>
+ <p>The program returns an exit status of zero for success and non-zero otherwise.</p>
+ <h4>Author</h4>
+ <p><tt>sntp</tt> was developed by N.M. Maclaren of the University of Cambridge Computing Service.</p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
+
+</html>
\ No newline at end of file
<h4>Synopsis</h4>
<tt>tickadj [ -Aqs ] [ -a <i>tickadj</i> ] [ -t <i>tick</i> ]</tt>
<h4>Description</h4>
- <p>The <tt>tickadj</tt> program reads, and optionally modifies, several timekeeping-related variables in 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>
- <p>Note that this program does NOT work in some kernels, in particular Solaris 2.6 or later.</p>
+ <p>The <tt>tickadj</tt> program reads, and optionally modifies, several timekeeping-related variables in older kernels that do not have support for precision ttimekeeping, including HP-UX, SunOS, Ultrix, SGI and probably others. Those machines provide means to patch the kernel <tt>/dev/kmem</tt>. Newer machines with precision time support, including Solaris, Tru64, FreeBSD and Linux (with PPSkit patch) should NOT use the program. The particular variables that can be changed with <tt>tickadj</tt> include <tt>tick</tt>, which is the number of microseconds added to the system time for a clock interrupt, <tt>tickadj</tt>, which sets the slew rate and resolution used by the <tt>adjtime</tt> system call, and <tt>dosynctodr</tt>, which indicates to the kernels on some machines whether they should internally adjust the system clock to keep it in line with time-of-day clock or not.</p>
<p>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>
projects / thirdparty / ntp.git / commitdiff
