-<HTML><HEAD><TITLE>
-Access Control Options
-</TITLE></HEAD><BODY><H3>
-Access Control Options
-</H3><HR>
-
-<H4>Access Control Support</H4>
-
-The <TT>ntpd</TT> daemon provides an access control mechanism based on a
-restriction list. Each entry in the list includes a 32-bit IP address,
-32-bit mask and a set of restriction flags. The list is sorted first by
-address and then by mask. The source address of every incoming NTP
-packet is matched with each entry of the list in order. The matching
-operation consists of first computing the bitwise AND of the packet IP
-address and mask, then the bitwise AND of the entry IP address and mask.
-If the results of the two AND operations agree, the restriction flags of
-the entry define the restrictions for the packet. In the case of
-multiple matches, the last match found is used. This allows default
-restrictions to be defined, then exceptions for networks, subnets and
-individual hosts defined as needed. Additional information and examples
-can be found in the <A HREF="notes.htm">Notes on Configuring NTP and
-Setting up a NTP Subnet </A>page.
-
-<H4>Access Control Commands</H4>
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>Access Control Options
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+Access Control Options</H3>
+
+<HR>
+<H4>
+Access Control Support</H4>
+<TT>ntpd</TT> implements a general purpose address-and-mask based restriction
+list. The list is sorted by address and by mask, and the list is searched
+in this order for matches, with the last match found defining the restriction
+flags associated with the incoming packets. The source address of incoming
+packets is used for the match, with the 32-bit address being and'ed with
+the mask associated with the restriction entry and then compared with the
+entry's address (which has also been and'ed with the mask) to look for
+a match. Additional information and examples can be found in the <A HREF="notes.htm">Notes
+on Configuring NTP and Setting up a NTP Subnet </A>page.
+
+<P>The restriction facility was implemented in conformance with the access
+policies for the original NSFnet backbone time servers. While this facility
+may be otherwise useful for keeping unwanted or broken remote time servers
+from affecting your own, it should not be considered an alternative to
+the standard NTP authentication facility. Source address based restrictions
+are easily circumvented by a determined cracker.
+<H4>
+Access Control Commands</H4>
<DL>
-
-<DT><TT>restrict <I>numeric_address</I> [mask <I>numeric_mask</I>]
-[<I>flag</I>]
+<DT>
+<TT>restrict <I>numeric_address</I> [mask <I>numeric_mask</I>] [<I>flag</I>]
[...]</TT></DT>
-<DD>The <I><TT>numeric_address</TT></I> argument, expressed in
-dotted-quad form, is the IP address of a network, subnet or individual
-host. The <I><TT>mask</TT></I> argument, also expressed in dotted-quad
-form, defaults to <TT>255.255.255.255</TT>, so that a
-<I><TT>numeric_address</TT></I> without mask is treated as the address
-of an individual host. The special <I><TT>numeric_address</TT></I>
-value specified as the string <tt>default</tt> is interpreted as address
-<TT>0.0.0.0</TT>) and mask <TT>255.255.255.255</TT>. Since the
-restriction list entries are sorted by IP address and mask, this is
-always the first entry in the list.</DD>
-
-<DD>The <I><TT>flag</TT></I> always restricts access, i.e., an entry
-with no flags indicates that no restrictions are defined. The flags
-are not orthogonal, in that more restrictive flags will often make less
-restrictive ones redundant. The flags can generally be classed into two
-categories, those which restrict time service and those which restrict
-informational queries and attempts to do run-time reconfiguration of the
-server. One or more of the following flags may be specified:</DD>
-</DL>
+<DD>
+The <I><TT>numeric_address</TT></I> argument, expressed in dotted-quad
+form, is the address of an host or network. The <I><TT>mask</TT></I> argument,
+also expressed in dotted-quad form, defaults to <TT>255.255.255.255</TT>,
+meaning that the <I><TT>numeric_address</TT></I> is treated as the address
+of an individual host. A default entry (address <TT>0.0.0.0</TT>, mask
+<TT>0.0.0.0</TT>) is always included and, given the sort algorithm, is
+always the first entry in the list. Note that, while <I><TT>numeric_address</TT></I>
+is normally given in dotted-quad format, the text string <TT>default</TT>,
+with no mask option, may be used to indicate the default entry.</DD>
+
+<DD>
+In the current implementation, <I><TT>flag</TT></I> always restricts access,
+i.e., an entry with no flags indicates that free access to the server is
+to be given. The flags are not orthogonal, in that more restrictive flags
+will often make less restrictive ones redundant. The flags can generally
+be classed into two catagories, those which restrict time service and those
+which restrict informational queries and attempts to do run-time reconfiguration
+of the server. One or more of the following flags may be specified:</DD>
+
+<DD>
+ </DD>
<DL>
-<DT><TT>ignore</TT></DT>
-<DD>Ignore all packets from hosts which match this entry. If this flag
-is specified neither queries nor time server polls will be responded
-to.</DD>
-
-<DT><TT>noquery</TT></DT>
-<DD>Ignore all NTP mode 6 and 7 packets (i.e. information queries and
-configuration requests) from the source. Time service is not
-affected.</DD>
-
-<DT><TT>nomodify</TT></DT>
-<DD>Ignore all NTP mode 6 and 7 packets which attempt to modify the
-state of the server (i.e. run time reconfiguration). Queries which
-return information are permitted.</DD>
-
-<DT><TT>notrap</TT></DT>
-<DD>Decline to provide mode 6 control message trap service to matching
-hosts. The trap service is a subsystem of the mode 6 control message
-protocol which is intended for use by remote event logging
-programs.</DD>
-
-<DT><TT>lowpriotrap</TT></DT>
-<DD>Declare traps set by matching hosts to be low priority. The number
-of traps a server can maintain is limited (the current limit is 3).
-Traps are usually assigned on a first come, first served basis, with
-later trap requestors being denied service. This flag modifies the
-assignment algorithm by allowing low priority traps to be overridden by
-later requests for normal priority
+<DT>
+<TT>ignore</TT></DT>
+
+<DD>
+Ignore all packets from hosts which match this entry. If this flag is specified
+neither queries nor time server polls will be responded to.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>noquery</TT></DT>
+
+<DD>
+Ignore all NTP mode 6 and 7 packets (i.e. information queries and configuration
+requests) from the source. Time service is not affected.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>nomodify</TT></DT>
+
+<DD>
+Ignore all NTP mode 6 and 7 packets which attempt to modify the state of
+the server (i.e. run time reconfiguration). Queries which return information
+are permitted.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>notrap</TT></DT>
+
+<DD>
+Decline to provide mode 6 control message trap service to matching hosts.
+The trap service is a subsystem of the mode 6 control message protocol
+which is intended for use by remote event logging programs.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>lowpriotrap</TT></DT>
+
+<DD>
+Declare traps set by matching hosts to be low priority. The number of traps
+a server can maintain is limited (the current limit is 3). Traps are usually
+assigned on a first come, first served basis, with later trap requestors
+being denied service. This flag modifies the assignment algorithm by allowing
+low priority traps to be overridden by later requests for normal priority
traps.</DD>
-<DT><TT>noserve</TT></DT>
-<DD>Ignore NTP packets whose mode is other than 6 or 7. In effect, time
-service is denied, though queries may still be permitted.</DD>
-
-<DT><TT>nopeer</TT></DT>
-<DD>Provide stateless time service to polling hosts, but do not allocate
-peer memory resources to these hosts even if they otherwise might be
-considered useful as future synchronization partners.</DD>
-
-<DT><TT>notrust</TT></DT>
-<DD>Treat these hosts normally in other respects, but never use them as
-synchronization sources.</DD>
-
-<DT><TT>limited</TT></DT>
-<DD>These hosts are subject to limitation of number of clients from the
-same net. Net in this context refers to the IP notion of net (class A,
-class B, class C, etc.). Only the first <TT>client_limit</TT> hosts that
-have shown up at the server and that have been active during the last
-<TT>client_limit_period</TT> seconds are accepted. Requests from other
-clients from the same net are rejected. Only time request packets are
-taken into account. Query packets sent by the <TT>ntpq</TT> and
-<TT>ntpdc</TT> programs are not subject to these limits. A history of
-clients is kept using the monitoring capability of <TT>ntpd</TT>. Thus,
-monitoring is always active as long as there is a restriction entry with
-the <TT>limited</TT> flag.</DD>
-
-<DT><TT>ntpport</TT></DT>
-<DD>This is actually a match algorithm modifier, rather than a
-restriction flag. Its presence causes the restriction entry to be
-matched only if the source port in the packet is the standard NTP UDP
-port (123). Both <TT>ntpport</TT> and <TT>non-ntpport</TT> may be
-specified. The <TT>ntpport</TT> is considered more specific and is
-sorted later in the list.</DD>
-
-<DD>Default restriction list entries, with the flags <TT>ignore,
-ntpport</TT>, for each of the local host's interface addresses are
-inserted into the table at startup to prevent the server from attempting
-to synchronize to its own time. A default entry is also always present,
-though if it is otherwise unconfigured; no flags are associated with the
-default entry (i.e., everything besides your own NTP server is
-unrestricted).</DD>
+<DD>
+ </DD>
+
+<DT>
+<TT>noserve</TT></DT>
+
+<DD>
+Ignore NTP packets whose mode is other than 6 or 7. In effect, time service
+is denied, though queries may still be permitted.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>nopeer</TT></DT>
+
+<DD>
+Provide stateless time service to polling hosts, but do not allocate peer
+memory resources to these hosts even if they otherwise might be considered
+useful as future synchronization partners.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>notrust</TT></DT>
+
+<DD>
+Treat these hosts normally in other respects, but never use them as synchronization
+sources.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>limited</TT></DT>
+
+<DD>
+These hosts are subject to limitation of number of clients from the same
+net. Net in this context refers to the IP notion of net (class A, class
+B, class C, etc.). Only the first <TT>client_limit</TT> hosts that have
+shown up at the server and that have been active during the last <TT>client_limit_period</TT>
+seconds are accepted. Requests from other clients from the same net are
+rejected. Only time request packets are taken into account. Query packets
+sent by the <TT>ntpq</TT> and <TT>ntpdc</TT> programs are not subject to
+these limits. A history of clients is kept using the monitoring capability
+of <TT>ntpd</TT>. Thus, monitoring is always active as long as there is
+a restriction entry with the <TT>limited</TT> flag.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>ntpport</TT></DT>
+
+<DD>
+This is actually a match algorithm modifier, rather than a restriction
+flag. Its presence causes the restriction entry to be matched only if the
+source port in the packet is the standard NTP UDP port (123). Both <TT>ntpport</TT>
+and <TT>non-ntpport</TT> may be specified. The <TT>ntpport</TT> is considered
+more specific and is sorted later in the list.</DD>
+
+<DD>
+ </DD>
</DL>
-<DL>
-<DT><TT>clientlimit <I>limit</I></TT></DT>
-<DD>Set the <TT>client_limit</TT> variable, which limits the number of
-simultaneous access-controlled clients. The default value for this
-variable is 3.</DD>
+<DD>
+Default restriction list entries, with the flags <TT>ignore, ntpport</TT>,
+for each of the local host's interface addresses are inserted into the
+table at startup to prevent the server from attempting to synchronize to
+its own time. A default entry is also always present, though if it is otherwise
+unconfigured; no flags are associated with the default entry (i.e., everything
+besides your own NTP server is unrestricted).</DD>
+
+<DD>
+ </DD>
-<DT><TT>clientperiod <I>period</I></TT></DT>
-<DD>Set the <TT>client_limit_period</TT> variable, which specifies the
-number of seconds after which a client is considered inactive and thus
-no longer is counted for client limit restriction. The default value for
-this variable is 3600 seconds.</DD>
+<DT>
+<TT>clientlimit <I>limit</I></TT></DT>
+<DD>
+Set the <TT>client_limit</TT> variable, which limits the number of simultaneous
+access-controlled clients. The default value for this variable is 3.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>clientperiod <I>period</I></TT></DT>
+
+<DD>
+Set the <TT>client_limit_period</TT> variable, which specifies the number
+of seconds after which a client is considered inactive and thus no longer
+is counted for client limit restriction. The default value for this variable
+is 3600 seconds.</DD>
</DL>
-<hr><a href=index.htm><img align=left src="pic/home.gif"></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
-<HTML><HEAD><TITLE>
-Association Management
-</TITLE></HEAD><BODY><H3>
-Association Management
-</H3><HR>
-
-<H4>Association Modes</H4>
-
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>Release Notes
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+Association Management</H3>
+
+<HR>
+<H4>
+Association Modes</H4>
This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates
-new features and refinements to the NTP Version 3 (NTPv3) algorithms.
-However, it continues the tradition of retaining backwards compatibility
-with older versions. The NTPv4 version has been under development for
-quite a while and isn't finished yet. In fact, quite a number of NTPv4
-features have already been implemented in the current NTPv3, including a
-number of new operating modes for automatic server discovery and
-improved accuracy in occasionally-connected networks. Following is an
-extended abstract describing the new features.
-
-<P>An ephemeral association of some mode is mobilized when a message
-arrives from another client or server. For instance, a symmetric-passive
-association is mobilized upon arrival of a message from a symmetric-
-active peer. A client association is mobilized upon arrival of a
-broadcast message from a multicast server or a server message from a
-manycast server. Ephemeral associations are demobilized when either (a)
-the server becomes unreachable or (b) an error occurs on initial contact
-before the association is mobilized.
-
-<P>The one exception to (a) and (b) above is when <TT><A
-HREF=authopt.htm>autokey</A></TT> is in use and the initial
-authentication check fails due to unknown key identifier or autokey
-mismatch. This exception is necessary because the Unix kernel does not
-bind the local address until the first packet is received. The result in
-broadcast mode is a rather painful initial exchange, where
-authentication fails until after the first round of messages. The result
-in multicast mode is in general fatal, especially if multiple interfaces
+new features and refinements to the NTP Version 3 (NTPv3) algorithms. However,
+it continues the tradition of retaining backwards compatibility with older
+versions. The NTPv4 version has been under development for quite a while
+and isn't finished yet. In fact, quite a number of NTPv4 features have
+already been implemented in the current NTPv3, including a number of new
+operating modes for automatic server discovery and improved accuracy in
+occasionally-connected networks. Following is an extended abstract describing
+the new features..
+
+<P>An ephemeral association of some mode is mobilized when a message arrives
+from another client or server. For instance, a symmetric-passive association
+is mobilized upon arrival of a message from a symmetric- active peer. A
+client association is mobilized upon arrival of a broadcast message from
+a multicast server or a server message from a manycast server. Ephemeral
+associations are demobilized when either (a) the server becomes unreachable
+or (b) an error occurs on initial contact before the association is mobilized.
+
+<P>The one exception to (a) and (b) above is when
+<TT><A HREF="authopt.htm">autokey</A></TT> is in use and the initial
+authentication check fails due to unknown
+key identifier or autokey mismatch. This exception is necessary because
+the Unix kernel does not bind the local address until the first packet
+is received. The result in broadcast mode is a rather painful initial exchange,
+where authentication fails until after the first round of messages. The
+result in multicast mode is in general fatal, especially if multiple interfaces
are in use. As promiscuous modes such as multicast and manycast require
-authentication for reliable and safe operation, autokey is in general
-useless with these modes until and if the input/output machinery is
-overhauled.
+authentication for reliable and safe operation, autokey is in general useless
+with these modes until and if the input/output machinery is overhauled.
<P>Following is a summary of the protocol operations for each mode.
-<DL>
-
-<DT>Peer Modes (Active and Passive)</DT>
-
-<DD>In these modes, two client/server peers agree to back each other up,
-should the synchronization source for either peer fail. One or both
-peers are configured in symmetric-active mode using the peer command.
-Alternatively, one - the active peer - is configured in this mode and
-the other, the passive peer, operates in symmetric-passive mode and
-requires no prior configuration. Both association scenarios operate in
-NTPv4 as in NTPv3; however, several bugs in the handling of keys and
-recovery of resources when an active peer fails, have been corrected in
-NTPv4. The original NTPv3 authentication scheme is applicable in this
-mode, as well as the new NTPv4 autokey scheme.</DD>
-
-<DT>Client/Server Modes</DT>
-
-<DD>In these modes, a client sends a request to the server and expects a
-reply at some future time. The client is configured in client mode using
-the server (sic) command; the server requires no prior configuration.
-The original NTPv3 authentication scheme is applicable in this mode, as
-well as the new NTPv4 autokey scheme.</DD>
-
-<DT>Broadcast/Multicast Modes</DT>
-
-<DD>In these modes, the server generates messages at intervals specified
+<P>Peer Modes (Active and Passive)
+<UL>In these modes, two client/server peers agree to back each other up,
+should the synchronization source for either peer fail. One or both peers
+is configured in symmetric-active mode using the peer command. Alternatively,
+one - the active peer - is configured in this mode and the other, the passive
+peer, operates in symmetric-passive mode and requires no prior configuration.
+Both association scenarios operate in NTPv4 as in NTPv3; however, several
+bugs in the handling of keys and recovery of resources when an active peer
+fails, have been corrected in NTPv4. The original NTPv3 authentication
+scheme is applicable in this mode, as well as the new NTPv3 autokey scheme.</UL>
+Client/Server Modes
+<UL>In these modes, a client sends a request to the server and expects
+a reply at some future time. The client is configured in client mode using
+the server (sic) command; the server requires no prior configuration. The
+original NTPv3 authentication scheme is applicable in this mode, as well
+as the new NTPv3 autokey scheme.</UL>
+Broadcast/Multicast Modes
+<UL>In these modes, the server generates messages at intervals specified
by the minpoll subcommand. When using IP multicast addresses, the scope
of the multicast tree is specified by the ttl subcommand in hops. When
using a local interface broadcast address, the scope is limited to the
-attached subnet. The client responds to the first message received by
-waiting an interval randomized over the minpoll interval, in order to
-avoid implosions. Then, it polls the server in burst mode, in order to
-accumulate data to reliably set the host clock. This normally results in
-eight client/server cycles over a 32-s interval. When the next multicast
-message is received, the client computes the offset between the system
-clock just set and the apparent time of the multicast message in order
-to correct the apparent time in future multicast messages.</DD>
-
-<DT>Manycast Mode</DT>
-
-<DD>In this mode, a configured client broadcasts a request message as in
-client mode to a designated multicast group address. All servers
-configured as manycast clients and in ttl range respond with a server
-reply message. Each reply mobilizes a persistent client/server
-association as in client mode. Then, the NTP intersection and clustering
-algorithms act to discard all but the best of these associations, which
-then continue as in client/server mode.</DD>
-</DL>
-
-<H4>Poll Interval Management</H4>
-
-<p>A major goal in the system design is to minimize network overhead
-without significant impairment in accuracy. Since each system clock
-update requires an exchange of messages with each of possibly several
-servers, the interval between these messages, the poll interval, must be
-carefully and automatically managed over a prescribed range in response
-to prevailing wander of the system clock oscillator and network jitter.
-The limits to this range are set by the <tt>minpoll</tt> and
-<tt>maxpoll</tt> variables described on the <a
-href=confopt.htm>Configuration Options</a> page. The default values
-(usually 64 s and 1024 s) should be changed only in very special
-circumstances and thorough understanding of the consequences.
-
-<p>Ordinarily, the daemon manages the poll interval automatically so
-that, most of the time the interval hovers near the maximum. However,
-under conditions of extreme network jitter or when the servers are
-intermittently unreachable, the poll interval may be reduced, in the
-extreme to the minimum. However, after some period when a server remains
-unreachable, the poll interval is increased in steps to the maximum.
-This protects the network against spurious traffic while continuing to
-probe for server reachability.
-
-<p>Burst mode can be configured when the network attachment requires an
-initial calling or training procedure and in cases where the first
-message sent after a considerable interval is lost or the network has
-moderate to high loss rate. This mode does produce additional network
-overhead and can cause trouble if used indiscriminately. It should only
-be used where the poll interval is expected to settle to values at or
-above 1024 s.
-
-<p>Each poll initiates a burst of either two or eight request messages.
-If the server is unreachable, 2 messages are sent; if reachable, 8
-messages are sent. If no valid reply is received, the client waits for
-16 s before sending the next request. This is to allow time to complete
-a dial-out modem or ISDN call. If a valid reply is received, the client
-waits for 2 s before sending the next request. Reply messages update the
-clock filter, but do not update the system clock until 2 s after the
-last request is sent.
-
-<H4>Error Checking</H4>
-
-It is very important to avoid spurious mobilizations from possibly
-broken or rogue servers; in particular, to avoid denial-of-service
-attacks. In order to resist such attacks, arriving messages that might
-mobilize ephemeral associations are carefully screened using a series of
-eleven sanity checks.
-
+attached subnet. The client responds to the first message received by waiting
+an interval randomized over the minpoll interval, in order to avoid implosions.
+Then, it polls the server in burst mode, in order to accumulate data to
+reliably set the host clock. This normally results in eight client/server
+cycles over a 32-s interval. When the next multicast message is received,
+the client computes the offset between the system clock just set and the
+apparent time of the multicast message in order to correct the apparent
+time in future multicast messages.</UL>
+Manycast Mode
+<UL>In this mode, a configured client broadcasts a request message as in
+client mode to a designated multicast group address. All servers configured
+as manycast clients and in ttl range respond with a server reply message.
+Each reply mobilizes a persistent client/server association as in client
+mode. Then, the NTP intersection and clustering algorithms act to discard
+all but the "best" of these associations, which then continue as in client/server
+mode.</UL>
+
+<H4>
+Burst Mode</H4>
+Burst mode can be configured when the network attachment requires an initial
+calling or training procedure. Each poll initiates a burst of eight request
+messages at intervals randomized over the range 3-5 s. The reply messages
+update the clock filter, which then selects the best (most accurate) among
+them. When the last reply in the burst is sent, the next reply updates
+the client variables and system clock in the usual manner, as if only a
+single request/reply cycle had occurred. This mode does produce additional
+network overhead and can cause trouble if used indiscriminately. It should
+only be used where the poll interval is expected to settle to values above
+1024 s.
+<H4>
+Revised Error Checking</H4>
+It is very important to avoid spurious mobilizations from possibly broken
+or rogue servers; in particular, to avoid denial-of-service attacks. In
+order to resist such attacks, arriving messages that might mobilize ephemeral
+associations are carefully screened using a series of eleven sanity checks.
<OL>
-
-<LI>Duplicate packet. This message is a duplicate of one previously
-received.</LI>
-
-<LI>Bogus packet. This message did not result from a message previously
-sent, or messages have been received out of order.</LI>
-
-<LI>Unsynchronized. The server has not yet stored the previous
-timestamps.</LI>
-
-<LI>Invalid delay or dispersion. Either the delay or dispersion or both
-computed from the message timestamps are above the normal range.</LI>
-
-<LI>Authentication failed. The sent MAC does not match the received MAC,
-either due to the wrong key material or damaged message.</LI>
-
-<LI>Server unsynchronized. The server indicates unsynchronized in the
-leap warning bits included in the packet.</LI>
-
-<LI>Server stratum check. The server is operating at a stratum above the
-normal range.</LI>
-
-<LI>Delay/dispersion check. The related server packet data values are
-above the normal range.</LI>
-
-<LI>Autokey failed. The hash of the current session key does not match
-the most recent key identifiers used. (The hash is repeated four times,
-in order to recover from lost packets whenever possible.)</LI>
-
-<LI>Access denied. The sender has been blocked by the access control
-list.</LI>
-
-<LI>Key not found. The key identifier does not match any identifier in
-the key list or the key has expired or been revoked.</LI>
-
+<LI>
+Duplicate packet. This message is a duplicate of one previously received.</LI>
+
+<BR>
+<LI>
+Bogus packet. This message did not result from a message previously sent,
+or messages have been received out of order.</LI>
+
+<BR>
+<LI>
+Unsynchronized. The server has not yet stored the previous timestamps.</LI>
+
+<BR>
+<LI>
+Invalid delay or dispersion. Either the delay or dispersion or both computed
+from the message timestamps are above the normal range.</LI>
+
+<BR>
+<LI>
+Authentication failed. The sent MAC does not match the received MAC, either
+due to the wrong key material or damaged message.</LI>
+
+<BR>
+<LI>
+Server unsynchronized. The server indicates unsynchronized in the leap
+bits included in the packet.</LI>
+
+<BR>
+<LI>
+Server stratum check. The server is operating at a stratum above the normal
+range.</LI>
+
+<BR>
+<LI>
+Delay/dispersion check. The related server packet data values are above
+the normal range.</LI>
+
+<BR>
+<LI>
+Autokey failed. The hash of the current session key does not match the
+most recent key identifiers used. (The hash is repeated four times, in
+order to recover from lost packets whenever possible.)</LI>
+
+<BR>
+<LI>
+Access denied. The sender has been blocked by the access control list.</LI>
+
+<BR>
+<LI>
+Key not found. The key identifier does not match any identifier in the
+key list or the key has expired or been revoked.</LI>
</OL>
-
Failure to pass tests 5-11 is sufficient evidence to discard the packet
-without forming an association. However, failure to pass tests 1-4 is
-not necessarily grounds to reject the packet, since subsequent packets
-may be acceptable. In this case, the association is mobilized, but only
-the packet timestamps are stored. For the moment, and until the
-cryptographic signature algorithm is available, test 9 is temporarily
-disabled.
-
+without forming an association. However, failure to pass tests 1-4 is not
+necessarily grounds to reject the packet, since subsequent packets may
+be acceptable. In this case, the association is mobilized, but only the
+packet timestamps are stored. For the moment, and until the cryptographic
+signature algorithm is available, test 9 is temporarily disabled.
<BR>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+<BR>
+</BODY>
+</HTML>
-<HTML><HEAD><TITLE>
-Authentication Options
-</TITLE></HEAD><BODY><H3>
-Authentication Options
-</H3><HR>
-
-<H4>Authentication Support</H4>
-
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>Authentication Options
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+Authentication Options</H3>
+
+<HR>
+<H4>
+Authentication Support</H4>
Authentication support allows the NTP client to verify that the server
is in fact known and trusted and not an intruder intending accidentally
-or on purpose to masquerade as that server. The NTPv3 specification
-RFC-1305 defines a scheme which provides cryptographic authentication of
-received NTP packets. Originally, this was done using the Data
-Encryption Standard (DES) operating in Cipher Block Chaining (CBC) mode,
-commonly called DES-CBC. Subsequently, this was augmented by the RSA
-Message Digest 5 (MD5) using a private key, commonly called keyed-MD5.
-Either algorithm computes a message digest, or one-way hash, which can
-be used to verify the server has the correct private key and key
-identifier. NTPv4 retains this scheme and, in addition, provides a new
-<I>autokey</I> scheme based on reverse hashing and public key
-cryptography. Authentication can be configured separately for each
-association using the <TT>key</TT> or <TT>autokey</TT> subcommands on
-the <TT>peer</TT>, <TT>server</TT>, <TT>broadcast</TT> and
-<TT>manycastclient</TT> commands as described in the <A
-HREF="config.htm">Configuration Options</A> page.
+or on purpose to masquerade as that server. The NTPv3 specification RFC-1305
+defines an scheme which provides cryptographic authentication of received
+NTP packets. Originally, this was done using the Data Encryption Standard
+(DES) operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC.
+Subsequently, this was augmented by the RSA Message Digest 5 (MD5) using
+a private key, commonly called keyed-MD5. Either algorithm computes a message
+digest, or one-way hash, which can be used to verify the server has the
+correct private key and key identifier. NTPv4 retains this scheme and,
+in addition, provides a new <I>autokey </I>scheme based on reverse hashing
+and public key cryptography. Authentication can be configured separately
+for each association using the <TT>key </TT>or <TT>autokey </TT>subcommands
+on the <TT>peer</TT>, <TT>server</TT>, <TT>broadcast</TT> and <TT>manycastclient</TT>
+commands as described in the <A HREF="config.htm">Configuration Options</A>
+page.
<P>The authentication options specify the suite of keys, select the key
for each configured association and manage the configuration operations,
-as described below. The <TT>auth</TT> flag which controls these
-functions can be set or reset by the <TT>enable</TT> and
-<TT>disable</TT> configuration commands and also by remote configuration
-commands sent by a <TT>ntpdc</TT> program running in another machine. If
-this flag is set, persistent peer associations and remote configuration
-commands are effective only if cryptographically authenticated. If this
-flag is disabled, these operations are effective even if not
-cryptographically authenticated. It should be understood that operating
-in the latter mode invites a significant vulnerability where a rogue
-hacker can seriously disrupt timekeeping operations.
-
-<P>The <TT>auth</TT> flag affects all authentication procedures
-described below; however, it operates differently if cryptographic
-support is compiled in the distribution. If this support is available
-and the flag is enabled, then persistent associations are mobilized and
-remote configuration commands are effective only if successfully
-authenticated. If the support is unavailable and the flag is enabled,
-then it is not possible under any conditions to mobilize persistent
-associations or respond to remote or local configuration commands. The
-<TT>auth</TT> flag normally defaults enabled if cryptographic support is
-available and disabled otherwise.
-
-<p>Persistent associations are normally mobilized upon arrival of a
-message from a server operating in symmetric active mode. The
-<tt>peer</tt> configuration file command mobilizes such an association.
-When a message arrives from the active server, the passive server
-attempts to mobilize a symmetric passive association. Unless refused by
-the passive server, either using access controls or authentication, this
-could allow a rogue active server to control the passive server clock.
-Using cryptographic authentication, such attacks can be deflected.
-
-<P>With the above vulnerabilities in mind, it is desirable to set the
-<tt>auth</tt> flag in all cases. One aspect which is often confusing is
-the name resolution process which maps server names in the configuration
-file to IP addresses. In order to protect against bogus name server
-messages, this process is authenticated using an internally generated
-key which is normally invisible to the user. However, if cryptographic
-support is unavailable and the <TT>auth</TT> flag is enabled, the name
-resolution process will fail. This can be avoided either by specifying
-IP addresses instead of host names, which is generally inadvisable, or
-by leaving the flag disabled and enabling it once the name resolution
-process is complete.
-
-<H4>Private Key Scheme</H4>
-
-The original RFC-1305 specification allows any one of possibly 65,536
-keys, each distinguished by a 32-bit key identifier, to authenticate an
-association. The servers involved must agree on the key and key
-identifier to authenticate their messages. Keys and related information
-are specified in a key file, usually called <TT>ntp.keys</TT>, which
-should be exchanged and stored using secure procedures beyond the scope
-of the NTP protocol itself. Besides the keys used for ordinary NTP
-associations, additional ones can be used as passwords for the <TT><A
-HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
+as described below. The <TT>auth</TT> flag which controls these functions
+can be set or reset by the <TT>enable</TT> and <TT>disable</TT> configuration
+commands and also by remote configuration commands sent by a <TT>ntpdc</TT>
+program running in another machine. If this flag is set, persistent peer
+associations and remote configuration commands are effective only if cryptographically
+authenticated. If this flag is disabled, these operations are effective
+even if not cryptographic authenticated. It should be understood that operating
+in the latter mode invites a significant vulnerability where a rogue hacker
+can seriously disrupt client operations.
+
+<P>The <TT>auth</TT> flag affects all authentication procedures described
+below; however, it operates differently if cryptographic support is compiled
+in the distribution. If this support is available and the flag is enabled,
+then persistent associations are mobilized and remote configuration commands
+are effective only if successfully authenticated. If the support is unavailable
+and the flag is enabled, then it is not possible under any conditions to
+mobilize persistent associations or respond to remote configuration commands.
+The <TT>auth </TT>flag normally defaults to set if cryptographic support
+is available and to reset otherwise.
+
+<P>With the above vulnerabilities in mind, it is desirable to set the auth
+flag in all cases. One aspect which is often confusing is the name resolution
+process which maps server names in the configuration file to IP addresses.
+In order to protect against bogus name server messages, this process is
+authenticated using an internally generated key which is normally invisible
+to the user. However, if cryptographic support is unavailable and the <TT>auth</TT>
+flag is enabled, the name resolution process will fail. This can be avoided
+either by specifying IP addresses instead of host names, which is generally
+inadvisable, or by leaving the flag disabled and enabling it once the name
+resolution process is complete.
+<H4>
+Private Key Scheme</H4>
+The original RFC-1305 specification allows any one of possibly 65,536 keys,
+each distinguished a 32-bit key identifier, to authenticate an association.
+The servers involved must agree on the key and key identifier to authenticate
+their messages. Keys and related information are specified in a key file,
+usually called <TT>ntp.key</TT>s, which should be exchanged and stored
+using secure procedures beyond the scope of the NTP protocol itself. Besides
+the keys used for ordinary NTP associations, additional ones can be used
+as passwords for the <TT><A HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
utility programs.
-<P>When <TT>ntpd</TT>is first started, it reads the key file and
-installs the keys in the key cache. However, the keys must be activated
-before they can be used with the <TT>trusted </TT>command. This allows,
-for instance, the installation of possibly several batches of keys and
-then activating or inactivating 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.
-
-<H4>Autokey Scheme</H4>
-
+<P>When <TT>ntpd </TT>is first started, it reads the key file and installs
+the keys in the key cache. However, the keys must be activated before they
+can be used with the <TT>trusted </TT>command. This allows, for instance,
+the installation of possibly several batches of keys and then activating
+or inactivating 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 the <TT>ntpq </TT>utility.
+<H4>
+Autokey Scheme</H4>
The original NTPv3 authentication scheme described in RFC-1305 continues
-to be supported. In NTPv4, an additional authentication scheme called
-<I>autokey</I> is available. It operates much like the S/KEY scheme, in
-that a session key list is constructed and the entries used in reverse
-order. A description of the scheme, along with a comprehensive security
-analysis, is contained in a technical report available from the IETF web
-page <A HREF="www.ietf.org">www.ietf.org</A>.
-
-<P>The autokey scheme is specifically designed for multicast modes,
-where clients normally do not send messages to the server. In these
-modes, the server uses the scheme to generate a key list by repeated
-hashing of a secret value. The list is used in reverse order to generate
-a unique session key for each message sent. The client regenerates the
-session key and verifies that the hash matches the previous session key. Each
-message contains the public values binding the session key to the secret
-value, but these values need to be verified only when the server
-generates a new key list or more than four server messages have been
-lost.
+to be supported. In NTPv4, an additional authentication scheme called <I>autokey
+</I>is available. It operates much like the S-KEY scheme, in that a session
+key list is constructed and the entries used in reverse order. A description
+of the scheme, along with a comprehensive security analysis, is contained
+in a technical report available from the IETF web page <A HREF="www.ietf.org">www.ietf.org</A>
+.
+
+<P>The autokey scheme is specifically designed for multicast modes, where
+clients normally do not send messages to the server. In these modes, the
+server uses the scheme to generate a key list by repeated hashing of a
+secret value. The list is used in reverse order to generate a unique session
+key for each message sent. The client regenerates the session key and verifies
+the hash matches the previous session key. Each message contains the public
+values binding the session key to the secret value, but these values need
+to be verified only when the server generates a new key list or more than
+four server messages have been lost.
<P>The scheme is appropriate for client/server and symmetric-peer modes
-as well. In these modes, the client generates a session key as in
-multicast modes. The server regenerates the session key and uses it to
-formulate a reply using its own public values. The client verifies that the
-key identifier of the reply matches the request, verifies the public
-values and validates the message. In peer mode, each peer independently
-generates a key list and operates as in the multicast mode.
+as well. In these modes, the client generates a session key as in multicast
+modes. The server regenerates the session key and uses it to formulates
+a reply using its own public values. The client verifies the key identifier
+of the reply matches the request, verifies the public values and validates
+the message. In peer mode, each peer independently generates a key list
+and operates as in the multicast mode.
<P>The autokey scheme requires no change to the NTP packet header format
or message authentication code (MAC), which is appended to the header;
however, if autokey is in use, an extensions field is inserted between
the header and MAC. The extensions field contains a random public value
which is updated at intervals specified by the revoke command, together
-with related cryptographic values used in the signing algorithm. The
-format of the extensions field is defined in Internet Draft
-draft-ntp-auth-coexist-01.txt. The MAC itself is constructed in the same
-way as NTPv3, but using the original NTP header and the extensions field
-padded to a 64-bit boundary. Each new public value is encrypted by the
-host private value. It is the intent of the design, not yet finalized,
-that the public value, encrypted public value, public key and
-certificate be embedded in the extensions field where the client can
-decrypt as needed. However, the relatively expensive encryption
-and decryption operations are necessary only when the public value is
-changed.
+with related cryptographic values used in the signing algorithm. The format
+of the extensions field is defined in Internet Draft draft-NTP- auth-coexist-00.txt.
+The MAC itself is constructed in the same way as NTPv3, but using the original
+NTP header and the extensions field padded to a 64-bit boundary. Each new
+public value is encrypted by the host private value. It is the intent of
+the design, not yet finalized, that the public value, encrypted public
+value, public key and certificate be embedded in the extensions field where
+the client can decrypt as needed. However, the relatively expensive encryption
+and decryption operations are necessary only when the public value is changed.
<P>Note that both the original NTPv3 authentication scheme and the new
NTPv4 autokey scheme operate separately for each configured association,
cache, provisions have been made to avoid collisions, where some random
roll happens to collide with another already generated. Since something
like four billion different session key identifiers are available, the
-chances are small that this might happen. If it happens during
-generation, the generator terminates the current session key list. By
-the time the next list is generated, the collided key will probably have
-been expired or revoked.
-
-<P>While permanent keys have lifetimes that expire only when manually
-revoked, random session keys have a lifetime specified at the time of
-generation. When generating a key list for an association, the lifetime
-of each key is set to expire one poll interval later than it is
-scheduled to be used. The maximum lifetime of any key in the list is
-specified by the <TT>autokey</TT> command. Lifetime enforcement is a
-backup to the normal procedure that revokes the last-used key at the
-time the next key on the key list is used.
-
-<H4>Authentication Commands</H4>
+chances are small that this might happen. If it happens during generation,
+the generator terminates the current session key list. By the time the
+next list is generated, the collided key will probably have been expired
+or revoked.
+
+<P>While permanent keys have lifetimes that expire only when manually revoked,
+random session keys have a lifetime specified at the time of generation.
+When generating a key list for an association, the lifetime of each key
+is set to expire one poll interval later than it is scheduled to be used.
+The maximum lifetime of any key in the list is specified by the <TT>autokey</TT>
+command. Lifetime enforcement is a backup to the normal procedure that
+revokes the last-used key at the time the next key on the key list is used.
+<H4>
+Authentication Commands</H4>
<DL>
-
-<DT><TT>keys <I>keyfile</I></TT></DT>
-<DD>Specifies the file name containing the encryption keys and key
-identifiers used by <TT>ntpd</TT>, <TT>ntpq</TT> and <TT>ntpdc</TT> when
-operating in authenticated mode. The format of this file is described
-later in this document.</DD>
-
-<DT><TT>trustedkey <I>key</I> [...]</TT></DT>
-<DD>Specifies the encryption key identifiers which are trusted for the
-purposes of authenticating peers suitable for synchronization, as well
-as keys used by the <TT>ntpq </TT>and <TT>ntpdc </TT>programs. The
-authentication procedures require that both the local and remote servers
-share the same key and key identifier for this purpose, although
-different keys can be used with different servers. The
-<I><TT>key</TT></I> arguments are 32-bit unsigned integers with values
-less than 65,536. Note that NTP key 0 is used to indicate an invalid key
-and/or key identifier, so should not be used for any other purpose.</DD>
-
-<DT><TT>requestkey <I>key</I></TT></DT>
-<DD>Specifies the key identifier to use with the <TT>ntpdc</TT> program,
-which uses a proprietary protocol specific to this implementation of
-<TT>ntpd</TT>. This program is useful to diagnose and repair problems
-that affect <TT>ntpd</TT> operation. The <I><TT>key</TT></I> argument to
-this command is a 32-bit key identifier for a previously defined trusted
-key. If no <TT>requestkey </TT>command is included in the configuration
-file, or if the keys don't match, any request to change a server
-variable with be denied.</DD>
-
-<DT><TT>controlkey <I>key</I></TT></DT>
-<DD>Specifies the key identifier to use with the <TT>ntpq</TT> program,
-which uses the standard protocol defined in RFC-1305. This program is
-useful to diagnose and repair problems that affect <TT>ntpd</TT>
+<DT>
+<TT>keys <I>keyfile</I></TT></DT>
+
+<DD>
+Specifies the file name containing the encryption keys and key identifiers
+used by <TT>ntpd</TT>, <TT>ntpq</TT> and <TT>ntpdc</TT> when operating
+in authenticated mode. The format of this file is described later in this
+document.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>trustedkey <I>key</I> [...]</TT></DT>
+
+<DD>
+Specifies the encryption key identifiers which are trusted for the purposes
+of authenticating peers suitable for synchronization, as well as keys used
+by the <TT>ntpq </TT>and <TT>ntpdc </TT>programs. The authentication procedures
+require that both the local and remote servers share the same key and key
+identifier for this purpose, although different keys can be used with different
+servers. The <I><TT>key</TT></I> arguments are 32-bit unsigned integers
+with values less than 65,536. Note that NTP key 0 is used to indicate an
+invalid key and/or key identifier, so should not be used for any other
+purpose.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>requestkey <I>key</I></TT></DT>
+
+<DD>
+Specifies the key identifier to use with the <TT>ntpdc</TT> program, which
+uses a proprietary protocol specific to this implementation of <TT>ntpd</TT>.
+This program is useful to diagnose and repair problems that affect <TT>ntpd</TT>
operation. The <I><TT>key</TT></I> argument to this command is a 32-bit
-key identifier for a trusted key in the key cache. If no <TT>controlkey
+key identifier for a previously defined trusted key. If no <TT>requestkey
</TT>command is included in the configuration file, or if the keys don't
match, any request to change a server variable with be denied.</DD>
-</DL>
+<DD>
+ </DD>
-<H4>Authentication Key File Format</H4>
+<DT>
+<TT>controlkey <I>key</I></TT></DT>
+<DD>
+Specifies the key identifier to use with the <TT>ntpq</TT> program, which
+uses the standard protocol defined in RFC-1305. This program is useful
+to diagnose and repair problems that affect <TT>ntpd</TT> operation. The
+<I><TT>key</TT></I> argument to this command is a 32-bit key identifier
+for a trusted key in the key cache. If no <TT>controlkey </TT>command is
+included in the configuration file, or if the keys don't match, any request
+to change a server variable with be denied.</DD>
+</DL>
+
+<H4>
+Authentication Key File Format</H4>
In the case of DES, the keys are 56 bits long with, depending on type,
a parity check on each byte. In the case of MD5, the keys are 64 bits (8
-bytes). <TT>ntpd</TT> reads its keys from a file specified using the
-<TT>-k</TT> command line option or the <TT>keys</TT> statement in the
-configuration file. While key number 0 is fixed by the NTP standard (as
-56 zero bits) and may not be changed, one or more of the keys numbered 1
-through 15 may be arbitrarily set in the keys file.
+bytes). <TT>ntpd</TT> reads its keys from a file specified using the <TT>-k</TT>
+command line option or the <TT>keys</TT> statement in the configuration
+file. While key number 0 is fixed by the NTP standard (as 56 zero bits)
+and may not be changed, one or more of the keys numbered 1 through 15 may
+be arbitrarily set in the keys file.
<P>The key file uses the same comment conventions as the configuration
file. Key entries use a fixed format of the form
<P><I><TT>keyno type key</TT></I>
-<P>where <I><TT>keyno</TT></I> is a positive integer,
-<I><TT>type</TT></I> is a single character which defines the key format,
-and <I><TT>key</TT></I> is the key itself.
+<P>where <I><TT>keyno</TT></I> is a positive integer, <I><TT>type</TT></I>
+is a single character which defines the key format, and <I><TT>key</TT></I>
+is the key itself.
<P>The key may be given in one of three different formats, controlled by
-the <I><TT>type</TT></I> character. The three key types, and
-corresponding formats, are listed following.
-
+the <I><TT>type</TT></I> character. The three key types, and corresponding
+formats, are listed following.
<DL>
-
-<DT><TT>S</TT></DT>
-<DD>The key is a 64-bit hexadecimal number in the format specified in
-the DES specification; that is, the high order seven bits of each octet
-are used to form the 56-bit key while the low order bit of each octet is
-given a value such that odd parity is maintained for the octet. Leading
-zeroes must be specified (i.e., the key must be exactly 16 hex digits
-long) and odd parity must be maintained. Hence a zero key, in standard
-format, would be given as <TT>0101010101010101</TT>.</DD>
-
-<DT><TT>N</TT></DT>
-<DD>The key is a 64-bit hexadecimal number in the format specified in
-the NTP standard. This is the same as the DES format, except the bits in
-each octet have been rotated one bit right so that the parity bit is now
-the high order bit of the octet. Leading zeroes must be specified and
-odd parity must be maintained. A zero key in NTP format would be
-specified as <TT>8080808080808080</TT>.</DD>
-
-<DT><TT>A</TT></DT>
-<DD>The key is a 1-to-8 character ASCII string. A key is formed from
-this by using the low order 7 bits of each ASCII character in the
-string, with zeroes added on the right when necessary to form a full
-width 56-bit key, in the same way that encryption keys are formed from
-Unix passwords.</DD>
-
-<DT><TT>M</TT></DT>
-<DD>The key is a 1-to-8 character ASCII string, using the MD5
-authentication scheme. Note that both the keys and the authentication
-schemes (DES or MD5) must be identical between a set of peers sharing
-the same key number.</DD>
-
+<DT>
+<TT>S</TT></DT>
+
+<DD>
+The key is a 64-bit hexadecimal number in the format specified in the DES
+specification; that is, the high order seven bits of each octet are used
+to form the 56-bit key while the low order bit of each octet is given a
+value such that odd parity is maintained for the octet. Leading zeroes
+must be specified (i.e., the key must be exactly 16 hex digits long) and
+odd parity must be maintained. Hence a zero key, in standard format, would
+be given as <TT>0101010101010101</TT>.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>N</TT></DT>
+
+<DD>
+The key is a 64-bit hexadecimal number in the format specified in the NTP
+standard. This is the same as the DES format, except the bits in each octet
+have been rotated one bit right so that the parity bit is now the high
+order bit of the octet. Leading zeroes must be specified and odd parity
+must be maintained. A zero key in NTP format would be specified as <TT>8080808080808080</TT>.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>A</TT></DT>
+
+<DD>
+The key is a 1-to-8 character ASCII string. A key is formed from this by
+using the low order 7 bits of each ASCII character in the string, with
+zeroes added on the right when necessary to form a full width 56-bit key,
+in the same way that encryption keys are formed from Unix passwords.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>M</TT></DT>
+
+<DD>
+The key is a 1-to-8 character ASCII string, using the MD5 authentication
+scheme. Note that both the keys and the authentication schemes (DES or
+MD5) must be identical between a set of peers sharing the same key number.</DD>
</DL>
-
Note that the keys used by the <TT>ntpq</TT> and <TT>ntpdc</TT> programs
are checked against passwords requested by the programs and entered by
-hand, so it is generally appropriate to specify these keys in ASCII
-format.
+hand, so it is generally appropriate to specify these keys in ASCII format.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src="pic/home.gif"></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
<p>Note that network timekeeping technology continues to advance and may
obsolete some of the following documents. For a current list of all
papers, reports, briefings and other documents relevant to the NTP
-community, see the <a href="http://www.eecis.udel.edu/~mills">David L.
+community, see the <a href=http://www.eecis.udel.edu/~mills>David L.
Mills</a> web page.
<P>The NTP architecture, protocol and algorithm models are described in
<li>Mills, D.L. Internet time synchronization: the Network Time
Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991),
1482-1493. <A
-HREF="http://www.eecis.udel.edu/~mills/database/papers/trans.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/papers/trans.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf>
PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States
and Time in Distributed Systems</I>. IEEE Computer Society Press, Los
Alamitos, CA, 1994, 91-102.
<li>Mills, D.L. Network Time Protocol (Version 3) specification,
implementation and analysis. Network Working Group Report RFC-1305,
University of Delaware, March 1992, 113 pp. Abstract: <A
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps">
-PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps>
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf>
PDF</A>, Body: <a
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps">
-PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps>
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf>
PDF</A>, Appendices: <A
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps>
PostScript</a> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf>
PDF</A>.
</UL>
<OL>
-<LI>Support for precision-time kernel modifications, as described
-in
+<p><LI>Support for precision-time kernel modifications, as described
+in</LI>
-<p>Mills, D.L. Unix kernel modifications for precision time
+<P>Mills, D.L. Unix kernel modifications for precision time
synchronization. Electrical Engineering Department Report 94-10-1,
University of Delaware, October 1994, 24 pp. Abstract: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf>
PDF</a>, Body: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf>
PDF</a>. Major revision and update of: Network Working Group Report
RFC-1589, University of Delaware, March 1994. 31 pp. <A
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt">ASCII</A>
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</A>
-<LI>Support for IP Multicasting, as described in
+<p><LI>Support for IP Multicasting, as described in</LI>
<P>Mills, D.L, and A. Thyagarajan. Network time protocol version 4
proposed changes. Electrical Engineering Department Report 94-10-2,
University of Delaware, October 1994, 32 pp. Abstract: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps>
PostScript</A> | <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf>
PDF</A>, Body: <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf>
PDF</a>
-<LI>A new hybrid phase/frequency-lock clock discipline, which
-replaces the RFC-1305 local clock algorithm, as described in
+<p><LI>A new hybrid phase/frequency-lock clock discipline, which
+replaces the RFC-1305 local clock algorithm, as described in</LI>
<P>Mills, D.L. Clock discipline algorithms for the Network Time Protocol
Version 4. Electrical Engineering Report 97-3-3, University of Delaware,
March 1997, 35 pp. Abstract: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf">
+HREF=
+http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf>
PDF</a>, Body: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf">
+HREF=
+http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>
PDF</a>
<P>Mills, D.L. Improved algorithms for synchronizing computer network
clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <A
-HREF="http://www.eecis.udel.edu/~mills/database/papers/tune2.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>
PDF</a>
-<LI>Engineered refinements to radio clock drivers and interface code,
-as described in:
+<P><LI>Engineered refinements to radio clock drivers and interface code,
+as describedin:</LI>
<P>Mills, D.L. Precision synchronization of computer network clocks.
<I>ACM Computer Communication Review 24, 2</I> (April 1994). 28-43. <A
-HREF="http://www.eecis.udel.edu/~mills/database/papers/fine.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.ps>
PostScript</A> | <A
-HREF="http://www.eecis.udel.edu/~mills/database/papers/fine.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf>
PDF</a>
-<LI>Support for over two dozen reference clock drivers for all known
+<P><LI>Support for over two dozen reference clock drivers for all known
national and international radio, satellite and modem standard time
services known at this time. See the <A HREF=refclock.htm>Reference
-Clock Drivers </A>page.
+Clock Drivers </A>page.</LI>
-<LI>A new security model and authentication scheme based on public-
-key cryptography called <I>autokey</I>, as described in
+<P><LI>A new security model and authentication scheme based on public-
+key cryptography called <I>autokey</I>, as described in</LI>
<P>Mills, D.L., T.S. Glassey, and M.E. McNeil. Coexistence and
interoperability of NTP authentication schemes. Internet Draft
draft-mills-ntp-auth-coexist-00.txt, University of Delaware and Coastek
InfoSys, Inc., November 1997, 8 pp. <A
-HREF="http://www.eecis.udel.edu/~mills/memos/draft.txt">ASCII</A>
+HREF=http://www.eecis.udel.edu/~mills/memos/draft.txt>ASCII</A>
<P>Mills, D.L. Authentication scheme for distributed, ubiquitous, real-
time protocols. <I>Proc. Advanced Telecommunications/Information
Distribution Research Program (ATIRP) Conference</I> (College Park MD,
January 1997), 293-298. <A
-HREF="http://www.eecis.udel.edu/~mills/database/papers/atirp.ps">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf">
+HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf>
PDF</a>
<P>Mills, D.L. Proposed authentication enhancements for the Network Time
Protocol version 4. Electrical Engineering Report 96-10-3, University of
Delaware, October 1996, 36 pp. Abstract: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps">
+HREF=
+http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf">
+HREF=
+http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf>
PDF</a>, Body: <A
-HREF="http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps">
+HREF=
+http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps>
PostScript</A> | <a
-HREF="http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf">
+HREF=
+http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf>
PDF</a>
-<LI> Support for the MD5 cryptographic hash algorithm, in addition to
+<P><LI> Support for the MD5 cryptographic hash algorithm, in addition to
the DES-CBC algorithm described in RFC-1305, as described in the <A
HREF=ntpd.htm><TT>ntpd</TT> - Network Time Protocol (NTP) daemon
</A>page.</LI>
-<LI>The prefer-peer scheme, as described in the <A
+<
P><LI>The prefer-peer scheme, as described in the <A
HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword
</A>page.</LI>
-<LI>Specification for the Simple Network Time Protocol (SNTP), as
-described in
+<P><LI>Specification for the Simple Network Time Protocol (SNTP), as
+described in</LI>
<P>Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4,
IPv6 and OSI. Network Working Group Report RFC-2030, University of
Delaware, October 1996, 18 pp. <A
-HREF="http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt">
+HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt>
ASCII</A>. Obsoletes RFC-1769 and RFC-1361.
-<LI>Performance surveys for NTP Version 4 can be found in
+<P><LI>Performance surveys for NTP Version 4 can be found in</LI>
-<p>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet
+<p><li>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet
timekeeping around the globe. <i>Proc. Precision Time and Time Interval
(PTTI) Applications and Planning Meeting</i> (Long Beach CA, December
1997), 365-371. Paper: <a
-href="http://www.eecis.udel.edu/~mills/database/papers/survey5.ps">
+href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf">
+href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>
PDF</a>, Slides: <a
-href="http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm">
+href=
+http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>
HTML</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps">
+href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/brief/survey.ppt">
+href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>
PowerPoint</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf">
-PDF</a>
+href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>
+PDF</a></li>
-<li>Mills, D.L. The network computer as precision timekeeper.
+<p><li>Mills, D.L. The network computer as precision timekeeper.
<i>Proc. Precision Time and Time Interval (PTTI) Applications and
Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a
-href="http://www.eecis.udel.edu/~mills/database/papers/ptti.ps">
+href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf">
+href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>
PDF</a>, Slides: <a
-href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm">
+href=
+http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>
HTML</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps">
+href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt">
+href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>
PowerPoint</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf">
-PDF</a>
+href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>
+PDF</a></li>
</OL>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
<H4>Building and Installing the Distribution</H4>
-Note that the automatic build process inspects the machine environment
-and tests for the presence of system header files and the contents of
-these files to determine if certain features are available. When one or
-more of these features are present, the code is compiled to use them; if
-not, no special code is compiled. However, even if the code is compiled
-to use these features, the code does a special test at run time to see
-if one or more are actually present and avoids using them if not
-present. In such cases a warning message is sent to the system log, but
-the daemon should still work properly.
-
-<H4>Support for Cryptographic Authentication</H4>
-
-As required by the International Trade in Arms Regulations (ITAR), now
-called the Defense Trade Regulations (DTR), certain cryptographic
-products and media, including the Data Encryption Standard (DES), cannot
-be exported without per-instance license. For this reason, the DES
-encryption routine has been removed from the the current version, even
-though it is used only to compute a message digest. Current DTR
-regulations allow export of the the MD5 message digest routine, which is
-in fact the preferred algorithm, and this is included in the current
+As a practical matter, every computer architecture and operating system
+version seems to be different than any other. The device drivers may be
+different, the input/output system may bew idiosyncratic and the
+libraries may have different semantics. It is not possible in a software
+distribution such as this one to support every individual sysdtem with a
+common set of binaries, even with the same system but different
+versions. Therefore, it is necessary to configure each system
+individually for each system and version, both at compile time and at
+run time. In almost all cases, these procedures are completely automatic
+and all the newbie user need do is type "make" and the autoconfigure
+system does the rest. There are some exceptions, as noted below.
+
+<p>The autoconfigure system inspects the hardware and software
+environment and tests for the presence of system header files and the
+contents of these files to determine if certain features are available.
+When one or more of these features are present, the code is compiled to
+use them; if not, no special code is compiled. However, even if the code
+is compiled to use these features, the code does a special test at run
+time to see if one or more are actually present and avoids using them if
+not present. In such cases a warning message is sent to the system log,
+but the daemon should still work properly.
+
+Some programs included in this distribution use cryptographic algorithms
+to verify server authenticity and credentials. As required by the
+International Trade in Arms Regulations (ITAR), now called the Defense
+Trade Regulations (DTR), certain cryptographic products and media,
+including the Data Encryption Standard (DES), cannot be exported without
+per-instance license. For this reason, the DES encryption routine has
+been removed from the the current version, even though it is used only
+to compute a message digest. Current DTR regulations allow export of the
+the MD5 message digest routine, which is in fact the preferred
+algorithm, and this is included in the current
version.
<P>The NTP authentication routines conform to the interface used by RSA
to create a NTP configuration file <TT>ntp.conf</TT> and possibly a
cryptographic key file <TT>ntp.keys</TT>. Directions for doing that are
in the <A HREF="notes.htm">Notes on Configuring NTP and Setting up a NTP
-Subnet</A>. A tutorial on debugging technique is in <A
-HREF="debug.htm">NTP Debugging Technique</A>.
+Subnet</A>. The behavior when the daemon starts for the first time can
+be counterintuitive. To reduce the level of angst, see the <a
+href=quick.htm>Quick Start</a> page. A tutorial on debugging technique
+is in <A HREF="debug.htm">NTP Debugging Technique</A>.
<P>If problems peculiar to the particular hardware and software
environment (e.g. operating system -specific issues) are suspected,
-<HTML><HEAD><TITLE>
-Reference Clock Options
-</TITLE></HEAD><BODY><H3>
-Reference Clock Options
-</H3><HR>
-
-<H4>Reference Clock Support</H4>
-
-The NTP Version 4 daemon supports many different radio, satellite and
-modem reference clocks plus a special pseudo-clock used for backup or
-when no other clock source is available. Detailed descriptions of
-individual device drivers and options can be found in the <A
-HREF="refclock.htm">Reference Clock Drivers </A>page. Additional
-information can be found in the pages referenced there, including the <A
-HREF="rdebug.htm">Debugging Hints for Reference Clock Drivers</A> and <A
-HREF="howto.htm">How To Write a Reference Clock Driver</A> pages. In
-many drivers, support for a PPS signal is available as described in <A
-HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A> page. Many
-drivers support special line discipline/streams modules which can
-significantly improve the accuracy using the driver. These are described
-in the <A HREF="ldisc.htm">Line Disciplines and Streams Drivers</A>
-page.
-
-<P>A reference clock will generally (though not always) be a radio
-timecode receiver which is synchronized to a source of standard time
-such as the services offered by the NRC in Canada and NIST and USNO in
-the U.S. The interface between the computer and the timecode receiver is
-device dependent, but is usually a serial port. A device driver specific
-to each reference clock must be selected and compiled in the
-distribution; however, most common radio, satellite and modem clocks are
-included by default. Note that an attempt to configure a reference clock
-when the driver has not been included or the hardware port has not been
-appropriately configured results in a scalding remark to the system log
-file, but is otherwise non hazardous.
-
-<P>For the purposes of configuration, <TT>ntpd</TT> treats reference
-clocks in a manner analogous to normal NTP peers as much as possible.
-Reference clocks are identified by a syntactically correct but invalid
-IP address, in order to distinguish them from normal NTP peers.
-Reference clock addresses are of the form <TT>127.127.<I>t.u</I></TT>,
-where <I><TT>t</TT></I> is an integer denoting the clock type and
-<I><TT>u</TT></I> indicates the unit number. While it may seem overkill,
-it is in fact sometimes useful to configure multiple reference clocks of
-the same type, in which case the unit numbers must be unique.
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>Reference Clock Options
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+Reference Clock Options</H3>
+
+<HR>
+<H4>
+Reference Clock Support</H4>
+The NTP Version 4 daemon supports many different radio, satellite and modem
+reference clocks plus a special pseudo-clock used for backup or when no
+other clock source is available. Detailed descriptions of individual device
+drivers and options can be found in the <A HREF="refclock.htm">Reference
+Clock Drivers </A>page. Additional information can be found in the pages
+referenced there, including the <A HREF="rdebug.htm">Debugging Hints for
+Reference Clock Drivers</A> and <A HREF="howto.html">How To Write a Reference
+Clock Driver</A> pages. In many drivers, support for a PPS signal is available
+as described in <A HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A>
+page. Many drivers support special line discipline/streams modules which
+can significantly improve the accuracy using the driver. These are described
+in the <A HREF="ldisc.htm">Line Disciplines and Streams Drivers</A> page.
+
+<P>A reference clock will generally (though not always) be a radio timecode
+receiver which is synchronized to a source of standard time such as the
+services offered by the NRC in Canada and NIST and USNO in the U.S. The
+interface between the computer and the timecode receiver is device dependent,
+but is usually a serial port. A device driver specific to each reference
+clock must be selected and compiled in the distribution; however, most
+common radio, satellite and modem clocks are included by default. Note
+that an attempt to configure a reference clock when the driver has not
+been included or the hardware port has not been appropriately configured
+results in a scalding remark to the system log file, but is otherwise non
+hazardous.
+
+<P>For the purposes of configuration, <TT>ntpd</TT> treats reference clocks
+in a manner analogous to normal NTP peers as much as possible. Reference
+clocks are identified by a syntactically correct but invalid IP address,
+in order to distinguish them from normal NTP peers. Reference clock addresses
+are of the form <TT>127.127.<I>t.u</I></TT>, where <I><TT>t</TT></I> is
+an integer denoting the clock type and <I><TT>u</TT></I> indicates the
+unit number. While it may seem overkill, it is in fact sometimes useful
+to configure multiple reference clocks of the same type, in which case
+the unit numbers must be unique.
<P>The <TT>server</TT> command is used to configure a reference clock,
where the <I><TT>address</TT></I> argument in that command is the clock
address. The <TT>key</TT>, <TT>version</TT> and <TT>ttl</TT> options are
not used for reference clock support. The <TT>mode</TT> option is added
-for reference clock support, as described below. The <TT>prefer</TT>
-option can be useful to persuade the server to cherish a reference clock
-with somewhat more enthusiasm than other reference clocks or peers.
-Further information on this option can be found in the <A
-HREF="prefer.htm">Mitigation Rules and the <TT>prefer</TT> Keyword
-</A>page. The <TT>minpoll</TT> and <TT>maxpoll</TT> options have meaning
-only for selected clock drivers. See the individual clock driver
-document pages for additional information.
+for reference clock support, as described below. The <TT>prefer</TT> option
+can be useful to persuade the server to cherish a reference clock with
+somewhat more enthusiasm than other reference clocks or peers. Further
+information on this option can be found in the <A HREF="prefer.htm">Mitigation
+Rules and the <TT>prefer</TT> Keyword </A>page. The <TT>minpoll</TT> and
+<TT>maxpoll</TT> options have meaning only for selected clock drivers.
+See the individual clock driver document pages for additional information.
<P>The stratum number of a reference clock is by default zero. Since the
-<TT>ntpd</TT> daemon adds one to the stratum of each peer, a primary
-server ordinarily displays stratum one. In order to provide engineered
-backups, it is often useful to specify the reference clock stratum as
-greater than zero. The <TT>stratum</TT> option is used for this purpose.
-Also, in cases involving both a reference clock and a pulse-per-second
-(PPS) discipline signal, it is useful to specify the reference clock
-identifier as other than the default, depending on the driver. The
-<TT>refid</TT> option is used for this purpose. Except where noted,
-these options apply to all clock drivers.
-
-<H4>Reference Clock Commands</H4>
+<TT>ntpd</TT> daemon adds one to the stratum of each peer, a primary server
+ordinarily displays stratum one. In order to provide engineered backups,
+it is often useful to specify the reference clock stratum as greater than
+zero. The <TT>stratum</TT> option is used for this purpose. Also, in cases
+involving both a reference clock and a pulse-per-second (PPS) discipline
+signal, it is useful to specify the reference clock identifier as other
+than the default, depending on the driver. The <TT>refid</TT> option is
+used for this purpose. Except where noted, these options apply to all clock
+drivers.
+<H4>
+Reference Clock Commands</H4>
<DL>
+<DT>
+<TT>server 127.127.<I>t.u</I> [prefer] [mode <I>int</I>] [minpoll <I>int</I>]
+[maxpoll <I>int</I>]</TT></DT>
-<DT><TT>server 127.127.<I>t.u</I> [prefer] [mode <I>int</I>] [minpoll
-<I>int</I>] [maxpoll <I>int</I>]</TT></DT>
-<DD>This command can be used to configure reference clocks in special
-ways. The options are interpreted as follows:</DD>
-
-<DT><TT>prefer</TT></DT>
-<DD>Marks the reference clock as preferred. All other things being
-equal, this host will be chosen for synchronization among a set of
-correctly operating hosts. See the <A HREF="prefer.htm">Mitigation Rules
-and the <TT>prefer</TT> Keyword </A>page for further information.</DD>
-
-<DT><TT>mode <I>int</I></TT></DT>
-<DD>Specifies a mode number which is interpreted in a device-specific
-fashion. For instance, it selects a dialing protocol in the ACTS driver
-and a device subtype in the <TT>parse</TT> drivers.</DD>
-
-<DT><TT>minpoll <I>int</I></TT></DT>
-<DT><TT>maxpoll<I> int</I></TT></DT>
-<DD>These options specify the minimum and maximum polling interval for
-referenceclock messages, in seconds to the power of two. For most
-directly connected reference clocks, both <TT>minpoll</TT> and
-<TT>maxpoll</TT> default to 6 (64 s). For modem reference clocks,
-<TT>minpoll</TT> defaults to 10 (17.1 m) and <TT>maxpoll</TT> defaults
-to 14 (4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h)
-inclusive.</DD>
-
-<DT><TT>fudge 127.127.<I>t.u</I> [time1 <I>sec</I>] [time2 <I>sec</I>]
-[stratum <I>int</I>] [refid <I>string</I>] [mode <I>int</I>] [flag1 0|1]
-[flag2 0|1] [flag3 0|1] [flag4 0|1]</TT></DT>
-<DD>This command can be used to configure reference clocks in special
-ways. It must immediately follow the <TT>server</TT> command which
-configures the driver. Note that the same capability is possible at run
-time using the <TT><A HREF="ntpdc.htm">ntpdc</A></TT> program. The
-options are interpreted as follows:</DD>
-
-<DT><TT>time1 <I>sec</I></TT></DT>
-<DD>Specifies a constant to be added to the time offset produced by the
-driver, a fixed-point decimal number in seconds. This is used as a
-calibration constant to adjust the nominal time offset of a particular
-clock to agree with an external standard, such as a precision PPS
-signal. It also provides a way to correct a systematic error or bias due
-to serial port latencies, different cable lengths or receiver internal
-delay. The specified offset is in addition to the propagation delay
-provided by other means, such as internal DIP switches. Where a
-calibration for an individual system and driver is available, an
-approximate correction is noted in the driver documentation pages.</DD>
-
-<DT><TT>time2 <I>secs</I></TT></DT>
-<DD>Specifies a fixed-point decimal number in seconds, which is
-interpreted in a driver-dependent way. See the descriptions of specific
-drivers in the <A HREF="refclock.htm">reference clock drivers</A>
-page.</DD>
-
-<DT><TT>stratum <I>int</I></TT></DT>
-<DD>Specifies the stratum number assigned to the driver, an integer
-between 0 and 15. This number overrides the default stratum number
-ordinarily assigned by the driver itself, usually zero.</DD>
-
-<DT><TT>refid <I>string</I></TT></DT>
-<DD>Specifies an ASCII string of from one to four characters which
-defines the reference identifier used by the driver. This string
-overrides the default identifier ordinarily assigned by the driver
-itself.</DD>
-
-<DT><TT>mode <I>int</I></TT></DT>
-<DD>Specifies a mode number which is interpreted in a device-specific
-fashion. For instance, it selects a dialing protocol in the ACTS driver
-and a device subtype in the <TT>parse</TT> drivers.</DD>
-
-<DT><TT>flag1</TT> <TT>flag2</TT> <TT>flag3</TT> <TT>flag4</TT></DT>
-<DD>These four flags are used for customizing the clock driver. The
-interpretation of these values, and whether they are used at all, is a
-function of the particular clock driver. However, by convention
-<TT>flag4</TT> is used to enable recording verbose monitoring data to
-the <TT>clockstats</TT> file configured with the <TT>filegen</TT>
-command. Further information on the <TT>filegen</TT> command can be
-found in the <A HREF="monopt.htm">Monitoring Options </A>page.</DD>
-
-<DT><TT>pps <I>device</I></TT></DT>
-<DD>Specifies the name of the serial port device to which the PPS signal
-is connected. Note, this command replaces use of <TT>fudge flag3</TT>,
-which was used for the same purpose in NTPv3. Note also that this
-command should preceed the <TT>server</TT> and <TT>fudge</TT> command
-for the same device.</DD>
+<DD>
+This command can be used to configure reference clocks in special ways.
+The options are interpreted as follows:</DD>
+<DD>
+ </DD>
+
+<DL>
+<DT>
+<TT>prefer</TT></DT>
+
+<DD>
+Marks the reference clock as preferred. All other things being equal, this
+host will be chosen for synchronization among a set of correctly operating
+hosts. See the <A HREF="prefer.htm">Mitigation Rules and the <TT>prefer</TT>
+Keyword </A>page for further information.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>mode <I>int</I></TT></DT>
+
+<DD>
+Specifies a mode number which is interpreted in a device-specific fashion.
+For instance, it selects a dialing protocol in the ACTS driver and a device
+subtype in the <TT>parse</TT> drivers.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>minpoll <I>int</I></TT></DT>
+
+<DT>
+<TT>maxpoll<I> int</I></TT></DT>
+
+<DD>
+These options specify the minimum and maximum polling interval for reference
+clock messages, in seconds to the power of two. For most directly connected
+reference clocks, both <TT>minpoll</TT> and <TT>maxpoll</TT> default to
+6 (64 s). For modem reference clocks, <TT>minpoll</TT> defaults to 10 (17.1
+m) and <TT>maxpoll</TT> defaults to 14 (4.5 h). The allowable range is
+4 (16 s) to 17 (36.4 h) inclusive.</DD>
+</DL>
+
+<DT>
+<TT>fudge 127.127.<I>t.u</I> [time1 <I>sec</I>] [time2 <I>sec</I>] [stratum
+<I>int</I>] [refid <I>string</I>] [mode <I>int</I>] [flag1 0|1] [flag2
+0|1] [flag3 0|1] [flag4 0|1]</TT></DT>
+
+<DD>
+This command can be used to configure reference clocks in special ways.
+It must immediately follow the <TT>server</TT> command which configures
+the driver. Note that the same capability is possible at run time using
+the <TT><A HREF="ntpdc.htm">ntpdc</A></TT> program. The options are interpreted
+as follows:</DD>
+
+<DD>
+ </DD>
+
+<DL>
+<DT>
+<TT>time1 <I>sec</I></TT></DT>
+
+<DD>
+Specifies a constant to be added to the time offset produced by the driver,
+a fixed-point decimal number in seconds. This is used as a calibration
+constant to adjust the nominal time offset of a particular clock to agree
+with an external standard, such as a precision PPS signal. It also provides
+a way to correct a systematic error or bias due to serial port latencies,
+different cable lengths or receiver internal delay. The specified offset
+is in addition to the propagation delay provided by other means, such as
+internal DIPswitches. Where a calibration for an individual system and
+driver is available, an approximate correction is noted in the driver documentation
+pages.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>time2 <I>secs</I></TT></DT>
+
+<DD>
+Specifies a fixed-point decimal number in seconds, which is interpreted
+in a driver-dependent way. See the descriptions of specific drivers in
+the <A HREF="refclock.htm">reference clock drivers</A> page.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>stratum <I>int</I></TT></DT>
+
+<DD>
+Specifies the stratum number assigned to the driver, an integer between
+0 and 15. This number overrides the default stratum number ordinarily assigned
+by the driver itself, usually zero.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>refid <I>string</I></TT></DT>
+
+<DD>
+Specifies an ASCII string of from one to four characters which defines
+the reference identifier used by the driver. This string overrides the
+default identifier ordinarily assigned by the driver itself.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>mode <I>int</I></TT></DT>
+
+<DD>
+Specifies a mode number which is interpreted in a device-specific fashion.
+For instance, it selects a dialing protocol in the ACTS driver and a device
+subtype in the <TT>parse</TT> drivers.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>flag1</TT> <TT>flag2</TT> <TT>flag3</TT> <TT>flag4</TT></DT>
+
+<DD>
+These four flags are used for customizing the clock driver. The interpretation
+of these values, and whether they are used at all, is a function of the
+particular clock driver. However, by convention <TT>flag4</TT> is used
+to enable recording verbose monitoring data to the <TT>clockstats</TT>
+file configured with the <TT>filegen</TT> command. Further information
+on the <TT>filegen</TT> command can be found in the <A HREF="monopt.htm">Monitoring
+Options </A>page.</DD>
+
+<DD>
+ </DD>
</DL>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<DT>
+<TT>pps <I>device</I></TT></DT>
+
+<DD>
+Specifies the name of the serial port device to which the PPS signal is
+connected. Note, this command replaces use of <TT>fudge flag3</TT>, which
+was used for the same purpose in NTPv3. Note also that this command should
+preceed the <TT>server</TT> and <TT>fudge</TT> command for the same device.</DD>
+</DL>
+
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
<P>Usage: <TT>configure [options] [host]</TT>
<BR>Options: <TT>[defaults in brackets after descriptions]</TT>
-<PRE>
-Configuration
- --cache-file=FILE cache test results in FILE
- --help print this message
- --no-create do not create output files
- --quiet, --silent do not print `checking...' messages
- --version print the version of autoconf that created configure
-Directory and file names:
- --prefix=PREFIX install architecture-independent files in PREFIX
- [/usr/local]
- --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
- [same as prefix]
- --bindir=DIR user executables in DIR [EPREFIX/bin]
- --sbindir=DIR system admin executables in DIR [EPREFIX/sbin]
- --libexecdir=DIR program executables in DIR [EPREFIX/libexec]
- --datadir=DIR read-only architecture-independent data in DIR
- [PREFIX/share]
- --sysconfdir=DIR read-only single-machine data in DIR [PREFIX/etc]
- --sharedstatedir=DIR modifiable architecture-independent data in DIR
- [PREFIX/com]
- --localstatedir=DIR modifiable single-machine data in DIR [PREFIX/var]
- --libdir=DIR object code libraries in DIR [EPREFIX/lib]
- --includedir=DIR C header files in DIR [PREFIX/include]
- --oldincludedir=DIR C header files for non-gcc in DIR [/usr/include]
- --infodir=DIR info documentation in DIR [PREFIX/info]
- --mandir=DIR man documentation in DIR [PREFIX/man]
- --srcdir=DIR find the sources in DIR [configure dir or ..]
- --program-prefix=PREFIX prepend PREFIX to installed program names
- --program-suffix=SUFFIX append SUFFIX to installed program names
- --program-transform-name=PROGRAM
- run sed PROGRAM on installed program names
-Host type:
- --build=BUILD configure for building on BUILD [BUILD=HOST]
- --host=HOST configure for HOST [guessed]
- --target=TARGET configure for TARGET [TARGET=HOST]
-Features and packages:
- --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
- --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
- --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
- --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
- --x-includes=DIR X include files are in DIR
- --x-libraries=DIR X library files are in DIR
---enable and --with options recognized:
- --enable-debugging + include debugging code
- --enable-dst-minutes=60 + minutes per DST adjustment
- --enable-md5 + include support for MD5 keys
- --enable-des s include support for DES keys
- --enable-BANCOMM - Datum/Bancomm bc635/VME interface
- --enable-GPSVME - TrueTime GPS receiver/VME interface
- --enable-SHM - SHM clock attached thru shared memory
- --enable-ONCORE + Motorola VP/UT Oncore GPS receiver
- --enable-all-clocks + include all suitable non-PARSE clocks:
- --enable-ACTS + ACTS modem service
- --enable-ARBITER + Arbiter 1088A/B GPS receiver
- --enable-ARCRON-MSF + Arcron MSF receiver
- --enable-AS2201 + Austron 2200A/2201A GPS receiver
- --enable-ATOM + PPS interface
- --enable-CHU + CHU modem/decoder
- --enable-AUDIO-CHU s - CHU audio/decoder
- --enable-DATUM s Datum Programmable Time System
- --enable-HEATH s Heath GC-1000 WWV/WWVH receiver
- --enable-HPGPS + HP 58503A GPS receiver
- --enable-IRIG s Sun IRIG audio decoder
- --enable-LEITCH + Leitch CSD 5300 Master Clock System Driver
- --enable-LOCAL-CLOCK + local clock reference
- --enable-MSFEES + EES M201 MSF receiver
- --enable-MX4200 s Magnavox MX4200 GPS receiver
- --enable-NMEA + NMEA GPS receiver
- --enable-PALISADE + Palisade clock
- --enable-PST + PST/Traconex 1020 WWV/WWVH receiver
- --enable-JUPITER s Rockwell Jupiter GPS receiver
- --enable-PTBACTS s PTB modem service
- --enable-TPRO s KSI/Odetics TPRO/S GPS receiver/IRIG interface
- --enable-TRAK + TRAK 8810 GPS receiver
- --enable-CHRONOLOG + Chrono-log K-series WWVB receiver
- --enable-DUMBCLOCK + Dumb generic hh:mm:ss local clock
- --enable-TRUETIME s Kinemetrics/TrueTime receivers
- --enable-WWVB + Spectracom 8170/Netclock/2 WWVB receiver
- --enable-USNO s USNO modem service
- --enable-parse-clocks - include all suitable PARSE clocks:
- --enable-COMPUTIME s Diem Computime Radio Clock
- --enable-DCF7000 s ELV/DCF7000 clock
- --enable-HOPF6021 s HOPF 6021 clock
- --enable-MEINBERG s Meinberg clocks
- --enable-RAWDCF s DCF77 raw time code
- --enable-RCC8000 s RCC 8000 clock
- --enable-SCHMID s Schmid DCF77 clock
- --enable-TRIMTAIP s Trimble GPS receiver/TAIP protocol
- --enable-TRIMTSIP s Trimble GPS receiver/TSIP protocol
- --enable-WHARTON s WHARTON 400A Series clock
- --enable-kmem s read /dev/kmem for tick and/or tickadj
- --enable-accurate-adjtime
- s the adjtime() call is accurate
- --enable-tick=VALUE s force a value for 'tick'
- --enable-tickadj=VALUE s force a value for 'tickadj'
- --enable-udp-wildcard s use UDP wildcard delivery
- --enable-slew-always s always slew the time
- --enable-step-slew s step and slew the time
- --enable-ntpdate-step s if ntpdate should step the time
- --enable-hourly-todr-sync
- s if we should sync TODR hourly
- --enable-kernel-fll-bug s if we should avoid a kernel FLL bug
-</PRE>
+<PRE>Configuration
+
+ --cache-file=FILE cache test
+results in FILE
+ --
+help &n
+bsp; print this message
+ --no-
+create
+do not create output files
+ --quiet, --silent do not print
+`checking...' messages
+ --
+version  
+; print the version of autoconf that created
+
+
+configure
+Directory and file names
+
+ --prefix=PREFIX install
+architecture-independent files in
+
+
+PREFIX [/usr/local]
+ --exec-prefix=EPREFIX install architecture-dependent files
+in EPREFIX
+
+
+[same as prefix]
+ --
+bindir=DIR
+user executables in DIR [EPREFIX/bin]
+ --
+sbindir=DIR system
+admin executables in DIR [EPREFIX/sbin]
+ --libexecdir=DIR program
+executables in DIR [EPREFIX/libexec]
+ --
+datadir=DIR read-
+only architecture-independent data in DIR
+
+
+[PREFIX/share]
+ --sysconfdir=DIR read-only
+single-machine data in DIR
+
+
+[PREFIX/etc]
+ --sharedstatedir=DIR modifiable architecture-
+independent data in DIR
+
+
+[PREFIX/com]
+ --localstatedir=DIR modifiable single-machine
+data in DIR
+
+
+[PREFIX/var]
+ --
+libdir=DIR
+object code libraries in DIR [EPREFIX/lib]
+ --includedir=DIR C header
+files in DIR [PREFIX/include]
+ --oldincludedir=DIR C header files for non-gcc
+in DIR
+
+
+[/usr/include]
+ --
+infodir=DIR info
+documentation in DIR [PREFIX/info]
+ --
+mandir=DIR
+man documentation in DIR [PREFIX/man]
+ --
+srcdir=DIR
+find the sources in DIR [configure dir or ..]
+ --program-prefix=PREFIX prepend PREFIX to installed program names
+ --program-suffix=SUFFIX append SUFFIX to installed program names
+ --program-transform-name=PROGRAM run sed PROGRAM on installed
+program
+
+
+names
+Host type
+
+ --
+build=BUILD
+configure for building on BUILD [BUILD=HOST]
+ --
+host=HOST &nb
+sp; configure for HOST [guessed]
+ --target=TARGET
+configure for TARGET [TARGET=HOST]</PRE>
+
+<PRE>Features and packages
+
+ --disable-FEATURE do not include
+FEATURE (same as --enable-
+
+
+FEATURE=no)
+ --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
+ --without-PACKAGE do not use
+PACKAGE (same as --with-PACKAGE=no)
+ --x-includes=DIR X include
+files are in DIR
+ --x-libraries=DIR X library files
+are in DIR
+
+--enable- and --disable- with options recognized
+
+
+debugging
+Include debugging code [enable]
+ gdt-
+surveying Include GDT survey code
+[disable]
+
+md5 &nb
+sp; Include support for MD5 keys [enable]
+
+des &nb
+sp; Include support for DES keys [enable]
+ all-
+clocks Include
+drivers for all reference clocks
+
+
+[enable]
+
+ Radio Clocks (these are ordinarily enabled, if supported by the
+
+
+machine and operating system)
+
+
+ACTS &n
+bsp; NIST dialup clock
+
+ARBITER  
+; Arbiter 1088A/B GPS receiver
+
+AS2201
+ Austron 2200A or 2201A GPS receiver
+
+ATOM &n
+bsp; ATOM clock
+
+BANCOMM  
+; BANCOMM clock
+
+CHU &nb
+sp; CHU clock
+
+DATUM &
+nbsp; Datum Programmable Time System
+
+DCF7000  
+; ELV/DCF7000
+
+GPSVME
+ GPS-VME Clock
+
+HEATH &
+nbsp; HeathKit GC-1000 Most Accurate Clock
+
+HOPF6021 &nbs
+p; HOPF6021 Radio Clock support
+
+HPGPS &
+nbsp; HP 58503A GPS Time & Frequency receiver
+
+IRIG &n
+bsp; IRIG (Audio) Clock
+
+LEITCH
+ Leitch CSD 5300 Master Clock System Driver
+ LOCAL-
+CLOCK Local Clock driver
+
+MEINBERG &nbs
+p; Meinberg clocks
+
+MSFEES
+ MSFEES clock
+
+MOTO &n
+bsp; Motorola GPS clock
+
+MX4200
+ MX4200 clock
+
+NMEA &n
+bsp; NMEA GPS clock
+
+PARSE &
+nbsp; PARSE clock code
+
+PST &nb
+sp; PST/Traconex 1020 WWV/H receiver
+
+PTBACTS  
+; PTB dialup clock support
+
+RAWDCF
+ use raw DCF77 time code
+
+RCC8000  
+; RCC8000 Radio Clock support
+
+SCHMID
+ SCHMID DCF77 clock support
+
+TRAK &n
+bsp; TRAK 8810 GPS station clock
+
+TPRO &n
+bsp; KSI/Odetics TPRO/S IRIG Interface
+
+TRIMTAIP &nbs
+p; Trimble GPS/TAIP Protocol
+
+TRIMTSIP &nbs
+p; Trimble GPS/TSIP Protocol
+
+TRUETIME &nbs
+p; Kinemetrics/TrueTime (generic) receiver
+
+WWVB &n
+bsp; Spectracom 8170 or Netclock/2 WWVB receiver
+
+USNO &n
+bsp; US Naval Observatory dialup clock
+ Miscellany
+
+ accurate-adjtime The
+adjtime() call is accurate
+
+kmem &n
+bsp; Read kmem
+
+tick=VALUE Force a
+value for 'tick'
+
+tickadj=VALUE Force a value for
+'tickadj'
+ udp-
+wildcard Use UDP wildcard
+delivery
+ slew-
+always Always slew the
+time
+ step-
+slew Step
+and slew the time
+ ntpdate-
+step If ntpdate should step
+the time
+ hourly-todr-sync If we should
+sync TODR hourly</PRE>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
-<html><head><title>
-Configuration Options
-</title></head><body><h3>
-Configuration Options
-</h3><hr>
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+
+<head>
+<meta http-equiv="Content-Type"
+content="text/html; charset=iso-8859-1">
+<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
+<title>Configuration Options </title>
+</head>
+
+<body>
+
+<h3>Configuration Options</h3>
+
+<hr>
<h4>Configuration Support</h4>
D), or (r) a reference clock address (127.127.x.x). Note that,
while autokey and burst modes are supported by these commands,
their effect in some weird mode combinations can be meaningless
-or even destructive.
-
-<dl>
-
-<dt><tt>peer </tt><i><tt>address</tt></i><tt> [autokey | key
-</tt><i><tt>key</tt></i><tt>] [burst] [version
-</tt><i><tt>version</tt></i><tt>] [prefer] [minpoll
-</tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt> </tt></i><tt>[maxpoll
-</tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
-
-<dt><tt>server </tt><i><tt>address</tt></i><tt> [autokey | key
-</tt><i><tt>key</tt></i><tt>] [burst] [version
-</tt><i><tt>version</tt></i><tt>] [prefer] [minpoll
-</tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt> </tt></i><tt>[maxpoll
-</tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
-
-<dt><tt>broadcast </tt><i><tt>address</tt></i><tt> [autokey | key
-</tt><i><tt>key</tt></i><tt>] [burst] [version
-</tt><i><tt>version</tt></i><tt>] [minpoll
-</tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt> </tt></i><tt>[maxpoll
-</tt><i><tt>maxpoll</tt></i><tt>] [ttl
-</tt><i><tt>ttl</tt></i><tt>]</tt></dt>
-
-<dt><tt>manycastclient </tt><i><tt>address</tt></i><tt> [autokey |
-key</tt><i><tt>key</tt></i><tt>] [burst] [version
-</tt><i><tt>version</tt></i><tt>] [minpoll </tt><i><tt>minpoll
-</tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>] [ttl
-</tt><i><tt>ttl</tt></i><tt>]</tt></dt>
-
-<dd>These four commands specify the time server name or address to be
-used and the mode in which to operate. The <i><tt>address</tt></i><tt>
-</tt>can be either a DNS name or a IP address in dotted-quad notation.
-Additional information on association behavior can be found in the <a
-href="assoc.htm">Association Management</a> page.</dd>
-
-<dd>
+or even destructive.</p>
<dl>
-
-<dt><tt>server</tt></dt>
-<dd>For type s and r addresses, this operates as the NTPv3 server
-command, which mobilizes a persistent client mode association. The
-<tt>server</tt> command specifies that the local server is to operate in
-client mode with the specified remote server. In this mode, the local
-server can be synchronized to the remote server, but the remote server
-can never be synchronized to the local server.</dd>
-
-<dt><tt>peer</tt></dt>
-<dd>For type s addresses (only), this operates as the current <tt>peer
-</tt>command, which mobilizes a persistent symmetric-active mode
-association, except that additional modes are available. This command
-should NOT be used for type b, m or r addresses.
-
-<p>The <tt>peer</tt> command specifies that the local server is to
-operate in symmetric active mode with the remote server. In this mode,
-the local server can be synchronized to the remote server and, in
-addition, the remote server can be synchronized by the local server.
-This is useful in a network of servers where, depending on various
-failure scenarios, either the local or remote server may be the better
-source of time.</dd>
-
-<dt><tt>broadcast</tt></dt>
-<dd>For type b and m addresses (only), this operates as the current
-NTPv3 <tt>broadcast</tt> command, which mobilizes a persistent broadcast
-mode association, except that additional modes are available. Multiple
-commands can be used to specify multiple local broadcast interfaces
-(subnets) and/or multiple multicast groups. Note that local broadcast
-messages go only to the interface associated with the subnet specified,
-but multicast messages go to all interfaces. In the current
-implementation, the source address used for these messages is the Unix
-host default address.
-
-<p>In broadcast mode, the local server sends periodic broadcast
-messages to a client population at the <i><tt>address
-</tt></i>specified, which is usually the broadcast address on (one of)
-the local network(s) or a multicast address assigned to NTP. The IANA
-has assigned the multicast group address 224.0.1.1 exclusively to NTP,
-but other nonconflicting addresses can be used to contain the messages
-within administrative boundaries. Ordinarily, this specification
-applies only to the local server operating as a sender; for operation as
-a broadcast client, see the <tt>broadcastclient</tt> or
-<tt>multicastclient</tt> commands below.</dd>
-
-<dt><tt>manycastclient</tt> </dt>
-<dd>For type m addresses (only), this mobilizes a manycast client-mode
-association for the multicast address specified. In this case a specific
-address must be supplied which matches the address used on the
-<tt>manycastserver </tt>command for the designated manycast servers. The
-NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used,
-unless specific means are taken to avoid spraying large areas of the
-Internet with these messages and causing a possibly massive implosion of
-replies at the sender.</dd>
-
-<dd>The <tt>manycastclient</tt> command specifies that the local server is to
-operate in client mode with the remote servers that are discovered as the
-result of broadcast/multicast messages. The client broadcasts a request
-message to the group address associated with the specified
-<i><tt>address </tt></i>and specifically enabled servers respond to
-these messages. The client selects the servers providing the best time
-and continues as with the <tt>server </tt>command. The remaining servers
-are discarded as if never heard.</dd>
-
-</dl></dd>
-
-<dd>Options</dd>
-
-<dd><dl>
-
-<dt><tt>autokey</tt></dt>
-<dd>All packets sent to the address are to include authentication fields
-encrypted using the autokey scheme.</dd>
-
-<dt><tt>burst</tt></dt>
-<dd>At each poll interval, send a burst of eight packets spaced, instead
-of the usual one.</dd>
-
-<dt><tt>key</tt> <i><tt>key</tt></i></dt>
-<dd>All packets sent to the address are to include authentication fields
-encrypted using the specified <i>key</i> identifier, which is an
-unsigned 32-bit integer less than 65536. The default is to include no
-encryption field.</dd>
-
-<dt><tt>version</tt> <i><tt>version</tt></i></dt>
-<dd>Specifies the version number to be used for outgoing NTP packets.
-Versions 1-4 are the choices, with version 4 the default.</dd>
-
-<dt><tt>prefer</tt></dt>
-<dd>Marks the server as preferred. All other things being equal, this
-host will be chosen for synchronization among a set of correctly
-operating hosts. See the <a href="prefer.htm">Mitigation Rules and the
-<tt>prefer</tt> Keyword </a>page for further information.</dd>
-
-<dt><tt>ttl</tt> <i><tt>ttl</tt></i></dt>
-<dd>This option is used only with broadcast mode. It specifies the time-
-to-live <i><tt>ttl</tt></i> to use on multicast packets. Selection of
-the proper value, which defaults to 127, is something of a black art and
-must be coordinated with the network administrator.</dd>
-
-<dt><tt>minpoll</tt> <i><tt>minpoll</tt></i></dt>
-<dt><tt>maxpoll</tt> <i><tt>maxpoll</tt></i></dt>
-<dd>These options specify the minimum and maximum polling intervals for
-NTP messages, in seconds to the power of two. The default range is 6 (64
-s) to 10 (1,024 s).The allowable range is 4 (16 s) to 17 (36.4 h)
-inclusive.</dd>
-
-</dl></dd>
-
-<dt><tt>broadcastclient</tt></dt>
-<dd>This command directs the local server to listen for and respond to
-broadcast messages received on any local interface. Upon hearing a
-broadcast message for the first time, the local server measures the
-nominal network delay using a brief client/server exchange with the
-remote server, then enters the broadcastclient mode, in which it listens
-for and synchronizes to succeeding broadcast messages. Note that, in
-order to avoid accidental or malicious disruption in this mode, both the
-local and remote servers should operate using authentication and the
-same trusted key and key identifier.</dd>
-
-<dt><tt>multicastclient [</tt><i><tt>address</tt></i><tt>]
-[...]</tt></dt>
-<dd>This command directs the local server to listen for multicast
-messages at the group address(es) of the global network. The default
-address is that assigned by the Numbers Czar to NTP (224.0.1.1). This
-command operates in the same way as the <tt>broadcastclient</tt>
-command, but uses IP multicasting. Support for this command requires a
- multicast kernel.</dd>
-
-<dt><tt>driftfile</tt> <i><tt>driftfile</tt></i></dt>
-<dd>This command specifies the name of the file used to record the
-frequency offset of the local clock oscillator. If the file exists, it
-is read at startup in order to set the initial frequency offset and then
-updated once per hour with the current frequency offset computed by the
-daemon. If the file does not exist or this command is not given, the
-initial frequency offset is assumed zero. In this case, it may take some
-hours for the frequency to stabilize and the residual timing errors to
-subside.
-
-<p>The file format consists of a single line containing a single
-floating point number, which records the frequency offset measured in
-parts-per-million (PPM). The file is updated by first writing the
-current drift value into a temporary file and then renaming this file to
-replace the old version. This implies that <tt>ntpd</tt> must have
- write permission for the directory the drift file is located in, and
-that file system links, symbolic or otherwise, should be avoided.</dd>
-
-<dt><tt>manycastserver</tt> <i><tt>address</tt></i><tt>[...]</tt></dt>
-<dd>This command directs the local server to listen for and respond to
-broadcast messages received on any local interface, and in addition
-enables the server to respond to client mode messages to the multicast
-group address(es) (type m) specified. At least one address is required,
-but the NTP multicast address 224.0.1.1 assigned by the IANA should NOT
-be used, unless specific means are taken to limit the span of the reply
-and avoid a possibly massive implosion at the original sender.</dd>
-
-<dt><tt>revoke [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
-<dd>Specifies the interval between recomputations of the private value
-used with the autokey feature, which ordinarily requires an expensive
-public-key computation. The default value is 12 (65,536 s or about 18
-hours). For poll intervals above the specified interval, a new private
-value will be recomputed for every message sent.</dd>
-
-<dt><tt>autokey [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
-<dd>Specifies the interval between regenerations of the session key list
-used with the autokey feature. Note that the size of the key list for
-each association depends on this interval and the current poll interval.
-The default value is 12 (4096 s or about 1.1 hours). For poll intervals
-above the specified interval, a session key list with a single entry
-will be regenerated for every message sent.</dd>
-
-<dt><tt>enable [auth | bclient | kernel | monitor | ntp |
-stats]</tt></dt>
-<dt><tt>disable [auth | bclient | kernel | monitor | ntp |
-stats]</tt></dt>
-<dd>Provides a way to enable or disable various server options. Flags
-not mentioned are unaffected. Note that all of these flags can be
-controlled remotely using the <a href="ntpdc.htm"><tt>ntpdc</tt></a>
-utility program.</dd>
-
-<dd><dl>
-
-<dt><tt>auth</tt></dt>
-<dd>Enables the server to synchronize with unconfigured peers only if
-the peer has been correctly authenticated using a trusted key and
-key identifier. The default for this flag is enable.</dd>
-
-<dt><tt>bclient</tt></dt>
-<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
-command. The default for this flag is disable.</dd>
-
-<dt><tt>kernel</tt></dt>
-<dd>Enables the precision-time kernel support for the
-<tt>ntp_adjtime()</tt> system call, if implemented. Ordinarily, support
-for this routine is detected automatically when the NTP daemon is
-compiled, so it is not necessary for the user to worry about this flag.
-It flag is provided primarily so that this support can be disabled
-during kernel development.</dd>
-
-<dt><tt>monitor</tt></dt>
-<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program and
-the <tt>monlist</tt> command for further information. The default for
-this flag is enable.</dd>
-
-<dt><tt>ntp</tt></dt>
-<dd>Enables the server to adjust its local clock by means of NTP. If
-disabled, the local clock free-runs at its intrinsic time and frequency
-offset. This flag is useful in case the local clock is controlled by
-some other device or protocol and NTP is used only to provide
-synchronization to other clients. In this case, the local clock driver
-can be used to provide this function and also certain time variables for
-error estimates and leap-indicators. See the <a
-href="refclock.htm">Reference Clock Drivers </a>page for further
-information. The default for this flag is enable.</dd>
-
-<dt><tt>stats</tt></dt>
-<dd>Enables the statistics facility. See the <a
-href="monopt.htm">Monitoring Options </a>page for further information.
-The default for this flag is enable.</dd>
-
-</dl></dd></dl>
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+ <dt><tt>peer </tt><i><tt>address</tt></i><tt> [autokey | key </tt><i><tt>key</tt></i><tt>]
+ [burst] [version </tt><i><tt>version</tt></i><tt>]
+ [prefer] [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt>
+ </tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
+ <dd> </dd>
+ <dt><tt>server </tt><i><tt>address</tt></i><tt> [autokey |
+ key </tt><i><tt>key</tt></i><tt>] [burst] [version </tt><i><tt>version</tt></i><tt>]
+ [prefer] [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt>
+ </tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
+ <dd> </dd>
+ <dt><tt>broadcast </tt><i><tt>address</tt></i><tt> [autokey |
+ key </tt><i><tt>key</tt></i><tt>] [burst] [version </tt><i><tt>version</tt></i><tt>]
+ [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt> </tt></i><tt>[maxpoll
+ </tt><i><tt>maxpoll</tt></i><tt>] [ttl </tt><i><tt>ttl</tt></i><tt>]</tt></dt>
+ <dd> </dd>
+ <dt><tt>manycastclient </tt><i><tt>address</tt></i><tt>
+ [autokey | key </tt><i><tt>key</tt></i><tt>] [burst]
+ [version </tt><i><tt>version</tt></i><tt>] [minpoll </tt><i><tt>minpoll
+ </tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]
+ [ttl </tt><i><tt>ttl</tt></i><tt>]</tt></dt>
+ <dd> </dd>
+ <dd>These four commands specify the time server name or
+ address to be used and the mode in which to operate. The <i><tt>address</tt></i><tt>
+ </tt>can be either a DNS name or a IP address in
+ dotted-quad notation. Additional information on
+ association behavior can be found in the <a
+ href="assoc.htm">Association Management</a> page.</dd>
+ <dd> </dd>
+ <dd><dl>
+ <dt><tt>server</tt></dt>
+ <dd>For type s and r addresses, this operates as the
+ NTPv3 server command, which mobilizes a
+ persistent client mode association. The <tt>server</tt>
+ command specifies that the local server is to
+ operate in client mode with the specified remote
+ server. In this mode, the local server can be
+ synchronized to the remote server, but the remote
+ server can never be synchronized to the local
+ server.</dd>
+ <dd> </dd>
+ <dt><tt>peer</tt></dt>
+ <dd>For type s addresses (only), this operates as the
+ current <tt>peer </tt>command, which mobilizes a
+ persistent symmetric-active mode association,
+ except that additional modes are available. This
+ command should NOT be used for type b, m or r
+ addresses.</dd>
+ <dd> </dd>
+ <dd>The <tt>peer</tt> command specifies that the
+ local server is to operate in symmetric active
+ mode with the remote server. In this mode, the
+ local server can be synchronized to the remote
+ server and, in addition, the remote server can be
+ synchronized by the local server. This is useful
+ in a network of servers where, depending on
+ various failure scenarios, either the local or
+ remote server may be the better source of time.</dd>
+ <dd> </dd>
+ <dt><tt>broadcast</tt></dt>
+ <dd>For type b and m addresses (only), this is
+ operates as the current NTPv3 <tt>broadcast </tt>command,
+ which mobilizes a persistent broadcast mode
+ association, except that additional modes are
+ available. Multiple commands can be used to
+ specify multiple local broadcast interfaces
+ (subnets) and/or multiple multicast groups. Note
+ that local broadcast messages go only to the
+ interface associated with the subnet specified,
+ but multicast messages go to all interfaces. In
+ the current implementation, the source address
+ used for these messages is the Unix host default
+ address.</dd>
+ <dd> </dd>
+ <dd>In broadcast mode, the local server sends
+ periodic broadcast messages to a client
+ population at the <i><tt>address </tt></i>specified,
+ which is usually the broadcast address on (one
+ of) the local network(s) or a multicast address
+ assigned to NTP. The IANA has assigned the
+ multicast group address 224.0.1.1 exclusively to
+ NTP, but other nonconflicting addresses can be
+ used to contain the messages within
+ administrative boundaries.. Ordinarily, this
+ specification applies only to the local server
+ operating as a sender; for operation as a
+ broadcast client, see the <tt>broadcastclient</tt>
+ or <tt>multicastclient</tt> commands below.</dd>
+ <dd> </dd>
+ <dt><tt>manycastclient</tt> </dt>
+ <dd>For type m addresses (only), this mobilizes a
+ manycast client-mode association for the
+ multicast address specified. In this case a
+ specific address must be supplied which matches
+ the address used on the <tt>manycastserver </tt>command
+ for the designated manycast servers. The NTP
+ multicast address 224.0.1.1 assigned by the IANA
+ should NOT be used, unless specific means are
+ taken to avoid spraying large areas of the
+ Internet with these messages and causing a
+ possibly massive implosion of replies at the
+ sender. </dd>
+ <dd> </dd>
+ <dd>The <tt>manycast </tt>command specifies that the
+ local server is to operate in client mode with
+ the remote server that are discovered as the
+ result of broadcast/multicast messages. The
+ client broadcasts a request message to the group
+ address associated with the specified <i><tt>address
+ </tt></i>and specifically enabled servers respond
+ to these messages. The client selects the servers
+ providing the best time and continues as with the
+ <tt>server </tt>command. The remaining servers
+ are discarded as if never heard.</dd>
+ <dd> </dd>
+ </dl>
+ </dd>
+ <dd>Options</dd>
+ <dd> </dd>
+ <dd><dl>
+ <dt><tt>autokey</tt></dt>
+ <dd>All packets sent to the address are to include
+ authentication fields encrypted using the autokey
+ scheme.</dd>
+ <dd> </dd>
+ <dt><tt>burst</tt></dt>
+ <dd>At each poll interval, send a burst of eight
+ packets spaced, instead of the usual one.</dd>
+ <dd> </dd>
+ <dt><tt>key </tt><i><tt>key</tt></i></dt>
+ <dd>All packets sent to the address are to include
+ authentication fields encrypted using the
+ specified <i>key</i> identifier, which is an
+ unsigned 32-bit integer less than 65536. The
+ default is to include no encryption field.</dd>
+ <dd> </dd>
+ <dt><tt>version </tt><i><tt>version</tt></i></dt>
+ <dd>Specifies the version number to be used for
+ outgoing NTP packets. Versions 1-4 are the
+ choices, with version 4 the default.</dd>
+ <dd> </dd>
+ <dt><tt>prefer</tt></dt>
+ <dd>Marks the server as preferred. All other things
+ being equal, this host will be chosen for
+ synchronization among a set of correctly
+ operating hosts. See the <a href="prefer.htm">Mitigation
+ Rules and the <tt>prefer</tt> Keyword </a>page
+ for further information.</dd>
+ <dd> </dd>
+ <dt><tt>ttl </tt><i><tt>ttl</tt></i></dt>
+ <dd>This option is used only with broadcast mode. It
+ specifies the time-to-live <i><tt>ttl</tt></i> to
+ use on multicast packets. Selection of the proper
+ value, which defaults to 127, is something of a
+ black art and must be coordinated with the
+ network administrator.</dd>
+ <dd> </dd>
+ <dt><tt>minpoll </tt><i><tt>minpoll</tt></i></dt>
+ <dt><tt>maxpoll </tt><i><tt>maxpoll</tt></i></dt>
+ <dd>These options specify the minimum and maximum
+ polling intervals for NTP messages, in seconds to
+ the power of two. The default range is 6 (64 s)
+ to 10 (1,024 s).The allowable range is 4 (16 s)
+ to 17 (36.4 h) inclusive.</dd>
+ <dd> </dd>
+ </dl>
+ </dd>
+ <dt><tt>broadcastclient</tt></dt>
+ <dd>This command directs the local server to listen for and
+ respond to broadcast messages received on any local
+ interface. Upon hearing a broadcast message for the first
+ time, the local server measures the nominal network delay
+ using a brief client/server exchange with the remote
+ server, then enters the broadcastclient mode, in which it
+ listens for and synchronizes to succeeding broadcast
+ messages. Note that, in order to avoid accidental or
+ malicious disruption in this mode, both the local and
+ remote servers should operate using authentication and
+ the same trusted key and key identifier.</dd>
+ <dd> </dd>
+ <dt><tt>multicastclient [</tt><i><tt>address</tt></i><tt>]
+ [...]</tt></dt>
+ <dd>This command directs the local server to listen for
+ multicast messages at the group address(es) of the global
+ network. The default address is that assigned by the
+ Numbers Czar to NTP (224.0.1.1). This command operates in
+ the same way as the <tt>broadcastclient</tt> command, but
+ uses IP multicasting. Support for this command requires a
+ multicast kernel.</dd>
+ <dd> </dd>
+ <dt><tt>driftfile </tt><i><tt>driftfile</tt></i></dt>
+ <dd>This command specifies the name of the file used to
+ record the frequency offset of the local clock
+ oscillator. If the file exists, it is read at startup in
+ order to set the initial frequency offset and then
+ updated once per hour with the current frequency offset
+ computed by the daemon. If the file does not exist or
+ this command is not given, the initial frequency offset
+ is assumed zero. In this case, it may take some hours for
+ the frequency to stabilize and the residual timing errors
+ to subside.</dd>
+ <dd> </dd>
+ <dd>The file format consists of a single line containing a
+ single floating point number, which records the frequency
+ offset measured in parts-per-million (PPM). The file is
+ updated by first writing the current drift value into a
+ temporary file and then renaming this file to replace the
+ old version. This implies that <tt>ntpd</tt> must have
+ write permission for the directory the drift file is
+ located in, and that file system links, symbolic or
+ otherwise, should be avoided.</dd>
+ <dd> </dd>
+ <dt><tt>manycastserver </tt><i><tt>address </tt></i><tt>[...]</tt></dt>
+ <dd>This command directs the local server to listen for and
+ respond to broadcast messages received on any local
+ interface, and in addition enables the server to respond
+ to client mode messages to the multicast group
+ address(es) (type m) specified. At least one address is
+ required, but The NTP multicast address 224.0.1.1
+ assigned by the IANA should NOT be used, unless specific
+ means are taken to limit the span of the reply and avoid
+ a possibly massive implosion at the original sender.</dd>
+ <dd> </dd>
+ <dt><tt>revoke [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
+ <dd>Specifies the interval between recomputations of the
+ private value used with the autokey feature, which
+ ordinarily requires an expensive public- key computation.
+ The default value is 12 (65,536 s or about 18 hours). For
+ poll intervals above the specified interval, a new
+ private value will be recomputed for every message sent.</dd>
+ <dd> </dd>
+ <dt><tt>autokey [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
+ <dd>Specifies the interval between regenerations of the
+ session key list used with the autokey feature. Note that
+ the size of the key list for each association depends on
+ this interval and the current poll interval. The default
+ value is 12 (4096 s or about 1.1 hours). For poll
+ intervals above the specified interval, a session key
+ list with a single entry will be regenerated for every
+ message sent.</dd>
+ <dd> </dd>
+ <dt><tt>enable [auth | bclient | kernel | monitor | ntp |
+ stats]</tt></dt>
+ <dt><tt>disable [auth | bclient | kernel | monitor | ntp |
+ stats</tt><font face="Courier New">] </font></dt>
+ <dd>Provides a way to enable or disable various server
+ options. Flags not mentioned are unaffected. Note that
+ all of these flags can be controlled remotely using the <a
+ href="ntpdc.htm"><tt>ntpdc</tt></a> utility program.</dd>
+ <dd> </dd>
+ <dd><dl>
+ <dt><tt>auth</tt></dt>
+ <dd>Enables the server to synchronize with
+ unconfigured peers only if the peer has been
+ correctly authenticated using a trusted key and
+ key identifier. The default for this flag is
+ enable.</dd>
+ <dd> </dd>
+ <dt><tt>bclient</tt></dt>
+ <dd>When enabled, this is identical to the <tt>broadcastclient</tt>
+ command. The default for this flag is disable.</dd>
+ <dd> </dd>
+ <dt><tt>kernel</tt></dt>
+ <dd>Enables the precision-time kernel support for the
+ <tt>ntp_adjtime()</tt> system call, if
+ implemented. Ordinarily, support for this routine
+ is detected automatically when the NTP daemon is
+ compiled, so it is not necessary for the user to
+ worry about this flag. It flag is provided
+ primarily so that this support can be disabled
+ during kernel development.</dd>
+ <dd> </dd>
+ <dt><tt>monitor</tt></dt>
+ <dd>Enables the monitoring facility. See the <tt>ntpdc</tt>
+ program and the <tt>monlist</tt> command or
+ further information. The default for this flag is
+ enable.</dd>
+ <dd> </dd>
+ <dt><tt>ntp</tt></dt>
+ <dd>Enables the server to adjust its local clock by
+ means of NTP. If disabled, the local clock
+ free-runs at its intrinsic time and frequency
+ offset. This flag is useful in case the local
+ clock is controlled by some other device or
+ protocol and NTP is used only to provide
+ synchronization to other clients. In this case,
+ the local clock driver can be used to provide
+ this function and also certain time variables for
+ error estimates and leap-indicators. See the <a
+ href="refclock.htm">Reference Clock Drivers </a>page
+ for further information. The default for this
+ flag is enable.</dd>
+ <dd> </dd>
+ <dt><tt>stats</tt></dt>
+ <dd>Enables the statistics facility. See the <a
+ href="monopt.htm">Monitoring Options </a>page for
+ further information. The default for this flag is
+ enable.</dd>
+ <dd> </dd>
+ </dl>
+ </dd>
+</dl>
+
+<hr>
+
+<address>
+ David L. Mills (mills@udel.edu)
+</address>
+</body>
+</html>
<P>The following copyright notice applies to all files collectively called the Network Time Protocol Version 4 Distribution. Unless specifically declared otherwise in an individual file, this notice applies as if the text was explicitly included in the file.
<br>
-<PRE>
-/***********************************************************************
- * *
- * Copyright (c) David L. Mills 1992-1998 *
- * *
- * Permission to use, copy, modify, and distribute this software and *
- * its documentation for any purpose and without fee is hereby *
- * granted, provided that the above copyright notice appears in all *
- * copies and that both the copyright notice and this permission *
- * notice appear in supporting documentation, and that the name *
- * University of Delaware not be used in advertising or publicity *
- * pertaining to distribution of the software without specific, *
- * written prior permission. The University of Delaware makes no *
- * representations about the suitability this software for any *
- * purpose. It is provided "as is" without express or implied *
- * warranty. *
- **********************************************************************/
-</PRE>
+<PRE>/***********************************************************************
+ * *
+ * Copyright (c) David L. Mills 1992-1998 *
+ * *
+ * Permission to use, copy, modify, and distribute this software and *
+ * its documentation for any purpose and without fee is hereby *
+ * granted, provided that the above copyright notice appears in all *
+ * copies and that both the copyright notice and this permission *
+ * notice appear in supporting documentation, and that the name *
+ * University of Delaware not be used in advertising or publicity *
+ * pertaining to distribution of the software without specific, *
+ * written prior permission. The University of Delaware makes no *
+ * representations about the suitability this software for any *
+ * purpose. It is provided "as is" without express or implied *
+ * warranty. *
+ **********************************************************************/</PRE>
The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work.
<A HREF="mailto: clift@ml.csiro.au">Steve Clift <clift@ml.csiro.au></A>
OMEGA clock driver</LI>
+<LI>
+<A HREF="mailto:casey@csc.co.za">Casey Crellin <casey@csc.co.za></A>
+vxWorks (Tornado) port and help with target configuration</LI>
+
<LI>
<A HREF="mailto: casey@csc.co.za">Casey Crellin <casey@csc.co.za></A>
VxWorks (Tornado) port and help with target configuration</LI>
GPS driver, generic TrueTime clock driver</LI>
<LI>
-<A HREF="mailto: Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl
-<Ulrich.Windl@rz.uni-regensburg.de></A>
- <UL>
- <LI>Corrected and validated HTML documents according to the official
-HTML DTDs from IETF and <A HREF="http://www.w3.org">W3C</A>
- <LI>Contributed several fixes for better Linux support
- <LI>Implemented <A
-HREF="ftp://linux.kernel.org/pub/linux/daemons/ntp/PPS/">PPS code for the
-Linux kernel</A>, including the ``nanokernel''
- </UL>
-</LI>
-
+<A HREF="mailto: Ulrich.Windl@rz.uni-regensburg.de">Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de></A>
+corrected and validated HTML documents according to the HTML DTD</LI>
</OL>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
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 a keyword, such as <tt>receive</tt> or <tt>clock</tt> of the
-trace you want to see.
+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>Some problems are immediately apparent when the daemon first starts
-running. The most common of these are the lack of <tt>ntp</tt> (UDP port 123)
-in the host <TT>/etc/services</TT> file. Note that NTP always uses UDP
-and never uses TCP. 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
+running. The most common of these are the lack of a ntp (UDP port 123)
+in the host <TT>/etc/services</TT> file. Note that NTP does not use TCP
+in any form. 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 responds to the Unix <TT>ping</TT> command.
<P>When first started, the daemon normally polls the servers listed in
the configuration file at 64-second intervals. In order to allow a
sufficient number of samples for the NTP algorithms to reliably
-discriminate between correctly operating servers (truechimers) and
-possible intruders (falsetickers), at least four valid messages from at
-least one server is required before the daemon can set the local clock.
-However, if the current local time is more than 1000 seconds in error
-from the server time, the daemon will not set the local clock; instead,
-it will plant a message in the system log and shut down. It is necessary
-to set the local clock to within 1000 seconds first, either from the
-time-of-year (TOY) chip, the <A HREF="ntpdate.htm"><TT>ntpdate</TT></A>
-program or manually by eyeball and wristwatch.
+discriminate between correctly operating servers and possible intruders,
+at least four valid messages from at least one server is required before
+the daemon can set the local clock. However, if the current local time
+is greater than 1000 seconds in error from the server time, the daemon
+will not set the local clock; instead, it will plant a message in the
+system log and shut down. It is necessary to set the local clock to
+within 1000 seconds first, either by a time-of-year hardware clock, by
+first using the <A HREF="ntpdate.htm"><TT>ntpdate</TT> </A>program or
+manually be eyeball and wristwatch.
<P>After starting the daemon, run the <TT>ntpq</TT> program using the
<TT>-n</TT> switch, which will avoid possible distractions due to name
the daemon. After operating for a few minutes, the display should be
something like:
-<PRE>
-ntpq>pe
+<PRE>ntpq>pe
remote refid st t when poll reach delay offset disp
===================================================================
+128.4.2.6 132.249.16.1 2 u 131 256 373 9.89 16.28 23.25
following procedure. First, use the <TT>as</TT> command to display an
index of association identifiers, such as
-<PRE>
-ntpq>as
+<PRE>ntpq>as
ind assID status conf reach auth condition last_event cnt
=========================================================
1 11670 7414 no yes ok candidate reachable 1
2 11673 7614 no yes ok sys.peer reachable 1
3 11833 7314 no yes ok outlyer reachable 1
4 11868 7414 no yes ok candidate reachable 1
-</PRE>
+ </PRE>
-Each line in this billboard is associated with the corresponding line of
+Each line in this billboard is associated with the corresponding line
the <TT>pe</TT> billboard above. Next, use the <TT>rv</TT> command and
the respective identifier to display a detailed synopsis of the selected
peer, such as
-<PRE>
-ntpq>rv 11670
+<PRE>ntpq>rv 11670
status=7414 reach, auth, sel_sync, 1 event, event_reach
srcadr=128.4.2.6, srcport=123, dstadr=128.4.2.7, dstport=123, keyid=1,
stratum=2, precision=-10, rootdelay=362.00, rootdispersion=21.99,
filterror= 16.27 20.17 27.98 31.89 35.80 39.70 43.61 47.52
</PRE>
-A detailed explanation of the fields in this billboard is beyond the
+A detailed explanation of the fields in this billboard are beyond the
scope of this discussion; however, most variables defined in the
specification RFC-1305 can be found. The most useful portion for
debugging is the last three lines, which give the roundtrip delay, clock
<P>Finally, the state of the local clock can be determined using the
<TT>rv</TT> command (without the argument), such as
-<PRE>
-ntpq>rv
+<PRE>ntpq>rv
status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg
system="UNIX", leap=00, stratum=2, rootdelay=280.62,
rootdispersion=45.26, peer=11673, refid=128.4.1.20,
<P>When nothing seems to happen in the <TT>pe</TT> billboard after some
minutes, there may be a network problem. The most common network problem
-is an access controlled router on the path to the selected peer. Few
-public NTP time server selectively restricts access, although this may
-change in future; however, many private network servers do. It also may
-be the case that the server is down or running in unsynchronized mode
-due to a local problem. Use the <TT>ntpq</TT> program and <tt>hosts</tt>
-command program to spy on the server variables in the same way you can
-spy on your own.
+is an access controlled router on the path to the selected peer. No
+known public NTP time server selectively restricts access at this time,
+although this may change in future; however, many private networks do.
+It also may be the case that the server is down or running in
+unsynchronized mode due to a local problem. Use the <TT>ntpq</TT>
+program to spy on its own variables in the same way you can spy on your
+own.
<P>Once the daemon has set the local clock, it will continuously track
the discrepancy between local time and NTP time and adjust the local
clock accordingly. There are two components of this adjustment, time and
frequency. These adjustments are automatically determined by the clock
-discipline algorithm. The behavior of this algorithm is carefully
-controlled to minimize residual errors due to network jitter and
-frequency variations of the local clock hardware oscillator due to
-temperature changes. However, when started for the first time, the
-algorithm may take many hours to converge to the intrinsic frequency
-of the host machine.
-<P>It has sometimes been the experience that the local clock oscillator
-frequency error is too large for the NTP discipline algorithm, which
-cannot correct frequency errors larger than 500 parts-per-million (PPM)
-or 43 seconds per day. There are two possibilities that may result in
-this problem. First, the hardware TOY clock chip must be disabled
-when using NTP, since it can destabilize the discipline process. This
-is usually done using the <TT><A HREF="tickadj.htm">tickadj</A></TT>
-program and the <TT>-s</TT> command line argument, but other means may
-be necessary. For instance, in the Sun Solaris kernel, this can be done
-using a command in the <tt>/etc/system</tt> system startup file.
-
-<P>Normally, the NTP daemon amortizes time adjustments at a rate of
-500 PPM until the remaining adjustment is completely amortized. The
-adjustment process is updated with a new time correction each second.
-This process, or slew, operates continuously as long as the adjustment
-does not exceed 128 milliseconds, which for most Internet paths is a
-rare event. If an adjustment does exceed this value, perhaps due to an
-occasional network delay spike, the correction is simply discarded;
-however, if outlyer values persist in subsequent updates for an interval
-of 900 seconds, the local clock is stepped to the new value. This
-behavior is designed to resist errors due to severely congested network
-paths, as well as errors due to confused radio clocks upon the epoch of
-a leap second.
-
-<h4>Network Problems</h4>
-
-<p>Most problems observed with NTP over the years has been some kind of
-network problem. Frequently, the problem turns out to be a filter in the
-firewall between a public server and a client on a private network. In
-other cases the problem is due simply to the fact a designated server is
-unreachable or itself unsynchronized. The Unix <tt>ping</tt> program can
-be used to verify server reachability and the <tt>traceroute</tt>
-utility to explore the path between the remote server and local client.
-The techniques used are common to other network services and considered
-beyond the scope of the discussion here.
-
-<p>Sometimes such things as access control and authentication can get in
-the way of successful synchronization. The <tt>-d</tt> command line
-debug flag is a useful diagnostic in such cases. One or more debug flags
-and the Unix <tt>grep</tt> filter can be used to identify and resolve
-intractable cases. For this purpose, the lavish commentary sprinkled in
-the <tt>ntp_proto.c</tt> source file may be helpful in resolving the
-cause. In particular, the various header and data sanity checks can be
-determined for each arriving message.
-
-<p>The Unix <tt>tcpdump</tt> program is useful to discover rogue packets
-and to calibrate the traffic between a client and its server or peer.
-The <tt>ntptrace</tt> program is useful to discover the synchronization
-path to the primary server, which can be useful should loops develop. If
-kernel support is available, the <tt>ntptime</tt> program can be used to
-display and alter the kernel state variables. The status bits reveal the
-current state; see the <tt>/usr/include/sys/timex.h</tt> header file for
-interpretation. Typical performance expectations are jitter less than 5
-microseconds and stability less than .05 PPM.
-
-<h4>With Extreme Prejudice</h4>
+discipline algorithm, which functions as a hybrid phase/frequency
+feedback loop. The behavior of this algorithm is carefully controlled to
+minimize residual errors due to network jitter and frequency variations
+of the local clock hardware oscillator that normally occur in practice.
+However, when started for the first time, the algorithm may take some
+time to converge on the intrinsic frequency error of the host machine.
<P>It has sometimes been the experience that the local clock oscillator
frequency error is too large for the NTP discipline algorithm, which can
-correct frequency errors as large as 500 parts-per-million (PPM) or 43
-seconds per day. There are two possibilities that may result in this
-behavior. First, the hardware time-of-year (TOY) clock chip must be
-disabled when using NTP, since this can destabilize the discipline
-process. If this is not done, the time can be jerked from under NTP,
-with result excessive jitter and instability. The TOY chip can be
-disabled in many systems using the <TT><A
-HREF="tickadj.htm">tickadj</A></TT> program and the <TT>-s</TT> command
-line argument, but other means may be necessary. For instance, in the
-Sun Solaris kernel, this is done using a command in the
-<tt>/etc/system</tt> system startup file.
-
-<p>Second, the local intrinsic clock frequency error may exceed the 500
-PPM limit. If this occurs, the apparent clock offset will grow until
-reaching 128 ms; then, after the 900-second timeout, the clock will be
-stepped to the apparent time. If the <tt>-x</tt> option is used to
-always slew the clock, the offset will grow continuously. Eventually,
-the offset will reach 1000 seconds and the daemon will fall on its sword
-and terminate with an uncivil message to the system log.
-
-<p>The <tt>tickadj</tt> program can be used to force the clock frequency
-error to a low value which the NTP daemon can handle. This is done by
-changing the value of the <tt>tick</tt> kernel variable which defines
-the number of microseconds added to the clock at each timer interrupt.
-The best way to determine if this is the cause is to start the daemon
-with a configuration file listing a known good server and including the
-line <tt>disable ntp</tt>. For this purpose, the drift file
-<tt>/etc/ntp.drift</tt> should be temporarily removed or renamed. If
-kernel support is available and enabled, previous debugging may have
-left nonsense in the kernel variables. The <tt>ntptime</tt> program can
-be used to set the frequency variable to zero, or the system can be
-rebooted with the same effect.
-
-<p>Once the daemon has started, the <tt>ntpq</tt> program can be used to
-inspect the clock filter values, which show the roundtrip delay, offset
-and dispersion. By inspecting successive offsets in the eight-sample
-clock filter window and finding the interval between updates, the
-intrinsic clock frequency can be calculated. If this exceeds 500 PPM,
-the daemon cannot correct the frequency and a correction to the
-<tt>tick</tt> kernel variable is required. For 100-Hz kernels, which
-represent the majority of systems, this value is normally 10000, which
-results in ten milliseconds clock increment for each timer interrupt.
-Changing this value in unit increments results in frequency changes in
-100 PPM increments. The intrinsic offset calculated previously, the
-correct value of <tt>tick</tt> can be determined to the nearest 100-PPM
-value.
+correct frequency errors as large as 43 seconds per day. There are two
+possibilities that may result in this problem. First, the hardware time-
+of-year clock chip must be disabled when using NTP, since this can
+destabilize the discipline process. This is usually done using the
+<TT><A HREF="tickadj.htm">tickadj</A></TT> program and the <TT>-s</TT>
+command line argument, but other means may be necessary. For instance,
+in the Sun Solaris kernel, this can be done using a command in the
+system startup file.
+
+<P>Normally, the daemon will adjust the local clock in small steps in
+such a way that system and user programs are unaware of its operation.
+The adjustment process operates continuously as long as the apparent
+clock error exceeds 128 milliseconds, which for most Internet paths is a
+quite rare event. If the event is simply an outlyer due to an occasional
+network delay spike, the correction is simply discarded; however, if the
+apparent time error persists for an interval of about 20 minutes, the
+local clock is stepped to the new value (as an option, the daemon can be
+compiled to slew at an accelerated rate to the new value, rather than be
+stepped). This behavior is designed to resist errors due to severely
+congested network paths, as well as errors due to confused radio clocks
+upon the epoch of a leap second.
<H4>Debugging Checklist</H4>
<OL>
-<LI>Verify the <TT>/etc/services</TT> file host machine is configured
-to accept UDP packets on the NTP port 123. NTP is specifically designed
-to use UDP and does not respond to TCP.</LI>
+<P><LI>Verify the <TT>/etc/services</TT> file host machine is configured
+to
+accept UDP packets on the NTP port 123. NTP is specifically designed to
+use UDP and does not respond to TCP.</LI>
-<LI>Check the system log for <TT>ntpd</TT> messages about
-configuration errors, name-lookup failures or initialization
-problems.</LI>
+<P><LI>Check the system log for <TT>ntpd</TT> messages about
+configuration
+errors, name-lookup failures or initialization problems.</LI>
-<LI>Using the <TT>ntpdc</TT> program and <TT>iostats</TT> command,
+<P><LI>Using the <TT>ntpdc</TT> program and <TT>iostats</TT> command,
verify that the received packets and packets sent counters are
-incrementing. If the packets sent counter does not increment and the
+incrementing. If the packets send counter does not increment and the
configuration file includes designated servers, something may be wrong
in the network configuration of the ntpd host. If this counter does
increment and packets are actually being sent to the network, but the
received packets counter does not increment, something may be wrong in
the network or the server may not be responding.</LI>
-<LI>If both the packets sent counter and received packets counter do
+<P><LI>If both the packets sent counter and received packets counter do
increment, but the <TT>rec</TT> timestamp in the <TT>pe</TT> billboard
shows far from the current date, received packets are probably being
discarded for some reason. There is a handy, undocumented state variable
-<TT>flash</TT> visible in the <TT>pe</TT> billboard. The value is in hex
+<TT>flash</TT> visible in the <TT>pe</TT>billboard. The value is in hex
and normally has the value zero (OK). However, if something is wrong,
the bits of this variable, reading from the right, correspond to the
sanity checks listed in Section 3.4.3 of the NTP specification <A
>RFC-1305</A>. A bit other than zero indicates the associated sanity
check failed.</LI>
-<LI>If the <TT>org, rec</TT> and <TT>xmt</TT> timestamps in the
+<P><LI>If the <TT>org, rec</TT> and <TT>xmt</TT> timestamps in the
<TT>pe</TT> billboard appear current, but the local clock is not set, as
indicated by a stratum number less than 16 in the <TT>rv</TT> command
without arguments, verify that valid clock offset, roundtrip delay and
the dispersion less than one second.</LI>
-<LI>While the algorithm can tolerate a relatively large frequency
+<P><LI>While the algorithm can tolerate a relatively large frequency
error (up to 500 parts per million or 43 seconds per day), various
configuration errors (and in some cases kernel bugs) can exceed this
tolerance, leading to erratic behavior. This can result in frequent loss
</OL>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
-<HTML><HEAD><TITLE>
-Undisciplined Local Clock
-</TITLE></HEAD><BODY><H3>
-Undisciplined Local Clock
-</H3><HR>
-
-<H4>Synopsis</H4>
-
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>Undisciplined Local Clock
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+Undisciplined Local Clock</H3>
+
+<HR>
+<H4>
+Synopsis</H4>
Address: 127.127.1.<I>u</I>
<BR>Reference ID: <TT>LCL</TT>
<BR>Driver ID: <TT>LOCAL</TT>
-
-<H4>Description</H4>
-
+<H4>
+Description</H4>
This driver is intended for use in an isolated network where no external
source of synchronization such as a radio clock or modem is available.
-It allows a designated time server to act as a primary or backup server
-to provide synchronization to other clients on the network. Pick a
-machine that has a good clock oscillator (Digital machines are good, Sun
-machines are not) and configure it with this driver. Set the clock using
-the best means available, like eyeball-and-wristwatch. Then, point all
-the other machines at this one or use broadcast (not multicast) mode to
-distribute time.
+It allows a designated time server to act as a primary server to provide
+synchronization to other clients on the network. Pick a machine that has
+a good clock oscillator (Digital machines are good, Sun machines are not)
+and configure it with this driver. Set the clock using the best means available,
+like eyeball-and-wristwatch. Then, point all the other machines at this
+one or use broadcast (not multicast) mode to distribute time.
<P>Another application for this driver is if a particular server clock
-is to be used as the clock of last resort when all other normal
-synchronization sources have gone away. This is especially useful if
-that server has an ovenized oscillator. For this you would configure
-this driver at a stratum greater than any other likely sources of time
-(say 3 or 4) to prevent the server taking over when legitimate sources
-are still available.
-
-<P>A third application for this driver is when an external discipline
-source is available, such as the NIST <TT>lockclock</TT> program, which
-synchronizes the local clock via a telephone modem and the NIST
-Automated Computer Time Service (ACTS), or the Digital Time
-Synchronization Service (DTSS), which runs on DCE machines. In this case
-the stratum should be set at zero, indicating a bona fide stratum-1
-source. In the case of DTSS, the local clock can have a rather large
-jitter, depending on the interval between corrections and the intrinsic
-frequency error of the clock oscillator. In extreme cases, this can
-cause clients to exceed the 128-ms slew window and drop off the NTP
-subnet.
+is to be used as the clock of last resort when all other normal synchronization
+sources have gone away. This is especially useful if that server has an
+ovenized oscillator. For this you would configure this driver at a stratum
+greater than any other likely sources of time (say 3 or 4) to prevent the
+server taking over when legitimate sources are still available.
+
+<P>A third application for this driver is when an external discipline source
+is available, such as the NIST <TT>lockclock</TT> program, which synchronizes
+the local clock via a telephone modem and the NIST Automated Computer Time
+Service (ACTS), or the Digital Time Synchronization Service (DTSS), which
+runs on DCE machines. In this case the stratum should be set at zero, indicating
+a bona fide stratum-1 source. In the case of DTSS, the local clock can
+have a rather large jitter, depending on the interval between corrections
+and the intrinsic frequency error of the clock oscillator. In extreme cases,
+this can cause clients to exceed the 128-ms slew window and drop off the
+NTP subnet.
<P>In the case where a NTP time server is synchronized to some device or
-protocol external to the NTP daemon itself, a means must be available to
-pass such things as error and health values to the NTP daemon for
-dissemination to its clients. If this is not done, there is a very real
-danger that the device or protocol could fail and with no means to tell
-NTP clients of the mishap. When ordinary Unix system calls like
-<TT>adjtime()</TT> are used to discipline the kernel clock, there is no
-obvious way this can be done without modifying the code for each case.
-However, when kernel support for the <TT>ntp_adjtime()</TT> system call
-is available, that routine can be used for the same purpose as the
-<TT>adjtime()</TT> system call and in addition provided with the
-estimated error, maximum error, and leap-indicator values. This is the
-preferred way to synchronize the kernel clock and pass information to
-the NTP clients.
-
-<p>The means currently available in the latest version of the local
-clock driver and kernel support implement a simple protocol used by the
-daemon and external device driver to relinquish control by the device
-driver when the external device becomes unreachable or inoperable and to
-regain control when it resumes normal operation. The device driver
-communicates with the daemon via bits in the status word managed by the
-<tt>ntp_adjtime()</tt> system call. Details of the protocol are
-described in the source code for the local clock driver.
+protocol that is not external to the NTP daemon itself, some means should
+be provided to pass such things as error and health values to the NTP daemon
+for dissemination to its clients. If this is not done, there is a very
+real danger that the device or protocol could fail and with no means to
+tell NTP clients of the mishap. When ordinary Unix system calls like <TT>adjtime()</TT>
+are used to discipline the kernel clock, there is no obvious way this can
+be done without modifying the code for each case. However, when a modified
+kernel with the <TT>ntp_adjtime()</TT> system call is available,
+that routine can be used for the same purpose as the <TT>adjtime()</TT>
+routine and in addition provided with the estimated error, maximum error,
+and leap-indicator values. This is the preferred way to synchronize the
+kernel clock and pass information to the NTP clients.
<P>In the default mode the behavior of the clock selection algorithm is
modified when this driver is in use. The algorithm is designed so that
this driver will never be selected unless no other discipline source is
-available. This can be overridden with the <TT>prefer</TT> keyword of
-the <TT>server</TT> configuration command, in which case only this
-driver will be selected for synchronization and all other discipline
-sources will be ignored. This behavior is intended for use when an
-external discipline source controls the system clock. See the <A
-HREF="prefer.htm">Mitigation Rules and the <TT>prefer</TT> Keyword
-</A>page for a detailed description of the exact behavior.
-
-<P>The stratum for this driver is set at 3 by default, but can be
-changed by the <TT>fudge</TT> configuration command and/or the
-<TT>ntpdc</TT> utility. The reference ID is <TT>LCL</TT> by default, but
-can be changed using the same mechanisms. <B>*NEVER*</B> configure this
-driver to operate at a stratum which might possibly disrupt a client
-with access to a bona fide primary server, unless the local clock
-oscillator is reliably disciplined by another source. <B>*NEVER
-NEVER*</B> configure a server which might devolve to an undisciplined
-local clock to use multicast mode.
+available. This can be overridden with the <TT>prefer</TT> keyword of the
+<TT>server</TT> configuration command, in which case only this driver will
+be selected for synchronization and all other discipline sources will be
+ignored. This behavior is intended for use when an external discipline
+source controls the system clock. See the <A HREF="prefer.htm">Mitigation
+Rules and the <TT>prefer</TT> Keyword </A>page for a detailed description
+of the exact behavior.
+
+<P>The stratum for this driver is set at 3 by default, but can be changed
+by the <TT>fudge</TT> configuration command and/or the <TT>ntpdc</TT> utility.
+The reference ID is <TT>LCL</TT> by default, but can be changed using the
+same mechanisms. <B>*NEVER*</B> configure this driver to operate at a stratum
+which might possibly disrupt a client with access to a bona fide primary
+server, unless the local clock oscillator is reliably disciplined by another
+source. <B>*NEVER NEVER*</B> configure a server which might devolve to
+an undisciplined local clock to use multicast mode.
<P>This driver provides a mechanism to trim the local clock in both time
-and frequency, as well as a way to manipulate the leap bits. The
-<TT>fudge time1</TT> parameter adjusts the time (in seconds) and the
-<TT>fudge time2</TT> parameter adjusts the frequency (in parts per
-million). Both parameters are additive and operate only once; that is,
-each command (as from <TT>ntpdc</TT>) adds signed increments in time or
-frequency to the system clock nominal time and frequency.
+and frequency, as well as a way to manipulate the leap bits. The <TT>fudge
+time1</TT> parameter adjusts the time (in seconds) and the <TT>fudge time2</TT>
+parameter adjusts the frequency (in parts per million). Both parameters
+are additive and operate only once; that is, each command (as from <TT>ntpdc</TT>)
+adds signed increments in time or frequency to the nominal local clock
+time and frequency.
+<H4>
+Monitor Data</H4>
+No <TT>filegen clockstats</TT> monitor data are produced by this driver.
+<H4>
+Fudge Factors</H4>
-<H4>Monitor Data</H4>
+<DL>
+<DT>
+<TT>time1 <I>time</I></TT></DT>
-No <TT>filegen clockstats</TT> monitor data are produced by this driver.
+<DD>
+Specifies the time offset calibration factor, in seconds and fraction,
+with default 0.0.</DD>
-<H4>Fudge Factors</H4>
+<DT>
+<TT>time2 <I>time</I></TT></DT>
-<DL>
+<DD>
+Specifies the frequency offset calibration factor, in parts per million,
+with default 0.0.</DD>
+
+<DT>
+<TT>stratum <I>number</I></TT></DT>
+
+<DD>
+Specifies the driver stratum, in decimal from 0 to 15, with default 3.</DD>
+
+<DT>
+<TT>refid <I>string</I></TT></DT>
-<DT><TT>time1 <I>time</I></TT></DT>
-<DD>Specifies the time offset calibration factor, in seconds and
-fraction, with default 0.0.</DD>
+<DD>
+Specifies the driver reference identifier, an ASCII string from one to
+four characters, with default <TT>LCL</TT>.</DD>
-<DT><TT>time2 <I>time</I></TT></DT>
-<DD>Specifies the frequency offset calibration factor, in parts per
-million, with default 0.0.</DD>
+<DT>
+<TT>flag1 0 | 1</TT></DT>
-<DT><TT>stratum <I>number</I></TT></DT>
-<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
-3.</DD>
+<DD>
+Not used by this driver.</DD>
-<DT><TT>refid <I>string</I></TT></DT>
-<DD>Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default <TT>LCL</TT>.</DD>
+<DT>
+<TT>flag2 0 | 1</TT></DT>
-<DT><TT>flag1 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<DD>
+Not used by this driver.</DD>
-<DT><TT>flag2 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<DT>
+<TT>flag3 0 | 1</TT></DT>
-<DT><TT>flag3 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<DD>
+Not used by this driver.</DD>
+
+<DT>
+<TT>flag4 0 | 1</TT></DT>
+
+<DD>
+Not used by this driver.</DD>
-<DT><TT>flag4 0 | 1</TT></DT>
-<DD>Not used by this driver.
<P>Additional Information
<P><A HREF="refclock.htm">Reference Clock Drivers</A></DL>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
be repeated once per second until turned off by the <TT>B0</TT> command.
<P>Format <TT>B5</TT> (24 ASCII printing characters):
-<PRE>
-<cr><lf>i yy ddd hh:mm:ss.000bbb
+<PRE><cr><lf>i yy ddd hh:mm:ss.000bbb
on-time = <cr>
i = synchronization flag (' ' = locked, '?' = unlocked)
ddd = day of year
hh:mm:ss = hours, minutes, seconds
.000 = fraction of second (not used)
-bbb = tailing spaces for fill
-</PRE>
+bbb = tailing spaces for fill</PRE>
The alarm condition is indicated by a '?' at i, which indicates the receiver
is not synchronized. In normal operation, a line consisting of the timecode
followed by the time quality character (TQ) followed by the receiver status
<P>The time quality character is encoded in IEEE P1344 standard:
<P>Format <TT>TQ</TT> (IEEE P1344 estimated worst-case time quality)
-<PRE>
-0 clock locked, maximum accuracy
-F clock failure, time not reliable
-4 clock unlocked, accuracy < 1 us
-5 clock unlocked, accuracy < 10 us
-6 clock unlocked, accuracy < 100 us
-7 clock unlocked, accuracy < 1 ms
-8 clock unlocked, accuracy < 10 ms
-9 clock unlocked, accuracy < 100 ms
-A clock unlocked, accuracy < 1 s
-B clock unlocked, accuracy < 10 s
-</PRE>
+<PRE>0 clock locked, maximum accuracy
+F clock failure, time not reliable
+4 clock unlocked, accuracy < 1 us
+5 clock unlocked, accuracy < 10 us
+6 clock unlocked, accuracy < 100 us
+7 clock unlocked, accuracy < 1 ms
+8 clock unlocked, accuracy < 10 ms
+9 clock unlocked, accuracy < 100 ms
+A clock unlocked, accuracy < 1 s
+B clock unlocked, accuracy < 10 s</PRE>
The status string is encoded as follows:
<P>Format <TT>SR</TT> (25 ASCII printing characters)
-<PRE>
-V=vv S=ss T=t P=pdop E=ee
+<PRE>V=vv S=ss T=t P=pdop E=ee
vv = satellites visible
ss = relative signal strength
t = satellites tracked
pdop = position dilution of precision (meters)
-ee = hardware errors
-</PRE>
+ee = hardware errors</PRE>
A three-stage median filter is used to reduce jitter and provide a dispersion
measure. The driver makes no attempt to correct for the intrinsic jitter
of the radio itself.
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
l = leap-second warning (see driver listing)
uuu = DUT1 correction (see driver listing)
mmmmm = modem calibration (see driver listing)
-on-time = '*'
-</PRE>
+on-time = '*'</PRE>
The timecode message is transmitted continuously after a signon banner,
which this driver ignores. The driver also ignores all but the yy-mm-dd,
hh:mm:ss and on-time character '*' fields, although it checks the format
<P>Manual call attempts can be made at any time by setting fudge flag1
using ntpdc. For example, the ntpdc command
<PRE>
-fudge 127.127.18.1 flags 1
-</PRE>
+fudge 127.127.18.1 flags 1</PRE>
will ask for a key identifier and password and, if authenticated by the
server, will set flag1. There may be a short delay until the expiration
of the current poll timeout.
<P>The flag1 can be set from a cron job in the following way. Construct
a file with contents
-<PRE>
-keyid 11
+<PRE>keyid 11
passwd dialup
fudge 127.127.18.1 flags 1
-quit
-</PRE>
+quit</PRE>
Then, run the following program at specified times as required.
<PRE>/usr/local/bin/ntpdc <file</PRE>
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<P>The clock message consists of 23 ASCII printing characters in the following
format:
-<PRE>
-hh:mm:ss.f dd/mm/yr<cr>
+<PRE>hh:mm:ss.f dd/mm/yr<cr>
hh:mm:ss.f = hours, minutes, seconds
f = deciseconds ('?' when out of spec)
-dd/mm/yr = day, month, year
-</PRE>
+dd/mm/yr = day, month, year</PRE>
The alarm condition is indicated by '?', rather than a digit, at A. Note
that 0?:??:??.? is displayed before synchronization is first established
and hh:mm:ss.? once synchronization is established and then lost again
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<P>In operation, this driver sends a <TT>RQTS\r</TT> request to the radio
at initialization in order to put it in continuous time output mode. The
radio then sends the following message once each second:
-<PRE>
-*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
+<PRE>*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
on-time = '*'
ddd = day of year
hh:mm:ss = hours, minutes, seconds
q = quality indicator (phase error), 0-6:
- 0 > 20 us
- 6 > 10 us
- 5 > 1 us
- 4 > 100 ns
- 3 > 10 ns
- 2 < 10 ns
-</PRE>
+ 0 > 20 us
+ 6 > 10 us
+ 5 > 1 us
+ 4 > 100 ns
+ 3 > 10 ns
+ 2 < 10 ns</PRE>
The alarm condition is indicated by <TT>0</TT> at <TT>Q</TT>, which means
the radio has a phase error greater than 20 us relative to the broadcast
time. The absence of year, DST and leap-second warning in this format is
<TT>flag4 0 | 1</TT></DT>
<DD>
-Not used by this driver.
+Not used by this driver.</DD>
+
<P>Additional Information
of the serial interface and operating system.
<P>The $GPRMC message that the GPS transmits look like this:
-<PRE>
-$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC<cr><lf>
-
- POS_UTC - UTC of position. Hours, minutes and seconds. (hhmmss)
- POS_STAT - Position status. (A = Data valid, V = Data invalid)
- LAT - Latitude (llll.ll)
- LAT_REF - Latitude direction. (N = North, S = South)
- LON - Longitude (yyyyy.yy)
- LON_REF - Longitude direction (E = East, W = West)
- SPD - Speed over ground. (knots) (x.x)
- HDG - Heading/track made good (degrees True) (x.x)
- DATE - Date (ddmmyy)
- MAG_VAR - Magnetic variation (degrees) (x.x)
- MAG_REF - Magnetic variation (E = East, W = West)
- CC - Checksum (optional)
- <cr><lf> - Sentence terminator.
-</PRE>
+<PRE>$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC<cr><lf>
+
+ POS_UTC - UTC of position. Hours, minutes and seconds. (hhmmss)
+ POS_STAT - Position status. (A = Data valid, V = Data invalid)
+ LAT - Latitude (llll.ll)
+ LAT_REF - Latitude direction. (N = North, S = South)
+ LON - Longitude (yyyyy.yy)
+ LON_REF - Longitude direction (E = East, W = West)
+ SPD - Speed over ground. (knots) (x.x)
+ HDG - Heading/track made good (degrees True) (x.x)
+ DATE - Date (ddmmyy)
+ MAG_VAR - Magnetic variation (degrees) (x.x)
+ MAG_REF - Magnetic variation (E = East, W = West)
+ CC - Checksum (optional)
+ <cr><lf> - Sentence terminator.</PRE>
The driver will send a <TT>$PMOTG,RMC,0000*1D<cr><lf></TT> message
each time a <TT>$GPRMC</TT> string is needed. This is not needed on most
GPS receivers because they automatically send the <TT>$GPRMC</TT> string
<TT>flag4 0 | 1</TT></DT>
<DD>
-Not used by this driver.
+Not used by this driver.</DD>
+
<P>Additional Information
<TT>flag4 0 | 1</TT></DT>
<DD>
-Not used by this driver.
+Not used by this driver.</DD>
+
<P>Additional Information
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<DD>
Request for signal quality. Answer only valid during (late part of) resync
-to MSF signal. The response consists of two characters as follows:
+to MSF signal. The response consists of two characters as follows:</DD>
+<OL>
<DL compact>
<DT>
bit 7</DT>
value drops to zero when not resyncing, ie when first returned byte is
not `3'.</DD>
</DL>
+</OL>
<DT>
<TT>h</TT> CR</DT>
Request timestamp. Start bit of first byte of response is on-time, so may
be delayed up to 1 second. Note that when the BST mode is in effect the
time is GMT/UTC +0100, ie an hour ahead of UTC to reflect local time in
-the UK. The response data is as follows:
+the UK. The response data is as follows:</DD>
<OL>
<LI>
year units</LI>
<LI>
-BST/UTC status
+BST/UTC status</LI>
<DL compact>
<DT>
</DL>
<LI>
-clock status
+clock status</LI>
-<DL compact>
+<DL compact>
<DT>
bit 7</DT>
time, it is not clear what effect that will have on the time broadcast
by MSF, and therefore on this driver's usefulness.</DL>
A typical <TT>ntp.conf</TT> configuration file for this driver might be:
-<PRE>
-# hostname(n) means we expect (n) to be the stratum at which hostname runs.
+<PRE># hostname(n) means we expect (n) to be the stratum at which hostname runs.
#------------------------------------------------------------------------------
# SYNCHRONISATION PARTNERS
# RESTRICTIONS
# ============
-# By default, don't trust and don't allow modifications. Ignore in fact.
+# By default, don't trust and don't allow modifications. Ignore in fact.
restrict default ignore notrust nomodify
# Allow others in our subnet to check us out...
restrict 11.22.33.0 mask 255.255.255.0 nomodify notrust
-# Trust our peers for time. Don't trust others in case they are insane.
+# Trust our peers for time. Don't trust others in case they are insane.
restrict 127.127.27.0 nomodify
restrict 11.22.33.4 nomodify
restrict 11.22.33.9 nomodify
# Allow anything from the local host.
-restrict 127.0.0.1
-</PRE>
+restrict 127.0.0.1</PRE>
There are a few <TT>#define</TT>s in the code that you might wish to play
with:
<DL>
available in <TT>ntp_refclock.c</TT> since the latter seems to have a minor
bug, at least in version 3-5.90. If this bug goes away this flag should
be turned off to avoid duplication of code. (The bug, if that's what it
-is, causes the last raw offset to be used rather than the median offset.)
+is, causes the last raw offset to be used rather than the median offset.)</DD>
+
<P>Without this defined (and without <TT>ARCRON_MULTIPLE_SAMPLES</TT> below)
a typical set of offsets reported and used to drive the clock-filter algorithm
is (oldest last):
-<PRE>filtoffset= -4.32 -34.82 -0.78 0.89 2.76 4.58 -3.92 -2.17</PRE>
+<PRE>filtoffset= -4.32 -34.82 -0.78 0.89 2.76 4.58 -3.92 -2.17</PRE>
Look at that spike!
<P>With this defined a typical set of offsets is:
-<PRE>filtoffset= -7.06 -7.06 -2.91 -2.91 -2.91 -1.27 -9.54 -6.70</PRE>
+<PRE>filtoffset= -7.06 -7.06 -2.91 -2.91 -2.91 -1.27 -9.54 -6.70</PRE>
with the repeated values being some evidence of outlyers being discarded.
<DT>
<TT>ARCRON_MULTIPLE_SAMPLES</TT></DT>
the unit's batteries, so the syslog entry seems justified.
<P>Syslog entries are of the form:
-<PRE>
-May 10 10:15:24 oolong ntpd[615]: ARCRON: unit 0: sending resync command
+<PRE>May 10 10:15:24 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 10:17:32 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock
May 10 11:13:01 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 11:14:06 oolong ntpd[615]: ARCRON: sync finished, signal quality -1: UNKNOWN, will use clock anyway
May 10 11:41:49 oolong ntpd[615]: ARCRON: unit 0: sending resync command
May 10 11:43:57 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock
May 10 12:39:26 oolong ntpd[615]: ARCRON: unit 0: sending resync command
-May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, will use clock
-</PRE>
+May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, will use clock</PRE>
<H4>
Fudge Factors</H4>
<A HREF="refclock.htm">Reference Clock Drivers</A>
<P><A HREF="http://www2.exnet.com/NTP/ARC/ARC.htm">ARC Rugby MSF Receiver</A>
-page
+page
<HR>
<ADDRESS>
Damon Hart-Davis (d@hd.org)</ADDRESS>
<H4>
Structure of shared memory-segment</H4>
-<PRE>
-struct shmTime {
- int mode; /* 0 - if valid set
- * use values,
- * clear valid
- * 1 - if valid set
- * if count before and after read of
- * values is equal,
- * use values
- * clear valid
- */
- int count;
- time_t clockTimeStampSec; /* external clock */
- int clockTimeStampUSec; /* external clock */
- time_t receiveTimeStampSec; /* internal clock, when external value was received */
- int receiveTimeStampUSec; /* internal clock, when external value was received */
- int leap;
- int precision;
- int nsamples;
- int valid;
- int dummy[10];
-};
-</PRE>
+<PRE>struct shmTime {
+ int mode; /* 0 - if valid set
+ * use values,
+ * clear valid
+ * 1 - if valid set
+ * if count before and after read of
+ * values is equal,
+ * use values
+ * clear valid
+ */
+ int count;
+ time_t clockTimeStampSec; /* external clock */
+ int clockTimeStampUSec; /* external clock */
+ time_t receiveTimeStampSec; /* internal clock, when external value was received */
+ int receiveTimeStampUSec; /* internal clock, when external value was received */
+ int leap;
+ int precision;
+ int nsamples;
+ int valid;
+ int dummy[10];
+};</PRE>
<H4>
Operation mode=0</H4>
<TT>flag4 0 | 1</TT></DT>
<DD>
-Not used by this driver.
+Not used by this driver.</DD>
+
<P>Additional Information
<P>Using the poll sequence <TT>QTQDQM</TT>, the response timecode is in
three sections totalling 50 ASCII printing characters, as concatenated
by the driver, in the following format:
-<PRE>
-ahh:mm:ss.fffs<cr> yy/dd/mm/ddd<cr>
+<PRE>ahh:mm:ss.fffs<cr> yy/dd/mm/ddd<cr>
frdzycchhSSFTttttuuxx<cr>
on-time = first <cr>
T = transmitter (C = WWV, H = WWVH)
tttt = time since last update (0000 = minutes)
uu = flush character (03 = ^c)
-xx = 94 (unknown)
-</PRE>
+xx = 94 (unknown)</PRE>
The alarm condition is indicated by other than <TT>8</TT> at <TT>a</TT>,
which occurs during initial synchronization and when received signal is
lost for an extended period; unlock condition is indicated by other than
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
-<!doctype html public "-//W3C//DTD HTML 3.2//EN">
-<HTML><TITLE>
-Motorola Oncore GPS Receiver
-</TITLE></HEAD><BODY><H3>
-Motorola Oncore GPS receiver
-</H3><HR>
-
-<H4>Synopsis</H4>
+<!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.06 [en] (X11; I; FreeBSD
+3.0-CURRENT i386) [Netscape]">
+ <TITLE>Motorola Oncore GPS Receiver
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+Motorola Oncore GPS receiver</H3>
+
+<HR>
+<H4>
+Synopsis</H4>
Address: 127.127.30.0
<BR>Reference ID: <TT>GPS</TT>
<BR>Driver ID: ONCORE
-<BR>Serial Port: <TT>/dev/oncore.serial.<I>u</I></TT>; 9600 baud,
-8-bits, no parity
-<BR>PPS Port: <TT>/dev/oncore.pps.<I>u</I></TT>;
-<TT>PPS_CAPTUREASSERT</TT> required,
-<TT>PPS_OFFSETASSERT</TT> supported.
-
-<H4>Description</H4>
-
+<BR>Serial Port: <TT>/dev/cuaa0</TT>; 9600 baud, 8-bits, no parity
+<BR>PPS Port: <TT>/dev/xpps0</TT>; <TT>PPS_CAPTUREASSERT</TT>
+required, <TT>PPS_OFFSETASSERT</TT> supported.
+<H4>
+Description</H4>
This driver supports various models of the <A
-HREF="http://www.mot.com/ACCES/GPS/">Motorola Oncore GPS receivers</A>.
-as long as they support the <I>Motorola Binary Protocol</I>.<P>The two
-most interesting version of the Oncore are the "UT+" and the
-"Remote" which is a prepackaged "UT+". The evaluation kit can
-also be recommended, it interfaces to a PC straightaway, using the
+HREF="http://www.mot.com/AECS/PNSB/products">Motorola Oncore GPS
+receivers</A>. as long as they support the <I>Motorola Binary
+Protocol</I>.
+
+<P>The two most interesting version of the Oncore are the "UT+"
+and the "Remote" which is a prepackaged "UT+". The evaluation kit
+can also be recommended, it interfaces to a PC straightaway, using the
parallel port for PPS input (supported under FreeBSD), and packs the
receiver in a nice and sturdy box.
-
-<BR><CENTER><TABLE NOSAVE >
-
+<BR>
+<CENTER><TABLE NOSAVE >
<TR NOSAVE>
<TD NOSAVE><IMG SRC="pic/oncore_utplusbig.gif" HEIGHT=124
WIDTH=210></TD>
+
<TD><IMG SRC="pic/oncore_evalbig.gif" HEIGHT=124 WIDTH=182></TD>
+
<TD><IMG SRC="pic/oncore_remoteant.jpg" HEIGHT=188 WIDTH=178></TD>
</TR>
<TR>
-<TD><CENTER>UT+ oncore</CENTER></TD>
-<TD><CENTER>Evaluation kit</CENTER></TD>
-<TD><CENTER>Oncore Remote</CENTER></TD>
-</TR>
+<TD>
+<CENTER>UT+ oncore</CENTER>
+</TD>
+<TD>
+<CENTER>Evaluation kit</CENTER>
+</TD>
+
+<TD>
+<CENTER>Oncore Remote</CENTER>
+</TD>
+</TR>
</TABLE></CENTER>
-<P>The driver requires a standard <TT>PPS</TT> interface for the
-pulse-per-second output from the receiver. The serial data stream alone
+<P>The driver requires a standard <TT>PPS</TT> interface for the pulse-
+per-second output from the receiver. The serial data stream alone
does not provide precision time stamps (0-50msec variance, according to
the manual), whereas the PPS output is precise down to 50 nsec (1 sigma)
-for the UT models.
-
-<P>The driver will use the "position hold" mode if available, with
-either the receivers built-in site-survey or a similar algorithm
-implemented in this driver.
-
-<P>Please check the source file for more info on configuration of this
-driver.
-
-<H4>Monitor Data</H4>
-
-The driver is quite chatty on stdout if ntpd is run with debugging.
+for the UT models. <P>The driver will use the "position hold" mode if
+available, with either the receivers built-in site-survey or a similar
+algorithm implemented in this driver.
+<H4>
+Monitor Data</H4>
+The driver is quite chatty on stdout if ntpd is run with
+debugging.
A manual will be required though.
-
-<H4>Fudge Factors</H4>
+<H4>
+Fudge Factors</H4>
<DL>
+<DT>
+<TT>time1 <I>time</I></TT></DT>
-<DT><TT>time1 <I>time</I></TT></DT>
-<DD>Specifies the time offset calibration factor, in seconds and
-fraction, with default 0.0.</DD>
+<DD>
+Specifies the time offset calibration factor, in seconds and fraction,
+with default 0.0.</DD>
-<DT><TT>time2 <I>time</I></TT></DT>
-<DD>Not used by this driver.</DD>
+<DT>
+<TT>time2 <I>time</I></TT></DT>
-<DT><TT>stratum <I>number</I></TT></DT>
-<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
-0.</DD>
+<DD>
+Not used by this driver.</DD>
-<DT><TT>refid <I>string</I></TT></DT>
-<DD>Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default <TT>GPS</TT>.</DD>
+<DT>
+<TT>stratum <I>number</I></TT></DT>
-<DT><TT>flag1 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<DD>
+Specifies the driver stratum, in decimal from 0 to 15, with default
+0.</DD>
-<DT><TT>flag2 0 | 1</TT></DT>
-<DD>Assume GPS receiver is on a mobile platform if set.</DD>
+<DT>
+<TT>refid <I>string</I></TT></DT>
-<DT><TT>flag3 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<DD>
+Specifies the driver reference identifier, an ASCII string from one to
+four characters, with default <TT>GPS</TT>.</DD>
-<DT><TT>flag4 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<DT>
+<TT>flag1 0 | 1</TT></DT>
-</DL>
+<DD>
+Not used by this driver.</DD>
-<B>Additional Information</B>
+<DT>
+<TT>flag2 0 | 1</TT></DT>
-<P>The driver has been developed under FreeBSD, and may still be pretty
-FreeBSD centric. Patches are most welcome.
+<DD>
+Assume GPS receiver is on a mobile platform if set.</DD>
-<P><B>Performance</B>
+<DT>
+<TT>flag3 0 | 1</TT></DT>
-<P>Really good. With the UT+, the generated PPS pulse is referenced
-to UTC(GPS) with better than 50 nsec (1 sigma) accuracy.
-<BR>Actual measurements can be found here: <A
-HREF="http://phk.freebsd.dk/oncore">Oncore UT+ performance
-measurements</A>
+<DD>
+Not used by this driver.</DD>
-<P>The limiting factor will be the timebase of the computer and the
-precision with which you can timestamp the rising flank of the PPS
-signal.
+<DT>
+<TT>flag4 0 | 1</TT></DT>
-<BR><HR><ADDRESS>Poul-Henning Kamp (phk@FreeBSD.org)</ADDRESS></BODY>
+<DD>
+Not used by this driver.</DD>
+</DL>
+<B>Additional Information</B><B></B>
+<P>The driver has been developed under FreeBSD, and may still be pretty
+FreeBSD centric. Patches are most welcome.
+<P><B>Performance</B><B></B>
+<P>Really good. With the UT+, the generated PPS pulse is
+referenced
+to UTC(GPS) with better than 50 nsec (1 sigma) accuracy. The
+limiting factor will be the timebase of the computer and the precision
+with which you can timestamp the rising flank of the
+PPS signal.
+Using FreeBSD, a FPGA based Timecounter/PPS interface
+and
+an ovenized quartz oscillator, that performance has been reproduced.
+ For
+more details on this aspect: <A
+HREF="http://phk.freebsd.dk/rover.html">Sub-Microsecond
+timekeeping under FreeBSD</A>
+<HR>
+<ADDRESS>
+Poul-Henning Kamp (phk@FreeBSD.org)</ADDRESS>
+
+</BODY>
</HTML>
available only with the Netclock/2 and specially modified 8170.
<P>Format 0 (22 ASCII printing characters):
-<PRE>
-<cr><lf>i ddd hh:mm:ss TZ=zz<cr><lf>
+<PRE><cr><lf>i ddd hh:mm:ss TZ=zz<cr><lf>
on-time = first <cr>
i = synchronization flag (' ' = in synch, '?' = out synch)
-hh:mm:ss = hours, minutes, seconds
-</PRE>
+hh:mm:ss = hours, minutes, seconds</PRE>
The alarm condition is indicated by other than ' ' at <TT>i</TT>, which
occurs during initial synchronization and when received signal is lost
for about ten hours.
<P>Format 2 (24 ASCII printing characters):
-<PRE>
-<cr><lf>iqyy ddd hh:mm:ss.fff ld
+<PRE><cr><lf>iqyy ddd hh:mm:ss.fff ld
on-time = <cr>
i = synchronization flag (' ' = in synch, '?' = out synch)
q = quality indicator (' ' = locked, 'A'...'D' = unlocked)
yy = year (as broadcast)
ddd = day of year
-hh:mm:ss.fff = hours, minutes, seconds, milliseconds
-</PRE>
+hh:mm:ss.fff = hours, minutes, seconds, milliseconds</PRE>
The alarm condition is indicated by other than ' ' at <TT>i</TT>, which
occurs during initial synchronization and when received signal is lost
for about ten hours. The unlock condition is indicated by other than '
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<P>Most of this code is originally from refclock_wwvb.c with thanks. It
has been so mangled that wwvb is not a recognizable ancestor.
-<PRE>
-Timcode format: ADDD:HH:MM:SSQCL
+<PRE>Timcode format: ADDD:HH:MM:SSQCL
A - control A (this is stripped before we see it)
Q - Quality indication (see below)
Quality codes indicate possible error of
- 468-DC GOES Receiver:
- GPS-TM/TMD Receiver:
- ? +/- 500 milliseconds # +/- 50 milliseconds
- * +/- 5 milliseconds . +/- 1 millisecond
- space less than 1 millisecond
+ 468-DC GOES Receiver:
+ GPS-TM/TMD Receiver:
+ ? +/- 500 milliseconds # +/- 50 milliseconds
+ * +/- 5 milliseconds . +/- 1 millisecond
+ space less than 1 millisecond
- OM-DC OMEGA Receiver:
+ OM-DC OMEGA Receiver:
- > +/- 5 seconds
+ > +/- 5 seconds
- ? +/- 500 milliseconds # +/- 50 milliseconds
- * +/- 5 milliseconds . +/- 1 millisecond
+ ? +/- 500 milliseconds # +/- 50 milliseconds
+ * +/- 5 milliseconds . +/- 1 millisecond
- A-H less than 1 millisecond. Character indicates which
+ A-H less than 1 millisecond. Character indicates which
station
- is being received as follows: A = Norway, B = Liberia,
- C = Hawaii, D = North Dakota, E = La Reunion, F =
+ is being received as follows: A = Norway, B = Liberia,
+ C = Hawaii, D = North Dakota, E = La Reunion, F =
Argentina,
- G = Australia, H = Japan.
-</PRE>
+ G = Australia, H = Japan.</PRE>
The carriage return start bit begins on 0 seconds and extends to 1 bit
time.
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
-<HTML><HEAD><TITLE>
-IRIG Audio Decoder II for Sun SPARCstation
-</TITLE></HEAD><BODY><H3>
-IRIG Audio Decoder II for Sun SPARCstation
-</H3><HR>
-
-<H4>Synopsis</H4>
-
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>IRIG Audio Decoder II for Sun SPARCstation
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+IRIG Audio Decoder</H3>
+
+<HR>
+<H4>
+Synopsis</H4>
Address: 127.127.6.<I>u</I>
<BR>Reference ID: <TT>IRIG</TT>
<BR>Driver ID: <TT>IRIG_AUDIO</TT>
<BR>Audio Device: <TT>/dev/audio</TT> and <TT>/dev/audioctl</TT>
<P>Note: This driver supersedes an older one of the same name, address
-and ID which required replacing the original kernel audio driver with
-another which works only on older Sun SPARCstation systems. The new
-driver described here uses the stock kernel audio driver and works in
-SunOS 4.1.3 and Solaris 2.6 versions and probably all versions in
-between. The new driver requires no modification of the operating
-system. While it is generic and likely portable to other systems, it is
-somewhat slower than the original, since the extensive signal
-conditioning, filtering and decoding is done in user space, not kernel
-space.
-
-<H4>Description</H4>
-
-This driver supports the Inter-Range Instrumentation Group (IRIG)
-standard time distribution signal using the audio codec native to the
-Sun SPARCstation. This signal is generated by several radio clocks,
-including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom
-and TrueTime, among others, although it is often an add-on option. The
-signal is connected via an optional attenuator box and cable to either
-the microphone or line-in ports on a Sun SPARCstation
-<TT>/dev/audio</TT> audio codec device. The driver receives, demodulates
-and decodes the IRIG-B and IRIG-E signal formats using internal filters
-designed to reduce the effects of noise and interfering signals.
-
-<P>The IRIG signal format uses an amplitude-modulated carrier with
-pulse-width modulated data bits. For IRIG-B, the carrier frequency is
-1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequency is 100
-Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy,
-generally within a few tens of microseconds relative to IRIG time, it
-can also generate a significant load on the processor with older
-workstations. Generally, the accuracy with IRIG-E is about ten times
-worse than IRIG-B, but the processor load is ten times less.
+and ID which required replacing the original kernel audio driver with another
+which works only on older Sun SPARCstation systems. The new driver described
+here uses the stock kernel audio driver and works in SunOS 4.1.3 and Solaris
+2.6 versions and probably all versions in between. The new driver requires
+no modification of the operating system. While it is generic and likely
+portable to other systems, it is somewhat slower than the original, since
+the extensive signal conditioning, filtering and decoding is done in user
+space, not kernel space.
+<H4>
+Description</H4>
+This driver supports the Inter-Range Instrumentation Group (IRIG) standard
+time distribution signal using the audio codec native to the Sun SPARCstation.
+This signal is generated by several radio clocks, including those made
+by Arbiter, Austron, Bancomm, Odetics, Spectracom and TrueTime, among others,
+although it is often an add-on option. The signal is connected via an optional
+attenuator box and cable to either the microphone or line-in ports on a
+Sun SPARCstation <TT>/dev/audio</TT> audio codec device. The driver receives,
+demodulates and decodes the IRIG-B and IRIG-E signal formats using internal
+filters designed to reduce the effects of noise and interfering signals.
+
+<P>The IRIG signal format uses an amplitude-modulated carrier with pulse-width
+modulated data bits. For IRIG-B, the carrier frequency is 1000 Hz and bit
+rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 Hz and bit rate
+10 b/s. While IRIG-B provides the best accuracy, generally within a few
+tens of microseconds relative to IRIG time, it can also generate a significant
+load on the processor with older workstations. Generally, the accuracy
+with IRIG-E is about ten times worse than IRIG-B, but the processor load
+is ten times less.
<P>The program processes 8000-Hz mu-law companded samples using separate
signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector
-and automatic threshold corrector. Cycle crossings relative to the
-corrected slice level determine the width of each pulse and its value -
-zero, one or position identifier. The data encode 20 BCD digits which
-determine the second, minute, hour and day of the year and sometimes the
-year and synchronization condition. The comb filter exponentially
-averages the corresponding samples of successive baud intervals in order
-to reliably identify the reference carrier cycle. A type-II phase-lock
-loop (PLL) performs additional integration and interpolation to
-accurately determine the zero crossing of that cycle, which determines
-the reference timestamp. A pulse-width discriminator demodulates the
-data pulses, which are then encoded as the BCD digits of the timecode.
+and automatic threshold corrector. Cycle crossings relative to the corrected
+slice level determine the width of each pulse and its value - zero, one
+or position identifier. The data encode 20 BCD digits which determine the
+second, minute, hour and day of the year and sometimes the year and synchronization
+condition. The comb filter exponentially averages the corresponding samples
+of successive baud intervals in order to reliably identify the reference
+carrier cycle. A type-II phase-lock loop (PLL) performs additional integration
+and interpolation to accurately determine the zero crossing of that cycle,
+which determines the reference timestamp. A pulse-width discriminator demodulates
+the data pulses, which are then encoded as the BCD digits of the timecode.
The timecode and reference timestamp are updated once each second with
-IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved
-for later processing. At poll intervals of 64 s, the saved samples are
-processed by a trimmed-mean filter and used to update the system clock.
+IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved for
+later processing. At poll intervals of 64 s, the saved samples are processed
+by a trimmed-mean filter and used to update the system clock.
<P>Infinite impulse response (IIR) filters are used with both IRIG-B and
-IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a 130-
-Hz lowpass filter for IRIG-E. These are intended for use with noisy
-signals, such as might be received over a telephone line or radio
-circuit, or when interfering signals may be present in the audio
-passband. The driver determines which IRIG format is in use by sampling
-the amplitude of each filter output and selecting the one with maximum
-signal. An automatic gain control feature provides protection against
-overdriven or underdriven input signal amplitudes. It is designed to
-maintain adequate demodulator signal amplitude while avoiding occasional
-noise spikes. In order to assure reliable capture, the decompanded input
-signal amplitude must be greater than 100 units and the codec sample
-frequency error less than 250 PPM (.025 percent).
-
-<P>The program performs a number of error checks to protect against
-overdriven or underdriven input signal levels, incorrect signal format
-or improper hardware configuration. Specifically, if any of the
-following errors occur for a timecode, the data are rejected.
-Specifically, if any of the following errors occur for a time
-measurement, the data are rejected.
-
+IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a 130-Hz
+lowpass filter for IRIG-E. These are intended for use with noisy signals,
+such as might be received over a telephone line or radio circuit, or when
+interfering signals may be present in the audio passband. The driver determines
+which IRIG format is in use by sampling the amplitude of each filter output
+and selecting the one with maximum signal. An automatic gain control feature
+provides protection against overdriven or underdriven input signal amplitudes.
+It is designed to maintain adequate demodulator signal amplitude while
+avoiding occasional noise spikes. In order to assure reliable capture,
+the decompanded input signal amplitude must be greater than 100 units and
+the codec sample frequency error less than 250 PPM (.025 percent).
+
+<P>The program performs a number of error checks to protect against overdriven
+or underdriven input signal levels, incorrect signal format or improper
+hardware configuration. Specifically, if any of the following errors occur
+for a timecode, the data are rejected. Secifically, if any of the following
+errors occur for a time measurement, the data are rejected.
<OL>
-
-<LI>The peak carrier amplitude is less than 100 units. This usually
-means dead IRIG signal source, broken cable or wrong input port.</LI>
-
-<LI>The frequency error is greater than +-250 PPM (.025 percent). This
-usually means broken codec hardware or wrong codec configuration.</LI>
-
-<LI>The modulation index is less than 0.5. This usually means overdriven
-IRIG signal or wrong IRIG format.</LI>
-
-<LI>A frame synchronization error has occurred. This usually means wrong
-IRIG signal format or the IRIG signal source has lost synchronization
-(signature control).</LI>
-
-<LI>A data decoding error has occurred. This usually means wrong IRIG
-signal format.</LI>
-
-<LI>The current second of the day is not exactly one greater than the
-previous one. This usually means a very noisy IRIG signal or
-insufficient CPU resources.</LI>
-
-<LI>An audio codec error (overrun) occurred. This usually means
-insufficient CPU resources, as sometimes happens with Sun SPARC IPCs
-when doing something useful.</LI>
-
+<LI>
+The peak carrier amplitude is less than 100 units. This usually means dead
+IRIG signal source, broken cable or wrong input port.</LI>
+
+<BR>
+<LI>
+The frequency error is greater than +-250 PPM (.025 percent). This usually
+means broken codec hardware or wrong codec configuration.</LI>
+
+<BR>
+<LI>
+The modulation index is less than 0.5. This usually means overdriven IRIG
+signal or wrong IRIG format.</LI>
+
+<BR>
+<LI>
+A frame synchronization error has occured. This usually means wrong IRIG
+signal format or the IRIG signal source has lost synchronization (signature
+control).</LI>
+
+<BR>
+<LI>
+A data decoding error has occured. This usually means wrong IRIG signal
+format.</LI>
+
+<BR>
+<LI>
+The current second of the day is not exactly one greater than the previous
+one. This usually means a very noisy IRIG signal or insufficient CPU resources.</LI>
+
+<BR>
+<LI>
+An audio codec error (overrun) occured. This usually means insufficient
+CPU resources, as sometimes happens with Sun SPARC IPCs when doing something
+useful.</LI>
</OL>
-
-Note that additional checks are done elsewhere in the reference clock
-interface routines.
-
-<P>Unlike other drivers, which can have multiple instantiations, this
-one supports only one. It does not seem likely that more than one audio
-codec would be useful in a single machine. More than one would probably
-chew up too much CPU time anyway.
-
-<H4>IRIG-B Timecode Format</H4>
-
-The 100 elements of the IRIG timecode are numbered from 0 through 99.
-Position identifiers occur at elements 0, 9, 19 and every ten thereafter
-to 99. The control function (CF) elements begin at element 50 (CF 1) and
-extend to element 78 (CF 27). The straight-binary-seconds (SBS) field,
-which encodes the seconds of the UTC day, begins at element 80 (CF 28)
-and extends to element 97 (CF 44). The encoding of elements 50 (CF 1)
-through 78 (CF 27) is device dependent. This driver presently decodes
-the CF elements, but does nothing with them.
-
-<P>Where feasible, the IRIG signal source should be operated with
-signature control so that, if the signal is lost or mutilated, the
-source produces an unmodulated signal, rather than possibly random
-digits. The driver will automatically reject the data and declare itself
-unsynchronized in this case. Some devices, in particular Spectracom
-radio/satellite clocks, provide additional year and status indication in
-the format:
-
-<PRE>
- Element
-CF Function
- -------------------------------------
- 55
-6 time sync status
- 60-63 10-
-13 BCD year units
- 65-68 15-
-18 BCD year tens
-</PRE>
-
+Note that additional checks are done elsewhere in the reference clock interface
+routines.
+
+<P>Unlike other drivers, which can have multiple instantiations, this one
+supports only one. It does not seem likely that more than one audio codec
+would be useful in a single machine. More than one would probably chew
+up too much CPU time anyway.
+<H4>
+IRIG-B Timecode Format</H4>
+The 100 elements of the IRIG timecode are numbered from 0 through 99. Position
+identifiers occur at elements 0, 9, 19 and every ten thereafter to 99.
+The control function (CF) elements begin at element 50 (CF 1) and extend
+to element 78 (CF 27). The straight-binary-seconds (SBS) field, which encodes
+the seconds of the UTC day, begins at element 80 (CF 28) and extends to
+element 97 (CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27)
+is device dependent. This driver presently decodes the CF elements, but
+does nothing with them.
+
+<P>Where feasible, the IRIG signal source should be operated with signature
+control so that, if the signal is lost or mutilated, the source produces
+an unmodulated signal, rather than possibly random digits. The driver will
+automatically reject the data and declare itself unsynchronized in this
+case. Some devices, in particular Spectracom radio/satellite clocks, provide
+additional year and status indication in the format:
+<PRE> Element CF Function
+ -------------------------------------
+ 55 6 time sync status
+ 60-63 10-13 BCD year units
+ 65-68 15-18 BCD year tens</PRE>
Other devices set these elements to zero.
-
-<H4>Performance</H4>
-
+<H4>
+Performance</H4>
The mu-law companded data format allows considerable latitude in signal
levels; however, an automatic gain control (AGC) function is implemented
-to further compensate for varying input signal levels and to avoid
-signal distortion. For proper operation, the IRIG signal source should
-be configured for analog signal levels, NOT digital TTL levels.
-
-<P>The accuracy of the system clock synchronized to the IRIG-B source
-with this driver and the <TT>ntpd</TT> daemon is 10-20 microseconds with
-a Sun UltraSPARC II and maybe twice that with a Sun SPARC IPC. The
-processor resources consumed by the daemon can be significant, ranging
-from about 1.2 percent on the faster UltraSPARC II to 38 percent on the
-slower SPARC IPC. However, the overall timing accuracy is limited by the
-resolution and stability of the CPU clock oscillator and the interval
-between clock corrections, which is 64 s with this driver. This
-performance, while probably the best that can be achieved by the daemon
-itself, can be improved with assist from the PPS discipline as described
-elsewhere in the documentation.
-
-<H4>Monitor Data</H4>
-
+to further compensate for varying input signal levels and to avoid signal
+distortion. For proper operation, the IRIG signal source should be configured
+for analog signal levels, NOT digital TTL levels.
+
+<P>The accuracy of the system clock synchronized to the IRIG-B source with
+this driver and the <TT>ntpd</TT> daemon is 10-20 microseconds with a Sun
+UltraSPARC II and maybe twice that with a Sun SPARC IPC. The processor
+resources consumed by the daemon can be significant, ranging from about
+1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC
+IPC. However, the overall timing accuracy is limited by the resolution
+and stability of the CPU clock oscillator and the interval between clock
+corrections, which is 64 s with this driver. This performance, while probably
+the best that can be achieved by the daemon itself, can be improved with
+assist from the PPS discipline as described elsewhere in the documentation.
+<H4>
+Monitor Data</H4>
The timecode format used for debugging and data recording includes data
-helpful in diagnosing problems with the IRIG signal and codec
-connections. With debugging enabled (-d -d -d on the ntpd command line),
-the driver produces one line for each timecode in the following format:
-
+helpful in diagnosing problems with the IRIG signal and codec connections.
+With debugging enabled (-d -d -d on the ntpd command line), the driver
+produces one line for each timecode in the following format:
<PRE>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 3094572411.00027</PRE>
-
-The first field contains the error flags in hex, where the hex bits are
-interpreted as below. This is followed by the IRIG status indicator,
-year of century, day of year and time of day. The status indicator and
-year are not produced by some IRIG devices. Following these fields are
-the signal amplitude (0-8100), codec gain (0-255), field phase (0-79),
-time constant (2-20), modulation index (0-1), carrier phase error (0+-
-0.5) and carrier frequency error (PPM). The last field is the on-time
-timestamp in NTP format. The fraction part is a good indicator of how
-well the driver is doing. With an UltrSPARC 30, this is normally within
-a few tens of microseconds relative to the IRIG-B signal and within a
-few hundred microseconds with IRIG-E.
-
-<H4>Fudge Factors</H4>
+The first field containes the error flags in hex, where the hex bits are
+interpreted as below. This is followed by the IRIG status indicator, year
+of century, day of year and time of day. The status indicator and year
+are not produced by some IRIG devices. Following these fields are the signal
+amplitude (0-8100), codec gain (0-255), field phase (0-79), time constant
+(2-20), modulation index (0-1), carrier phase error (0+-0.5) and carrier
+frequency error (PPM). The last field is the on-time timestamp in NTP format.
+The fraction part is a good indicator of how well the driver is doing.
+With an UltrSPARC 30, this is normally within a few tens of microseconds
+relative to the IRIG-B signal and within a few hundred microseconds with
+IRIG-E.
+<H4>
+Fudge Factors</H4>
<DL>
+<DT>
+<TT>time1 <I>time</I></TT></DT>
-<DT><TT>time1 <I>time</I></TT></DT>
-
-<DD>Specifies the time offset calibration factor, in seconds and
-fraction, with default 0.0.</DD>
-
-<DT><TT>time2 <I>time</I></TT></DT>
+<DD>
+Specifies the time offset calibration factor, in seconds and fraction,
+with default 0.0.</DD>
-<DD>Not used by this driver.</DD>
+<DT>
+<TT>time2 <I>time</I></TT></DT>
-<DT><TT>stratum <I>number</I></TT></DT>
+<DD>
+Not used by this driver.</DD>
-<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
-0.</DD>
+<DT>
+<TT>stratum <I>number</I></TT></DT>
-<DT><TT>refid <I>string</I></TT></DT>
+<DD>
+Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
-<DD>Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default <TT>IRIG</TT>.</DD>
+<DT>
+<TT>refid <I>string</I></TT></DT>
-<DT><TT>flag1 0 | 1</TT></DT>
+<DD>
+Specifies the driver reference identifier, an ASCII string from one to
+four characters, with default <TT>IRIG</TT>.</DD>
-<DD>Not used by this driver.</DD>
+<DT>
+<TT>flag1 0 | 1</TT></DT>
-<DT><TT>flag2 0 | 1</TT></DT>
+<DD>
+Not used by this driver.</DD>
-<DD>Specifies the microphone port if set to zero or the line-in port if
-set to one. It does not seem useful to specify the compact disc player
-port.</DD>
+<DT>
+<TT>flag2 0 | 1</TT></DT>
-<DT><TT>flag3 0 | 1</TT></DT>
+<DD>
+Specifies the microphone port if set to zero or the line-in port if set
+to one. It does not seem useful to specify the compact disc player port.</DD>
-<DD>Enables audio monitoring of the input signal. For this purpose, the
-speaker volume must be set before the driver is started.</DD>
+<DT>
+<TT>flag3 0 | 1</TT></DT>
-<DT><TT>flag4 0 | 1</TT></DT>
+<DD>
+Enables audio monitoring of the input signal. For this purpose, the speaker
+volume must be set before the driver is started.</DD>
-<DD>Enable verbose <TT>clockstats</TT> recording if set.</DD>
+<DT>
+<TT>flag4 0 | 1</TT></DT>
+<DD>
+Enable verbose <TT>clockstats</TT> recording if set.</DD>
</DL>
-
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A><HR><ADDRESS>
-David L. Mills (mills@udel.edu)
-</ADDRESS></BODY></HTML>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
<P>Format A bursts are sent at seconds 32 through 39 of the minute in hex
digits
-<P><TT> 6dddhhmmss6dddhhmmss</TT>
+<P><TT> 6dddhhmmss6dddhhmmss</TT>
<P>The first ten digits encode a frame marker (<TT>6</TT>) followed by
the day (<TT>ddd</TT>), hour (<TT>hh </TT>in UTC), minute (<TT>mm</TT>)
<P>Format B bursts are sent at second 31 of the minute in hex digits
-<P><TT> xdyyyyttaaxdyyyyttaa</TT>
+<P><TT> xdyyyyttaaxdyyyyttaa</TT>
<P>The first ten digits encode a code (<TT>x </TT>described below) followed
by the DUT1 (<TT>d </TT>in deciseconds), Gregorian year (<TT>yyyy</TT>),
<P>The <TT>x </TT>is coded
-<P>1 Sign of DUT (0 = +)
-<BR>2 Leap second warning. One second will be added.
-<BR>4 Leap second warning. One second will be subtracted.
+<P>1 Sign of DUT (0 = +)
+<BR>2 Leap second warning. One second will be added.
+<BR>4 Leap second warning. One second will be subtracted.
This is not likely to happen in our universe.
-<BR>8 Even parity bit for this nibble.
+<BR>8 Even parity bit for this nibble.
<P>By design, the last stop bit of the last character in the burst coincides
with 0.5 second. Since characters have 11 bits and are transmitted at 300
line), the driver produces one line for each burst in two formats corresponding
to format A and B. Following is format A:
-<P><TT> n b f s m code</TT>
+<P><TT> n b f s m code</TT>
<P>where <TT>n </TT>is the number of characters in the burst (0-11), <TT>b
</TT>the burst distance (0-40), <TT>f </TT>the field alignment (-1, 0,
number (2-9) and <TT>code </TT>the burst characters as received. Note that
the hex digits in each character are reversed, so the burst
-<P><TT> 10 38 0 16 9 06851292930685129293</TT>
+<P><TT> 10 38 0 16 9 06851292930685129293</TT>
<P>is interpreted as containing 11 characters with burst distance 38, field
alignment 0, synchronization distance 16 and burst number 9. The nibble-swapped
<P>Following is format B:
-<P><TT> n b s code</TT>
+<P><TT> n b s code</TT>
<P>where <TT>n </TT>is the number of characters in the burst (0-11), <TT>b
</TT>the burst distance (0-40), <TT>s </TT>the synchronization distance
hex digits in each character are reversed and the last ten digits inverted,
so the burst
-<P> <TT>11 40 1091891300ef6e76ecff</TT>
+<P> <TT>11 40 1091891300ef6e76ecff</TT>
<P>is interpreted as containing 11 characters with burst distance 40. The
nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI - UTC
to the clockstats file and debug score after the last burst received in
the minute. The format is
-<P> <TT> qq yyyy ddd hh:mm:ss nn dd tt</TT>
+<P> <TT> qq yyyy ddd hh:mm:ss nn dd tt</TT>
<P>where <TT>qq </TT>are the error flags, as described below, <TT>yyyy
</TT>is the year, <TT>ddd </TT>the day, <TT>hh:mm:ss </TT>the time of day,
</DL>
Additional Information
-<P><A HREF="file:///J|/ntp4/html/refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="file:///J|/ntp4/html/refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<P>The actual receiver status is mapped into various synchronization
states generally used by receivers. The STREAMS module is configured to
interpret the time codes of DCF C51, PZF535, PZF509, GPS166, Trimble SV6
-GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see list below).
+GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see list
+below).
<P>The reference clock support in ntp contains the necessary
configuration tables for those receivers. In addition to supporting
optionally listed in parentheses. The actual time code is listed in
timecode.
A qualification of the decoded time code format is following in
-refclock_format.
-The last piece of information is the overall running time and the
-accumulated
-times for the clock event states in refclock_states. When PPS
-information
-is present additional variable are available. refclock_ppstime lists
-then
-the PPS timestamp and refclock_ppsskew lists the difference between
-RS232
+refclock_format. The last piece of information is the overall running
+time and the accumulated times for the clock event states in
+refclock_states. When PPS information is present additional variable are
+available. refclock_ppstime lists then the PPS timestamp and
+refclock_ppsskew lists the difference between RS232
derived timestamp and the PPS timestamp.
<P>Currently, fourteen clock types (devices /dev/refclock-0 -
-/dev/refclock-3)
-are supported by the PARSE driver.
+/dev/refclock-3) are supported by the PARSE driver.
<BR>A note on the implementations:
-<UL><li>These implementations where mainly done <B><I>WITHOUT</I></B> actual
-access to the hardware. Thus not all implementations provide full
-support.
-The development was done with the help of many souls who had the
-hardware
-and where so kind to borrow me their time an patience during the
-development
-and debugging cycle. Thus for continued support and quality direct
-access
-to the receivers is a big help. Nevertheless i am not prepared to buy
-these
-reference clocks - donations to <A HREF="http://www4.informatik.uni-
-erlangen.de/~kardel">me</A>
+<UL><li>These implementations where mainly done <B><I>WITHOUT</I></B>
+actual access to the hardware. Thus not all implementations provide full
+support. The development was done with the help of many souls who had
+the hardware and where so kind to borrow me their time an patience
+during the development and debugging cycle. Thus for continued support
+and quality direct access to the receivers is a big help. Nevertheless i
+am not prepared to buy these reference clocks - donations to <A
+HREF="http://www4.informatik.uni-erlangen.de/~kardel">me</A>
(<A HREF="mailto: kardel@acm.org">kardel@acm.org</A>) are welcome as
-long
-as they work within Europe 8-).
+long as they work within Europe 8-).
<P>Verified implementations are:
<UL>
RAWDCF variants
<p>These variants are tested for the decoding with my own homegrown
-receivers.
-Interfacing with specific commercial products may involve some fiddeling
-with cables. Especially commericial RAWDCF receivers have a seemingly
-unlimited
-number of ways to draw power from the RS232 port and to encode the DCF77
-datastream. You are mainly on your own here unless i have a sample of
-the
-receiver.
+receivers. Interfacing with specific commercial products may involve
+some fiddeling with cables. Especially commericial RAWDCF receivers have
+a seemingly unlimited number of ways to draw power from the RS232 port
+and to encode the DCF77 datastream. You are mainly on your own here
+unless i have a sample of the receiver.
<LI>
<A HREF="http://www.meinberg.de">Meinberg clocks</A>
and i have access to one of these clocks.</UL>
</UL>
The pictures below refer to the respective clock and where taken from
-the
-vendors web pages. They are linked to the respective vendors.
+the vendors web pages. They are linked to the respective vendors.
<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/pzf509.htm">PZF509
-receiver</A> (FM demodulation/TCXO / 50us)</TT></B>
-<BR>
+HREF="http://www.meinberg.de/english/pzf509.htm">PZF509 receiver</A> (FM
+demodulation/TCXO / 50us)</TT></B>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 1</TT></B>
<BR><A HREF="http://www.meinberg.de/english/pzf509.htm"><IMG
SRC="pic/pzf509.jpg" ALT="BILD PZF509" HEIGHT=300 WIDTH=260
ALIGN=TEXTTOP></A>
-<BR>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 2</TT></B>
(AM demodulation / 4ms)</TT></B>
<BR><A HREF="http://www.meinberg.de/english/c51.htm"><IMG
SRC="pic/c51.jpg" ALT="BILD C51" HEIGHT=180 WIDTH=330 ALIGN=TEXTTOP></A>
-<BR>
+<BR>
<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>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 4</TT></B>
<p><B><TT>Walter Schmid DCF receiver Kit (AM demodulation /
1ms)</TT></B>
-<BR>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 5</TT></B>
<p><B><TT>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module /
5ms)</TT></B>
-<BR>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 6</TT></B>
<p><B><TT>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module
/ 5ms)</TT></B>
-<BR>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 7</TT></B>
<BR><A HREF="http://www.meinberg.de/english/gps167.htm"><IMG
SRC="pic/gps167.jpg" ALT="BILD GPS167" HEIGHT=300 WIDTH=280
ALIGN=TEXTTOP></A>
-<BR>
+<BR>
<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>
+<BR>
<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>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 10</TT></B>
<BR><A HREF="http://www.trimble.com/cgi/omprod.cgi/pd_om006.htm"><IMG
SRC="pic/pd_om006.gif" ALT="Lassen-SK8" BORDER=0 HEIGHT=100
WIDTH=420></A>
-<BR>
+<BR>
<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>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 12</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>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 13</TT></B>
<p><B><TT>Diem's Computime Radio Clock</TT></B>
-<BR>
+<BR>
<LI>
<B><TT>server 127.127.8.0-3 mode 14</TT></B>
<LI>
<B><TT>server 127.127.8.0-3 mode 15</TT></B>
-<p><B><TT>WHARTON 400A Series Clocks with a 404.2 Serial Interface</TT></B>
+<p><B><TT>WHARTON 400A Series Clocks with a 404.2 Serial
+Interface</TT></B>
</UL>
<p>
Actual data formats and set-up requirements of the various clocks can be
syslog.
<P>PPS support is only available when the receiver is completely
-synchronized.
-The receiver is believed to deliver correct time for an additional
-period
-of time after losing synchronizations, unless a disruption in time code
-transmission is detected (possible power loss). The trust period is
-dependent
-on the receiver oscillator and thus a function of clock type. This is
-one
-of the parameters in the clockinfo field of the reference clock
-implementation.
-This parameter cannot be configured by ntpdc.
+synchronized. The receiver is believed to deliver correct time for an
+additional period of time after losing synchronizations, unless a
+disruption in time code transmission is detected (possible power loss).
+The trust period is dependent on the receiver oscillator and thus a
+function of clock type. This is one of the parameters in the clockinfo
+field of the reference clock implementation. This parameter cannot be
+configured by ntpdc.
<P>In addition to the PPS loopfilter control a true PPS hardware signal
can be applied on Sun Sparc stations via the CPU serial ports on the CD
pin. This signal is automatically detected and will be used for offset
calculation. The input signal must be the time mark for the following
-time
-code. (The edge sensitivity can be selected - look into the appropriate
-kernel/parsestreams.c for details). Meinberg receivers can be connected
-by feeding the PPS pulse of the receiver via a 1488 level converter to
-Pin 8 (CD) of a Sun serial zs-port. To select PPS support the STREAMS
-driver
-for PARSE must be loaded and the mode parameter ist the mode value of
-above
-plus 128. If 128 is not added to the mode value PPS will be detected to
-be available but it will not be used. For PPS to be used you MUST add
-128
-to the mode parameter.
+time code. (The edge sensitivity can be selected - look into the
+appropriate kernel/parsestreams.c for details). Meinberg receivers can
+be connected by feeding the PPS pulse of the receiver via a 1488 level
+converter to Pin 8 (CD) of a Sun serial zs-port. To select PPS support
+the STREAMS driver for PARSE must be loaded and the mode parameter ist
+the mode value of above plus 128. If 128 is not added to the mode value
+PPS will be detected to be available but it will not be used. For PPS to
+be used you MUST add 128 to the mode parameter.
<P>For the Meinberg GPS166/GPS167 receiver is also a special firmware
-release
-available (Uni-Erlangen). This release should be used for proper
+release available (Uni-Erlangen). This release should be used for proper
operation.
<P>The raw DCF77 pulses can be fed via a level converter directly into
Pin 3 (Rx) of the Sun. The telegrams will be decoded an used for
-synchronization.
-AM DCF77 receivers are running as low as $25. The accuracy is dependent
-on the receiver and is somewhere between 2ms (expensive) to 10ms
-(cheap).
-Upon bad signal reception of DCF77 synchronizations will cease as no
-backup
-oscillator is available as usually found in other reference clock
-receivers.
-So it is important to have a good place for the DCF77 antenna. For
-transmitter
-shutdowns you are out of luck unless you have other NTP servers with
-alternate
-time sources available.
-<H4>
-Monitor Data</H4>
-clock states statistics are written hourly the the syslog service.
-Online
-information can be found by examining the clock variable via the ntpq cv
-command.
-<H4>
-Fudge Factors</H4>
+synchronization. AM DCF77 receivers are running as low as $25. The
+accuracy is dependent on the receiver and is somewhere between 2ms
+(expensive) to 10ms (cheap). Upon bad signal reception of DCF77
+synchronizations will cease as no backup oscillator is available as
+usually found in other reference clock receivers. So it is important to
+have a good place for the DCF77 antenna. For transmitter shutdowns you
+are out of luck unless you have other NTP servers with alternate time
+sources available.
-<DL>
-<DT>
-<TT>time1 <I>time</I></TT></DT>
+<H4>Monitor Data</H4>
-<DD>
-Specifies the time offset calibration factor, in seconds and fraction,
-with default depending on clock type.</DD>
+Clock states statistics are written hourly the the syslog service.
+Online information can be found by examining the clock variable via the
+ntpq cv command.
-<DT>
-<TT>time2 <I>time</I></TT></DT>
-<DD>
-Specifies the offset if the PPS signal to the actual time. (PPS fine
-tuning).</DD>
-
-<DT>
-<TT>stratum <I>number</I></TT></DT>
-
-<DD>
-Specifies the driver stratum, in decimal from 0 to 15, with default
-0.</DD>
+<H4>Fudge Factors</H4>
-<DT>
-<TT>refid <I>string</I></TT></DT>
+<DL>
-<DD>
-Specifies the driver reference identifier, an ASCII string from one to
-four characters, with default according to current clock type.</DD>
+<DT><TT>time1 <I>time</I></TT></DT>
+<DD>Specifies the time offset calibration factor, in seconds and
+fraction, with default depending on clock type.</DD>
-<DT>
-<TT>flag1 0 | 1</TT></DT>
+<DT><TT>time2 <I>time</I></TT></DT>
+<DD>Specifies the offset if the PPS signal to the actual time. (PPS fine
+tuning).</DD>
-<DD>
-Not used by this driver.</DD>
+<DT><TT>stratum <I>number</I></TT></DT>
+<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
+0.</DD>
-<DT>
-<TT>flag2 0 | 1</TT></DT>
+<DT><TT>refid <I>string</I></TT></DT>
+<DD>Specifies the driver reference identifier, an ASCII string from one
+to four characters, with default according to current clock type.</DD>
-<DD>
-Not used by this driver.</DD>
+<DT><TT>flag1 0 | 1</TT></DT>
+<DD>Not used by this driver.</DD>
-<DT>
-<TT>flag3 0 | 1</TT></DT>
+<DT><TT>flag2 0 | 1</TT></DT>
+<DD>Not used by this driver.</DD>
-<DD>
-delete next leap second instead of adding it.</DD>
+<DT><TT>flag3 0 | 1</TT></DT>
+<DD>delete next leap second instead of adding it.</DD>
<DT>
<TT>flag4 0 | 1</TT></DT>
+<DD>Delete next leap second instead of adding it - flag will be re-
+defined soon - so don't use it. Statistics are provided by more common
+means (syslog, clock variable via ntpq)</DD>
-<DD>
-Delete next leap second instead of adding it - flag will be re-defined
-soon - so don't use it. Statistics are provided by more common means
-(syslog,
-clock variable via ntpq)</DD>
</DL>
-<H4>
-Making your own PARSE clocks</H4>
-The pare clock mechanismis deviated from the way other ntp reference
-clocks
-work. For a short description how to build parse reference clocks see <A
-HREF="parsenew.htm">making
-PARSE clocks</A>
+<H4>Making your own PARSE clocks</H4>
+
+The parse clock mechanismis deviated from the way other ntp reference
+clocks work. For a short description how to build parse reference clocks
+see <A HREF="parsenew.htm">making PARSE clocks</A>
<P>Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
</address></body></html>
-
<BR>Features: <TT>ppsclock</TT> (required)
<H4>
Description</H4>
-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.htm">Line
-Disciplines and Streams Modules</A> page. It also requires a <A
-HREF="gadget.htm">gadget box</A> and 1-PPS level converter, such as
-described in the <A HREF="pps.htm">Pulse-per-second (PPS) Signal
-Interfacing</A> page.
+This driver supports the Magnavox MX 4200 Navigation Receiver adapted to
+precision timing applications. It requires the <TT>ppsclock</TT> line discipline
+or streams module described in the <A HREF="ldisc.htm">Line Disciplines
+and Streams Modules</A> page. It also requires a gadget box and 1-PPS level
+converter, such as described in the <A HREF="pps.htm">Pulse-per-second
+(PPS) Signal Interfacing</A> page.
<P>This driver supports all compatible receivers such as the 6-channel
-MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.
-
-<P>
-<A HREF="http://www.leica-gps.com/">
-<IMG SRC="pic/9400n.jpg" ALT="Leica MX9400N Navigator" 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>
-Leica MX9400N Navigator.
-
-<P>
-
+MX 4200, MX 4200D, and the 12-channel MX 9212, MX 9012R, MX 9112.
<H4>
Operating Modes</H4>
This driver supports two modes of operation, static and mobile, controlled
for a fixed station. A DOP-weighted running average position is calculated
from this data. After 24 hours, the receiver is placed into a "Known Position"
mode, initialized with the calculated position, and then solves only for
-time.
+time. The position averaging algorithm does not take into account boundary
+conditions, so this mode of operation very near the international date
+line or the poles is not recommended.
<P>In mobile mode, the driver assumes the GPS antenna is mounted on a moving
platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic,
<H4>
Monitor Data</H4>
The driver writes each timecode as received to the <TT>clockstats</TT>
-file. Documentation for the <CITE>NMEA-0183</CITE> proprietary
-sentences produced by the MX4200 can be found in
-<A HREF="mx4200data.htm">MX4200 Receiver Data Format</A>.
-
+file.
<H4>
Fudge Factors</H4>
</DL>
Additional Information
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
+<P><A HREF="refclock.htm">Reference Clock Drivers</A>
<HR>
<ADDRESS>
David L. Mills (mills@udel.edu)</ADDRESS>
<p><center><i>T</i>(<i>t</i>) = <i>T</i>(<i>t</i><sub>0</sub>) +
<i>R</i>(<i>t - t</i><sub>0</sub>) + 1/2 <i>D</i>(<i>t -
-t</i><sub>0</sub>)<sup>2</sup>,</center>
+T</i><sub>0</sub>)<sup>2</sup>,</center>
<p>where <i>t</i> is the current time, <i>T</i> is the time offset at
the last measurement update <i>t</i><sub>0</sub>, <i>R</i> is the
<ol>
-<li>Cristian, F. Probabilistic clock synchronization. In Distributed
+<p><li>Cristian, F. Probabilistic clock synchronization. In Distributed
Computing 3, Springer Verlag, 1989, 146-158.</li>
-<li>Digital Time Service Functional Specification Version T.1.0.5.
-Digital Equipment Corporation, 1989.</li>
+<p><li>Digital Time Service Functional Specification Version T.1.0.5.
+DigitalEquipment Corporation, 1989.</li>
-<li>Gusella, R., and S. Zatti. TEMPO - A network time controller for
+<p><li>Gusella, R., and S. Zatti. TEMPO - A network time controller for
a distributed Berkeley UNIX system. IEEE Distributed Processing
Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in:
Proc. Summer 1984 USENIX (Salt Lake City, June 1984).</li>
-<li>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
+<p><li>Kopetz, H., and W. Ochsenreiter. Clock synchronization in
distributed real-time systems. IEEE Trans. Computers C-36, 8 (August
1987), 933-939.</li>
-<li>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
+<p><li>Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
presence of faults. JACM 32, 1 (January 1985), 52-78.</li>
-<li>Marzullo, K., and S. Owicki. Maintaining the time in a
+<p><li>Marzullo, K., and S. Owicki. Maintaining the time in a
distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-
54.</li>
-<li>Mills, D.L. Internet time synchronization: the Network Time
+<p><li>Mills, D.L. Internet time synchronization: the Network Time
Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-
1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and
Time in Distributed Systems, IEEE Press, Los Alamitos, CA, 91-102.</li>
-
-<li>Mills, D.L. Modelling and analysis of computer network clocks.
+<p><li>Mills, D.L. Modelling and analysis of computer network clocks.
Electrical Engineering Department Report 92-5-2, University of Delaware,
May 1992, 29 pp.</li>
-<li>NIST Time and Frequency Dissemination Services. NBS Special
-Publication 432 (Revised 1990), National Institute of Science and
+<p><li>NIST Time and Frequency Dissemination Services. NBS Special
+Publication432 (Revised 1990), National Institute of Science and
Technology, U.S. Department of Commerce, 1990.</li>
-<li>Schneider, F.B. A paradigm for reliable clock synchronization.
+<p><li>Schneider, F.B. A paradigm for reliable clock synchronization.
Department of Computer Science Technical Report TR 86-735, Cornell
University, February 1986.</li>
-<li>Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM
+<p><li>Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM
34, 3 (July 1987), 626-645.</li>
-<li>Stein, S.R. Frequency and time - their measurement and
+<p><li>Stein, S.R. Frequency and time - their measurement and
characterization (Chapter 12). In: E.A. Gerber and A. Ballato (Eds.).
Precision Frequency Control, Vol. 2, Academic Press, New York 1985, 191-
232, 399-416. Also in: Sullivan, D.B., D.W. Allan, D.A. Howe and F.L.
</ol>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
<br><code>sst0126.lpr</code> - pcb silkscreen mask (side 1)
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
</h3><hr>
<p>This is an index for a set of troubleshooting notes contained in
-individual text files in the <tt>./html/hints</tt> directory. They were
+individual text files in the <tt>./hints</tt> directory. They were
supplied by various volunteers in the form of mail messages, patches or
just plain word of mouth. Each note applies to a specific computer and
operating system and gives information found useful in setting up the
operating system (specific version(s) where appropriate), problem
description, problem solution and submitter's name and electric address.
If the submitter is willing to continue debate on the problem, please so
-advise. Bash <a href=http:hints/>here</a> for a directory listing.
+advise. Bash <a href=http:hints>here</a> for a directory listing.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
<P>
Instead of the <I>tick</I> kernel variable, which many operating
systems use to control microseconds added to the system time every
-clock tick (cf. <A HREF="../notes.htm#frequency_tolerance">Dealing
+clock tick (c
.f. <A HREF="../notes.htm#frequency_tolerance">Dealing
with Frequency Tolerance Violations</A>), Solaris has the variables
<I>nsec_per_tick</I> and <I>usec_per_tick</I>.
<P>
<H3>Solaris 2.6</H3>
<P>
Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this
-support in such a fashion that using it
is worse than not. This is <A
-HREF="solaris.xtra.4095849"> Sun Bug ID 4095849</A>, and it is not yet
+support in such a fashion that using it worse than not. This is <A
+HREF="solaris.xtra.4095849"> SUN Bug ID 4095849</A>, and it is not yet
fixed as of June 1998.
<P>
<H3>Solaris 2.5 and 2.5.1</H3>
On UltraSPARC systems, calculation of <I>cpu_tick_freq</I> is broken
such that values that are off by significant amounts may be used
instead. This unfortunately means that ntpd may have severe problems
-keeping synchronization. This is <A HREF="solaris.xtra.4023118"> Sun Bug ID
+keeping synchronization. This is <A HREF="solaris.xtra.4023118"> SUN Bug ID
4023118</A>. Bryan Cantrill <! -- <bmc@eng.sun.com> --> of Sun
posted <A HREF="solaris.xtra.patchfreq">patchfreq</A>, a workaround script,
to comp.protocols.time.ntp in March of 1997.
The second ntpdate will use adjtime to set the time of day since the
clock should be within 2 seconds of the correct time.
<P>
-The second tickadj sets the tick adjust system value to 200 microseconds.
+The second tickadj set the tick adjust system value to 5 microseconds.
<P>
The second sleeps insure that adjtime will complete before starting
-xntpd.
+the next xntpd.
<P>
-I tried running with a tickadj of 5 microseconds without much success.
+I tried running with a tickadj of 5 microseconds with out much success.
200 microseconds seems to work well.
<P>
<HR>
</dl>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
year-2000 issues can be found in the <A HREF=y2k.htm>Year 2000
Conformance Statement page</A>. Background information, bibliography and
briefing slides suitable for presentations can be found in the <A
-HREF="http://www.eecis.udel.edu/~mills/ntp.htm"> Network Time
+HREF=http://www.eecis.udel.edu/~mills/ntp.htm> Network Time
Synchronization Project</A> page.
<H4>Building and Installing NTP</H4>
operating at stratum two and so on to higher strata. In this hierarchy,
clients are simply servers that have no dependents.
-<P>The NTP subnet in early 1999 includes 79 public primary (stratum 1)
+<P>The NTP subnet in early 1998 includes 70 public primary (stratum 1)
servers synchronized directly to UTC by radio, satellite or modem and
-located in every continent of the globe except Antarctica (soon).
+located in every continent of the globe, except Antarctica (soon).
Normally, client workstations and servers with a relatively small number
-of clients do not synchronize to primary servers. There are over 100
-public secondary (stratum 2) servers synchronized to the primary servers
-and providing synchronization to a total in excess of 100,000 clients
-
and servers in the Internet. The current lists are maintained in the <A
-HREF="http://www.eecis.udel.edu/~mills/ntp/index.htm">Information on Time
+of clients do not synchronize to primary servers. There are 106 public
+secondary (stratum 2) servers synchronized to the primary servers and
+providing synchronization to a total in excess of 100,000 clients and
+servers in the Internet. The current lists are maintained in the <A
+HREF=http://www.eecis.udel.edu/~mills/ntp/index.htm>Information on Time
and Frequency Services</A> page, which is updated frequently. There are
numerous private primary and secondary servers not normally available to
the public as well. You are strongly discouraged from using these
to the outside world and your traffic can bring up expensive ISDN lines,
causing much grief and frustration.
-<p>In some cases where a network is isolated from the Internet and no
-external synchronization source is available, one of the network hosts
-can be designated as the primary server and the others operate as
-clients. In these cases the network hosts will be synchronized, but not
-necessarily to standard civil time. Even if an external synchronization
-source is available, a host can be designated as backup server in the
-event the external source becomes unreachable or inoperable. A host
-operating as the primary or backup server is configured with the <a
-href=driver1.htm>Undisciplined Local Clock</a> driver. The configuration
-options provide for a stratum number to be assigned to the server,
-usually one for a primary server and three or more for a backup server.
-
-<h4>Performance Expectations</h4>
-
-<p>In the majority of cases, the NTP subnet can keep the clock within a
-few milliseconds on LANs and a few tens of milliseconds on WANs.
-However, in some cases with network jitter of several hundred
-milliseconds or more, the clock discipline loop may not be able to
-converge to a stable frequency. In such cases, a large fraction of the
-time sample corrections are greater than the 128-ms step threshold and
-valid updates which can discipline the clock frequency are sparse. In
-these cases, the <tt>burst</tt> keyword should be used with the
-corresponding <tt>server</tt> line in the configuration file. This
-causes eight volleys in each measurement round, following which the best
-candidate is determined and used to discipline the clock. See the <a
-href=confopt.htm>Configuration Options</a> page for further information.
-
-<p>When multiple servers are configured, the NTP algorithms operate to
-determine the best combination providing the highest accuracy.
-However, there may be small systematic differences in the apparent time
-of each server due to the different network paths involved. In practice,
-this can lead to occasional <i>clockhopping</i> between servers and
-result in increased jitter as seen by the clock discipline algorithm.
-Usually, a favored server can be selected so that, under most
-circumstances, only that server is used and the others disregarded. The
-favored server is identified by the <tt>prefer</tt> keyword in the
-corresponding <tt>server</tt> or <tt>peer</tt> line in the configuration
-file. See the <a href=prefer.htm>Mitigation Rules and the
-<TT>prefer</TT> Keyword</a> page for further information.
-
-<p>In general, as the poll interval increases, so does the expected
-error. When the highest accuracy is required, the poll interval should
-be clamped at a low value using the <tt>maxpoll</tt> keyword in the
-corresponding <tt>server</tt> or <tt>peer</tt> line in the configuration
-file. A typical argument value is 6, which results in a poll interval of
-64 seconds. This should be done only sparingly, since it results in an
-increased load on the network. Where means are available, steps should
-be taken to minimize the ambient temperature variations, since the clock
-frequency is temperature dependent.
-
-<p>For the best accuracy, latencies in the hardware and software should
-by minimized wherever possible. Consider using the <tt>tty_clk</tt> line
-discipline, if available. Where available, interrupt-driven I/O is
-preferred over polled I/O. When means are available, the scheduling
-priority can be raised to avoid preempting the NTP daemon by other
-processes. This can be done using the <tt>-P</tt> option on the
-<tt>ntpd</tt> command line. However, this can lead to trouble should the
-daemon stumble on an endless program loop. While this is a "cannot
-happen" event, the possibility of this kind of bug should be considered
-in the overall robustness model for the client or server. See the <a
-href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a>
-page for further information.
-
-<p>The very best accuracy can be achieved only by using an external
-discipline signal, such as a pulse-per-second (PPS) or Inter-Range
-Instrumentation Group (IRIG) signal. This requires external connection
-via a serial port or audio codec. See the <a href=refclock.htm>Reference
-Clock Drivers</a> page for further information and links to device
-drivers. Using the PPS signal and kernel support, for example,
-accuracies of a few microseconds can be achieved with modern workstation
-hardware.
-
<H4>Resolving Problems</H4>
-Like other things on the Internet, the NTP synchronization subnets tend to be
+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
driver construction and debugging can be found in the <A
HREF=refclock.htm>Reference Clock Drivers </A>page. Further
information on NTP in the Internet can be found in the <A
-HREF="http://www.eecis.udel.edu/~ntp">NTP web page</A>.
+HREF=http://www.eecis.udel.edu/~ntp>NTP
+web page</A>.
<H4>Program Manual Pages</H4>
<ul>
-<LI><A HREF=http://www.eecis.udel.edu/~mills/ntp.htm>NTP Reference Library</A></LI>
+<LI<A HREF=ntp.htm>NTP Reference Library</A></LI>
<LI><A HREF=copyright.htm>Copyright Notice</A></LI>
<LI><A HREF=exec.htm>Executive Summary - Computer Network Time
Synchronization</A></LI>
</ul>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
<P>The hybrid PLL/FLL has been implemented in the Unix kernels for
several workstations, including those made by Sun Microsystems, Digital
and Hewlett Packard. Currently, the modifications are in licensed
-kernels beginning with Digital Unix 4.0 and Sun Solaris 2.6. Since these
-specific implementations involve modifications to licensed code, they
-cannot be provided directly. Inquiries should be directed to the
-manufacturer's representatives. In addition to the licensed kernels, the
-hybrid PLL/FLL has been implemented in the nonlicensed kernels for Linux
-and FreeBSD. The current engineering model for these implementations,
-including a simulator with code segments almost identical to the
-implementations, but not involving licensed code, is available via the
-web at <A
-HREF="http://www.eecis.udel.edu/~mills/ntp/ntp">nanokernel.tar.Z</A> or
-by anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
-The current version has an ultimate resolution of one nanosecond, while
-previous versions are limited to one microsecond.
+kernels for Digital Unix 4.0 and Sun Solaris 2.6. Since these specific
+implementations involve modifications to licensed code, they cannot be
+provided directly. Inquiries should be directed to the manufacturer's
+representatives. In addition to the licensed kernels, the hybrid PLL/FLL
+has been implemented in the nonlicensed kernels for Linux and FreeBSD.
+The engineering model for these implementations, including a simulator
+with code segments almost identical to the implementations, but not
+involving licensed code, is available via the web at <A
+HREF="http://www.eecis.udel.edu/~mills/ntp/ntp">kernel.tar.Z</A> or by
+anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory.
<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 a
-pulse-per-second (PPS) signal. The model incorporates a generic
-system-call interface for use with the Network Time Protocol (NTP) or similar
-time synchronization protocol. The NTP software daemons for Version 3
-<TT>xntpd</TT> and Version 4 <TT>ntpd</TT> operate with this model to
-provide synchronization limited in principle only by the accuracy and
+frequency to an external precision timing source, such as a pulse-per-
+second (PPS) signal. The model incorporates a generic system-call
+interface for use with the Network Time Protocol (NTP) or similar time
+synchronization protocol. The NTP software daemons for Version 3
+<TT>xntpd</TT> and Version 4 <TT>ntpd</TT> operate with this model
+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 the model, <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. Further
information on the calling sequences and variable definitions are in the
-<TT>/usr/include/sys/timex.h</TT> file.
-
-<p>If the <TT>/usr/include/sys/timex.h</TT> file is present when the
-distribution is built, code to use the hybrid PLL/FLL features is
-automatically generated. If necessary, these features can be disabled
-using the <tt>disable kernel</tt> configuration command. In this case,
-operation reverts to the standard NTP clock discipline algorithms
-included in the daemon.
+<TT>/usr/include/sys/timex.h</TT> file.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
converter/pulse generator.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
techniques found useful in practice.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
default when this command is not used is 0.004 seconds.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>trap <I>host_address</I> [port <I>port_number</I>] [interface <I>interface_address</I>]</TT></DT>
no messages are lost when the server is started.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>setvar <I>variable</I> [default]</TT></DT>
variables.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>logfile <I>logfile</I></TT></DT>
instead of the default system <TT>syslog</TT> facility.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>logconfig <I>configkeyword</I></TT></DT>
default, all output is turned on. All <I><TT>configkeyword</TT></I> keywords
can be prefixed with <TT>=</TT>, <TT>+</TT> and <TT>-</TT>, where <TT>=</TT>
sets the <TT>syslogmask</TT>, <TT>+</TT> adds and <TT>-</TT> removes messages.
-<TT>syslog</TT> messages can be controlled in four classes (<tt>clock</tt>, <TT>peer</TT>,
+<TT>syslog messages</TT> can be controlled in four classes (, <TT>peer</TT>,
<TT>sys</TT> and <TT>sync</TT>). Within these classes four types of messages
can be controlled.</DD>
Informational messages (<TT>info</TT>) control configuration information.
Event messages (<TT>events</TT>) control logging of events (reachability,
synchronization, alarm conditions). Statistical output is controlled with
-the <TT>statistics</TT> keyword. The final message group is the <TT>status</TT>
+the <TT>statistics</TT> keyword. The final message group is the status
messages. This describes mainly the synchronizations status. Configuration
keywords are formed by concatenating the message class with the event class.
-The <TT>all</TT> prefix can be used instead of a message class. A message
+The <TT>allprefix</TT> can be used instead of a message class. A message
class may also be followed by the <TT>all</TT> keyword to enable/disable
all messages of the respective message class.</DD>
Thus, a minimal log configuration could look like this:</DD>
<DD>
-<TT>logconfig =syncstatus +sysevents</TT></DD>
+<TT>logconfig = syncstatus +sysevents</TT></DD>
<DD>
This would just list the synchronizations state of <TT>ntpd</TT> and the
message configuration could be useful:</DD>
<DD>
-<TT>logconfig =syncall +clockall</TT></DD>
+<TT>logconfig = syncall +clockall</TT></DD>
<DD>
This configuration will list all clock information and synchronization
<H4>
Variables</H4>
Most variables used by the NTP protocol can be examined with the <TT>ntpdc</TT>
-(mode 7 messages) and the <TT>ntpq</TT> (mode 6 messages) programs. Currently, very
+(mode 7 messages) and the <TT>ntpq</TT> (mode 6 messages). Currently, very
few variables can be modified via mode 6 messages. These variables are
either created with the <TT>setvar</TT> directive or the leap warning bits.
The leap warning bits can be set in the <TT>leapwarning</TT> variable up
is passed on).</DD>
</DL>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
continuous, long term recording of server and client timekeeping performance.
See the <TT>statistics</TT> command below for a listing and example of
each type of statistics currently supported. Statistic files are managed
-using file generation sets and scripts in the <TT>./scripts</TT> directory of this
+using file generation sets and scripts in the ./scripts directory of this
distribution. Using these facilities and Unix <TT>cron</TT> jobs, the data
can be automatically summarized and archived for retrospective analysis.
<H4>
Enables writing of statistics records. Currently, three kinds of <I><TT>name</TT></I>
statistics are supported.</DD>
+<DD>
+ </DD>
+
+<DL>
<DT>
<TT>loopstats</TT></DT>
<DD>
Enables recording of loop filter statistics information. Each update of
the local clock outputs a line of the following form to the file generation
-set named <TT>loopstats</TT>:
+set named <TT>loopstats</TT>:</DD>
<PRE>50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 6</PRE>
(seconds), frequency offset (parts per million - PPM), RMS jitter (seconds),
Allan deviation (PPM) and clock discipline time constant.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>peerstats</TT></DT>
Enables recording of peer statistics information. This includes statistics
records of all peers of a NTP server and of special signals, where present
and configured. Each valid update appends a line of the following form
-to the current element of a file generation set named <TT>peerstats</TT>:
+to the current element of a file generation set named <TT>peerstats</TT>:</DD>
<PRE>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142</PRE>
1305. The final three fields show the offset, delay and RMS jitter, all
in seconds.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>clockstats</TT></DT>
<DD>
Enables recording of clock driver statistics information. Each update received
from a clock driver appends a line of the following form to the file generation
-set named <TT>clockstats</TT>:
+set named <TT>clockstats</TT>:</DD>
<PRE>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</PRE>
drivers a good deal of additional information can be gathered and displayed
as well. See information specific to each clock for further details.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>rawstats</TT></DT>
clock driver appends a line of the following form to the file generation
set named <TT>rawstats</TT>:</DD>
+<DD>
+ </DD>
+
<DD>
<TT>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031
02453332.540806000 3102453332.541458000</TT></DD>
<DD>
-<TT> </TT></DD>
+<TT> </TT></DD>
<DD>
The first two fields show the date (Modified Julian Day) and time (seconds
receive, transmit and final NTP timestamps in order. The timestamp values
are as received and before processing by the various data smoothing and
mitigation algorithms.</DD>
+</DL>
+
+<DD>
+ </DD>
<DT>
<TT>statsdir <I>directory_path</I></TT></DT>
for handling statistics logs.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>filegen <I>name</I> [file <I>filename</I>] [type <I>typename</I>] [link
| nolink] [enable | disable]</TT></DT>
<DT>
-<TT> </TT></DT>
+<TT> </TT></DT>
<DD>
Configures setting of generation file set <I>name</I>. Generation file
they can be removed to free space for new data produced.)</DD>
<DD>
- </DD>
+ </DD>
<DD>
Note that this command can be sent from the <TT>ntpdc</TT> program running
at a remote location.</DD>
+<DD>
+ </DD>
+
+<DL>
<DT>
<I><TT>name</TT></I></DT>
command.</DD>
<DD>
-<TT>file <I>filename</I></TT>
+ </DD>
+</DL>
+
+<DD>
+<TT>file <I>filename</I></TT></DD>
-<DD>This is the file name for the statistics records. Filenames of set members
+<DL>
+<DD>
+This is the file name for the statistics records. Filenames of set members
are built from three elements:</DD>
+<DD>
+ </DD>
+
+<DL>
<DT>
prefix</DT>
<TT>loopstats</TT> and <TT>peerstats</TT> generation can be configured
using the <TT>statsdir</TT> option explained above.</DD>
+<DD>
+ </DD>
+
<DT>
<I><TT>filename</TT></I></DT>
allowed in this component to prevent filenames referring to parts outside
the filesystem hierarchy denoted by <TT>prefix</TT>.</DD>
+<DD>
+ </DD>
+
<DT>
suffix</DT>
<DD>
This part is reflects individual elements of a file set. It is generated
according to the type of a file set.</DD>
+</DL>
+
+<DD>
+ </DD>
+</DL>
-<DT><TT>type <I>typename</I></TT></DT>
+<DD>
+<TT>type <I>typename</I></TT></DD>
+<DL>
<DD>
A file generation set is characterized by its type. The following types
are supported:</DD>
+<DD>
+ </DD>
+
+<DL>
<DT>
<TT>none</TT></DT>
<DD>
The file set is actually a single plain file.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>pid</TT></DT>
strings, and appending the decimal representation of the process ID of
the <TT>ntpd</TT> server process.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>day</TT></DT>
written at 10 December 1992 would end up in a file named <TT><I>prefix
filename</I>.19921210</TT>.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>week</TT></DT>
letter <TT>W</TT>, and a 2-digit week number. For example, information
from January, 10th 1992 would end up in a file with suffix <TT>.1992W1</TT>.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>month</TT></DT>
One generation file set element is generated per month. The file name suffix
consists of a dot, a 4-digit year number, and a 2-digit month.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>year</TT></DT>
One generation file element is generated per year. The filename suffix
consists of a dot and a 4 digit year number.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>age</TT></DT>
a dot, the letter <TT>a</TT>, and an 8-digit number. This number is taken
to be the number of seconds the server is running at the start of the corresponding
24-hour period. Information is only written to a file generation by specifying
-<TT>enable</TT>; output is prevented by specifying <TT>disable</TT>.</DD>
+<TT>enabl</TT>; output is prevented by specifying <TT>disable</TT>.</DD>
+
+<DD>
+ </DD>
+</DL>
+</DL>
<DD>
-<TT>link | nolink</TT>
+<TT>link | nolink</TT></DD>
+<DL>
<DD>
It is convenient to be able to access the current element of a file generation
set by a fixed name. This feature is enabled by specifying <TT>link</TT>
to be accessed by a constant name.</DD>
<DD>
-<TT>enable | disable</TT>
+ </DD>
+</DL>
+
+<DD>
+<TT>enable | disable</TT></DD>
+<DL>
<DD>
Enables or disables the recording function.</DD>
</DL>
+</DL>
+
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
<HTML><HEAD><TITLE>
-Notes on Configuring NTP and Setting up a NTP Subnet
-</TITLE></HEAD><BODY>
-<H3>Notes on Configuring NTP and Setting up a NTP Subnet</H3>
+Notes on Configuring NTP and Setting up a NTP Subnet</H3>
+</TITLE></HEAD><BODY><H3>
+Notes on Configuring NTP and Setting up a NTP Subnet</H3>
+</H3>
<img align=left src=pic/tonea.gif>
From NBS Special Publication 432 (out of print)
<H4>Introduction</H4>
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
+relatedprograms, 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
<ul>
-<li>Mills, D.L. Network Time Protocol (Version 3) specification,
+<p><li>Mills, D.L. Network Time Protocol (Version 3) specification,
implementation and analysis. Network Working Group Report RFC-1305,
University of Delaware, March 1992, 113 pp. Abstract: <a
-href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps">
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf">
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf>
PDF</a>, Body: <a
-href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps">
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf">
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf>
PDF</a>, Appendices: <a
-href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps>
PostScript</a> | <a
-href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf">
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf>
PDF</a>
</ul>
-Additional features are described for <A HREF="release.htm">NTP
+Additional features
have are described for <A HREF="release.htm">NTP
Version 4</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
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 extension to the
+considerable amount of internal detail. As extensions to the
specification, a flexible address-and-mask restriction facility has been
included.
including two remote-monitoring programs (<A HREF="ntpq.htm">
<TT>ntpq</TT></A>, <TT><A HREF="ntpdc.htm">ntpdc</A></TT>), a remote
clock-setting program similar to the Unix rdate program
-(<TT>ntpdate</TT>), a traceback utility useful to discover suitable
+(<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
may not result in any sort of useful synchronization of the clocks, even
if you don't care about UTC. However, in networks isolated from UTC
sources,
-provisions can be made to nominate one of them as a phantom UTC source.
+provisions can made to nominate one of them as a phantom UTC source.
<P>NTP operates on the premise that there is one true standard time, and
that if several servers which claim synchronization to standard time
to supply time to the remote server if need be. This mode is appropriate
in configurations involving a number of redundant time servers
interconnected
-via diverse network paths, which is presently the case for most stratum-1
+via diverse network paths, which is presently the case for most stratum-
+1
and stratum-2 servers on the Internet today. Configuring an association
in client mode (usually indicated by a <TT>server</TT> declaration in
the
Symmetric modes are most often used between two or more servers
operating
as a mutually redundant group. In these modes, the servers in the group
-arrange the synchronization paths for maximum performance,
+members arrange the synchronization paths for maximum performance,
depending
on network jitter and propagation delay. If one or more of the group
members
of associations to the primary sources of synchronization are disrupted
due to failures.</LI>
+<BR>
<LI>
Don't configure peer associations with higher stratum servers. Let the
higher strata configure lower stratum servers, but not the reverse. This
much greater configuration churn in the high stratum clients such as
personal
workstations.</LI>
-
+<BR>
<LI>
Don't synchronize more than one time server in a particular
administrative
A working configuration file might look like (in this and other
examples,
do not copy this directly):
-<PRE>
- # peer configuration for host whimsy
- # (expected to operate at stratum 2)
+<PRE> # peer configuration for host whimsy
+ # (expected to operate at stratum 2)
- server rackety.udel.edu
- server umd1.umd.edu
- server lilben.tn.cornell.edu
+ server rackety.udel.edu
+ server umd1.umd.edu
+ server lilben.tn.cornell.edu
- driftfile /etc/ntp.drift
-</PRE>
+ driftfile /etc/ntp.drift</PRE>
(Note the use of host names, although host addresses in dotted-quad
notation
can also be used. It is always preferable to use names rather than
<TT>manycastclient
</TT>command can be used to change the default. In unconfigured
(ephemeral)
-associations, the daemon always replies in the same version as the
+associaitons, the daemon always replies in the same version as the
request.
<P>An NTP implementation conforming to a previous version specification
ordinarily discards packets from a later version. However, in most
respects
-documented in RFC-1305, the version 2 implementation is compatible with
+documented in RFC-1305, The version 2 implementation is compatible with
the version 3 algorithms and protocol. The version 1 implementation
contains
most of the version 2 algorithms, but without important features for
this, <TT>ntpd</TT> allows a qualifier to be added to configuration
entries
to indicate which version to use when polling. Hence the entries
-<PRE>
- # specify NTP version 1
+<PRE> # specify NTP version 1
- server mimsy.mil version 1 # server running ntpd version 1
- server apple.com version 2 # server running ntpd version 2
-</PRE>
+ server mimsy.mil version
+1 # server running ntpd version 1
+ server apple.com version
+2 # server running ntpd version 2</PRE>
will cause version 1 packets to be sent to the host mimsy.mil and
version
2 packets to be sent to apple.com. If you are testing <TT>ntpd</TT>
normally
enabled, but can be disabled if desired using the configuration file
entry:
-<PRE>
- # disable monitoring feature
- disable monitor
-</PRE>
+<PRE> # disable monitoring feature
+ disable monitor</PRE>
The recorded information can be displayed using the <TT>ntpdc</TT> query
program, described briefly below.
<H4>
is compared to each entry in the list, with a match being posted when
the
following is true:
-<PRE> (source_addr & mask) == (address & mask)</PRE>
+<PRE> (source_addr & mask) == (address &
+mask)</PRE>
A particular source address may match several list entries. In this case
the entry with the most one bits in the mask is chosen. The flags
associated
that,
a time source on net 128.100. The following entries in the configuration
file would implement this policy:
-<PRE>
- # by default, don't trust and don't allow modifications
+<PRE> # by default, don't trust and don't allow
+modifications
- restrict default notrust nomodify
+ restrict default notrust nomodify
- # these guys are trusted for time, but no modifications allowed
+ # these guys are trusted for time, but no
+modifications allowed
- restrict 128.100.0.0 mask 255.255.0.0 nomodify
- restrict 128.8.10.1 nomodify
- restrict 192.35.82.50 nomodify
+ restrict 128.100.0.0 mask 255.255.0.0 nomodify
+ restrict 128.8.10.1 nomodify
+ restrict 192.35.82.50 nomodify
- # the local addresses are unrestricted
+ # the local addresses are unrestricted
- restrict 128.100.100.7
- restrict 127.0.0.1
-</PRE>
+ restrict 128.100.100.7
+ restrict 127.0.0.1</PRE>
The first entry is the default entry, which all hosts match and hence
which
provides the default set of flags. The next three entries indicate that
DES
algorithm is not included in the current distribution. Directions for
obtaining
-it in other countries
are in the <A HREF="build.htm">Building and
+it in other countries
is in the <A HREF="build.htm">Building and
Installing
the Distribution</A> page. With either algorithm the receiving peer
recomputes
Hence,
for a server running in authenticated mode, the configuration file might
look similar to the following:
-<PRE>
- # peer configuration for 128.100.100.7
- # (expected to operate at stratum 2)
- # fully authenticated this time
-
- peer 128.100.49.105 key 22 # suzuki.ccie.utoronto.ca
- peer 128.8.10.1 key 4 # umd1.umd.edu
- peer 192.35.82.50 key 6 # lilben.tn.cornell.edu
-
- keys /usr/local/etc/ntp.keys # path for key file
- trustedkey 1 2 14 15 # define trusted keys
- requestkey 15 # key (7) for accessing server variables
- controlkey 15 # key (6) for accessing server variables
-
- authdelay 0.000094 # authentication delay (Sun4c/50 IPX)
-</PRE>
+<PRE> # peer configuration for 128.100.100.7
+ # (expected to operate at stratum 2)
+ # fully authenticated this time
+
+ peer 128.100.49.105 key 22 #
+suzuki.ccie.utoronto.ca
+ peer 128.8.10.1 key 4 #
+umd1.umd.edu
+ peer 192.35.82.50 key 6 #
+lilben.tn.cornell.edu
+
+ keys /usr/local/etc/ntp.keys # path for
+key file
+ trustedkey 1 2 14 15 #
+define trusted keys
+ requestkey
+15 #
+key (7) for accessing server variables
+ controlkey
+15 #
+key (6) for accessing server variables
+
+ authdelay
+0.000094 # authentication delay
+(Sun4c/50 IPX)</PRE>
There are a couple of previously unmentioned things in here. The
<TT>keys
</TT>line specifies the path to the keys file (see below and the
prevent
unauthorized modification of daemon variables.
-<P>Ordinarily, the authentication delay, that is, the processing time
+<P>Ordinarily, the authentication delay; that is, the processing time
taken
between the freezing of a transmit timestamp and the actual transmission
of the packet when authentication is enabled (i.e. more or less the time
</A>program included in the distribution. The usage is illustrated by
the
following:
-<PRE>
- # for DES keys
+<PRE> # for DES keys
- authspeed -n 30000 auth.samplekeys
- # for MD5 keys
+ authspeed -n 30000 auth.samplekeys
+ # for MD5 keys
- authspeed -mn 30000 auth.samplekeys
-</PRE>
+ authspeed -mn 30000 auth.samplekeys</PRE>
Additional utility programs included in the <TT>./authstuff</TT>
directory
can be used to generate random keys, certify implementation correctness
key IDs the server knows about (for obvious reasons this file is better
left unreadable by anyone except root). The contents of this file might
look like:
-<PRE>
- # ntp keys file (ntp.keys)
- 1 N 29233E0461ECD6AE # des key in NTP format
- 2 M RIrop8KPPvQvYotM # md5 key as an ASCII random string
- 14 M sundial # md5 key as an ASCII string
- 15 A sundial # des key as an ASCII string
-
- # the following 3 keys are identical
-
- 10 A SeCReT
- 10 N d3e54352e5548080
- 10 S a7cb86a4cba80101
-</PRE>
+<PRE> # ntp keys file (ntp.keys)
+ 1 N
+29233E0461ECD6AE # des key in NTP format
+ 2 M
+RIrop8KPPvQvYotM # md5 key as an ASCII random string
+ 14 M
+sundial  
+; # md5 key as an ASCII string
+ 15 A
+sundial  
+; # des key as an ASCII string
+
+ # the following 3 keys are identical
+
+ 10 A SeCReT
+ 10 N
+d3e54352e5548080
+ 10 S
+a7cb86a4cba80101</PRE>
In the keys file the first token on each line indicates the key ID, the
second token the format of the key and the third the key itself. There
-are four key formats. An <TT>A</TT> indicates a DES key written as a
-1-to-8
+are four key formats. An <TT>A</TT> indicates a DES key written as a 1-
+to-8
character string in 7-bit ASCII representation, with each character
standing
for a key octet (like a Unix password). An <TT>S</TT> indicates a DES
<TT>ntptrace</TT> and <TT>ntpdc</TT>. <TT>ntpq</TT> is a handy program
which sends queries and receives responses using NTP standard mode-6
control
-messages. Since it uses the standard control protocol specified in RFC-1305,
+messages. Since it uses the standard control protocol specified in RFC-
+1305,
it may be used with NTP Version 2 and Version 3 implementations for both
Unix and Fuzzball, but not Version 1 implementations. It is most useful
to query remote NTP implementations to assess timekeeping accuracy and
variable (up to one month ahead) and in the <TT>leap_indication</TT>
variable
have a slightly different encoding than the usual interpretation:
-<PRE>
-Value Action
-
-00 The daemon passes the leap bits of its
- synchronisation source (usual mode of operation)
-
-01/10 A leap second is added/deleted
-
-11 Leap information from the synchronization source
- is ignored (thus LEAP_NOWARNING is passed on)
-</PRE>
+<PRE>
+Value Action
+
+
+00 &nbs
+p; The daemon passes the leap bits of its
+
+
+synchronisation source (usual mode of operation)
+
+ 01/10 A leap
+second is added/deleted
+
+
+11 &nbs
+p; Leap information from the synchronization source
+
+ is
+ignored (thus LEAP_NOWARNING is passed on)</PRE>
Mode-6 and mode-7 messages which would modify the configuration of the
server are required to be authenticated using standard NTP
authentication.
fragment
might be added to a configuration file to enable the mode-6 (ntpq) and
mode-7 (ntpdc) facilities in the daemon:
-<PRE>
- # specify mode-6 and mode-7 trusted keys
+<PRE> # specify mode-6 and mode-7 trusted keys
- requestkey 65535 # for mode-7 requests
- controlkey 65534 # for mode-6 requests
-</PRE>
+ requestkey 65535 # for mode-7
+requests
+ controlkey 65534 # for mode-6
+requests</PRE>
If the <TT>requestkey</TT> and/or the <TT>controlkey</TT> configuration
declarations are omitted from the configuration file, the corresponding
run-time reconfiguration facility is disabled.
This
variable controls whether to synchronize the system clock to the time-
of-day
-clock, something you really don't want to happen when <TT>ntpd</TT>
+clock, something you really don't want to be happen when <TT>ntpd</TT>
is trying to keep it under control. In some systems, such as recent Sun
Solaris kernels, the <TT>dosynctodr </TT>variable is the only one that
can be changed by the <TT>tickadj </TT>program. In this and other modern
Multiply the time change over the day by 0.116 and add or subtract the
result to tick, depending on whether the CPU is fast or slow. An example
call to <TT>tickadj</TT> useful on SunOS 4.1.1 is:
-<PRE> <TT>tickadj</TT> -t 9999 -a 5 -s</PRE>
+<PRE> <TT>tickadj</TT> -t 9999 -a 5 -s</PRE>
which sets tick 100 PPM fast, <TT>tickadj</TT> to 5 microseconds and
turns
off the clock/calendar chip fiddle. This line can be added to the
to elect one of the servers at each stratum level as the preferred one
using the keyword <TT>prefer</TT> on the configuration declaration for
the selected server:
-<PRE>
- # preferred server declaration
+<PRE> # preferred server declaration
- peer rackety.udel.edu prefer # preferred server
-</PRE>
+ peer rackety.udel.edu prefer
+# preferred server</PRE>
The preferred server will always be included in the surviving
population,
regardless of its characteristics and as long as it survives preliminary
servers
by the NTP protocol itself and automatically implemented by
<TT>ntpd</TT>
-and the time-conversion routines of each host. The implementation is
+and the time- conversion routines of each host. The implementation is
independent
of the idiosyncrasies of the particular radio clock, which vary widely
among the various devices, as long as the idiosyncratic behavior does
responding to the available information. This caveat goes also for the
maximum-error and statistical-error bounds carefully calculated for all
clients and servers, which could be very useful for application programs
-needing to calibrate the delays and offsets to achieve a near-simultaneous
+needing to calibrate the delays and offsets to achieve a near-
+simultaneous
commit procedure, for example. While this information is maintained in
the <TT>ntpd</TT> data structures, there is at present no way for
application
peer, should this stretch of imagination ever be useful. As a concession
to the need to sometimes transmit additional information to clock
drivers,
-an additional configuration command is available: the <TT>fudge</TT>
+an additional configuration file is available: the <TT>fudge</TT>
statement.
This enables one to specify the values of two time quantities, two
integral
radio
clock once it has gone 30 minutes without an update, one might use the
following configuration file entries:
-<PRE>
- # radio clock fudge fiddles
- server 127.127.3.1
- fudge 127.127.3.1 time1 0.0075 time2 0.0265
- fudge 127.127.3.1 value2 30 flag1 1
-</PRE>
+<PRE> # radio clock fudge fiddles
+ server 127.127.3.1
+ fudge 127.127.3.1 time1 0.0075 time2 0.0265
+ fudge 127.127.3.1 value2 30 flag1 1</PRE>
Additional information on the interpretation of these data with respect
to various radio clock drivers is given in the <A
HREF="refclock.htm">Reference
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.
+of microseconds with a fast RISC- based platform.
<P>There are three ways to implement PPS support, depending on the radio
clock model, platform model and serial line interface. These are
<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>
-directory of the distribution. One of these is the <TT>propdelay</TT>
+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
<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.
+the daemon on data received from a serial port.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
-<html><head><title>
-ntpd</tt> - Network Time Protocol (NTP) daemon
-</title></head><BODY><h3>
-<tt>ntpd</tt> - Network Time Protocol (NTP) daemon
-</h3><hr>
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>ntpd - Network Time Protocol (NTP) daemon
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
+<TT>ntpd</TT> - Network Time Protocol (NTP) daemon</H3>
+
+<HR>
+<H4>
+Synopsis</H4>
+<TT>ntpd [ -aAbdm ] [ -c <I>conffile</I> ] [ -f <I>driftfile</I> ] [ -k
+<I>keyfile</I> ] [ -l <I>logfile</I> ] [ -p <I>pidfile</I> ] [ -r <I>broadcastdelay</I>
+] [ -s <I>statsdir</I> ] [ -t <I>key</I> ] [ -v <I>variable</I> ] [ -V
+<I>variable</I> ]</TT>
+<H4>
+Description</H4>
+<TT>ntpd</TT> is an operating system daemon which sets and maintains the
+system time-of-day in synchronism with Internet standard time servers.
+<TT>ntpd</TT> is a complete implementation of the Network Time Protocol
+(NTP) version 4, but also retains compatibility with version 3, as defined
+by RFC-1305, and version 1 and 2, as defined by RFC-1059 and RFC-1119,
+respectively. <TT>ntpd</TT> does most computations in 64-bit floating point
+arithmetic and does relatively clumsy 64-bit fixed point operations only
+when necessary to preserve the unltimate precision, about 232 picoseconds.
+While the ultimate precision, is not achievable with ordinary workstations
+and networks of today, it may be required with future nanosecond CPU clocks
+and gigabit LANs.
-<h4>Synopsis</h4>
+<P>The daemon can operate in any of several modes, including symmetric
+active/passive, client/server broadcast/multicast and manycast. A broadcast/multicast
+or manycast client can discover remote servers, compute server-client propagation
+delay correction factors and configure itself automatically. This makes
+it possible to deploy a fleet of workstations without specifying configuration
+details specific to the local environment.
-<tt>ntpd [ -aAbdgmnx ] [ -c <i>conffile</i> ] [ -D <i>level</i> ]
-[ -f <i>driftfile</i> ] [ -k <i>keyfile</i> ] [ -l <i>logfile</i> ]
-[ -p <i>pidfile</i> ] [ -P <i>priority</i> ] [ -r <i>broadcastdelay</i> ]
-[ -s <i>statsdir</i> ] [ -t <i>key</i> ] [ -v <i>variable</i> ]
-[ -V <i>variable</i> ]</tt>
+<P>Ordinarily, <TT>ntpd</TT> reads the <TT>ntp.conf</TT> configuration
+file at startup time in order to determine the synchronization sources
+and operating modes. It is also possible to specify a working, although
+limited, configuration entirely on the command line, obviating the need
+for a configuration file. This may be particularly appropriate when the
+local host is to be configured as a broadcast/multicast client or manycast
+client, with all peers being determined by listening to broadcasts at run
+time.
-<h4>Description</h4>
+<P>Various internal <TT>ntpd</TT> variables can be displayed and configuration
+options altered while the daemon is running using the <TT><A HREF="ntpq.htm">ntpq</A></TT>
+and <TT><A HREF="ntpdc.htm">ntpdc</A></TT> utility programs.
-<tt>ntpd</tt> is an operating system daemon which sets and maintains the
-system time-of-day in synchronism with Internet standard time servers.
-<tt>ntpd</tt> is a complete implementation of the Network Time Protocol
-(NTP) version 4, but also retains compatibility with version 3, as
-defined by RFC-1305, and version 1 and 2, as defined by RFC-1059 and
-RFC-1119, respectively. <tt>ntpd</tt> does most computations in 64-bit
-floating point arithmetic and does relatively clumsy 64-bit fixed point
-operations only when necessary to preserve the 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 nanosecond CPU clocks and gigabit LANs.
-
-<p>The daemon can operate in any of several modes, including symmetric
-active/passive, client/server, broadcast/multicast and manycast. A
-broadcast/multicast or manycast client can discover remote servers,
-compute server-client propagation delay correction factors and configure
-itself automatically. This makes it possible to deploy a fleet of
-workstations without specifying configuration details specific to the
-local environment.
-
-<p>Ordinarily, <tt>ntpd</tt> reads the command line options and
-<tt>ntp.conf</tt> configuration file at startup time in order to
-determine the synchronization sources and operating modes. It is also
-possible to specify a working, although limited, configuration entirely
-on the command line, obviating the need for a configuration file. This
-may be particularly appropriate when the local host is to be configured
-as a broadcast/multicast client or manycast client, with all peers being
-determined by listening to broadcasts at run time.
-
-<p>Note that the <tt>-x</tt> command line option disables clock
-stepping, in which case all adjustments are always slewed, no matter
-what the correction value is. Since the slew rate is intentionally
-small, as required by correctness principles, this may delay convergence
-of the clock discipline 2000 seconds for each second of correction.
-During this interval the clock cannot be considered correct and can
-easily destabilize dependent clients. Thus, this option should be used
-only sparingly.
-
-<p>Various internal <tt>ntpd</tt> variables can be displayed and
-configuration options altered while the daemon is running using the
-<tt><A HREF=ntpq.htm>ntpq</A></tt> and <tt><A
-HREF=ntpdc.htm>ntpdc</A></tt> utility programs.
-
-<p>When <tt>ntpd</tt> starts it looks at the value of <tt>umask</tt>,
-and if it's zero <tt>ntpd</tt> will set the <tt>umask</tt> to
-<tt>022</tt>.
-
-<h4>Command Line Options</h4>
-
-<dl>
-<dt><tt>-a</tt></dt>
-<dd>Enable authentication mode (default).</dd>
-
-<dt><tt>-A</tt></dt>
-<dd>Disable authentication mode.</dd>
-
-<dt><tt>-b</tt></dt>
-<dd>Synchronize using NTP broadcast messages.</dd>
-<dt><tt>-c <i>conffile</i></tt></dt>
-<dd>Specify the name and path of the configuration file.</dd>
-
-<dt><tt>-d</tt></dt>
-<dd>Increase debugging level. This flag may occur multiple times, with
-the debug level increasing by one with each occurance.</dd>
-
-<dt><tt>-D <i>level</i></tt></dt>
-<dd>Specify debugging level.</dd>
-
-<dt><tt>-f <i>driftfile</i></tt></dt>
-<dd>Specify the name and path of the drift file.</dd>
-
-<dt><tt>-g</tt></dt>
-<dd>Allow time corrections greater than the panic maximum (default 1000
-seconds).</dd>
-
-<dt><tt>-k <i>keyfile</i></tt></dt>
-<dd>Specify the name and path of the file containing the NTP
-authentication keys.</dd>
-
-<dt><tt>-l <i>logfile</i></tt></dt>
-<dd>Specify the name and path of the log file. The default is the system
-log facility.</dd>
-
-<dt><tt>-m</tt></dt>
-<dd>Synchronize using NTP multicast messages on the IP multicast group
-address 224.0.1.1 (requires multicast kernel).</dd>
-
-<dt><tt>-n</tt></dt>
-<dd>Do not fork resolver process (for system debugging).</dd>
-
-<dt><tt>-p <i>pidfile</i></tt></dt>
-<dd>Specify the name and path to record the daemon's process ID.</dd>
-
-<dt><tt>-P <i>priority</i></tt></dt>
-<dd>Specify scheduling priority (requires kernel support).</dd>
-
-<dt><tt>-r <i>broadcastdelay</i></tt></dt>
-<dd>Specify the default propagation delay from the broadcast/multicast
-server and this client. This is necessary only if the delay cannot be
-computed automatically by the protocol.</dd>
-
-<dt><tt>-s <i>statsdir</i></tt></dt>
-<dd>Specify the directory path for files created by the statistics
-facility.</dd>
-
-<dt><tt>-t <i>key</i></tt></dt>
-<dd>Add a key number to the trusted key list.</dd>
-
-<dt><tt>-v <i>variable</i></tt></dt>
-<dd>Add a system variable.</dd>
-
-<dt><tt>-V <i>variable</i></tt></dt>
-<dd>Add a system variable listed by default.</dd>
-
-<dt><tt>-x</tt></dt>
-<dd>Disable step time corrections; use only slew corrections (maximum
-500 PPM slew rate).</dd>
-
-</dl>
-
-<h4>The Configuration File</h4>
-
-The <tt>ntpd</tt> configuration file is read at initial startup in order
-to specify the synchronization sources, modes and other related
-information. Usually, it is installed in the <tt>/etc</tt> directory,
-but could be installed elsewhere (see the <tt>-c <i>conffile</i></tt>
-command line option). The file format is similar to other Unix
-configuration files - comments begin with a <tt>#</tt> character and
-extend to the end of the line; blank lines are ignored. Configuration
-commands consist of an initial keyword followed by a list of arguments,
-some of which may be optional, separated by whitespace. Commands may not
-be continued over multiple lines. Arguments may be host names, host
-addresses written in numeric, dotted-quad form, integers, floating point
-numbers (when specifying times in seconds) and text strings. Optional
-arguments are delimited by <tt>[ ]</tt> in the following descriptions,
-while alternatives are separated by <tt>|</tt>. The notation <tt>[ ...
-]</tt> means an optional, indefinite repetition of the last item before
-the <tt>[ ... ]</tt>.
-
-<p>See the following pages for configuration and control options. While
-there is a rich set of options available, the only required option is
-one or more <tt>server, peer,</tt> <tt>broadcast</tt> or
-<tt>manycastclient </tt>commands described in the Configuration Options
-page. The <A HREF=notes.htm>Notes on Configuring NTP and Setting up a
-NTP Subnet </A>page contains an extended
-discussion of these options.
+<P>When <TT>ntpd</TT> starts it looks at the value of <TT>umask</TT>, and
+if it's zero <TT>ntpd</TT> will set the <TT>umask</TT> to <TT>022</TT>.
+<H4>
+Command Line Options</H4>
+
+<DL>
+<DT>
+<TT>-a</TT></DT>
+
+<DD>
+Enable authentication mode (default).</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-A</TT></DT>
+
+<DD>
+Disable authentication mode.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-b</TT></DT>
+
+<DD>
+Synchronize using NTP broadcast messages.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-c <I>conffile</I></TT></DT>
+
+<DD>
+Specify the name and path of the configuration file.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-d</TT></DT>
+
+<DD>
+Specify debugging mode. This flag may occur multiple times, with each occurrence
+indicating greater detail of display.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-f <I>driftfile</I></TT></DT>
+
+<DD>
+Specify the name and path of the drift file.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-k <I>keyfile</I></TT></DT>
+
+<DD>
+Specify the name and path of the file containing the NTP authentication
+keys.</DD>
+
+<DD>
+</DD>
-<p><A HREF=confopt.htm>Configuration Options</A>
-<BR><A HREF=authopt.htm>Authentication Options</A>
-<BR><A HREF=monopt.htm>Monitoring Options</A>
-<BR><A HREF=accopt.htm>Access Control Options</A>
-<BR><A HREF=clockopt.htm>Reference Clock Options</A>
-<BR><A HREF=miscopt.htm>Miscellaneous Options</A>
+<DT>
+<TT>-l <I>logfile</I></TT></DT>
-<h4>Files</h4>
+<DD>
+Specify the name and path of the log file. The default is the system log
+facility.</DD>
-<tt>/etc/ntp.conf</tt> - the default name of the configuration file
-<BR><tt>/etc/ntp.drift</tt> - the default name of the drift file
-<BR><tt>/etc/ntp.keys</tt> - the default name of the key file
+<DD>
+</DD>
+
+<DT>
+<TT>-m</TT></DT>
+
+<DD>
+Synchronize using NTP multicast messages on the IP multicast group address
+224.0.1.1 (requires multicast kernel).</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-p <I>pidfile</I></TT></DT>
+
+<DD>
+Specify the name and path to record the daemon's process ID.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-r <I>broadcastdelay</I></TT></DT>
+
+<DD>
+Specify the default propagation delay from the broadcast/multicast server
+and this computer. This is necessary only if the delay cannot be computed
+automatically by the protocol.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-s <I>statsdir</I></TT></DT>
+
+<DD>
+Specify the directory path for files created by the statistics facility.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-t <I>key</I></TT></DT>
+
+<DD>
+Add a key number to the trusted key list.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-v <I>variable</I></TT></DT>
+
+<DD>
+Add a system variable.</DD>
+
+<DD>
+</DD>
+
+<DT>
+<TT>-V <I>variable</I></TT></DT>
+
+<DD>
+Add a system variable listed by default.</DD>
+</DL>
+
+<H4>
+The Configuration File</H4>
+The <TT>ntpd</TT> configuration file is read at initial startup in order
+to specify the synchronization sources, modes and other related information.
+Usually, it is installed in the <TT>/etc</TT> directory, but could be installed
+elsewhere (see the <TT>-c <I>conffile</I></TT> command line option). The
+file format is similar to other Unix configuration files - comments begin
+with a <TT>#</TT> character and extend to the end of the line; blank lines
+are ignored. Configuration commands consist of an initial keyword followed
+by a list of arguments, some of which may be optional, separated by whitespace.
+Commands may not be continued over multiple lines. Arguments may be host
+names, host addresses written in numeric, dotted-quad form, integers, floating
+point numbers (when specifying times in seconds) and text strings. Optional
+arguments are delimited by <TT>[ ]</TT> in the following descriptions,
+while alternatives are separated by <TT>|</TT>. The notation <TT>[ ...
+]</TT> means an optional, indefinite repetition of the last item before
+the <TT>[ ... ]</TT>.
+
+<P>See the following pages for configuration and control options. While
+there is a rich set of options available, the only required option is one
+or more <TT>server, peer,</TT> <TT>broadcast</TT> or <TT>manycastclient
+</TT>commands described in the Configuration Options page. The <A HREF="notes.htm">Notes
+on Configuring NTP and Setting up a NTP Subnet </A>page contains an extended
+discussion of these options.
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<P><A HREF="confopt.htm">Configuration Options</A>
+<BR><A HREF="authopt.htm">Authentication Options</A>
+<BR><A HREF="monopt.htm">Monitoring Options</A>
+<BR><A HREF="accopt.htm">Access Control Options</A>
+<BR><A HREF="clockopt.htm">Reference Clock Options</A>
+<BR><A HREF="miscopt.htm">Miscellaneous Options</A>
+<H4>
+Files</H4>
+<TT>/etc/ntp.conf</TT> - the default name of the configuration file
+<BR><TT>/etc/ntp.drift</TT> - the default name of the drift file
+<BR><TT>/etc/ntp.keys</TT> - the default name of the key file
+<H4>
+Bugs</H4>
+<TT>ntpd</TT> has gotten rather fat. While not huge, it has gotten larger
+than might be desireable for an elevated-priority daemon running on a workstation,
+particularly since many of the fancy features which consume the space were
+designed more with a busy primary server, rather than a high stratum workstation,
+in mind.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
<DD>
Enable the authentication function and specify the key identifier to be
-used for authentication as the argument <I>key</I>. The
+used for authentication as the argument <I>key</I><TT>ntpdate</TT>. The
keys and key identifiers must match in both the client and server key files.
The default is to disable the authentication function.</DD>
<DD>
Force the time to always be slewed using the adjtime() system call, even
-if the measured offset is greater than +-500 ms. The default is to step
-the time using settimeofday() if the offset is greater than +-500 ms. Note
-that, if the offset is much greater than +-500 ms in this case, that it
+if the measured offset is greater than +-128 ms. The default is to step
+the time using settimeofday() if the offset is greater than +-128 ms. Note
+that, if the offset is much greater than +-128 ms in this case, that it
can take a long time (hours) to slew the clock to the correct value. During
-this time, the host should not be used to synchronize clients.</DD>
+this time. the host should not be used to synchronize clients.</DD>
<DT>
<TT>-b</TT></DT>
<DD>
Specify the NTP version for outgoint packets as the integer <I>version</I>,
-which can be 1, 2, 3 or 4. The default is 4. This allows <TT>ntpdate</TT> to
+which can be 1 or 2. The default is 3. This allows <TT>ntpdate</TT> to
be used with older NTP versions.</DD>
<DT>
The slew adjustment is actually 50% larger than the measured offset, since
this (it is argued) will tend to keep a badly drifting clock more accurate.
This is probably not a good idea and may cause a troubling hunt for some
-values of the kernel variables <TT>tick</TT> and <TT>tickadj</TT>.
+values of the kernel variables <TT>tick</TT> and <TT>tickadj</TT>.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
be specified at start up using ntpd's configuration file may also be specified
at run time using <TT>ntpdc</TT>.
-<P>If one or more request options are included on the command line when
+<P>If one or more request options is included on the command line when
<TT>ntpdc</TT> is executed, each of the requests will be sent to the NTP
servers running on each of the hosts given as command line arguments, or
on localhost by default. If no request options are given, <TT>ntpdc</TT>
will prompt for commands if the standard input is a terminal device.
<P><TT>ntpdc</TT> uses NTP mode 7 packets to communicate with the NTP server,
-and hence can be used to query any compatible server on the network which
+and hence can be used to query any compatable server on the network which
permits it. Note that since NTP is a UDP protocol this communication will
be somewhat unreliable, especially over large distances in terms of network
topology. <TT>ntpdc</TT> makes no attempt to retransmit requests, and will
time requests out if the remote host is not heard from within a suitable
timeout time.
-<P>The operation of <TT>ntpdc</TT> is specific to the particular implementation
+<P>The operation of <TT>ntpdc</TT> are specific to the particular implementation
of the <TT>ntpd</TT> daemon and can be expected to work only with this
and maybe some previous versions of the daemon. Requests from a remote
<TT>ntpdc</TT> program which affect the state of the local server must
<DD>
The following argument is interpreted as an interactive format command
and is added to the list of commands to be executed on the specified host(s).
-Multiple <tt>-c</tt> options may be given.</DD>
+Multiple -c options may be given.</DD>
<DT>
<TT>-i</TT></DT>
<DD>
Print a list of the peers known to the server as well as a summary of their
-state, but in a slightly different format than the <tt>-p</tt> switch. This is equivalent
+state, but in a slightly different format than the -p switch. This is equivalent
to <TT>-c dmpeers</TT>.</DD>
</DL>
arguments. Only enough characters of the full keyword to uniquely identify
the command need be typed. The output of a command is normally sent to
the standard output, but optionally the output of individual commands may
-be sent to a file by appending a <TT>></TT>, followed by a file name,
+be sent to a file by appending a <TT><</TT>, followed by a file name,
to the command line.
<P>A number of interactive format commands are executed entirely within
<DT>
<TT>? [ <I>command_keyword</I> ]</TT></DT>
-<DT><TT>help [ <I>command_keyword</I> ]</TT></DT>
+<BR><TT>helpl [ <I>command_keyword</I> ]</TT>
<DD>
A <TT>?</TT> by itself will print a list of all the command keywords known
-to this incarnation of <TT>ntpdc</TT>. A <TT>?</TT> followed by a command
-keyword will print function and usage information about the command. This
-command is probably a better source of information about <TT>ntpdc</TT>
+to this incarnation of <TT>ntpq</TT>. A <TT>?</TT> followed by a command
+keyword will print funcation and usage information about the command. This
+command is probably a better source of information about <TT>ntpq</TT>
than this manual page.</DD>
<DT>
symmetric passive, a <TT>=</TT> means the remote server is being polled
in client mode, a <TT>^</TT> indicates that the server is broadcasting
to this address, a <TT>~</TT> denotes that the remote peer is sending broadcasts
-and a <TT>*</TT> marks the peer the server is currently synchronizing to.
+and a <TT>*</TT> marks the peer the server is currently synchonizing to.</DD>
+
<P>The contents of the host field may be one of four forms. It may be a
host name, an IP address, a reference clock implementation name with its
<DD>
Shows a detailed display of the current peer variables for one or more
-peers. Most of these values are described in the NTP Version 3 specification.</DD>
+peers. Most of these values are described in the NTP Version 2 specification.</DD>
<DT>
<TT>pstats <I>peer_address</I> [...]</TT></DT>
<DD>
Print a variety of system state variables, i.e., state related to the local
server. All except the last four lines are described in the NTP Version
-3 specification, RFC-1305.
+3 specification, RFC-1305.</DD>
+<DL>
<DD>
The <TT>system flags</TT> show various system flags, some of which can
be set and cleared by the <TT>enable</TT> and <TT>disable</TT> configuration
<DD>
The <TT>authdelay</TT> shows the default authentication delay, as set by
the <TT>authdelay</TT> configuration command.</DD>
+</DL>
<DT>
<TT>sysstats</TT></DT>
All requests which cause state changes in the server are authenticated
by the server using a configured NTP key (the facility can also be disabled
by the server by not configuring a key). The key number and the corresponding
-key must also be made known to <tt>ntpdc</tt>. This can be done using the keyid
+key must also be made known to xtnpdc. This can be done using the keyid
and passwd commands, the latter of which will prompt at the terminal for
a password to use as the encryption key. You will also be prompted automatically
for both the key number and password the first time a command which would
is a nonzero integer, all outgoing packets to the remote server will have
an authentication field attached encrypted with this key. If the value
is 0 (or not given) no authentication will be done. The <TT>version#</TT>
-can be 1, 2, 3 or 4 and defaults to 3. The <TT>prefer</TT> keyword indicates
+can be 1, 2 or 3 and defaults to 3. The <TT>prefer</TT> keyword indicates
a preferred peer (and thus will be used primarily for clock synchronisation
if possible). The preferred peer also determines the validity of the PPS
signal - if the preferred peer is suitable for synchronisation so is the
This command provides a way to set certain data for a reference clock.
See the source listing for further information.</DD>
-<DT><TT>enable [ <I>flag</I> ] [ ... ]</TT></DT>
-<DT><TT>disable [ <I>flag</I> ] [ ... ]</TT></DT>
+<DT>
+<TT>enable [ <I>flag</I> ] [ ... ]</TT></DT>
+
+<BR><TT>disable [ <I>flag</I> ] [ ... ]</TT>
<DD>
These commands operate in the same way as the <TT>enable</TT> and <TT>disable</TT>
configuration file commands of <TT>ntpd</TT>. Following is a description
of the flags. Note that only the <TT>auth</TT>, <TT>bclient</TT>, <TT>monitor</TT>,
<TT>pll</TT>, <TT>pps</TT> and <TT>stats</TT> flags can be set by <TT>ntpdc</TT>;
-the <TT>kernel_sync</TT> and <TT>pps_sync</TT> flags are read-only.</DD>
+the <TT>pll_kernel</TT> and <TT>pps_kernel</TT> flags are read-only.</DD>
+<DL>
<DT>
<TT>auth</TT></DT>
<TT>monitor</TT></DT>
<DD>
-Enables the monitoring facility. See the
-<TT>monlist</TT> command for further information. The default for this flag
+Enables the monitoring facility. See the <TT>ntpdc</TT> program and the
+<TT>monlist</TT> command or further information. The default for this flag
is enable.</DD>
<DT>
(PPS) signal is available, this indicates the PPS signal controls the clock
discipline; otherwise, the daemon or kernel controls the clock discipline,
as indicated by the <TT>pll_kernel</TT> flag.</DD>
+</DL>
<DT>
<TT>restrict <I>address mask flag</I> [ <I>flag</I> ]</TT></DT>
boring and could only be loved by its implementer. The program was designed
so that new (and temporary) features were easy to hack in, at great expense
to the program's ease of use. Despite this, the program is occasionally
-useful.
+useful.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
<BODY>
<H3>
-<TT>ntpq</TT> - standard NTP query program</H3>
+<TT>pq</TT> - standard NTP query program</H3>
<HR>
<H4>
<TT>ntpq</TT> can also obtain and print a list of peers in a common format
by sending multiple queries to the server.
-<P>If one or more request options are included on the command line when
+<P>If one or more request options is included on the command line when
<TT>ntpq</TT> is executed, each of the requests will be sent to the NTP
servers running on each of the hosts given as command line arguments, or
on localhost by default. If no request options are given, <TT>ntpq</TT>
will prompt for commands if the standard input is a terminal device.
<P><TT>ntpq</TT> uses NTP mode 6 packets to communicate with the NTP server,
-and hence can be used to query any compatible server on the network which
+and hence can be used to query any compatable server on the network which
permits it. Note that since NTP is a UDP protocol this communication will
be somewhat unreliable, especially over large distances in terms of network
topology. <TT>ntpq</TT> makes one attempt to retransmit requests, and will
timeout time.
<P>Command line options are described following. Specifying a command line
-option other than <TT>-i</TT> or <TT>-n</TT> will cause the specified query (queries) to
+option other than -i or -n will cause the specified query (queries) to
be sent to the indicated host(s) immediately. Otherwise, <TT>ntpq</TT>
will attempt to read interactive format commands from the standard input.
<DL>
<DD>
The following argument is interpreted as an interactive format command
and is added to the list of commands to be executed on the specified host(s).
-Multiple <TT>-c</TT> options may be given.</DD>
+Multiple -c options may be given.</DD>
<DT>
<TT>-i</TT></DT>
arguments. Only enough characters of the full keyword to uniquely identify
the command need be typed. The output of a command is normally sent to
the standard output, but optionally the output of individual commands may
-be sent to a file by appending a ">", followed by a file name, to the
+be sent to a file by appending a "<", followed by a file name, to the
command line. A number of interactive format commands are executed entirely
within the <TT>ntpq</TT> program itself and do not result in NTP mode 6
requests being sent to a server. These are described following.
<DL>
-<DT><TT>? [<I>command_keyword</I>]</TT></DT>
-<DT><TT>help [ <I>command_keyword</I> ]</TT></DT>
+<DT>
+<TT>? [<I>command_keyword</I>]</TT></DT>
+
+<BR><TT>helpl [ <I>command_keyword</I> ]</TT>
<DD>
A <TT>"?"</TT> by itself will print a list of all the command keywords
known to this incarnation of <TT>ntpq</TT>. A <TT>"?"</TT> followed by
-a command keyword will print function and usage information about the
+a command keyword will print funcation and usage information about the
command. This command is probably a better source of information about
<TT>ntpq</TT> than this manual page.</DD>
-<DT><TT>addvars <I>variable_name</I> [ = <I>value</I>] [...]</TT></DT>
-<DT><TT>rmvars <I>variable_name</I> [...]</TT></DT>
-<DT><TT>clearvars</TT></DT>
+<DD>
+ </DD>
+
+<DT>
+<TT>addvars <I>variable_name</I> [ = <I>value</I>] [...]</TT></DT>
+<BR><TT>rmvars <I>variable_name</I> [...]</TT>
+<BR><TT>clearvars</TT>
<DD>
The data carried by NTP mode 6 messages consists of a list of items of
the form <TT><I>variable_name</I> = <I>value</I></TT>, where the <TT>"
= <I>value</I>"</TT> is ignored, and can be omitted, in requests to the
server to read variables. <TT>ntpq</TT> maintains an internal list in which
data to be included in control messages can be assembled, and sent using
-the readlist and writelist commands described below. The <TT>addvars</TT> command
+the readlist and writelist commands described below. The addvars command
allows variables and their optional values to be added to the list. If
more than one variable is to be added, the list should be comma-separated
-and not contain white space. The <tt>rmvars</tt> command can be used to remove individual
-variables from the list, while the <tt>clearvars</tt> command removes all variables
+and not contain white space. The rmvars command can be used to remove individual
+variables from the list, while the clearlist command removes all variables
from the list.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>authenticate yes | no</TT></DT>
<DD>
Normally <TT>ntpq</TT> does not authenticate requests unless they are write
-requests. The command <tt>authenticate yes</tt> causes <TT>ntpq</TT> to send authentication
+requests. The command authenticate yes causes <TT>ntpq</TT> to send authentication
with all requests it makes. Authenticated requests causes some servers
to handle requests slightly differently, and can occasionally melt the
CPU in fuzzballs if you turn authentication on before doing a peer display.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>cooked</TT></DT>
consumption. Variables which <TT>ntpq</TT> thinks should have a decodeable
value but didn't are marked with a trailing <TT>"?"</TT>.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>debug more | less | off</TT></DT>
Turns internal query program debugging on and off.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>delay <I>milliseconds</I></TT></DT>
in authenticated requests, so this command may be obsolete.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>host <I>hostname</I></TT></DT>
a host name or a numeric address.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>hostnames [yes | no]</TT></DT>
switch.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>keyid <I>keyid</I></TT></DT>
has been configured to use for this purpose.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>ntpversion 1 | 2 | 3 | 4</TT></DT>
version 1.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>quit</TT></DT>
Exit <TT>ntpq</TT>.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>passwd</TT></DT>
purpose if such requests are to be successful.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>raw</TT></DT>
<DD>
-Causes all output from query commands to be printed as received from the remote
-server. The only formating/interpretation done on the data is to transform
+Causes all output from query commands is printed as received from the remote
+server. The only formating/intepretation done on the data is to transform
nonascii data into a printable (but barely understandable) form.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>timeout <I>millseconds</I></TT></DT>
The first of these is an index numbering the associations from 1 for internal
use, the second the actual association identifier returned by the server
and the third the status word for the peer. This is followed by a number
-of columns containing data decoded from the status word. See the peers command
+of columns containing data decoded from the status word See the peers command
for a decode of the <TT>condition</TT> field. Note that the data returned
by the <TT>"associations"</TT> command is cached internally in <TT>ntpq</TT>.
The index is then of use when dealing with stupid servers which use association
and index may be used as an alternative.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>clockvar [<I>assocID</I>] [<I>variable_name</I> [ = <I>value</I> [...]
cause the server to return a default variable display.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>lassocations</TT></DT>
command is used, but are included in the output of <TT>"lassociations"</TT>.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>lpassociations</TT></DT>
<TT>"passociations"</TT> only when dealing with fuzzballs.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>lpeers</TT></DT>
<DD>
-Like peers, except a summary of all associations for which the server
+Like R peers, except a summary of all associations for which the server
is maintaining state is printed. This can produce a much longer list of
peers from fuzzball servers.</DD>
<DD>
- </DD>
+ </DD>
+
+<DT>
+<TT>mreadlist <I>assocID</I> <I>assocID</I></TT></DT>
-<DT><TT>mreadlist <I>assocID</I> <I>assocID</I></TT></DT>
-<DT><TT>mrl <I>assocID</I> <I>assocID</I></TT></DT>
+<BR><TT>mrl <I>assocID</I> <I>assocID</I></TT>
<DD>
Like the <TT>readlist</TT> command, except the query is done for each of
a range of (nonzero) association IDs. This range is determined from the
association list cached by the most recent <TT>associations</TT> command.</DD>
<DD>
- </DD>
+ </DD>
-<DT><TT>mreadvar <I>assocID</I> <I>assocID</I>
-[ <I>variable_name</I> [ = <I>value</I> [ ... ]</TT></DT>
-<DT><TT>mrv <I>assocID</I> <I>assocID</I>
-[ <I>variable_name</I> [ = <I>value</I> [ ... ]</TT></DT>
+<DT>
+<TT>mreadvar <I>assocID</I> <I>assocID</I> [ <I>variable_name</I> [ = <I>value</I>
+[ ... ]</TT></DT>
+
+<BR><TT>mrv <I>assocID</I> <I>assocID</I> [ <I>variable_name</I> [ = <I>value</I>
+[ ... ]</TT>
<DD>
Like the <TT>readvar</TT> command, except the query is done for each of
a range of (nonzero) association IDs. This range is determined from the
association list cached by the most recent <TT>associations</TT> command.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>opeers</TT></DT>
by the local interface address.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>passociations</TT></DT>
new query.</DD>
<DD>
- </DD>
+ </DD>
<DT>
<TT>peers</TT></DT>
register, in octal, and the current estimated delay, offset and dispersion
of the peer, all in milliseconds.</DD>
+<DD>
+ </DD>
+
<DD>
The character in the left margin indicates the fate of this peer in the
-clock selection process. Following is a list of these characters, the pigeon
+clock selection process. Folowing is a list of these characters, the pidgeon
used in the <TT>rv</TT> command, and a short explanation of the condition
revealed.</DD>
+<DD>
+ </DD>
+
<DD>
<TT>space reject</TT></DD>
+<DL>
<DD>
The peer is discarded as unreachable, synchronized to this server (synch
loop) or outrageous synchronization distance.</DD>
<DD>
-<TT>x falsetick</TT></DD>
+ </DD>
+</DL>
+<DD>
+<TT>x falsetick</TT></DD>
+
+<DL>
<DD>
The peer is discarded by the intersection algorithm as a falseticker.</DD>
<DD>
-<TT>. excess</TT></DD>
+ </DD>
+</DL>
+<DD>
+<TT>. excess</TT></DD>
+
+<DL>
<DD>
The peer is discarded as not among the first ten peers sorted by synchronization
distance and so is probably a poor candidate for further consideration.</DD>
<DD>
-<TT>- outlyer</TT></DD>
+ </DD>
+</DL>
+
+<DD>
+<TT>- outlyer</TT></DD>
+<DL>
<DD>
The peer is discarded by the clustering algorithm as an outlyer.</DD>
<DD>
-<TT>+ candidat</TT></DD>
+ </DD>
+</DL>
+
+<DD>
+<TT>+ candidat</TT></DD>
+<DL>
<DD>
The peer is a survivor and a candidate for the combining algorithm.</DD>
<DD>
-<TT># selected</TT></DD>
+ </DD>
+</DL>
+<DD>
+<TT># selected</TT></DD>
+
+<DL>
<DD>
The peer is a survivor, but not among the first six peers sorted by synchronization
distance. If the assocation is ephemeral, it may be demobilized to conserve
resources.</DD>
<DD>
-<TT>* sys.peer</TT></DD>
+ </DD>
+</DL>
+<DD>
+<TT>* sys.peer</TT></DD>
+
+<DL>
<DD>
The peer has been declared the system peer and lends its variables to the
system variables.</DD>
+</DL>
-<DT>
-<TT>o pps.peer</TT></DT>
+<DD>
+<TT> </TT></DD>
+<DD>
+<TT>o pps.peer</TT></DD>
+
+<DL>
<DD>
The peer has been declared the system peer and lends its variables to the
system variables. However, the actual system synchronization is derived
from a pulse-per-second (PPS) signal, either indirectly via the PPS reference
clock driver or directly via kernel interface.</DD>
+<DD>
+ </DD>
+</DL>
+
<DD>
The <TT>flash</TT> variable is not defined in the NTP specification, but
is included as a valuable debugging aid. It displays the results of the
packet sanity checks defined in the NTP specification <TT>TEST1</TT> through
-<TT>TEST10</TT>. The bits for each test read in increasing sequency from
+<TT>TEST9</TT>. The bits for each test read in increasing sequency from
the least significant bit and are defined as follows.</DD>
+<DD>
+ </DD>
+
<DD>
The following <TT>TEST1</TT> through <TT>TEST4</TT> enumerate procedure
errors. The packet timestamps may or may not be believed, but the remaining
-header data are ignored.
+header data are ignored.</DD>
<DL>
-<DT>
+<DD>
+ </DD>
+</DL>
+
+<DD>
<TT>TEST1</TT></DD>
+<DL>
<DD>
Duplicate packet. A copy from somewhere.</DD>
+</DL>
-<DT>
-<TT>TEST2</TT></DT>
+<DL>
+<DD>
+ </DD>
+</DL>
+<DD>
+<TT>TEST2</TT></DD>
+
+<DL>
<DD>
Bogus packet. It is not a reply to a message previously sent. This can
happen when the NTP daemon is restarted and before a peer notices.</DD>
-<DT>
-<TT>TEST3</TT></DT>
+<DD>
+ </DD>
+</DL>
+<DD>
+<TT>TEST3</TT></DD>
+
+<DL>
<DD>
Unsynchronized. One or more timestamp fields are missing. This normally
happens when the first packet from a peer is received.</DD>
-<DT>
-<TT>TEST4</TT></DT>
+<DD>
+ </DD>
+</DL>
+
+<DD>
+<TT>TEST4</TT></DD>
+<DL>
<DD>
Either peer delay or peer dispersion is greater than one second. Ya gotta
be kidding.</DD>
+
+<DD>
+ </DD>
</DL>
<DD>
-The following <TT>TEST5</TT> through <TT>TEST10</TT> enumerate errors
-in the packet header. The packet is discarded without inspecting its contents.
+The following <TT>TEST5</TT> through <TT>TEST10</TT> ennumerate errors
+in the packet header. The packet is discarded without inspecting its contents.</DD>
<DL>
-<DT>
-<TT>TEST5</TT></DT>
+<DD>
+ </DD>
+</DL>
+<DD>
+<TT>TEST5</TT></DD>
+
+<DL>
<DD>
Cryptographic authentication fails. See the <A HREF="authopt.htm">Authentication
Options</A> page.</DD>
-<DT>
-<TT>TEST6</TT></DT>
+<DD>
+ </DD>
+</DL>
+<DD>
+<TT>TEST6</TT></DD>
+
+<DL>
<DD>
Peer is unsynchronized. Wind up its clock first.</DD>
-<DT>
-<TT>TEST7</TT></DT>
+<DD>
+ </DD>
+</DL>
+<DD>
+<TT>TEST7</TT></DD>
+
+<DL>
<DD>
Peer stratum is greater than 15. The peer is probably unsynchronized.</DD>
-<DT>
-<TT>TEST8</TT></DT>
+<DD>
+ </DD>
+</DL>
+<DD>
+<TT>TEST8</TT></DD>
+
+<DL>
<DD>
Either root delay or root dispersion is greater than one second. Too far
from home.</DD>
+</DL>
-<DT>
-<TT>TEST9</TT></DT>
+<DL>
+<DD>
+ </DD>
+</DL>
+
+<DD>
+<TT>TEST9</TT></DD>
+<DL>
<DD>
Peer cryptographic authentication fails. Either the key identifier or key
is wrong or somebody trashed our packet.</DD>
-<DT>
-<TT>TEST10</TT></DT>
+<DD>
+ </DD>
+</DL>
+
+<DD>
+<TT>TEST10</TT></DD>
<DL>
<DD>
page.</DD>
<DD>
- </DD>
+ </DD>
</DL>
<DT>
Sends a read status request to the server for the given association. The
names and values of the peer variables returned will be printed. Note that
the status word from the header is displayed preceding the variables, both
-in hexidecimal and in pigeon English.</DD>
+in hexidecimal and in pidgeon English.</DD>
+
+<DD>
+ </DD>
+
+<DT>
+<TT>readlist [ <I>assocID</I> ]</TT></DT>
-<DT><TT>readlist [ <I>assocID</I> ]</TT></DT>
-<DT><TT>rl [ <I>assocID</I> ]</TT></DT>
+<BR><TT>rl [ <I>assocID</I> ]</TT>
<DD>
Requests that the values of the variables in the internal variable list
be returned by the server. If the association ID is omitted or is 0 the
sent without data, which should induce the remote server to return a default
display.</DD>
+<DD>
+ </DD>
-<DT><TT>readvar <I>assocID</I> <I>variable_name</I> [ = <I>value</I> ] [ ...
-]</TT></DT>
-<DT><TT>rv <I>assocID</I> [ <I>variable_name</I> [ = <I>value</I> ] [ ...
+<DT>
+<TT>readvar <I>assocID</I> <I>variable_name</I> [ = <I>value</I> ] [ ...
]</TT></DT>
+
+<BR><TT>rv <I>assocID</I> [ <I>variable_name</I> [ = <I>value</I> ] [ ...
+]</TT>
<DD>
Requests that the values of the specified variables be returned by the
server by sending a read variables request. If the association ID is omitted
peer. Omitting the variable list will send a request with no data which
should induce the server to return a default display.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>writevar <I>assocID</I> <I>variable_name</I> [ = <I>value</I> [ ...
]</TT></DT>
Like the readvar request, except the specified variables are written instead
of read.</DD>
+<DD>
+ </DD>
+
<DT>
<TT>writelist [ <I>assocID</I> ]</TT></DT>
instead of read.</DD>
</DL>
-<H4>Bugs</H4>
-
+<H4>
+Bugs</H4>
The peers command is non-atomic and may occasionally result in spurious
error messages about invalid associations occurring and terminating the
command. The timeout time is a fixed constant, which means you wait a long
time for timeouts since it assumes sort of a worst case. The program should
improve the timeout estimate as it sends queries to a particular host,
-but doesn't.
+but doesn't.
<HR>
-<a href=index.htm><img align=left src=pic/home.gif></a>
-<address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address>
-</body>
-</html>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
<HR>
<H4>
Synopsis</H4>
-<TT>ntptime [ -chlr ] [ -e <I>est_error</I> ] [ -f <I>frequency</I> ] [
+<TT>ntptime [ -chr ] [ -e <I>est_error</I> ] [ -f <I>frequency</I> ] [
-m <I>max_error</I> ] [ -o <I>offset</I> ] [ -s <I>status</I> ] [ -t <I>time_constant</I>
]</TT>
<H4>
<TT>-m <I>max_error</I></TT></DT>
<DD>
-Specify maximum possible error, in microseconds.</DD>
+Display help information.</DD>
<DT>
<TT>-o <I>offset</I></TT></DT>
Specify time constant, an integer in the range 0-4.</DD>
</DL>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
+
+</BODY>
+</HTML>
server gets its time from, and follows the chain of NTP servers back to
their master time source. If given no arguments, it starts with <TT>localhost</TT>.
Here is an example of the output from <TT>ntptrace</TT>:
-<PRE>
-% ntptrace
+<PRE>% ntptrace
localhost: stratum 4, offset 0.0019529, synch distance 0.144135
server2ozo.com: stratum 2, offset 0.0124263, synch distance 0.115784
-usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid 'WWVB'
-</PRE>
+usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid
+'WWVB'</PRE>
On each line, the fields are (left to right): the host name, the host stratum,
the time offset between that host and the local host (as measured by <TT>ntptrace</TT>;
this is why it is not always zero for "<TT>localhost</TT>"), the host synchronization
<H4>
Bugs</H4>
-This program makes no attempt to improve accuracy by doing multiple samples.
+This program makes no attempt to improve accuracy by doing multiple samples.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
<ol>
-<li>Please submit patches to <a href="mailto:mills@udel.edu">David L.
+<p><li>Please submit patches to <a href=mailto:mills@udel.edu>David L.
Mills <mills@udel.edu></a> in the form of either unified-diffs
(<tt>diff -u</tt>) or context-diffs (<tt>diff -c</tt>).</li>
-<li>Please include the <strong>output</strong> from
+<p><li>Please include the <strong>output</strong> from
<tt>config.guess</tt> in the description of your patch. If
<tt>config.guess</tt> does not produce any output for your machine,
please fix that, too!</li>
-<li>Please base the patch on the root directory of the distribution.
+<p><li>Please base the patch on the root directory of the distribution.
The preferred procedure here is to copy your patch to the root directory
and mumble</li>
<p><tt>patch -p <your_patch></tt></li>
-<li>Please avoid patching the RCS subdirectories; better yet, clean
+<p><li>Please avoid patching the RCS subdirectories; better yet, clean
them out before submitting patches.</li>
-<li>If you have whole new files, as well as patches, wrap the files
+<p><li>If you have whole new files, as well as patches, wrap the files
and patches in a shell script. If you need to compress it, use either
-GNU <tt>gzip</tt> or the stock Unix <tt>compress</tt> utility.</li>
+GNU zip or the stock Unix compress utility.</li>
-<li>Don't forget the documentation that may be affected by the patch.
+<p><li>Don't forget the documentation that may be affected by the patch.
Send us patches for the <tt>./html</tt> files as well. See the <a
href=htmlprimer.htm>A Beginner's Guide to HTML</a> page for a
tutorial.</li>
-<li>We would be glad to include your name, electric address and
+<p><li>We would be glad to include your name, electric address and
descriptive phrase in the <a href=copyright.htm>Copyright</a> page,
if you wish.</li>
<p>Prior to ntp3-5.83 (releases up to and including ntp3.5f) a
complete patch history back to the dark ages was kept in the
<tt>./patches</tt> directory, which might have been helpful to see
-if the same problem occurred in another port, etc. Patches were saved
-in
+if the same problem occured in another port, etc. Patches were saved in
that directory with file name in the form <tt>patch.<i>nnn</i></tt>,
where <i>nnn</i> was approaching 200. All patches in that directory have
been made; so, if yours was there, it was in the distribution.
-<p>Since we have been getting multiple patches for some bugs, plus many
+<p>Since we have been getting multple patches for some bugs, plus many
changes are implemented locally, no two maintainers here use the same
tools, and since we're not using any bug-tracking software or even
source code control, there is currently no tracking of specific changes.
<p>Thanks for your contribution and happy chime.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
Porting Hints
</h3><hr>
-<p>NOTE: The following procedures have been replaced by GNU Automake and
-Autoconf. This page is to be updated in the next release.
+<p>NOTE: The following procedures have been replaced by GNU automake and
+autoconfigure. This page is to be updated in the next release.
<p>Porting to a new machine or operating system ordinarily requires
updating the <code>./machines</code> directory and the
<p>Good luck.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
Pulse-per-second (PPS) Signal Interfacing
</H3><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
+<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 20 <FONT FACE=Symbol>m</FONT>s in time and 0.01 PPM in frequency.
The PPS signal can be connected in either of two ways: via the data
<P>The <TT>tty_clk</TT> module is included in the NTP software
distribution, while the <A
-HREF="http://www.eecis.udel.edu/~mills/ntp/ntp/ppsclock.tar.Z"><TT>
+HREF=http://www.eecis.udel.edu/~mills/ntp/ntp/ppsclock.tar.Z><TT>
ppsclock</TT></A> module can be obtained via the web at that link or by
anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory. Both
the <TT>tty_clk</TT> and <TT>ppsclock</TT> modules are described in the
<TT>ntpd</TT> to operate with these modules is described in <A
HREF=build.htm>Building and Installing the Distribution </A>page.
-<P>The PPS driver operates in conjunction with another reference
+<P>The PPS driver is operates in conjunction with another reference
clock driver that produces the PPS pulse, as described in the <A
HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword
</A>page. One of the drivers described in the <A
header file. The presence of these kernel provisions is automatically
detected and supporting code compiled.
-<P>Some configurations may have multiple radio clocks, each with PPS
-outputs, as well as kernel provisions for the PPS signal. In order to
+<P>In some configurations may have multiple radio clocks, each with PPS
+outputs, as well as a kernel provisions for the PPS signal. In order to
provide the highest degree of redundancy and survivability, the kernel
PPS discipline, <TT>tty_clk</TT> module, <TT>ppsclock</TT> module and
kernel modifications may all be in use at the same time, each backing up
the Mitigation Rules and the <TT>prefer</TT> Keyword page.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
-<HTML><HEAD><TITLE>
-Mitigation Rules and the ``prefer'' Keyword
-</TITLE></HEAD><BODY><H3>
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <TITLE>Mitigation Rules and the ``prefer'' Keyword
+</TITLE>
+</HEAD>
+<BODY>
+
+<H3>
Mitigation Rules and the <TT>prefer</TT> Keyword</H3>
-<HR>
-
-<H4>Introduction</H4>
-
-The mechanics of the NTP algorithms which select the best data sample
-from each available peer and the best subset of the peer population have
-been finely crafted to resist network jitter, faults in the network or
-peer operations, and to deliver the best possible accuracy. Most of the
-time these algorithms do a good job without requiring explicit manual
-tailoring of the configuration file. However, there are times when the
-accuracy can be improved by some careful tailoring. The following
-sections explain how to do this using explicit configuration items and
-special signals, when available, that are generated by some radio
-clocks.
-
-<P>In order to provide robust backup sources, primary (stratum-1)
-servers are usually operated in a diversity configuration, in which the
-server operates with a number of remote peers in addition to one or more
-radio or modem clocks operating as local peers. In these configurations
-the suite of algorithms used in NTP to refine the data from each peer
-separately and to select and weight the data from a number of peers are
-used with the entire ensemble of remote peers and local peers. As the
-result of these algorithms, a set of <I>survivors</I> are identified
-which can presumably provide the most reliable and accurate time.
-Ordinarily, the individual clock offsets of the survivors are combined
-on a weighted average basis to produce an offset used to control the
-system clock.
-<P>However, because of small but significant systematic time offsets
-between the survivors, it is in general not possible to achieve the
-lowest jitter and highest stability in these configurations. This
-happens because the selection algorithm tends to <I>clockhop</I> between
-survivors of substantially the same quality, but showing small
-systematic offsets between them. In addition, there are a number of
-configurations involving pulse-per-second (PPS) signals, modem backup
-services and other special cases, so that a set of mitigation rules
-becomes necessary to select a single peer from among the survivors.
-These rules are based on a set of special characteristics of the various
-peers and reference clock drivers specified in the configuration file.
-
-<H4>The <TT>prefer</TT> Peer</H4>
-
-The mitigation rules are designed to provide an intelligent selection
-between various peers of substantially the same statistical quality.
-They are designed to provide the best quality time without compromising
-the normal operation of the NTP algorithms. The mitigation scheme in its
-present form is not an integral component of the NTP Version 3
-specification RFC-1305. but is to be included in the version 4
-specification when it is published. The scheme is based on the concept
-of <I>prefer peer</I>, which is specified by including the
-<TT>prefer</TT> keyword with the associated <TT>server</TT> or
-<TT>peer</TT> command in the configuration file. This keyword can be
-used with any peer or server, but is most commonly used with a radio
-clock. While the scheme does not forbid it, it does not seem useful to
-designate more than one peer as preferred, since the additional
-complexities to mitigate among them do not seem justified from on-air
-experience.
-
-<P>The prefer scheme works on the set of peers that have survived the
-sanity checks and intersection algorithms of the clock selection
-procedures. Ordinarily, the members of this set can be considered
-<I>truechimers</I> and any one of them could in principle provide
-correct time; however, due to various error contributions, not all can
-provide the most accurate and stable time. The job of the clustering
-algorithm, which is invoked at this point, is to select the best subset
-of the survivors providing the least variance in the combined ensemble
-average, compared to the variance in each member of the subset
-separately. The detailed operation of the clustering algorithm, which is
-given in the specification, is not important here, other than to point
-out it operates in rounds, where a survivor, presumably the worst of the
-lot, is discarded in each round until one of several termination
+<HR>
+<H4>
+Introduction</H4>
+The mechanics of the NTP algorithms which select the best data sample from
+each available peer and the best subset of the peer population have been
+finely crafted to resist network jitter, faults in the network or peer
+operations, and to deliver the best possible accuracy. Most of the time
+these algorithms do a good job without requiring explicit manual tailoring
+of the configuration file. However, there are times when the accuracy can
+be improved by some careful tailoring. The following sections explain how
+to do this using explicit configuration items and special signals, when
+available, that are generated by some radio clocks.
+
+<P>In order to provide robust backup sources, primary (stratum-1) servers
+are usually operated in a diversity configuration, in which the server
+operates with a number of remote peers in addition to one or more radio
+or modem clocks operating as local peers. In these configurations the suite
+of algorithms used in NTP to refine the data from each peer separately
+and to select and weight the data from a number of peers are used with
+the entire ensemble of remote peers and local peers. As the result of these
+algorithms, a set of <I>survivors</I> are identified which can presumably
+provide the most reliable and accurate time. Ordinarily, the individual
+clock offsets of the survivors are combined on a weighted average basis
+to produce an offset used to control the system clock.
+
+<P>However, because of small but significant systematic time offsets between
+the survivors, it is in general not possible to achieve the lowest jitter
+and highest stability in these configurations. This happens because the
+selection algorithm tends to <I>clockhop</I> between survivors of substantially
+the same quality, but showing small systematic offsets between them. In
+addition, there are a number of configurations involving pulse-per-second
+(PPS) signals, modem backup services and other special cases, so that a
+set of mitigation rules becomes necessary to select a single peer from
+among the survivors. These rules are based on a set of special characteristics
+of the various peers and reference clock drivers specified in the configuration
+file.
+<H4>
+The <TT>prefer</TT> Peer</H4>
+The mitigation rules are designed to provide an intelligent selection between
+various peers of substantially the same statistical quality. They is designed
+to provide the best quality time without compromising the normal operation
+of the NTP algorithms. The mitigation scheme in its present form is not
+an integral component of the NTP Version 3 specification RFC- 1305. but
+is to be included in the version 4 specification when it is published.
+The scheme is based on the concept of <I>prefer peer</I>, which is specified
+by including the <TT>prefer</TT> keyword with the associated <TT>server</TT>
+or <TT>peer</TT> command in the configuration file. This keyword can be
+used with any peer or server, but is most commonly used with a radio clock.
+While the scheme does not forbid it, it does not seem useful to designate
+more than one peer as preferred, since the additional complexities to mitigate
+among them do not seem justified from on-air experience.
+
+<P>The prefer scheme works on the set of peers that have survived the sanity
+checks and intersection algorithms of the clock selection procedures. Ordinarily,
+the members of this set can be considered <I>truechimers</I> and any one
+of them could in principle provide correct time; however, due to various
+error contributions, not all can provide the most accurate and stable time.
+The job of the clustering algorithm, which is invoked at this point, is
+to select the best subset of the survivors providing the least variance
+in the combined ensemble average, compared to the variance in each member
+of the subset separately. The detailed operation of the clustering algorithm,
+which is given in the specification, is not important here, other than
+to point out it operates in rounds, where a survivor, presumably the worst
+of the lot, is discarded in each round until one of several termination
conditions is met.
<P>In the prefer scheme the clustering algorithm is modified so that the
prefer peer is never discarded; on the contrary, its potential removal
becomes a termination condition. If the original algorithm were about to
-toss out the prefer peer, the algorithm terminates right there. The
-prefer peer can still be discarded by the sanity checks and intersection
-algorithms, of course, but it will always survive the clustering
-algorithm. If it does not survive or for some reason it fails to provide
-updates, it will eventually become unreachable and the clock selection
-will remitigate to select the next best source.
+toss out the prefer peer, the algorithm terminates right there. The prefer
+peer can still be discarded by the sanity checks and intersection algorithms,
+of course, but it will always survive the clustering algorithm. If it does
+not survive or for some reason it fails to provide updates, it will eventually
+become unreachable and the clock selection will remitigate to select the
+next best source.
<P>Along with this behavior, the clock selection procedures are modified
-so that the combining algorithm is not used when a prefer peer is
-present. Instead, the offset of the prefer peer is used exclusively as
-the synchronization source. In the usual case involving a radio clock
-and a flock of remote stratum-1 peers, and with the radio clock
-designated a prefer peer, the result is that the high quality radio time
-disciplines the server clock as long as the radio itself remains
-operational and with valid time, as determined from the remote peers,
-sanity checks and intersection algorithm.
-
-<H4>Peer Classification</H4>
-
-In order to understand the effects of the various intricate schemes
-involved, it is necessary to understand some arcane details on how the
-algorithms decide on a synchronization source, when more than one source
-is available. This is done on the basis of a set of explicit mitigation
-rules, which define special classes of remote and local peers as a
-function of configuration declarations and reference clock driver type:
-
+so that the combining algorithm is not used when a prefer peer is present.
+Instead, the offset of the prefer peer is used exclusively as the synchronization
+source. In the usual case involving a radio clock and a flock of remote
+stratum-1 peers, and with the radio clock designated a prefer peer, the
+result is that the high quality radio time disciplines the server clock
+as long as the radio itself remains operational and with valid time, as
+determined from the remote peers, sanity checks and intersection algorithm.
+<H4>
+Peer Classification</H4>
+In order to understand the effects of the various intricate schemes involved,
+it is necessary to understand some arcane details on how the algorithms
+decide on a synchronization source, when more than one source is available.
+This is done on the basis of a set of explicit mitigation rules, which
+define special classes of remote and local peers as a function of configuration
+declarations and reference clock driver type:
<OL>
-
-<LI> The prefer peer is designated using the <TT>prefer</TT> keyword
-with the <TT>server</TT> or <TT>peer</TT> commands. All other things
-being equal, this peer will be selected for synchronization over all
-other survivors of the clock selection procedures.</LI>
-
-<LI>When a PPS signal is connected via the PPS Clock Discipline
-driver (type 22), this is called the <I>PPS peer</I>. This driver
-provides precision clock corrections only within one second, so is
-always operated in conjunction with another peer or reference clock
-driver, which provides the seconds numbering. The PPS peer is active
-only under conditions explained below.</LI>
-
-<LI>When the Undisciplined Local Clock driver (type 1) is configured,
-this is called the <I>local clock peer</I>. This is used either as a
-backup reference source (stratum greater than zero), should all other
-synchronization sources fail, or as the primary reference source
-(stratum zero) in cases where the kernel time is disciplined by some
-other means of synchronization, such as the NIST <TT>lockclock</TT>
-scheme, or another synchronization protocol, such as the Digital Time
-Synchronization Service (DTSS).</LI>
-
-<LI>When a modem driver such as the Automated Computer Time Service
-driver (type 18) is configured, this is called the <I>modem peer</I>.
-This is used either as a backup reference source, should all other
-primary sources fail, or as the (only) primary reference source.</LI>
-
-<LI>Where support is available, the PPS signal may be processed
-directly by the kernel, as described in the <A HREF="kern.htm">A Kernel
-Model for Precision Timekeeping</A> page. This is called the <I>kernel
-discipline</I>. The PPS signal can discipline the kernel in both
-frequency and time. The frequency discipline is active as long as the
-PPS interface device and signal itself is operating correctly, as
-determined by the kernel algorithms. The time discipline is active only
-under conditions explained below.</LI>
-
+<LI>
+The prefer peer is designated using the <TT>prefer</TT> keyword with the
+<TT>server</TT> or <TT>peer</TT> commands. All other things being equal,
+this peer will be selected for synchronization over all other survivors
+of the clock selection procedures.</LI>
+
+<BR>
+<LI>
+When a PPS signal is connected via the PPS Clock Discipline driver (type
+22), this is called the <I>PPS peer</I>. This driver provides precision
+clock corrections only within one second, so is always operated in conjunction
+with another peer or reference clock driver, which provides the seconds
+numbering. The PPS peer is active only under conditions explained below.</LI>
+
+<BR>
+<LI>
+When the Undisciplined Local Clock driver (type 1) is configured, this
+is called the <I>local clock peer</I>. This is used either as a backup
+reference source (stratum greater than zero), should all other synchronization
+sources fail, or as the primary reference source (stratum zero) in cases
+where the kernel time is disciplined by some other means of synchronization,
+such as the NIST <TT>lockclock</TT> scheme, or another synchronization
+protocol, such as the Digital Time Synchronization Service (DTSS).</LI>
+
+<BR>
+<LI>
+When a modem driver such as the Automated Computer Time Service driver
+(type 18) is configured, this is called the <I>modem peer</I>. This is
+used either as a backup reference source, should all other primary sources
+fail, or as the (only) primary reference source.</LI>
+
+<BR>
+<LI>
+Where support is available, the PPS signal may be processed directly by
+the kernel, as described in the <A HREF="kern.htm">A Kernel Model for Precision
+Timekeeping</A> page. This is called the <I>kernel discipline</I>. The
+PPS signal can discipline the kernel in both frequency and time. The frequency
+discipline is active as long as the PPS interface device and signal itself
+is operating correctly, as determined by the kernel algorithms. The time
+discipline is active only under conditions explained below.</LI>
</OL>
-
-<p>Reference clock drivers operate in the manner described in the <A
-HREF="refclock.htm">Reference Clock Drivers</A> page and its
-dependencies. The drivers are ordinarily operated at stratum zero, so
-that as the result of ordinary NTP operations, the server itself
-operates at stratum one, as required by the NTP specification. In some
-cases described below, the driver is intentionally operated at an
-elevated stratum, so that it will be selected only if no other survivor
+Reference clock drivers operate in the manner described in the <A HREF="refclock.htm">Reference
+Clock Drivers</A> page and its dependencies. The drivers are ordinarily
+operated at stratum zero, so that as the result of ordinary NTP operations,
+the server itself operates at stratum one, as required by the NTP specification.
+In some cases described below, the driver is intentionally operated at
+an elevated stratum, so that it will be selected only if no other survivor
is present with a lower stratum. In the case of the PPS peer or kernel
time discipline, these sources appear active only if the prefer peer has
survived the intersection and clustering algorithms, as described below,
and its clock offset relative to the current local clock is less than a
specified value, currently 128 ms.
-<P>The modem clock drivers are a special case. Ordinarily, the update
-interval between modem calls to synchronize the system clock is many
-times longer than the interval between polls of either the remote or
-local peers. In order to provide the best stability, the operation of
-the clock discipline algorithm changes gradually from a phase-lock mode
-at the shorter update intervals to a frequency-lock mode at the longer
-update intervals. If both remote or local peers together with a modem
-peer are operated in the same configuration, what can happen is that
-first the clock selection algorithm can select one or more remote/local
-peers and the clock discipline algorithm will optimize for the shorter
-update intervals. Then, the selection algorithm can select the modem
-peer, which requires a much different optimization. The intent in the
-design is to allow the modem peer to control the system clock either
-when no other source is available or, if the modem peer happens to be
-marked as prefer, then it always controls the clock, as long as it
+<P>The modem clock drivers are a special case. Ordinarily, the update interval
+between modem calls to synchronize the system clock is many times longer
+than the interval between polls of either the remote or local peers. In
+order to provide the best stability, the operation of the clock discipline
+algorithm changes gradually from a phase-lock mode at the shorter update
+intervals to a frequency-lock mode at the longer update intervals. If both
+remote or local peers together with a modem peer are operated in the same
+configuration, what can happen is that first the clock selection algorithm
+can select one or more remote/local peers and the clock discipline algorithm
+will optimize for the shorter update intervals. Then, the selection algorithm
+can select the modem peer, which requires a much different optimization.
+The intent in the design is to allow the modem peer to control the system
+clock either when no other source is available or, if the modem peer happens
+to be marked as prefer, then it always controls the clock, as long as it
passes the sanity checks and intersection algorithm. There still is room
for suboptimal operation in this scheme, since a noise spike can still
cause a clockhop either way. Nevertheless, the optimization function is
slow to adapt, so that a clockhop or two does not cause much harm.
<P>The local clock driver is another special case. Normally, this driver
-is eligible for selection only if no other source is available. When
-selected, vernier adjustments introduced via the configuration file or
-remotely using the <TT><A HREF="ntpdc.htm">ntpdc</A> </TT>program can be
-used to trim the local clock frequency and time. However, if the local
-clock driver is designated the prefer peer, this driver is always
-selected and all other sources are ignored. This behavior is intended
-for use when the kernel time is controlled by some means external to
-NTP, such as the NIST <TT>lockclock</TT> algorithm or another time
-synchronization protocol such as DTSS. In this case the only way to
-disable the local clock driver is to mark it unsynchronized using the
-leap indicator bits. In the case of modified kernels with the
-<TT>ntp_adjtime()</TT> system call, this can be done automatically if
-the external synchronization protocol uses it to discipline the kernel
+is eligible for selection only if no other source is available. When selected,
+vernier adjustments introduced via the configuration file or remotely using
+the <TT><A HREF="ntpdc.htm">ntpdc</A> </TT>program can be used to trim
+the local clock frequency and time. However, if the local clock driver
+is designated the prefer peer, this driver is always selected and all other
+sources are ignored. This behavior is intended for use when the kernel
+time is controlled by some means external to NTP, such as the NIST <TT>lockclock</TT>
+algorithm or another time synchronization protocol such as DTSS.
+In this case the only way to disable the local clock driver is to mark
+it unsynchronized using the leap indicator bits. In the case of modified
+kernels with the <TT>ntp_adjtime()</TT> system call, this can be done automatically
+if the external synchronization protocol uses it to discipline the kernel
time.
-
-<H4>Mitigation Rules</H4>
-
+<H4>
+Mitigation Rules</H4>
The mitigation rules apply in the intersection and clustering algorithms
-described in the NTP specification. The intersection algorithm first
-scans all peers with a persistent association and includes only those
-that satisfy specified sanity checks. In addition to the checks required
-by the specification, the mitigation rules require either the local-
-clock peer or modem peer to be included only if marked as the prefer
-peer. The intersection algorithm operates on the included population to
-select only those peers believed to represent the correct time. If one
-or more peers survive the operation, processing continues in the
-clustering algorithm. Otherwise, if there is a modem peer, it is
-declared the only survivor; otherwise, if there is a local-clock peer,
-it is declared the only survivor. Processing then continues in the
-clustering algorithm.
-
-<P>The clustering algorithm repeatedly discards outlyers in order to
-reduce the residual jitter in the survivor population. As required by
-the NTP specification, these operations continue until either a
-specified minimum number of survivors remain or the minimum select
-dispersion of the population is greater than the maximum peer dispersion
-of any member. The mitigation rules require an additional terminating
-condition which stops these operations at the point where the prefer
-peer is about to be discarded.
-
-<P>The mitigation rules establish the choice of <I>system peer</I>,
-which determine the stratum, reference identifier and several other
-system variables which are visible to clients of the local server. In
-addition, they establish which source or combination of sources control
-the local clock.
-
+described in the NTP specification. The intersection algorithm first scans
+all peers with a persistent association and includes only those that satisfy
+specified sanity checks. In addition to the checks required by the specification,
+the mitigation rules require either the local-clock peer or modem peer
+to be included only if marked as the prefer peer. The intersection algorithm
+operates on the included population to select only those peers believed
+to represent the correct time. If one or more peers survive the operation,
+processing continues in the clustering algorithm. Otherwise, if there is
+a modem peer, it is declared the only survivor; otherwise, if there is
+a local-clock peer, it is declared the only survivor. Processing then continues
+in the clustering algorithm.
+
+<P>The clustering algorithm repeatedly discards outlyers in order to reduce
+the residual jitter in the survivor population. As required by the NTP
+specification, these operations continue until either a specified minimum
+number of survivors remain or the minimum select dispersion of the population
+is greater than the maximum peer dispersion of any member. The mitigation
+rules require an additional terminating condition which stops these operations
+at the point where the prefer peer is about to be discarded.
+
+<P>The mitigation rules establish the choice of <I>system peer</I>, which
+determine the stratum, reference identifier and several other system variables
+which are visible to clients of the local server. In addition, they establish
+which source or combination of sources control the local clock.
<OL>
-
-<LI>If there is a prefer peer and it is the local-clock peer or the
-modem peer; or, if there is a prefer peer and the kernel time discipline
-is active, choose the prefer peer as the system peer and its offset as
-the system clock offset. If the prefer peer is the local-clock peer, an
-offset can be calculated by the driver to produce a frequency offset in
-order to correct for systematic frequency errors. In case a source other
-than NTP is controlling the system clock, corrections determined by NTP
-can be ignored by using the <TT>disable pll</TT> in the configuration
-file. If the prefer peer is the modem peer, it must be the primary
-source for the reasons noted above. If the kernel time discipline is
-active, the system clock offset is ignored and the corrections handled
-directly by the kernel.</LI>
-
-<LI>If the above is not the case and there is a PPS peer, then choose
-it as the system peer and its offset as the system clock offset.</LI>
-
-<LI>If the above is not the case and there is a prefer peer (not the
-local-clock or modem peer in this case), then choose it as the system
-peer and its offset as the system clock offset.</LI>
-
-<LI>If the above is not the case and the peer previously chosen as
-the system peer is in the surviving population, then choose it as the
-system peer and average its offset along with the other survivors to
-determine the system clock offset. This behavior is designed to avoid
-excess jitter due to clockhopping, when switching the system peer would
-not materially improve the time accuracy.</LI>
-
-<LI>If the above is not the case, then choose the first candidate in
-the list of survivors ranked in order of synchronization distance and
-average its offset along with the other survivors to determine the
-system clock offset. This is the default case and the only case
-considered in the current NTP specification.</LI>
+<LI>
+If there is a prefer peer and it is the local-clock peer or the modem peer;
+or, if there is a prefer peer and the kernel time discipline is active,
+choose the prefer peer as the system peer and its offset as the system
+clock offset. If the prefer peer is the local-clock peer, an offset can
+be calculated by the driver to produce a frequency offset in order to correct
+for systematic frequency errors. In case a source other than NTP is controlling
+the system clock, corrections determined by NTP can be ignored by using
+the <TT>disable pll</TT> in the configuration file. If the prefer peer
+is the modem peer, it must be the primary source for the reasons noted
+above. If the kernel time discipline is active, the system clock offset
+is ignored and the corrections handled directly by the kernel.</LI>
+
+<LI>
+If the above is not the case and there is a PPS peer, then choose it as
+the system peer and its offset as the system clock offset.</LI>
+
+<LI>
+If the above is not the case and there is a prefer peer (not the local-clock
+or modem peer in this case), then choose it as the system peer and its
+offset as the system clock offset.</LI>
+
+<LI>
+If the above is not the case and the peer previously chosen as the system
+peer is in the surviving population, then choose it as the system peer
+and average its offset along with the other survivors to determine the
+system clock offset. This behavior is designed to avoid excess jitter due
+to clockhopping, when switching the system peer would not materially improve
+the time accuracy.</LI>
+
+<LI>
+If the above is not the case, then choose the first candidate in the list
+of survivors ranked in order of synchronization distance and average its
+offset along with the other survivors to determine the system clock offset.
+This is the default case and the only case considered in the current NTP
+specification.</LI>
</OL>
-<H4>Using the Pulse-per-Second (PPS) Signal</H4>
+<H4>
+Using the Pulse-per-Second (PPS) Signal</H4>
Most radio clocks are connected using a serial port operating at speeds
-of 9600 bps or higher. The accuracy using typical timecode formats,
-where the on-time epoch is indicated by a designated ASCII character,
-like carriage-return <TT><cr></TT>, is limited to a millisecond at
-best and a few milliseconds in typical cases. However, some radios
-produce a PPS signal which can be used to improve the accuracy with
-typical workstation servers to the order of a few tens of microseconds.
-The details of how this can be accomplished are discussed in the <A
-HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A> page. The
-following paragraphs discuss how the PPS signal is affected by the
-mitigation rules.
-
-<P>First, it should be pointed out that the PPS signal is inherently
-ambiguous, in that it provides a precise seconds epoch, but does not
-provide a way to number the seconds. In principle and most commonly,
-another source of synchronization, either the timecode from an
-associated radio clock, or even one or more remote NTP servers, is
-available to perform that function. In all cases, a specific, configured
-peer or server must be designated as associated with the PPS signal.
-This is done using the <TT>prefer</TT> keyword as described previously.
-The PPS signal can be associated in this way with any peer, but is most
-commonly used with the radio clock generating the PPS signal.
+of 9600 bps or higher. The accuracy using typical timecode formats, where
+the on-time epoch is indicated by a designated ASCII character, like carriage-return
+<TT><cr></TT>, is limited to a millisecond at best and a few milliseconds
+in typical cases. However, some radios produce a PPS signal which can be
+used to improve the accuracy with typical workstation servers to the order
+of a few tens of microseconds. The details of how this can be accomplished
+are discussed in the <A HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</A>
+page. The following paragraphs discuss how the PPS signal is affected by
+the mitigation rules.
+
+<P>First, it should be pointed out that the PPS signal is inherently ambiguous,
+in that it provides a precise seconds epoch, but does not provide a way
+to number the seconds. In principle and most commonly, another source of
+synchronization, either the timecode from an associated radio clock, or
+even one or more remote NTP servers, is available to perform that function.
+In all cases, a specific, configured peer or server must be designated
+as associated with the PPS signal. This is done using the <TT>prefer</TT>
+keyword as described previously. The PPS signal can be associated in this
+way with any peer, but is most commonly used with the radio clock generating
+the PPS signal.
<P>The PPS signal can be used in two ways to discipline the local clock,
-one using a special PPS driver described in the <A
-HREF="driver22.htm">PPS Clock Discipline</A> page, the other using PPS
-signal support in the kernel, as described in the <A HREF="kern.htm">A
-Kernel Model for Precision Timekeeping</A> page. In either case, the
-signal must be present and within nominal jitter and wander error
-tolerances. In addition, the associated prefer peer must have survived
-the sanity checks and intersection algorithms and the dispersion settled
-below 1 s. This insures that the radio clock hardware is operating
+one using a special PPS driver described in the <A HREF="driver22.htm">PPS
+Clock Discipline</A> page, the other using PPS signal support in the kernel,
+as described in the <A HREF="kern.htm">A Kernel Model for Precision Timekeeping</A>
+page. In either case, the signal must be present and within nominal jitter
+and wander error tolerances. In addition, the associated prefer peer must
+have survived the sanity checks and intersection algorithms and the dispersion
+settled below 1 s. This insures that the radio clock hardware is operating
correctly and that, presumably, the PPS signal is operating correctly as
well. Second, the absolute offset of the local clock from that peer must
be less than 128 ms, or well within the 0.5-s unambiguous range of the
-PPS signal itself. In the case of the PPS driver, the time offsets
-generated from the PPS signal are propagated via the clock filter to the
-clock selection procedures just like any other peer. Should these pass
-the sanity checks and intersection algorithms, they will show up along
-with the offsets of the prefer peer itself. Note that, unlike the prefer
-peer, the PPS peer samples are not protected from discard by the
-clustering algorithm. These complicated procedures insure that the PPS
-offsets developed in this way are the most accurate, reliable available
-for synchronization.
+PPS signal itself. In the case of the PPS driver, the time offsets generated
+from the PPS signal are propagated via the clock filter to the clock selection
+procedures just like any other peer. Should these pass the sanity checks
+and intersection algorithms, they will show up along with the offsets of
+the prefer peer itself. Note that, unlike the prefer peer, the PPS peer
+samples are not protected from discard by the clustering algorithm. These
+complicated procedures insure that the PPS offsets developed in this way
+are the most accurate, reliable available for synchronization.
<P>The PPS peer remains active as long as it survives the intersection
-algorithm and the prefer peer is reachable; however, like any other
-clock driver, it runs a reachability algorithm on the PPS signal itself.
-If for some reason the signal fails or displays gross errors, the PPS
-peer will either become unreachable or stray out of the survivor
-population. In this case the clock selection remitigates as described
-above.
+algorithm and the prefer peer is reachable; however, like any other clock
+driver, it runs a reachability algorithm on the PPS signal itself. If for
+some reason the signal fails or displays gross errors, the PPS peer will
+either become unreachable or stray out of the survivor population. In this
+case the clock selection remitigates as described above.
<P>When kernel support for the PPS signal is available, the PPS signal
is interfaced to the kernel serial driver code via a modem control lead.
-As the PPS signal is derived from external equipment, cables, etc.,
-which sometimes fail, a good deal of error checking is done in the
-kernel to detect signal failure and excessive noise. The way in which
-the mitigation rules affect the kernel discipline is as follows.
-
-<P>The autoconfigure process normally detects the presence of the kernel
-support and compiles the required interface code. In order to operate,
-the PPS signal must be present and within nominal jitter and wander
-error tolerances. In the NTP daemon, the PPS discipline is active only
-when the prefer peer is among the survivors of the clustering algorithm,
-and its absolute offset is within 128 ms, as in the PPS driver. Under
-these conditions the kernel disregards updates produced by the NTP
-daemon and uses its internal PPS source instead. The kernel maintains a
-watchdog timer for the PPS signal; if the signal has not been heard or
-is out of tolerance for more than some interval, currently two minutes,
-the kernel discipline is declared inoperable and operation continues as
-if it were not present.
+As the PPS signal is derived from external equipment, cables, etc., which
+sometimes fail, a good deal of error checking is done in the kernel to
+detect signal failure and excessive noise. The way in which the mitigation
+rules affect the kernel discipline is as follows.
+
+<P>In order to operate, the kernel support must be enabled by the <TT>enable
+pll </TT>command in the configuration file and the signal must be present
+and within nominal jitter and wander error tolerances. In the NTP daemon,
+the PPS discipline is active only when the prefer peer is among the survivors
+of the clustering algorithm, and its absolute offset is within 128 ms,
+as in the PPS driver. Under these conditions the kernel disregards updates
+produced by the NTP daemon and uses its internal PPS source instead. The
+kernel maintains a watchdog timer for the PPS signal; if the signal has
+not been heard or is out of tolerance for more than some interval, currently
+two minutes, the kernel discipline is declared inoperable and operation
+continues as if it were not present.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
<H4>Introduction</H4>
-<p>[under construction]
+<p>This page describes what to expect when the NTP daemon <tt>ntpd</tt>
+is started for the first time. The discussion presumes the programs in
+this distribution have been compiled and installed as described in the
+<a href=build.htm>Building and Installing the Distribution</a> page.
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<p>When the daemon is started, whether for the first or subsequent
+times, a number of roundtrip samples are required to accumulate reliable
+measurements of network path delay and clock offset relative to the
+server. Normally, this takes about four minutes, after which the local
+clock is synchronized to the server. The daemon behavior at startup
+depends on whether a drift file <tt>ntp.drift</tt> exists. This file
+contains the latest estimate of local clock frequency error. When the
+daemon is started for the first time, it is created after about one hour
+of operation and updated once each hour after that. When the daemon is
+started and the file does not exist, the daemon enters a special mode
+designed to quickly adapt to the particular system clock oscillator time
+and frequency error. This takes approximately 15 minutes, after which
+the time and frequency are set to nominal values and the daemon enters
+normal mode, where the time and frequency are continuously tracked
+relative to the server.
+
+<p>As a practical matter, once the local clock has been set, it very
+rarely strays more than 128 ms relative to the server, even under
+extreme cases of network path congestion and jitter. Sometimes, in
+particular when the daemon is first started, the relative clock offset
+exceeds 128 ms. In such cases the normal behavior of the daemon is to
+set the clock directly, rather than rely on gradual corrections. This
+may cause the clock to be set backwards, if the local clock time is more
+than 128 s in the future relative to the server. In some applications,
+this behavior may be unacceptable. If the <tt>-x</tt> option is included
+on the command line that starts the daemon, the clock will never be
+stepped and only slew corrections will be used.
+
+<p>The issues should be carefully explored before deciding to use the
+<tt>-x</tt> option. The maximum slew rate possible is limited to 500
+parts-per-million (PPM) as a consequence of the correctness principles
+on which the NTP protocol and algorithm design are based. As a result,
+the local clock can take a long time to converge to an acceptable
+offset, about 2000 s for each second the clock is outside the acceptable
+range. During this interval the local clock will not be consistent with
+any other network clock and the system cannot be used for distributed
+applications that require correctly synchronized network time.
+<p>There may be an occasional outlyer, where an individual measurement
+exceeds 128 ms. When the frequency of occurrence of these outlyers is
+low, the measurement is discarded and operation continues with the next
+one. However, if the outlyers persist for an interval longer than about
+15 minutes, the next value is believed and the clock stepped or slewed
+as determined by the <tt>-x</tt> option. The usual reason for this
+behavior is when a leap second has occurred, but the reference clock
+receiver has not synchronized to it. When leap second support is
+implemented in the kernel, the kernel implements it as directed by the
+NTP daemon. If this happens and the reference clock source
+resynchronizes correctly within 15 minutes, the transient misbehavior of
+the source is transparent.
+
+<p>It has been observed that, as the result of extreme network
+congestion, the roundtrip delays can exceed three seconds and the
+synchronization distance, which is equal to one-half the roundtrip delay
+plus the error budget terms, can become very large. When the
+synchronization distance exceeds one second, the offset measurement is
+discarded. If this condition persists for several poll intervals, the
+server may be declared unreachable. Sometimes the large jitter results
+in large frequency errors which result in straying outside the
+acceptable offset range and an eventual step or slew time correction. If
+following such a correction the frequency error is so large that the
+first sample is outside the acceptable range, the daemon enters the same
+state as when the <tt>ntp.drift</tt> file is not present. The intent of
+this behavior is to quickly correct the frequency and restore operation
+to the normal tracking mode. In the most extreme cases
+(<tt>time.ien.it</tt> comes to mind), there may be occasional step/slew
+corrections and subsequent frequency corrections. It helps in these
+cases to use burst mode when configuring the server.
+
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
started using the command-line switches described in the <a href =
"ntpd.htm"> <code>ntpd</code> </a> page. The first thing to look for
are error messages on the system log. If none occur, the daemon has
-started, opened the devices specified and is waiting for peers and radios
+started, opened the devices specified and waiting for peers and radios
to come up.
<p>The next step is to be sure the RS232 messages, if used, are getting
<p>Most drivers write a message to the <code>clockstats</code> file as
each timecode or surrogate is received from the radio clock. By
-convention, this is the last ASCII timecode (or ASCII gloss of a
-binary-coded one) received from the radio clock. This file is managed by the
+convention, this is the last ASCII timecode (or ASCII gloss of a binary-
+coded one) received from the radio clock. This file is managed by the
<code>filegen</code> facility described in the <code>ntpd</code> page
and requires specific commands in the configuration file. This forms a
highly useful record to discover anomalies during regular operation of
summarize these data on a daily or weekly basis. The summary files have
proven invaluable to detect infrequent misbehavior due to clock
implementation bugs in some radios.
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+<hr><address>David L. Mills (mills@udel.edu)</address></body></html>
<TT>ntpd</TT>. Individual clocks can be activated by configuration file
commands, specifically the <TT>server</TT> and <TT>fudge</TT> commands
described in the <A HREF=ntpd.htm><TT>ntpd</TT> program manual
-page</A>. The following discussion presents information on how to select
+page</A>. The following discussion presents Information on how to select
and configure the device drivers in a running Unix system.
<P>Radio and modem clocks by convention have addresses in the form
(<TT>MSF_ARCRON</TT>)
<BR><A HREF=driver28.htm>Type 28</A> Shared memory driver
(<TT>SHM</TT>)
-<BR><A HREF=driver29.htm>Type 29</A> Trimble Navigation Palisade GPS
-(<TT>GPS_PALISADE</TT>)
-<BR><A HREF=driver30.htm>Type 30</A> Motorola UT Oncore GPS
+<BR>Type 29 Trimble Navigation Palisade GPS (<TT>GPS_PALISADE</TT>)
+<BR><A HREF=driver30.htm>Type 30 Motorola UT Oncore GPS
(<TT>GPS_ONCORE</TT>)
<BR>Type 31 Rockwell Jupiter GPS (<TT>GPS_JUPITER</TT>)
-<br><a href="driver32.htm">Type 32</a> Chrono-log K-series WWVB receiver (<tt>CHRONOLOG</tt>)
-<br><a href="driver33.htm">Type 33</a> Dumb localtime clock (<tt>DUMBCLOCK</tt>)
<P>* All TrueTime receivers are now supported by one driver, type 5.
Types
<BR><A HREF=ldisc.htm>Line Disciplines and Streams Drivers</A>
<BR><A HREF=pps.htm>Pulse-per-second (PPS) Signal Interfacing</A>
<BR><A HREF=howto.htm>How To Write a Reference Clock Driver</A>
-<BR><A HREF=index.htm>The Network Time Protocol (NTP) Distribution</A>
+<BR><A HREF=index.htm>The Network Time Protocol (NTP)
+Distribution </A>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
However, it continues the tradition of retaining backwards compatibility
with older versions. The NTPv4 version has been under development for
quite a while and isn't finished yet. In fact, quite a number of NTPv4
-features were implemented and tested in the later releases of NTPv3. The
-primary purpose of this release is to verify new features as they are
-implemented work correctly in the various architectures, operating
-systems and hardware complement that can't be verified here. Of
-particular interest are Windows NT, VMS and various reference clock
-drivers. As always, corrections and bugfixes are warmly received,
-especially in the form of context diffs.
+features have already been implemented in the current NTPv3. The primary
+purpose of this release is to verify the remaining new code compiles and
+runs in the various architectures, operating systems and hardware
+complement that can't be verified here. Of particular interest are
+Windows NT, VMS and various reference clock drivers. As always,
+corrections and bugfixes are warmly received, especially in the form of
+context diffs.
<P>This note summarizes the differences between this software release of
-NTPv4, called <tt>ntp-4.x.x</tt>, and the previous NTPv3 version, called
-<tt>xntp3-5.x.x</tt>
+NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called
+xntp3-5.x.x
<OL>
-<LI>Most of the extensive calculations are now done using 64-bit
+<P><LI>Most of the extensive calculations are now done using 64-bit
floating-point format, rather than 64-bit fixed-point format. The
motivation for this is to reduce size, improve speed and avoid messy
bounds checking. Workstations of today are much faster than when the
converting to double. The differences are ordinarily quite small
so can be expressed without loss of accuracy in double format.</LI>
-<LI>The clock discipline algorithm has been redesigned to improve
+<P><LI>The clock discipline algorithm has been redesigned to improve
accuracy, reduce the impact of network jitter and allow an increase in
poll intervals to well over one day with only moderate sacrifice in
accuracy. The NTPv4 design allows servers to increase the poll intervals
servers with hundreds of clients, the new design can dramatically reduce
the network load.</LI>
-<LI>A burst-mode feature is available which results in good accuracy
-with intermittent connections typical of PPP and ISDN services. When
-enabled, at each poll interval the server sends multiple messages and
-processes the replies in a batch. Outlyers and lost messages due to
-initial dial-up delay, ARP cache refresh, etc., are avoided and the
-server synchronizes with its peer generally usually within 30 s. See the
-<a href=assoc.htm>Association Management</a> page for further
-information.</LI>
-
-<LI>In addition to the NTPv3 authentication scheme, which uses
-private-key cryptography, a new NTPv4 autokey authentication scheme is
-available. Autokey uses public-key technology and avoids the need to
-distribute keys by separate means. The design is such that full accuracy
-is available without degradation due to processing demands of the
-public-key routines. It can be used in any of the NTP association modes,
-but is most useful in broadcast/multicast modes. See the <a
-href=authopt.htm>Authentication Options</a> page for further
-information.</LI>
-
-<LI>NTPv4 includes two new association modes which in most
+<P><LI>A <A HREF=assoc.htm>burst-mode</A> feature is available which
+results in good accuracy with intermittent connections typical of PPP
+and ISDN services. When enabled, at each poll interval the server sends
+eight messages over the next 30-s interval and processes them in a
+batch. Outlyers due to initial dial-up delays, etc., are avoided and the
+server synchronizes with its peer generally within 30 s.</LI>
+
+<P><LI>In addition to the NTPv3 authentication scheme, which uses
+private-key cryptography, a new NTPv4 <A HREF=authopt.htm>autokey
+</A>authentication scheme is available. Autokey uses public-key
+technology and avoids the need to distribute keys by separate means. The
+design is such that full accuracy is available without degradation due
+to processing demands of the public-key routines. It can be used in any
+of the NTP association modes, but is most useful in broadcast/multicast
+modes.</LI>
+
+<P><LI>NTPv4 includes two new association modes which in most
applications can avoid per-host configuration altogether. Both of these
are based on multicast technology. They provide for automatic discovery
-and configuration of servers and clients. In multicast mode, a server
-sends a message at fixed intervals using specified multicast addresses,
-while clients listen on these addresses. Upon receiving the message, a
-client exchanges several messages with the server in order to calibrate
-the multicast propagation delay between the client and server. In
-manycast mode, a client sends a message and expects one or more servers
-to reply. Using engineered algorithms, the client selects an appropriate
-subset of servers from the messages received and continues in ordinary
+and configuration of servers and clients. In <A HREF=assoc.htm>multicast
+</A>mode, a server sends a message at fixed intervals using specified
+multicast addresses, while clients listen on these addresses. Upon
+receiving the message, a client exchanges several messages with the
+server in order to calibrate the multicast propagation delay between the
+client and server. In <A HREF=assoc.htm>manycast </A>mode, a client
+sends a message and expects one or more servers to reply. Using
+engineered algorithms, the client selects an appropriate subset of
+servers from the messages received and continues in ordinary
client/server operation with them. The manycast scheme can provide
somewhat better accuracy than the multicast scheme at the price of
-additional network overhead. See the <a href=assoc.htm>Association
-Management</a> page for further information.</LI>
+additional network overhead.</LI>
-<LI>The reference clock driver interface is smaller, more rational
-and more accurate. Support for pulse-per-second (PPS) signals has been
+<P><LI>The reference clock driver interface is smaller, more rational
+and moreaccurate. Support for pulse-per-second (PPS) signals has been
extended to all drivers as an intrinsic function. Most of the drivers in
NTPv3 have been converted to this interface, but some, including the
PARSE subinterface, have yet to be overhauled. New drivers have been
connection of these signals to the Sun audio port
<TT>/dev/audio</TT>.</LI>
-<LI>In all except a very few cases, all timing intervals are
+<P><LI>In all except a very few cases, all timing intervals are
randomized, so that the tendency for NTPv3 to bunch messages, especially
with a large number of configured associations, is minimized.</LI>
-<LI>In NTPv3 a large number of weeds and useless code had grown over
+<P><LI>In NTPv3 a large number of weeds and useless code had grown over
the years since the original NTPv1 code was implemented almost ten years
ago. Using a powerful weedwacker, much of the shrubbery has been
removed, with effect a substantial reduction in size of almost 40
percent.</LI>
-<LI>The entire distribution has been converted to GNU Automake,
-which should greatly ease the task of porting to new and
+<P><LI>The entire distribution has been converted to <TT>gnu
+automake</TT>, which should greatly ease the task of porting to new and
different programming environments, as well as reduce the incidence of
bugs due to improper handling of idiosyncratic kernel functions.</LI>
</OL>
<H4>Nasty Surprises</H4>
There are a few things different about this release that have changed
-since the latest NTPv3 release. Following are a few things to worry
-about:
+since the latest NTP Version 3 release. Following are a few things to
+worry about:
<OL>
-<LI>As required by Defense Trade Regulations (DTR), the cryptographic
-routine supporting the Data Encryption Standard (DES) has been removed
-from the distribtution. These routines are readily available in most
-countries from RSA Laboratories. Directions for their use are in the <A
+<P><LI>As required by Defense Trade Regulations (DTR), the cryptographic
+routines supporting the Data Encryption Standard (DES) and Message
+Digest 5 (MD5) have been removed from the export version of the
+distribtution. These routines are readily available in most countries
+from RSA Laboratories. Directions for their use are in the <A
HREF=build.htm>Building and Installing the Distribution</A> page.</LI>
-<LI>As the result of the above, the <TT>./authstuff</TT> directory,
+<P><LI>As the result of the above, the <TT>./authstuff</TT> directory,
intended as a development and testing aid for porting cryptographic
routines to exotic architectures, has been removed. Developers should
note the NTP authentication routines use the interface defined in the
<TT>rsaref2.0</TT> package available from RSA laboratories.</LI>
-<LI>The <tt>enable</tt> and <tt>disable</tt> commands have a few
-changes in their arguments; see the <TT>ntpd</TT> <A
-HREF=confopt.htm>Configuration Options</A> page for details.</LI>
-
-<li>The protocol state machine has been modified to avoid certain
-cryptographic vulnerabilities. Authentication is normally required for
-configuration messages, including those for host name resolution, and to
-mobilize persistent associations. While authentication can be disabled
-with a <tt>disable auth</tt> command in the configuration file, this may
-result in some surprising behavior. See the <a
-href=authopt.htm>Authentication Options</a> page for details.
-
-<p><li>Additional flags have been added to the <tt>ntpd</tt> command
-line. See the <a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP)
-daemon</a> page for details.</LI>
+<P><LI>The enable and disable commands have a few changes in their
+arguments see the <TT>ntpd</TT> <A HREF=confopt.htm>Configuration
+Options</A> page for details.</LI>
-<LI>The scheme for enabling the <TT>ppsclock</TT> line
+<P><LI>The scheme for enabling the <TT>ppsclock</TT> line
discipline/streams module has changed. Formerly, it was enabled by
-setting <TT>fudge flag3</TT> for the serial port connected to the PPS
+setting f<TT>udge flag3</TT> for the serial port connected to the PPS
signal. Now, there is an explicit command <TT>pps</TT> used to designate
the device name. See the <A HREF=clockopt.htm>Reference Clock
Options</A> page for details.</LI>
-<LI>While in fact not a new problem, some obscure option combinations
+<P><LI>While in fact not a new problem, some obscure option combinations
require the <TT>server</TT> and <TT>peer</TT> commands to follow the
others; in particular, the <TT>enable</TT> and <TT>pps</TT> commands
should preceed these commands.</LI>
<H4>Caveats</H4>
This release has been compiled and tested on several systems, including
-SunOS 4.1.3, Solaris 2.5.1, 2.6 and 7, Digital Unix 4.0 and Ultrix
-4.4, Linux, FreeBSD 2.2.5 and 3.1, and HP-UX 10.02. It has not been
-compiled here for Windows NT or VMS. We are relying on the NTP volunteer
-brigade to do that. Known problems are summarized below:
+SunOS 4.1.3, Solaris 2.5.1 and 2.6, Alpha 4.0, Ultrix 4.4, Linux,
+FreeBSD and HP-UX 10.02. It has not been compiled for Windows NT or VMS.
+We are relying on the NTP volunteer brigade to do that. Known problems
+are summarized below:
<OL>
-<LI>To work properly in all cases, the <TT>enable</TT> and
+<P><LI>To work properly in all cases, the <TT>enable</TT> and
<TT>pps</TT> commands, if used, should appear before the <TT>server</TT>
and <TT>fudge</TT> commands in the configuration file.</LI>
-<LI>On Digital Unix 4.0 with reference clocks configured, debugging with the
+<P><LI>The precision time kernel modifications now in stock Solaris 2.6
+have bugs. The kernel discipline has been disabled by default. For
+testing, the kernel can be enabled using the <TT>enable kernel</TT>
+command either in the configuration file or via <TT>ntpdc</TT>.</LI>
+
+<P><LI>On Alpha 4.0 with reference clocks configured, debugging with the
<TT>-d</TT> options doesn't work.</LI>
-<LI>The autokey function requires an NTP header extensions field,
+<P><LI>The autokey function requires an NTP header extensions field,
which is documented in an internet draft and implemented in this
release. This field holds the public-key signature and certificate;
however, the detailed format for these data have not yet been
implementation of the required algorithms will quickly follow using
available cryptographic algorithms.</LI>
-<LI>The manycast function still needs some work. Ideally, the
+<P><LI>The manycast function still needs some work. Ideally, the
existing I/O routines would be enhanced to include the capability to
determine the source address on every multicast packet sent, so that the
autokey function could reliably construct the correct cryptosum.
limited to clients with only a single network
interface.</LI>
-<LI>The HTML documentation has been partially updated. However, most
+<P><LI>The HTML documentation has been partially updated. However, most
of the NTPv3 documentation continues to apply to NTPv4. Until the update
happens, what you see is what you get. We are always happy to accept
comments, corrections and bug reports. However, we are most thrilled
</OL>
-<H4>Wet Paint Department</H4>
-
-Beginning with the <tt>ntp-4.0.92e</tt> release, the following changes
-have been made:
-
-<ol>
-
-<li>The clock state machine has been modified to improve behavior
-under extreme conditions of network congestion together with large
-intrinsic hardware frequency errors in the hundreds of parts-per-million
-(PPM).</li>
-
-<li>The interface for external clock hardware and software has been
-refined. The refinements allow the external clock driver or software to
-alert the NTP daemon when something goes wrong, in which case an orderly
-fallback, first to one or more external servers and finally to the local
-clock driver can occur, if configured. See the <a
-href=driver1.htm>Undisciplined Local Clock</a> page for further
-information. Developers should see the extensive commentary in the
-<tt>./ntpd/ntp_loopfilter.c</tt> file for details.</li>
-
-<LI>The kernel interface has been modified to support the new
-nanokernel precision time support, if available. This extends the
-potential accuracy and precision well below the microsecond using fast
-workstations and networks. The scheme is such that both this and
-previous distributions of NTPv3 and NTPv4 are automatically recognized
-and configured for the highest accuracy available. The current interface
-works with stock Digital Unix 4.0 (compiled with the NTP_TIME and
-MICRO_TIME kernel configuration file defines), but the precision time
-kernel modifications now in stock Solaris 2.6 and 7 have bugs. The
-kernel discipline has been disabled by default for this version. For
-testing, the kernel can be enabled using the <TT>enable kernel</TT>
-command either in the configuration file or via <TT>ntpdc</TT>.</LI>
-
-<li>Certain bugs which can lead to lost associations when the autokey
-list is regenerated have been fixed.
-
-<p><li>A number of documentation corrections and updates have been made,
-including an extensive update to the <a href=debug.htm>NTP Debugging
-Techniques</a> page. Links to some relatively obscure but important
-information, but frequently asked, have been planted in more obvious
-places, primarily to reduce the volume of mail messages here.</li>
-
-</OL>
-
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
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 the time-of-day clock or not.
+with time-of-day clock or not.
<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
<DD>
Set the kernel variable <TT>dosynctodr</TT> to zero, which disables the
hardware time-of-year clock, a prerequisite for running the <TT>ntpd</TT>
-daemon under SunOS 4.</DD>
+daemon under SunOS4.</DD>
<DT>
<TT>-q</TT></DT>
<PRE>
/vmunix
+
/unix
-/dev/kmem
-</PRE>
+
+/dev/kmem</PRE>
<H4>
Bugs</H4>
is a hideous practice which is only necessary to make up for deficiencies
in the implementation of <TT>adjtime</TT> in many kernels and/or brokenness
of the system clock in some vendors' kernels. It would be much better if
-the kernels were fixed and the <TT>tickadj</TT> program went away.
+the kernels were fixed and the <TT>tickadj</TT> program went away.
+<HR>
+<ADDRESS>
+David L. Mills (mills@udel.edu)</ADDRESS>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+</BODY>
+</HTML>
<P><BR>
</P>
-<P>Casey Crellin<BR>
+<P>Casey Crellin</A> <BR>
<A HREF="mailto:casey@csc.co.za">casey@csc.co.za</A> </P>
<P><BR>
fail or operate incorrectly.
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href="mailto:mills@udel.edu"> David L. Mills <mills@udel.edu></a>
-</address></body></html>
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
projects / thirdparty / ntp.git / commitdiff
