<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Make sure who your friends are.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Sep-2010 3:04<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->12-Oct-2010 3:19<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
</ul>
<hr>
<h4 id="modes">Association Modes</h4>
-<p>This page describes the various modes of operation provided in NTPv4. There are three types of associations in NTP: <em>persistent</em>, <em>preemptable</em> and <em>ephemeral</em>. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>preempt</tt> option and are demobilized by a "better" server or by timeout, but only if the number of survivors exceeds the threshold set by the <tt>tos maxclock</tt> command. Ephemeral associations are mobilized upon arrival of designated NTP packets and demobilized by timeout.</p>
-<p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described in the <a href="authopt.html">Authentication Options</a> page.</p>
+<p>This page describes the various modes of operation provided in NTPv4. There are three types of associations in NTP: <em>persistent</em>, <em>preemptable</em> and <em>ephemeral</em>. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>preempt</tt> option or upon arrival of an automatic server discovery response. They are are demobilized by timeout or when preempted by a "better" server, as descrivbed on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. Ephemeral associations are mobilized upon arrival of designated NTP packets and demobilized by timeout.</p>
+<p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described in the <a href="authentic.html">Authentication Support</a> page.</p>
<p>There are three principal modes of operation in NTP: client/server, symmetric active/passive and broadcast/multicast. There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and pool described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. In addition, the orphan mode and burst options described on this page can be used in appropriate cases.</p>
-<p>Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
+<p>Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the <a href="confopt.html">Server Commands and Options</a> page. See that page for applicability and defaults.</p>
<h4 id="client">Client/Server Mode</h4>
<p>Client/server mode is the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers and stateful clients. In this mode a host sends a client (mode 3) request to the specified server and expects a server (mode 4) reply at some future time. In some contexts this would be described as a "pull" operation, in that the host pulls the time and related values from the server.</p>
<p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
<h4 id="many">Manycast and Pool Modes</h4>
<p>Manycast and pool modes are automatic discovery and configuration paradigms new to NTPv4. They are intended as a means for a client to troll the nearby network neighborhood to find cooperating willing servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each client mobilizes ephemeral client associations with some number of the "best" of the nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="discover.html">Automatic Server Discovery Schemes</a> page.</p>
<h4 id="poll">Poll Interval Control</h4>
-<p>NTP uses an intricate heuristic algorithm to automatically control the poll interval for maximum accuracy consistent with minimum network overhead. The algorithm measures the incidental offset and jitter to determine the best poll interval. When <tt>ntpd</tt> starts, the interval is the default minimum 64 s. Under normal conditions when the clock discipline has stabilized, the interval increases in steps to the default maximum 1024 s. In addition, should a server become unreachable after some time, the interval increases in steps to the maximum in order to reduce network overhead.</p>
-<p>The default poll interval range is suitable for most conditions, but can be changed using options on the <a href="confopt.html">Server Options</a> and <a href="miscopt.html">Miscellaneous Options</a> pages. However, when using maximum intervals much larger than the default, the residual clock frequency error must be small enough for the discipline loop to capture and correct. The capture range is 500 PPM with a 64-s interval decreasing by a factor of two for each interval doubling. At a 36-hr interval, for example, the capture range is only 0.24 PPM.</p>
-<p>In the NTPv4 specificationn and reference implementation, the poll interval is expressed in log<sub>2</sub> units, properly called the poll exponent. It is constrained by the lower limit <tt>minpoll</tt> and upper limit <tt>maxpoll</tt> options of the <tt>server</tt> command. The limits default to 6 (64 s) and 10 (1024 s), respectively, which are appropriate for the vast majority of cases. The default limits can be changed with these options to a minimum set by the <tt>average</tt> option of the <tt>discard</tt> command (see below) to a maximum of 17 (36 h).</p>
+<p>NTP uses an intricate heuristic algorithm to automatically control the poll interval for maximum accuracy consistent with minimum network overhead. The algorithm measures the incidental offset and jitter to determine the best poll interval. When <tt>ntpd</tt> starts, the interval is the default minimum 64 s. Under normal conditions when the clock discipline has stabilized, the interval increases in steps to the default maximum 1024 s. In addition, should a server become unreachable after some time, the interval increases in steps to the maximum in order to reduce network overhead. Additional information about the algorithm is on the <a href="poll.html">Poll Program</a> page.</p>
+<p>The default poll interval range is suitable for most conditions, but can be changed using options on the <a href="confopt.html">Server
Commands and Options</a> and <a href="miscopt.html">Miscellaneous Options</a> pages. However, when using maximum intervals much larger than the default, the residual clock frequency error must be small enough for the discipline loop to capture and correct. The capture range is 500 PPM with a 64-s interval decreasing by a factor of two for each interval doubling. At a 36-hr interval, for example, the capture range is only 0.24 PPM.</p>
+<p>In the NTPv4 specificationn and reference implementation, the poll interval is expressed in log<sub>2</sub> units, properly called the <em>poll exponent.</em> It is constrained by the lower limit <tt>minpoll</tt> and upper limit <tt>maxpoll</tt> options of the <a href="confopt.html"><tt>server</tt></a> command. The limits default to 6 (64 s) and 10 (1024 s), respectively, which are appropriate for the vast majority of cases.</p>
<p>As a rule of thumb, the expected errors increase by a factor of two as the poll interval increases by a factor of four. The poll interval algorithm slowly increases the poll interval when jitter dominates the error budget, but quickly reduces the interval when wander dominates it. More information about this algorithm is on the <a href="warp.html">How NTP Works</a> page.</p>
<p>There is normally no need to change the poll limits, as the poll interval is managed automatically as a function of prevailing jitter and wander. The most common exceptions are the following.</p>
<ul>
<li>The poll interval should not be modified for reference clocks, with the single exception the ACTS telephone modem driver. In this case the recommended minimum and maximum intervals are 12 (1.1 h) and 17 (36 h), respectively.</li>
</ul>
<h4 id="burst">Burst Options</h4>
-<p>Occasionally it is necessary to send packets at intervals less than the poll interval. For instance, with the <tt>burst</tt> and <tt>iburst</tt> options of the <tt>server</tt> command, the poll algorithm sends a burst of several packets at 2-s intervals. The <tt>ntpd</tt> poll algorithm avoids sending needless packets if the server is not responding. The client begins a burst with a single packet. When the first packet is received from the server, the client continues with the remaining packets in the burst. If the first packet is not received within 64 s, it will be sent again for two additional retries before beginning backoff. The result is to minimize network load if the server is not responding.</p>
-<p>For the <tt>iburst</tt> option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the <tt>burst</tt> option, the number of packets in the burst is determined by the difference between the poll interval and the minimum poll interval set by the <tt>minpoll</tt> option of the <a href="confopt.html#server"><tt>server</tt></a> command. For instance, with a poll exponent of 6 (64 s), only a single packet is sent for every poll, while the full number of eight packets is sent at poll intervals of 9 (512 s) or more.</p>
+<p>Occasionally it is necessary to send packets at intervals less than the poll interval. For instance, with the <tt>burst</tt> and <tt>iburst</tt> options of the <a href="confopt.html"><tt>server</tt></a> command, the poll algorithm sends a burst of several packets at 2-s intervals. The <tt>ntpd</tt> poll algorithm avoids sending needless packets if the server is not responding. The client begins a burst with a single packet. When the first packet is received from the server, the client continues with the remaining packets in the burst. If the first packet is not received within 64 s, it will be sent again for two additional retries before beginning backoff. The result is to minimize network load if the server is not responding.</p>
<p>There are two burst options where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal one packet. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands, but not with reference clock drivers nor symmetric peers. The <tt>burst</tt> option sends a burst when the server is reachable, while the <tt>iburst</tt> option sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. In either mode the client sends one packet, waits for the reply, then sends the remaining packets in the burst. This may be useful to allow a modem to complete a call.</p>
<p>In both modes received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and adjusts the system clock as if only a single packet exchange had occurred.</p>
<p>The <tt>iburst</tt> option is useful where the system clock must be set quickly or when the network attachment requires an initial calling or training sequence. The burst is initiated only when the server first becomes reachable. This improves accuracy with intermittent connections typical of PPP and ISDN services. Outliers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first received packet.</p>
Walt Kelly</a>
<p>The chicken is getting configuration advice.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Sep-2010 4:07<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->12-Oct-2010 1:14<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/confopt.txt"></script>
+<h4>Table of Contents</h4>
+<ul>
+ <li class="inline"><a href="#address">Server and Peer Addresses</a></li>
+ <li class="inline"><a href="#command">Server Commands</a></li>
+ <li class="inline"><a href="#option">Server Command Options</a></li>
+</ul>
<hr>
-<h4>Server and Peer Addresses</h4>
-<p>Following is a description of the configuration commands in NTPv4. There are two classes of commands, configuration commands that configure an association with a remote server, peer or reference clock, and auxilliary commands that specify environmental variables that control various related operations. </p>
+<h4 id="address">Server and Peer Addresses</h4>
+<p>Following is a description of the configuration commands in NTPv4. There are two classes of commands, configuration commands that configure an association with a remote server, peer or reference clock, and auxiliary commands that specify environmental variables that control various related operations. </p>
<p>The various modes described on the <a href="assoc.html">Association Management</a> page are determined by the command keyword and the DNS name or IP address. Addresses are classed by type as (s) a remote server or peer (IPv4 class A, B and C), (b) the IP broadcast address of a local interface, (m) a multicast address (IPv4 class D), or (r) a reference clock address (127.127.x.x). For type m addresses the IANA has assigned the multicast group address IPv4 224.0.1.1 and IPv6 ff05::101 (site local) exclusively to NTP, but other nonconflicting addresses can be used. </p>
<p>If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected,
support for the IPv6 address family is generated in addition to the default IPv4 address family. IPv6 addresses can be identified by the presence of colons ":" in the address field. IPv6 addresses can be used almost everywhere where IPv4 addresses can be used, with the exception of reference clock addresses, which are always IPv4. Note that in contexts where a host name is expected, a <tt>-4</tt> qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a <tt>-6</tt> qualifier forces DNS resolution to the IPv6 namespace.</p>
-<h4 id="cfg">Commands and Options</h4>
-<p>Unless noted otherwise, further information about these c
commands is on the <a href="assoc.html">Association Management</a> page.</p><dl>
+<h4 id="command">Server Commands</h4>
+<p>Unless noted otherwise, further information about these commands is on the <a href="assoc.html">Association Management</a> page.</p><dl>
<dt id="server"><tt>server <i>address</i> [options ...]</tt><br>
<tt>peer <i>address</i> [options ...]</tt><br>
<tt>broadcast <i>address</i> [options ...]</tt><br>
<tt>manycastclient <i>address</i> [options ...]</tt><br>
<tt>pool <i>address</i> [options ...]</tt><br>
<tt>unpeer [<i>address</i> | <i>associd</i>]</tt></dt>
- <dd>These commands specify the time server name or address to be used and the
- mode in which to operate. The <i>address</i> can be either a DNS name or a
- IPv4 or IPv6 address in standard notation. In general, multiple commands of
- each type can be used for different server and peer addresses or multicast
- groups.
+ <dd>These commands specify the time server name or address to be used and the mode in which to operate. The <i>address</i> can be either a DNS name or a IPv4 or IPv6 address in standard notation. In general, multiple commands of each type can be used for different server and peer addresses or multicast groups.
<dl>
<dt><tt>server</tt></dt>
- <dd>For type s and r addresses (only), this command mobilizes a persistent
- client mode association with the specified remote server or local reference
- clock. If the <tt>preempt</tt> flag is specified, a preemptable client mode
- association is mobilized instead.</dd>
+ <dd>For type s and r addresses (only), this command mobilizes a persistent client mode association with the specified remote server or local reference clock. If the <tt>preempt</tt> flag is specified, a preemptable client mode association is mobilized instead.</dd>
<dt><tt>peer</tt></dt>
- <dd>For type s addresses (only), this command mobilizes a persistent symmetric-active
- mode association with the specified remote peer.</dd>
+ <dd>For type s addresses (only), this command mobilizes a persistent symmetric-active mode association with the specified remote peer.</dd>
<dt><tt>broadcast</tt></dt>
- <dd>For type b and m addressees (only), this command mobilizes a persistent
- broadcast or multicast server mode association. Note that type
- b messages go only to the interface specified, but type m messages go to
- all interfaces.</dd>
+ <dd>For type b and m addressees (only), this command mobilizes an ephemeral broadcast or multicast server mode association. Note that type b messages go only to the interface specified, but type m messages go to all interfaces.</dd>
<dt><tt>manycastclient</tt></dt>
- <dd>For type m addresses (only), this command mobilizes a manycast client
- mode association for the multicast group address specified. In this mode
- the address must match the address specified on the <tt>manycastserver</tt> command
- of one or more designated manycast servers.</dd>
+ <dd>For type m addresses (only), this command mobilizes a preemptable manycast client mode association for the multicast group address specified. In this mode the address must match the address specified on the <tt>manycastserver</tt> command of one or more designated manycast servers. Additional information about this command is on the <a href="discover.html#pool">Automatic Server Discovery</a> page.</dd>
<dt><tt>pool</tt></dt>
- <dd>For type s addresses (only) this command mobilizes a pool client mode association
- for the DNS name specified. The DNS name must resolve to one or more IPv4 or
- IPv6 addresses. The pool automatic server discovery scheme is described on the
- <a href="discover.html#pool">Automatic Server Discovery</a> page.
- <a href="http://www.pool.ntp.org/">www.pool.ntp.org</a> describes a compatible pool
- of public NTP servers.</dd>
+ <dd>For type s addresses (only) this command mobilizes a preemptable pool client mode association for the DNS name specified. The DNS name must resolve to one or more IPv4 or IPv6 addresses. Additional information about this command is on the <a href="discover.html#pool">Automatic Server Discovery</a> page. The <a href="http://www.pool.ntp.org/">www.pool.ntp.org</a> page describes a compatible pool of public NTP servers.</dd>
<dt><tt>unpeer</tt></dt>
- <dd>This command removes a previously configured association. An address or association ID can
- be used to identify the association. Either an IP address or DNS name can be used. This
- command is most useful when supplied via <tt><a href="ntpq.html">ntpq</a></tt> runtime
- configuration commands <tt>:config</tt> and <tt>config-from-file</tt>.</dd>
+ <dd>This command removes a previously configured association. An address or association ID can be used to identify the association. Either an IP address or DNS name can be used. This command is most useful when supplied via <tt><a href="ntpq.html">ntpq</a></tt> runtime configuration commands <tt>:config</tt> and <tt>config-from-file</tt>.</dd>
</dl></dd>
</dl>
-<h4 id="opt">Command Options</h4>
+<h4 id="option">Server Command Options</h4>
<dl>
<dt><tt>autokey</tt></dt>
<dd>Send and receive packets authenticated by the Autokey scheme described
- in the <a href="autokey.html">Autokey Public Key Authentication</a> page. This option
- is mutually exclusive with the <tt>key</tt> option.</dd>
+ in the <a href="autokey.html">Autokey Public Key Authentication</a> page. This option is mutually exclusive with the <tt>key</tt> option.</dd>
<dt><tt>burst</tt></dt>
- <dd>When the server is reachable, send a burst of eight packets instead of the
- usual one. The packet spacing is normally 2 s; however, the spacing between
- the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command
- to allow additional time for a modem or ISDN call to complete. This option
- is valid only with the <tt>server</tt> command and type s addressesa.
- It is a recommended option when the <tt>maxpoll</tt> option is greater than
- 10 (1024 s).</dd>
+ <dd>When the server is reachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command to allow additional time for a modem or ISDN call to complete. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option when the <tt>maxpoll</tt> option is greater than 10 (1024 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>iburst</tt></dt>
- <dd>When the server is unreachable, send a burst of eight packets instead of
- the usual one. The packet spacing is normally 2 s; however, the spacing between
- the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command
- to allow additional time for a modem or ISDN call to complete. This option
- is valid only with the <tt>server</tt> command and type s addresses. It is
- a recommended option with this command.</dd>
+ <dd>When the server is unreachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command to allow additional time for a modem or ISDN call to complete. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option with this command. Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>key</tt> <i><tt>key</tt></i></dt>
- <dd>Send and receive packets authenticated by the symmetric key scheme described
- in the <a href="authentic.html">Authentication Support</a> page.
- The <i><tt>key</tt></i> specifies the key identifier with values from 1 to
- 65534, inclusive. This option is mutually exclusive with the <tt>autokey</tt> option.</dd>
- <dt><tt>minpoll <i>minpoll<br>
- </i></tt><tt>maxpoll <i>maxpoll</i></tt></dt>
- <dd>These options specify the minimum and maximum poll intervals for NTP messages,
- in seconds as a power of two. The maximum poll interval defaults to 10
- (1024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit
- of 17 (36 h). The minimum poll interval defaults to 6 (64 s), but can
- be decreased by the <tt>minpoll</tt> option to a lower limit of 3 (8 s).</dd>
+ <dd>Send and receive packets authenticated by the symmetric key scheme described in the <a href="authentic.html">Authentication Support</a> page. The <i><tt>key</tt></i> specifies the key identifier with values from 1 to 65534, inclusive. This option is mutually exclusive with the <tt>autokey</tt> option.</dd> <dt><tt>minpoll <i>minpoll<br>
+ </i></tt><tt>maxpoll <i>maxpoll</i></tt></dt>
+ <dd>These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two. The maximum poll interval defaults to 10 (1024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit of 17 (36 hr). The minimum poll interval defaults to 6 (64 s), but can be decreased by the <tt>minpoll</tt> option to a lower limit of 3 (8 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>mode <i>option</i></tt></dt>
- <dd>Pass the <tt><i>option</i></tt> to a reference clock driver, where <tt><i>option</i></tt> is
- an integer in the range from 0 to 255, inclusive. This option is valid
- only with type r addresses.</dd>
+ <dd>Pass the <tt><i>option</i></tt> to a reference clock driver, where <tt><i>option</i></tt> is an integer in the range from 0 to 255, inclusive. This option is valid only with type r addresses.</dd>
<dt><tt>noselect</tt></dt>
- <dd>Marks the server or peer to be ignored by the selection algorithm but visible
- to the monitoring program. This option is ignored with the <tt>broadcast</tt> command.</dd>
+ <dd>Marks the server or peer to be ignored by the selection algorithm but visible to the monitoring program. This option is ignored with the <tt>broadcast</tt> command.</dd>
<dt><tt>preempt</tt></dt>
- <dd>Specifies the association as preemptable rather than the default persistent.
- This option is ignored with the <tt>broadcast</tt> command and is most useful
- with the <tt>manycastclient</tt> and <tt>pool</tt> commands.</dd>
+ <dd>Specifies the association as preemptable rather than the default persistent. This option is ignored with the <tt>broadcast</tt> command and is most useful with the <tt>manycastclient</tt> and <tt>pool</tt> commands.</dd>
<dt><tt>prefer</tt></dt>
- <dd>Mark 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.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page
- for further information. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
+ <dd>Mark 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.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page for further information. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dt><tt>true</tt></dt>
- <dd>Mark the association to assume truechimer status; that is, always survive
- the selection and clustering algorithms. This option can be used with any association,
- but is most useful for reference clocks with large jitter on the serial port
- and precision pulse-per-second (PPS) signals. Caution: this option defeats
- the algorithms designed to cast out falsetickers and can allow these sources
- to set the system clock. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
+ <dd>Mark the association to assume truechimer status; that is, always survive the selection and clustering algorithms. This option can be used with any association, but is most useful for reference clocks with large jitter on the serial port and precision pulse-per-second (PPS) signals. Caution: this option defeats the algorithms designed to cast out falsetickers and can allow these sources to set the system clock. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dt><tt>ttl <i>ttl</i></tt></dt>
- <dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> command
- and the maximum <i><tt>ttl</tt></i> for the expanding ring search used by the <tt>manycastclient</tt> command.
- Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator. This option is invalid with type r addresses.</dd>
+ <dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> command and the maximum <i><tt>ttl</tt></i> for the expanding ring search used by the <tt>manycastclient</tt> command. Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator. This option is invalid with type r addresses.</dd>
<dt><tt>version <i>version</i></tt></dt>
- <dd>Specifies the version number to be used f
-or outgoing NTP packets. Versions
- 1-4 are the choices, with version 4 the default.</dd>
+ <dd>Specifies the version number to be used of
+or outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.</dd>
<dt><tt>xleave</tt></dt>
- <dd>Operate in interleaved mode (symmetric and broadcast modes only). Further information is on the <a href="xleave.html">NTP
- Interleaved Modes</a> page.</dd>
+ <dd>Operate in interleaved mode (symmetric and broadcast modes only). Further information is on the <a href="xleave.html">NTP Interleaved Modes</a> page.</dd>
</dl>
-<h4 id="aux">Auxilliary Commands</h4>
+<h4 id="aux">Auxiliary Commands</h4>
<dl>
<dt id="broadcastclient"><tt>broadcastclient</tt></dt>
- <dd>Enable reception of broadcast server messages to any local interface (type
- b address). Ordinarily, upon receiving a broadcast message for the first
- time, the broadcast client measures the nominal server propagation delay using
- a brief client/server exchange, after which it continues in listen-only mode.
- If a nonzero value is specified in the <tt>broadcastdelay</tt> command, the
- value becomes the delay and the volley is not executed. Note: the <tt>novolley</tt> option
- has been deprecated for future enhancements. Note that, in order to avoid
- accidental or malicious disruption in this mode, both the server and client
- should operate using symmetric key or public key authentication as described
- in the <a href="authopt.html">Authentication
- Options</a> page. Note that the <tt>novolley</tt> keyword is incompatible with
- public key authentication.</dd>
+ <dd>Enable reception of broadcast server messages to any local interface (type b address). Ordinarily, upon receiving a broadcast message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange, after which it continues in listen-only mode. If a nonzero value is specified in the <tt>broadcastdelay</tt> command, the value becomes the delay and the volley is not executed. Note: the <tt>novolley</tt> option has been deprecated for future enhancements. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page. Note that the <tt>novolley</tt> keyword is incompatible with public key authentication.</dd>
<dt id="manycastserver"><tt>manycastserver <i>address</i> [...]</tt></dt>
- <dd>Enable reception of manycast client messages (type m)to the multicast group
- address(es) (type m) specified. At least one address is required. Note that,
- in order to avoid accidental or malicious disruption, both the server and client
- should operate using symmetric key or public key authentication as described
- in the <a href="authopt.html">Authentication Options</a> page.</dd>
+ <dd>Enable reception of manycast client messages (type m)to the multicasts group address(es) (type m) specified. At least one address is required. Note that, in order to avoid accidental or malicious disruption, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page.</dd>
<dt id="multicastclient"><tt>multicastclient <i>address</i> [...]</tt></dt>
- <dd>Enable reception of multicast server messages to the multicast group address(es)
- (type m) specified. Upon receiving a message for the first time, the multicast
- client measures the nominal server propagation delay using a brief client/server
- exchange with the server, then enters the broadcast client mode, in which it
- synchronizes to succeeding multicast messages. Note that, in order to avoid
- accidental or malicious disruption in this mode, both the server and client
- should operate using symmetric key or public key authentication as described
- in the <a href="authopt.html">Authentication Options</a> page.</dd>
+ <dd>Enable reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page.</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
^
<h3>Clock Discipline Algorithm</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->22-Sep-2010 21:08<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->10-Oct-2010 2:27<!-- #EndDate -->
UTC</p>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a></li>
<li class="inline"><a href="#pll">Phase-Lock Loop Operations</a></li>
<li class="inline"><a href="#loop">Loop Dynamics</a></li>
- <li class="inline"><a href="#poll">Poll Interval Management</a></li>
- <li class="inline"><a href="#state">Clock State Machine</a></li>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
<p>However, the clock state machine used with the discipline algorithm avoids this transient at startup. It does this using a previously saved frequency file, if present, or by measuring the oscillator frequency, if not. It then quickly amortizes the residual offset at startup without affecting the oscillator frequency. In this way the offset error is less than 0.5 ms within 5 min if the file is present and within 10 min if not. See the <a href="clock.html">Clock State Machine</a> page for further details.</p>
<p>Since the PLL is linear, the response with different offset step amplitudes and poll intervals has the same characteristic shape, but scaled differently in amplitude and time. The response scales exactly with step amplitude, so that the response to a 10-ms step has the same shape as at 64 s, but with amplitude compressed by one-tenth. The response scales exactly with poll interval, so that response at a poll interval of 8 s has the same shape as at 64 s, but with time compressed by one-eighth.</p>
<p>In the NTP specification and reference implementation, poll intervals are expressed as exponents of 2. The clock discipline time constant is proportional to the poll interval by a factor of 32. Thus, a poll exponent of 6 corresponds to a poll interval of 64 s and a time constant of 2048 s. A change in the poll interval changes the time constant by a corresponding amount.</p>
-<p> The optimum time constant, and thus the poll interval, depends on the network time jitter and the oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. For typical Internet paths, the two error characteristics intersect at a point called the Allan intercept, which represents the ideal time constant. With a compromise Allan intercept of 2000 s, the optimum poll interval is about 64 s, which corresponds to a compromise poll exponent of 6. For fast LANs with modern computers, the Allan intercept is somewhat lower, so a compromise poll exponent of 8 is appropriate.</p>
-<h4 id="poll">Poll Interval Management</h4>
-<p>The poll interval is managed by a heuristic algorithm developed over several years of experimentation. It depends on an exponentially weighted average of clock offset differences, called the clock jitter, and a jiggle counter, which is initially set to zero. When a clock update is received and the offset exceeds the clock jitter by a factor of 4, the jiggle counter is increased by the poll exponent; otherwise, it is decreased by twice the poll exponent. If the jiggle counter is greater than an arbitrary threshold of 30, the poll exponent. if jiggle counter exceed an arbitrary threshold of 30, it is reset to zero and the poll exponent increased by 1. If the jiggle counter is less than -30, it is set to zero and the poll exponent decreased by 1. In effect, the algorithm has a relatively slow reaction to good news, but a relatively fast reaction to bad news.</p>
-<p>The optimum time constant, and thus the poll exponent, depends on the network time jitter and the clock oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. The two error characteristics intersect at a point called the Allan intercept, which represents the ideal time constant. With a compromise Allan intercept of 2000 s, the optimum poll interval is about 64 s, which corresponds to a poll exponent of 6.</p>
-<h4 id="state">Clock State Machine</h4>
+<p> The optimum time constant, and thus the poll interval, depends on the network time jitter and the oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. For typical Internet paths, the two error characteristics intersect at a point called the Allan intercept, which represents the ideal time constant. With a compromise Allan intercept of 2000 s, the optimum poll interval is about 64 s, which corresponds to a compromise poll exponent of 6. For fast LANs with modern computers, the Allan intercept is somewhat lower, so a compromise poll exponent of 8 is appropriate. An intricate, heuristic algorithm is used to manage the actual poll interval within a specified range. Details are on the <a href="poll.html">Poll Program</a> page.</p>
<p>In the NTPv4 specification and reference implementation a state machine is used to manage the system clock under exceptional conditions, as when the daemon is first started or when encountering severe network congestion. When the frequency file is present at startup is that the residual offset error is less than 0.5 ms within 300 s. When the frequency file is not present, this result is achieved within 600 s. Further details are on the <a href="clock.html">Clock State Machine</a> page.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<body>
<h3>How NTP Works</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->03-Oct-2010 1:48<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->09-Oct-2010 23:00<!-- #EndDate -->
UTC</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/special.txt"></script>
<h4 id="intro">Introduction and Overview</h4>
<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in late 2010 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
<p> The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio and telephone modem. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice.</p>
-<p>This page presents an overview of the NTP daemon included in this distribution. We refer to this as the <em>reference implementation</em> only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
+<p>This page presents an overview of the NTP daemon included in this distribution. We refer to this
daemon as the <em>reference implementation</em> only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<div align="center">
<p><img src="pic/fig_3_1.gif" alt="gif"></p>
<p>Figure 1. NTP Daemon Processes and Algorithms</p>
</div>
-<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and runs the on-wire protocol that collects four raw timestamps: the <em>origin timestamp</em> <em>T</em><sub>1</sub> upon departure of the client request, the <em>receive timestamp</em> <em>T</em><sub>2</sub> upon arrival at the server, the <em>transmit timestamp</em> <em>T</em><sub>3</sub> upon departure of the server reply, and the <em>destination timestamp</em> <em>T</em><sub>4</sub> upon arrival at the client. These timestamps, which are recorded as the <tt>rawstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command, are used to calculate the clock offset and roundtrip delay:</p>
+<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and performs the packet sanity tests of the <a href="decode.html#flash">flash status word</a>. Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process runs the on-wire protocol that uses four raw timestamps: the <em>origin timestamp</em> <em>T</em><sub>1</sub> upon departure of the client request, the <em>receive timestamp</em> <em>T</em><sub>2</sub> upon arrival at the server, the <em>transmit timestamp</em> <em>T</em><sub>3</sub> upon departure of the server reply, and the <em>destination timestamp</em> <em>T</em><sub>4</sub> upon arrival at the client. These timestamps, which are recorded by the <tt>rawstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command, are used to calculate the clock offset and roundtrip delay samples:</p>
<div align="center">
<p>offset = [(<em>T</em><sub>2</sub> -<em> T</em><sub>1</sub>) + (<em>T</em><sub>3</sub> - <em>T</em><sub>4</sub>)] / 2<br>
delay = (<em>T</em><sub>4</sub> - <em>T</em><sub>1</sub>) - (<em>T</em><sub>3</sub> - <em>T</em><sub>2</sub>).</p>
</div>
-<p>The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page
uses a window of offset and delay samples to select the best ones. Those sources that have passed a number of sanity checks are declared <em>selectable</em>. From the selectable population the statistics are used by the algorithm described on the <a href="select.html">Clock Select Algorithm</a> page to determine a number of <em>truechimers</em> according to correctness principles. From the truechimer population the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page determines a number of <em>survivors</em> on the basis of statistical clustering principles. The algorithms described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page combine the survivor offsets, designate one of them as the <em>system peer</em> and produces the final offset used by the algorithm described on the <a href="discipline.html">Clock Discipline Algorithm</a> page to adjust the system clock time and frequency. For additional details about these algorithms, see the Architecture Briefing on the <a href="htttp://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
+<p>The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page
selects the offset and delay samples most likely to produce accurate time. Those peers that have passed the peer sanity tests of the <a href="decode.html#flash">flash status word</a> are declared <em>selectable</em>. From the selectable population the statistics are used by the algorithm described on the <a href="select.html">Clock Select Algorithm</a> page to determine a number of <em>truechimers</em> according to correctness principles. From the truechimer population the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page determines a number of <em>survivors</em> on the basis of statistical clustering principles. The algorithms described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page combine the survivor offsets, designate one of them as the <em>system peer</em> and produces the final offset used by the algorithm described on the <a href="discipline.html">Clock Discipline Algorithm</a> page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. For additional details about these algorithms, see the Architecture Briefing on the <a href="htttp://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<h4 id="budget">Statistics Budget</h4>
-<p>Each source is characterized by the offset and delay measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm. This algorithm selects the offset sample with the lowest delay, which generally represents the most accurate data, so it and the associated offset sample become the <em>peer offset</em> and <em>peer delay</em>. The <em>peer dispersion</em> is determined as a weighted average of the dispersion samples in the shift register. It continues to grow at the same rate as the sample dispersion. Finally, the <em>peer jitter</em> is determined as the root-mean-square (RMS) average of the offset samples in the shift register relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter are recorded as the <tt>peerstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</p>
+<p>Each source is characterized by the offset and delay samples measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm. In a window of eight samples, this algorithm selects the offset sample with the lowest delay, which generally represents the most accurate data. The selected samples become the <em>peer offset</em> and <em>peer delay</em>. The <em>peer dispersion</em> is determined as a weighted average of the dispersion samples in the window. It continues to grow at the same rate as the sample dispersion, 15 <font face="symbol">m</font>s/s. Finally, the <em>peer jitter</em> is determined as the root-mean-square (RMS) average of the offset samples in the window relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter are recorded by the <tt>peerstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. Peer variables are displayed by the <tt>rv</tt> command of the <a href="ntpq.html#peer"><tt>ntpq</tt></a> program.</p>
<p> The clock filter algorithm continues to process packets in this way until the source is no longer reachable. Reachability is determined by an eight-bit shift register, which is shifted left by one bit as each poll packet is sent, with 0 replacing the vacated rightmost bit. Each time an update is received, the rightmost bit is set to 1. The source is considered reachable if any bit is set to 1 in the register; otherwise, it is considered unreachable.</p>
-<p> A server is considered selectable only if it is reachable and a timing loop would not be created. A timing loop occurs when the server is apparently synchronized to the client or when the server is synchronized to the same server as the client. When a source is unreachable, a dummy sample with "infinite" dispersion is inserted in the shift register at each poll, thus displacing old samples.</p>
-<p>The composition of the survivor population and the system peer selection is redetermined as each update from each source is received. The system variables are copied from the system peer variables of the same name and the system stratum set one greater than the system peer stratum. Like peer dispersion, the system dispersion increases at the same rate so, even if all sources have become unreachable, the daemon appears to dependent clients at ever increasing dispersion. It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.</p>
+<p>A server is considered selectable only if it is reachable and a timing loop would not be created. A timing loop occurs when the server is apparently synchronized to the client or when the server is synchronized to the same server as the client. When a source is unreachable, a dummy sample with "infinite" dispersion is inserted in the shift register at each poll, thus displacing old samples.</p>
+<p>The composition of the survivor population and the system peer selection is redetermined as each update from each source is received. The system variables are copied from the system peer variables of the same name and the system stratum set one greater than the system peer stratum. System variables are displayed by the <tt>rv</tt> command of the <a href="ntpq.html#system"><tt>ntpq</tt></a> program.</p>
+<p> Like peer dispersion, the system dispersion increases at the same rate so, even if all sources have become unreachable, the daemon appears to dependent clients at ever increasing dispersion. It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.</p>
<h4 id="quality">Quality of Service</h4>
-<p>Of interest in this discussion is how the protocol determines the quality of service from a particular reference clock or remote server. It is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error is determined from various jitter components; it represents the nominal error in determining the mean clock offset. The mitigation algorithms deliver two important statistics, <em>system offset</em> and <em>system jitter</em>. These statistics are determined by the mitigation algorithms's from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported as the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</p>
-<p> Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify this presentation, certain minor contribution s to the maximum error statistic are ignored. Elsewhere in this documentation the maximum error is called <em>synchronization distance</em>. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettimeofday()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
+<p>The mitigation algorithms deliver several important statistics, including <em>system offset</em> and <em>system jitter</em>. These statistics are determined by the mitigation algorithms's from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</p>
+<p>Of interest in this discussion is how the daemon determines the quality of service from a particular reference clock or remote server. This is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error, or system jitter, is determined from various jitter components; it represents the nominal error in determining the mean clock offset. </p>
+<p>Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called <em>synchronization distance</em>. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettimeofday()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
<p>The maximum error is computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.</p>
<p>A source is considered selectable only if its maximum error is less than the <em>select threshold</em>, by default 1.5 s, but can be changed according to client preference using the <tt>maxdist</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. A common consequences is when an upstream server loses all sources and its maximum error apparent to dependent clients begins to increase. The clients are not aware of this condition and continues to accept synchronization as long as the maximum error is less than the select threshold.</p>
-<p>Although it might seem counter-intuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. This means that not every sample can be used to update the peer variables and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration of the feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.</p>
+<p>Although it might seem counter-intuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the clock select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. This means that not every sample can be used to update the peer variables and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration for feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
projects / thirdparty / ntp.git / commitdiff
