<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Automatic Server Discoveryschemes</title>
+<title>Access Control Commands and Options</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
+<style type="text/css">
+<!--
+<style1 {
+color: #FF0000;
+ font-weight: bold;
+}
+-->
+</style>
</head>
<body>
-<h3>Automatic Server Discovery Schemes</h3>
-<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-<p>Make sure who your friends are.</p>
+<h3>Access Control Commands and Options</h3>
+<img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+<p>The skunk watches for intruders and sprays.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->11-Oct-2011 18:51<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 16:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
-<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
-<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
-<h4>Table of Contents</h4>
-<ul>
- <li class="inline"><a href="#assoc">Association Management</a></li>
- <li class="inline"><a href="#bcst">Broadcast/Multicast Scheme</a></li>
- <li class="inline"><a href="#mcst">Manycast Scheme</a></li>
- <li class="inline"><a href="#pool">Server Pool Scheme</a></li>
-</ul>
+<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
+<script type="text/javascript" language="javascript" src="scripts/accopt.txt"></script>
<hr>
-<h4 id="modes">Introduction</h4>
-<p>This page describes the automatic server discovery schemes provided in NTPv4. There are three automatic server discovery schemes: broadcast/multicast, manycast and server pool described on this page. The broadcast/multicast and manycast schemes utilize the ubiquitous broadcast or one-to-many paradigm native to IPv4 and IPv6. The server pool scheme uses DNS to resolve addresses of multiple volunteer servers scattered throughout the world. All three schemes work in much the same way and might be described as <i>grab-n'-prune</i>. Through one means or another they grab a number of associations either directly or indirectly from the configuration file, order them from best to worst according to a defined metric, then cast off the associations with the lowest metric until no more than the number specified by the <tt>maxclock</tt> option of the <tt>tos</tt>command remain.</p>
-<h4 id="assoc">Association Management</h4>
-<p>All schemes use a stratum filter to select just those servers with stratum considered useful. This can avoid large numbers of clients ganging up on a small number of low-stratum servers and avoid servers below or above specified stratum levels. By default, servers of all strata are acceptable; however, the <tt>tos</tt> command can be used to restrict the acceptable range from the <tt>floor</tt> option, inclusive, to the <tt>ceiling</tt> option, exclusive. Potential servers operating at the same stratum as the client will be avoided, unless the <tt>cohort</tt> option is present.</p>
-<p>The pruning process is handled using a set of counters, one for each preemptible association. Once each poll interval the counter is increased by one. If the association survives the selection and clustering algorithms; that is, it is a candidate for synchronization, the counter is reset to zero. If not and the counter reaches a defined threshold and the number of assocations is greater than <tt>maxclock</tt>, the association becomes a candidate for pruning. The pruning algorithm assigns to each association a metric ranging from the lowest, corresponding to no possibility of synchronization, to the highest, corresponding to a very likely possibility of synchronization. Upon reaching the threshold, an association is demobilized if it has the lowest metric of all associations. Operation continues in this way until the number of remaining associations is not greater than <tt>maxclock</tt>.</p>
-<p>Following is a summary of each scheme. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
-<h4 id="bcst">Broadcast/Multicast Scheme</h4>
-<p>A broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overriden by the <tt>minpoll</tt> and <tt>ttl</tt> options, respectively. Not all kernels support the <tt>ttl</tt> option. A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. It then polls the server in client/server mode using the <tt>iburst</tt> option in order to quickly authenticate the server, calibrate the propagation delay and set the host clock. This normally results in a volley of six client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.</p>
-<p>Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to these messages, the client will cease transmission and continue in listen-only mode with a default propagation delay. The volley can be avoided by using the <tt>broadcastdelay</tt> command with nonzero argument.</p>
-<p>A server is configured in broadcast mode using the <tt>broadcast</tt> command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a <tt>broadcast</tt> command is needed for each address. This provides a way to limit exposure in a firewall, for example. A broadcast client is configured using the <tt>broadcastclient</tt> command. </p>
-<p>NTP multicast mode can be used to extend the scope using IPv4 multicast or IPv6 broadcast with defined span. The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
-<p>A multicast server is configured using the <tt>broadcast</tt> command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the <tt>multicastclient</tt> command specifying a list of one or more multicast addresses. Note that there is a subtle distinction between the IPv4 and IPv6 address families. The IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For IPv6 the same distinction can be made using the link-local prefix FF02 for each interface and site-local prefix FF05 for all interfaces.</p>
-<p>It is possible and frequently useful to configure a host as both broadcast client and broadcast server. A number of hosts configured this way and sharing a common broadcast address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.</p>
-<p>Since an intruder can impersonate a broadcast server and inject false time values, broadcast mode should always be cryptographically authenticated. By default, a broadcast association will not be mobilized unless cryptographically authenticated. If necessary, the <tt>auth</tt> option of the <tt>disable</tt> command will disable this feature. The feature can be selectively enabled using the <tt>notrust</tt> option of the <tt>restrict</tt> command.</p>
-<p>With symmetric key cryptography each broadcast server can use the same or different keys. In one scenario on a broadcast LAN, a set of broadcast clients and servers share the same key along with another set that share a different key. Only the clients with matching key will respond to a server broadcast. Further information is on the <a href="authentic.html">Authentication Support</a> page.</p>
-<p>Public key cryptography can be used with some restrictions. If multiple servers belonging to different secure groups share the same broadcast LAN, the clients on that LAN must have the client keys for all of them. This scenario is illustrated in the example on the <a href="autokey.html">Autokey Public Key Authentication</a> page.</p>
-<h4 id="mcst">Manycast Scheme</h4>
-<p>Manycast is a automatic server discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. It uses the grab-n'-drop paradigm with the additional feature that active means are used to grab additional servers should the number of survivors fall below the <tt>minclock</tt> option of the <tt>tos</tt> command.</p>
-<p>The manycast paradigm is not the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p>
-<p>A manycast clients is configured using the <tt>manycastclient</tt> configuration command, which is similar to the <tt>server</tt> configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than <tt>minclock</tt> associations remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for future unicast client/server associations.</p>
-<p>A manycast server is configured using the <tt>manycastserver</tt> command, which listens on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies with an ordinary unicast server message.</p>
-<p>The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. </p>
-<p>It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common multicast group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.</p>
-<p>The use of cryptograpic authentication is always a good idea in any server discovery scheme. Both symmetric key and public key cryptography can be used in the same scenarios as described above for the broadast/multicast scheme.</p>
-<h4 id="pool">Server Pool Scheme</h4>
-<p>The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several thousand operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers using the NTP mitigation algorithms.</p>
-<p>To support this service custom DNS software used for pool.ntp.org and its subdomains
- returns a random selection of participating servers in response to a DNS query.
- The client receiving this list mobilizes some or all of them, similar to the
- manycast discovery scheme, and casts off the excess. Unlike <tt>manycastclient</tt>,
- cryptographic authentication is not required. The pool scheme solicits a single
- server at a time, compared to <tt>manycastclient</tt> which solicits all servers
- within a multicast TTL range simultaneously. Otherwise, the pool server discovery
- scheme operates as manycast does.</p>
-<p>The pool scheme is configured using one or more <tt>pool</tt> commands with DNS names
- indicating the pool from which to draw. The <tt>pool</tt> command can be used more
- than once; duplicate servers are detected and discarded. In principle, it is
- possible to use a configuration file containing a single line <tt>pool
- pool.ntp.org</tt>. The <a href="http://www.pool.ntp.org/en/use.html">NTP Pool
- Project</a> offers instructions on using the pool with the <tt>server</tt> command, which is suboptimal but works with older versions of <tt>ntpd</tt> predating the <tt>pool</tt> command. With recent ntpd, consider replacing the
- multiple <tt>server</tt> commands in their example with a single <tt>pool</tt> command.</p>
+<h4>Commands and Options</h4>
+<p>Unless noted otherwise, further information about these ccommands is on the <a href="accopt.html">Access Control Support</a> page.</p>
+<dl>
+ <dt id="discard"><tt>discard [ average <i>avg</i> ][ minimum <i>min</i> ] [ monitor <i>prob</i> ]</tt></dt>
+ <dd>Set the parameters of the rate control facility which protects the server from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets that violate these limits are discarded. If, in addition, the <tt>kod</tt> flag is present, a kiss-o'-death packet is returned. See the <a href="rate.html">Rate Management</a> page for further information. The options are:
+ <dl>
+ <dt><tt>average <i>avg</i></tt></dt>
+ <dd>Specify the minimum average interpacket spacing (minimum average headway
+ time) in log<sub>2</sub> s with default 3.</dd>
+ <dt><tt>minimum <i>min</i></tt></dt>
+ <dd>Specify the minimum interpacket spacing (guard time) in seconds with default 2.</dd>
+ <dt><tt>monitor</tt></dt>
+ <dd>Specify the probability of being recorded for packets that overflow the MRU list size limit set by <tt>mru maxmem</tt> or <tt>mru maxdepth</tt>. This is a performance optimization for servers with aggregate arrivals of 1000 packets per second or more.</dd>
+ </dl>
+ </dd>
+ <dt id="restrict"><tt>restrict default [<i>flag</i>][...]<br>
+ restrict source [<i>flag</i>][...]<br>
+ restrict <i>address</i> [mask <i>mask</i>] [<i>flag</i>][...]</tt></dt>
+ <dd>The <tt><i>address</i></tt> argument expressed in dotted-quad form is the address of a host or network. Alternatively, the <tt><i>address</i></tt> argument can be a valid host DNS name. The <tt><i>mask</i></tt> argument expressed in IPv4 or IPv6 numeric address form defaults to all mask bits on, meaning that the <tt><i>address</i></tt> is treated as the address of an individual host. A default entry (address 0.0.0.0, mask 0.0.0.0 for IPv4 and address :: mask :: for IPv6) is always the first entry in the list. <tt>restrict default</tt>, with no mask option, modifies both IPv4 and IPv6 default entries. <tt>restrict source</tt> configures a template restriction automatically added at runtime for each association, whether configured, ephemeral, or preemptible, and removed when the association is demobilized.</dd>
+ <dd>Some flags have the effect to deny service, some have the effect to enable service and some are conditioned by other flags. The flags. are not orthogonal, in that more restrictive flags will often make less restrictive ones redundant. The flags that deny service are classed in two categories, those that restrict time service and those that 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>
+ <dl>
+ <dt><tt>flake</tt></dt>
+ <dd>Discard received NTP packets with probability 0.1; that is, on average drop one packet in ten. This is for testing and amusement. The name comes from Bob Braden's <i>flakeway</i>, which once did a similar thing for early Internet testing.</dd>
+ <dt><tt>ignore</tt></dt>
+ <dd>Deny packets of all kinds, including <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
+ <dt><tt>kod</tt></dt>
+ <dd>Send a kiss-o'-death (KoD) packet if the <tt>limited</tt> flag is present and a packet violates the rate limits established by the <tt>discard</tt> command. KoD packets are themselves rate limited for each source address separately. If the <tt>kod</tt> flag is used in a restriction which does not have the <tt>limited</tt> flag, no KoD responses will result.</dd>
+ <dt id="limited"><tt>limited</tt></dt>
+ <dd>Deny time service if the packet violates the rate limits established by the <tt>discard</tt> command. This does not apply to <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</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>mssntp</tt></dt>
+ <dd>Enable Microsoft Windows MS-SNTP authentication using Active Directory services. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></dd>
+ <dt><tt>nomodify</tt></dt>
+ <dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries which attempt to modify the state of the server (i.e., run time reconfiguration). Queries which return information are permitted.</dd>
+ <dt><tt>noquery</tt></dt>
+ <dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries. Time service is not affected.</dd>
+ <dt><tt>nopeer</tt></dt>
+ <dd>Deny packets that might mobilize an association unless authenticated. This includes broadcast, symmetric-active and manycast server packets when a configured association does not exist. Note that this flag does not apply to packets that do not attempt to mobilize an association. </dd>
+ <dt><tt>noserve</tt></dt>
+ <dd>Deny all packets except <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</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 <tt>ntpdc</tt> control message protocol which is intended for use by remote event logging programs.</dd>
+ <dt><tt>notrust</tt></dt>
+ <dd>Deny packets that are not cryptographically authenticated. Note carefully how this flag interacts with the <tt>auth</tt> option of the <tt>enable</tt> and <tt>disable</tt> commands. If <tt>auth</tt> is enabled, which is the default, authentication is required for all packets that might mobilize an association. If <tt>auth</tt> is disabled, but the <tt>notrust</tt> flag is not present, an association can be mobilized whether or not authenticated. If <tt>auth</tt> is disabled, but the <tt>notrust</tt> flag is present, authentication is required only for the specified address/mask range. </dd>
+ <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). A restrict line
+ containing <tt>ntpport</tt> is considered more specific than one with the
+ same address and mask, but lacking <tt>ntpport</tt>.</dd>
+ <dt><tt>version</tt></dt>
+ <dd>Deny packets that do not match the current NTP version.</dd>
+ </dl>
+ </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>
+</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Event Messages and Status Words</title>
+<title>Association Management</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
-<h3>Event Messages and Status Words</h3>
-<img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
-<p>Caterpillar knows all the error codes, which is more than most of us do.</p>
+<h3>Association Management</h3>
+<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+<p>Make sure who your friends are.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->04-Oct-2011 21:20<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->12-May-2011 13:16<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
-<p>
- <script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
-</p>
+<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
+<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
<h4>Table of Contents</h4>
<ul>
- <li class="inline"><a href="#intro">Introduction</a></li>
- <li class="inline"><a href="#sys">System Status Word</a></li>
- <li class="inline"><a href="#peer">Peer Status Word</a></li>
- <li class="inline"><a href="#clock">Clock Status Word</a></li>
- <li class="inline"><a href="#flash">Flash Status Word</a></li>
- <li class="inline"><a href="#kiss">Kiss Codes</a></li>
- <li class="inline"><a href="#crypto">Crypto Messages</a></li>
+ <li class="inline"><a href="#modes">Association Modes</a></li>
+ <li class="inline"><a href="#client">Client/Server Mode</a></li>
+ <li class="inline"><a href="#symact">Symmetric Active/Passive Mode</a></li>
+ <li class="inline"><a href="#broad">Broadcast/Multicast Modes</a></li>
+ <li class="inline"><a href="#many">Manycast Mode</a></li>
+ <li class="inline"><a href="#poll">Poll Interval Management</a></li>
+ <li class="inline"><a href="#burst">Burst Options</a></li>
</ul>
<hr>
-<h4 id="intro">Introduction</h4>
-<p>This page lists the status words, event messages and error codes used for <tt>ntpd</tt> reporting and monitoring. Status words are used to display the current status of the running program. There is one system status word and a peer status word for each association. There is a clock status word for each association that supports a reference clock. There is a flash code for each association which shows errors found in the last packet received (pkt) and during protocol processing (peer). These are commonly viewed using the <tt>ntpq</tt> program.</p>
-<p>Significant changes in program state are reported as events. There is one
- set of system events and a set of peer events for each association. In addition,
- there is a set of clock events for each association that supports a reference
- clock. Events are normally reported to the <tt>protostats</tt> monitoring file
- and optionally to the system log. In addition, if the trap facility is configured,
- events can be reported to a remote program that can page an administrator.</p>
-<p>This page also includes a description of the error messages produced by the Autokey protocol. These messages are normally sent to the <tt>cryptostats</tt> monitoring file.</p>
-<p>In the following tables the Code Field is the status or event code assigned and the Message Field a short string used for display and event reporting. The Description field contains a longer explanation of the status or event. Some messages include additional information useful for error diagnosis and performance assessment.</p>
-<h4 id="sys">System Status Word</h4>
-<p>The system status word consists of four fields LI (0-1), Source (2-7), Count (8-11) and Code (12-15). It is reported in the first line of the <tt>rv</tt> display produced by the <tt>ntpq</tt> program.</p>
-<table width="50%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td><div align="center">Leap</div></td>
- <td><div align="center">Source</div></td>
- <td><div align="center">Count</div></td>
- <td><div align="center">Code</div></td>
- </tr>
-</table>
-<p>The Leap Field displays the system leap indicator bits coded as follows:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>0</tt></td>
- <td><tt>leap_none</tt></td>
- <td>normal synchronized state</td>
- </tr>
- <tr>
- <td><tt>1</tt></td>
- <td><tt>leap_add_sec</tt></td>
- <td>insert second after 23:59:59 of the current day</td>
- </tr>
- <tr>
- <td><tt>2</tt></td>
- <td><tt>leap_del_sec</tt></td>
- <td>delete second 23:59:59 of the current day</td>
- </tr>
- <tr>
- <td><tt>3</tt></td>
- <td><tt>leap_alarm</tt></td>
- <td>never synchronized</td>
- </tr>
-</table>
-<p>The Source Field displays the current synchronization source coded as follows:.</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>0</tt></td>
- <td><tt>sync_unspec</tt></td>
- <td>not yet synchronized</td>
- </tr>
- <tr>
- <td><tt>1</tt></td>
- <td><tt>sync_pps</tt></td>
- <td>pulse-per-second signal (Cs, Ru, GPS, etc.)</td>
- </tr>
- <tr>
- <td><tt>2</tt></td>
- <td><tt>sync_lf_radio</tt></td>
- <td>VLF/LF radio (WWVB, DCF77, etc.)</td>
- </tr>
- <tr>
- <td><tt>3</tt></td>
- <td><tt>sync_hf_radio</tt></td>
- <td>MF/HF radio (WWV, etc.)</td>
- </tr>
- <tr>
- <td><tt>4</tt></td>
- <td><tt>sync_uhf_radio</tt></td>
- <td>VHF/UHF radio/satellite (GPS, Galileo, etc.)</td>
- </tr>
- <tr>
- <td><tt>5</tt></td>
- <td><tt>sync_local</tt></td>
- <td>local timecode (IRIG, LOCAL driver, etc.)</td>
- </tr>
- <tr>
- <td><tt>6</tt></td>
- <td><tt>sync_ntp</tt></td>
- <td>NTP</td>
- </tr>
- <tr>
- <td><tt>7</tt></td>
- <td><tt>sync_other</tt></td>
- <td>other (IEEE 1588, openntp, crony, etc.)</td>
- </tr>
- <tr>
- <td><tt>8</tt></td>
- <td><tt>sync_wristwatch</tt></td>
- <td>eyeball and wristwatch</td>
- </tr>
- <tr>
- <td><tt>9</tt></td>
- <td><tt>sync_telephone</tt></td>
- <td>telephone modem (ACTS, PTB, etc.)</td>
- </tr>
-</table>
-<p>The Count Field displays the number of events since the last time the code changed. Upon reaching 15, subsequent events with the same code are ignored.</p>
-<p>The Event Field displays the most recent event message coded as follows:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>00</tt></td>
- <td><tt>unspecified</tt></td>
- <td>unspecified</td>
- </tr>
- <tr>
- <td><tt>01</tt></td>
- <td><tt>freq_not_set</tt></td>
- <td>frequency file not available</td>
- </tr>
- <tr>
- <td><tt>02</tt></td>
- <td><tt>freq_set</tt></td>
- <td>frequency set from frequency file</td>
- </tr>
- <tr>
- <td><tt>03</tt></td>
- <td><tt>spike_detect</tt></td>
- <td>spike detected</td>
- </tr>
- <tr>
- <td><tt>04</tt></td>
- <td><tt>freq_mode</tt></td>
- <td>initial frequency training mode</td>
- </tr>
- <tr>
- <td><tt>05</tt></td>
- <td><tt>clock_sync</tt></td>
- <td>clock synchronized</td>
- </tr>
- <tr>
- <td><tt>06</tt></td>
- <td><tt>restart</tt></td>
- <td>program restart</td>
- </tr>
- <tr>
- <td><tt>07</tt></td>
- <td><tt>panic_stop</tt></td>
- <td>clock error more than 600 s</td>
- </tr>
- <tr>
- <td><tt>08</tt></td>
- <td><tt>no_system_peer</tt></td>
- <td>no system peer</td>
- </tr>
- <tr>
- <td><tt>09</tt></td>
- <td><tt>leap_armed</tt></td>
- <td>leap second armed from file or Autokey</td>
- </tr>
- <tr>
- <td><tt>0a</tt></td>
- <td><tt>leap_disarmed</tt></td>
- <td>leap second disarmed</td>
- </tr>
- <tr>
- <td><tt>0b</tt></td>
- <td><tt>leap_event</tt></td>
- <td>leap event</td>
- </tr>
- <tr>
- <td><tt>0c</tt></td>
- <td><tt>clock_step</tt></td>
- <td>clock stepped</td>
- </tr>
- <tr>
- <td><tt>0d</tt></td>
- <td><tt>kern</tt></td>
- <td>kernel information message</td>
- </tr>
- <tr>
- <td><tt>0e</tt></td>
- <td><tt>TAI...</tt></td>
- <td>leapsecond values update from file</td>
- </tr>
- <tr>
- <td><tt>0f</tt></td>
- <td><tt>stale leapsecond values</tt></td>
- <td>new NIST leapseconds file needed</td>
- </tr>
-</table>
-<h4 id="peer">Peer Status Word</h4>
-<p>The peer status word consists of four fields: Status (0-4), Select (5-7), Count (8-11) and Code (12-15). It is reported in the first line of the <tt>rv <i>associd</i></tt> display produced by the <tt>ntpq</tt> program.</p>
-<table width="50%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td><div align="center">Status</div></td>
- <td><div align="center">Select</div></td>
- <td><div align="center">Count</div></td>
- <td><div align="center">Code</div></td>
- </tr>
-</table>
-<p>The Status Field displays the peer status code bits in hexadecimal; each bit is an independent flag. (Note this field is 5 bits wide, and combines with the the 3-bit-wide Select Field to create the first full byte of the peer status word.) The meaning of each bit in the Status Field is listed in the following table:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>08</tt></td>
- <td><tt>bcst</tt></td>
- <td>broadcast association</td>
- </tr>
- <tr>
- <td><tt>10</tt></td>
- <td><tt>reach</tt></td>
- <td>host reachable</td>
- </tr>
- <tr>
- <td><tt>20</tt></td>
- <td><tt>authenb</tt></td>
- <td>authentication enabled</td>
- </tr>
- <tr>
- <td><tt>40</tt></td>
- <td><tt>auth</tt></td>
- <td>authentication ok</td>
- </tr>
- <tr>
- <td><tt>80</tt></td>
- <td><tt>config</tt></td>
- <td>persistent association</td>
- </tr>
-</table>
-<p>The Select Field displays the current selection status. (The T Field in the following table gives the corresponding tally codes used in the <tt>ntpq peers</tt> display.) The values are coded as follows:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>T</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>0</tt></td>
- <td><tt>sel_reject</tt></td>
- <td> </td>
- <td>discarded as not valid (TEST10-TEST13)</td>
- </tr>
- <tr>
- <td><tt>1</tt></td>
- <td><tt>sel_falsetick</tt></td>
- <td><tt>x</tt></td>
- <td>discarded by intersection algorithm</td>
- </tr>
- <tr>
- <td><tt>2</tt></td>
- <td><tt>sel_excess</tt></td>
- <td><tt>.</tt></td>
- <td>discarded by table overflow (not used)</td>
- </tr>
- <tr>
- <td><tt>3</tt></td>
- <td><tt>sel_outlyer</tt></td>
- <td><tt>-</tt></td>
- <td>discarded by the cluster algorithm</td>
- </tr>
- <tr>
- <td><tt>4</tt></td>
- <td><tt>sel_candidate</tt></td>
- <td><tt>+</tt></td>
- <td>included by the combine algorithm</td>
- </tr>
- <tr>
- <td><tt>5</tt></td>
- <td><tt>sel_backup</tt></td>
- <td><tt>#</tt></td>
- <td>backup (more than <tt>tos maxclock</tt> sources)</td>
- </tr>
- <tr>
- <td><tt>6</tt></td>
- <td><tt>sel_sys.peer</tt></td>
- <td><tt>*</tt></td>
- <td>system peer</td>
- </tr>
- <tr>
- <td><tt>7</tt></td>
- <td><tt>sel_pps.peer</tt></td>
- <td><tt>o</tt></td>
- <td>PPS peer (when the prefer peer is valid)</td>
- </tr>
-</table>
-<p>The Count Field displays the number of events since the last time the code changed. Upon reaching 15, subsequent events with the same code are ignored. </p>
-<p>The Event Field displays the most recent event message coded as follows:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>01</tt></td>
- <td><tt>mobilize</tt></td>
- <td>association mobilized</td>
- </tr>
- <tr>
- <td><tt>02</tt></td>
- <td><tt>demobilize</tt></td>
- <td>association demobilized</td>
- </tr>
- <tr>
- <td><tt>03</tt></td>
- <td><tt>unreachable</tt></td>
- <td>server unreachable</td>
- </tr>
- <tr>
- <td><tt>04</tt></td>
- <td><tt>reachable</tt></td>
- <td>server reachable</td>
- </tr>
- <tr>
- <td><tt>05</tt></td>
- <td><tt>restart</tt></td>
- <td>association restart</td>
- </tr>
- <tr>
- <td><tt>06</tt></td>
- <td><tt>no_reply</tt></td>
- <td>no server found (<tt>ntpdate</tt> mode)</td>
- </tr>
- <tr>
- <td><tt>07</tt></td>
- <td><tt>rate_exceeded</tt></td>
- <td>rate exceeded (kiss code <tt>RATE</tt>)</td>
- </tr>
- <tr>
- <td><tt>08</tt></td>
- <td><tt>access_denied</tt></td>
- <td>access denied (kiss code <tt>DENY</tt>)</td>
- </tr>
- <tr>
- <td><tt>09</tt></td>
- <td><tt>leap_armed</tt></td>
- <td>leap armed from server LI code</td>
- </tr>
- <tr>
- <td><tt>0a</tt></td>
- <td><tt>sys_peer</tt></td>
- <td>become system peer</td>
- </tr>
- <tr>
- <td><tt>0b</tt></td>
- <td><tt>clock_event</tt></td>
- <td>see clock status word</td>
- </tr>
- <tr>
- <td><tt>0c</tt></td>
- <td><tt>bad_auth</tt></td>
- <td>authentication failure</td>
- </tr>
- <tr>
- <td><tt>0d</tt></td>
- <td><tt>popcorn</tt></td>
- <td>popcorn spike suppressor</td>
- </tr>
- <tr>
- <td><tt>0e</tt></td>
- <td><tt>interleave_mode</tt></td>
- <td>entering interleave mode</td>
- </tr>
- <tr>
- <td><tt>0f</tt></td>
- <td><tt>interleave_error</tt></td>
- <td>interleave error (recovered)</td>
- </tr>
-</table>
-<h4 id="clock">Clock Status Word</h4>
-<p>The clock status word consists of four fields: Unused (0-7), Count (8-11) and Code (12-15). It is reported in the first line of the <tt>clockvar <i>associd</i></tt> display produced by the <tt>ntpq</tt> program.</p>
-<table width="50%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td><div align="center">Unused</div></td>
- <td><div align="center">Count</div></td>
- <td><div align="center">Code</div></td>
- </tr>
-</table>
-<p>The Count Field displays the number of events since the last <tt>lockvar</tt> command, while the Event Field displays the most recent event message coded as follows:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>00</tt></td>
- <td><tt>clk_unspe</tt></td>
- <td>nominal</td>
- </tr>
- <tr>
- <td><tt>01</tt></td>
- <td><tt>clk_noreply</tt></td>
- <td>no reply to poll</td>
- </tr>
- <tr>
- <td><tt>02</tt></td>
- <td><tt>clk_badformat</tt></td>
- <td>bad timecode format</td>
- </tr>
- <tr>
- <td><tt>03</tt></td>
- <td><tt>clk_fault</tt></td>
- <td>hardware or software fault</td>
- </tr>
- <tr>
- <td><tt>04</tt></td>
- <td><tt>clk_bad_signal</tt></td>
- <td>signal loss</td>
- </tr>
- <tr>
- <td><tt>05</tt></td>
- <td><tt>clk_bad_date</tt></td>
- <td>bad date format</td>
- </tr>
- <tr>
- <td><tt>06</tt></td>
- <td><tt>clk_bad_time</tt></td>
- <td>bad time format</td>
- </tr>
-</table>
-<p>When the clock driver sets the code to a new value, a <tt>clock_alarm</tt> (11) peer event is reported.</p>
-<h4 id="flash">Flash Status Word</h4>
-<p>The flash status word is displayed by the <tt>ntpq</tt> program <tt>rv</tt> command. It consists of a number of bits coded in hexadecimal as follows:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td width="10%">Code</td>
- <td width="15%">Tag</td>
- <td width="20%">Message</td>
- <td width="55%">Description</td>
- </tr>
- <tr>
- <td><tt>0001</tt></td>
- <td>TEST1</td>
- <td><tt>pkt_dup</tt></td>
- <td>duplicate packet</td>
- </tr>
- <tr>
- <td><tt>0002</tt></td>
- <td>TEST2</td>
- <td><tt>pkt_bogus</tt></td>
- <td>bogus packet</td>
- </tr>
- <tr>
- <td><tt>0004</tt></td>
- <td>TEST3</td>
- <td><tt>pkt_unsync</tt></td>
- <td>server not synchronized</td>
- </tr>
- <tr>
- <td><tt>0008</tt></td>
- <td>TEST4</td>
- <td><tt>pkt_denied</tt></td>
- <td>access denied</td>
- </tr>
- <tr>
- <td><tt>0010</tt></td>
- <td>TEST5</td>
- <td><tt>pkt_auth</tt></td>
- <td> authentication failure</td>
- </tr>
- <tr>
- <td><tt>0020</tt></td>
- <td>TEST6</td>
- <td><tt>pkt_stratum</tt></td>
- <td>invalid leap or stratum</td>
- </tr>
- <tr>
- <td><tt>0040</tt></td>
- <td>TEST7</td>
- <td><tt>pkt_header</tt></td>
- <td> header distance exceeded</td>
- </tr>
- <tr>
- <td><tt>0080</tt></td>
- <td>TEST8</td>
- <td><tt>pkt_autokey</tt></td>
- <td>Autokey sequence error</td>
- </tr>
- <tr>
- <td><tt>0100</tt></td>
- <td>TEST9</td>
- <td><tt>pkt_crypto</tt></td>
- <td>Autokey protocol error</td>
- </tr>
- <tr>
- <td><tt>0200</tt></td>
- <td>TEST10</td>
- <td><tt>peer_stratum</tt></td>
- <td> invalid header or stratum</td>
- </tr>
- <tr>
- <td><tt>0400</tt></td>
- <td>TEST11</td>
- <td><tt>peer_dist</tt></td>
- <td> distance threshold exceeded</td>
- </tr>
- <tr>
- <td><tt>0800</tt></td>
- <td>TEST12</td>
- <td><tt>peer_loop</tt></td>
- <td> synchronization loop</td>
- </tr>
- <tr>
- <td><tt>1000</tt></td>
- <td>TEST13</td>
- <td><tt>peer_unreach</tt></td>
- <td> unreachable or nonselect</td>
- </tr>
-</table>
-<h4 id="kiss">Kiss Codes</h4>
-<p>Kiss codes are used in kiss-o'-death (koD) packets, billboard displays and log messages. They consist of a string of four zero-padded ASCII charactes. In practice they are informal and tend to change with time and implementation. Some of these codes can appear in the reference identifier field in <tt>ntpq</tt> billboards. Following is the current list:</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>ACST</tt></td>
- <td>manycast server</td>
- </tr>
- <tr>
- <td><tt>AUTH</tt></td>
- <td>authentication error</td>
- </tr>
- <tr>
- <td><tt>AUTO</tt></td>
- <td>Autokey sequence error</td>
- </tr>
- <tr>
- <td><tt>BCST</tt></td>
- <td>broadcast server</td>
- </tr>
- <tr>
- <td><tt>CRYPT</tt></td>
- <td>Autokey protocol error</td>
- </tr>
- <tr>
- <td><tt>DENY</tt></td>
- <td>access denied by server</td>
- </tr>
- <tr>
- <td><tt>INIT</tt></td>
- <td>association initialized</td>
- </tr>
- <tr>
- <td><tt>MCST</tt></td>
- <td>multicast server</td>
- </tr>
- <tr>
- <td><tt>RATE</tt></td>
- <td>rate exceeded</td>
- </tr>
- <tr>
- <td><tt>TIME</tt></td>
- <td>association timeout</td>
- </tr>
- <tr>
- <td><tt>STEP</tt></td>
- <td>step time change</td>
- </tr>
-</table>
-<h4 id="crypto">Crypto Messages</h4>
-<p>These messages are sent to the <tt>cryptostats</tt> file when an error is detected in the Autokey protocol.</p>
-<table width="100%" border="1" cellspacing="2" cellpadding="2">
- <tr>
- <td>Code</td>
- <td>Message</td>
- <td>Description</td>
- </tr>
- <tr>
- <td><tt>01</tt></td>
- <td><tt>bad_format</tt></td>
- <td>bad extension field format or length</td>
- </tr>
- <tr>
- <td><tt>02</tt></td>
- <td><tt>bad_timestamp</tt></td>
- <td>bad timestamp</td>
- </tr>
- <tr>
- <td><tt>03</tt></td>
- <td><tt>bad_filestamp</tt></td>
- <td>bad filestamp</td>
- </tr>
- <tr>
- <td><tt>04</tt></td>
- <td><tt>bad_public_key</tt></td>
- <td>bad or missing public key</td>
- </tr>
- <tr>
- <td><tt>05</tt></td>
- <td><tt>bad_digest</tt></td>
- <td>unsupported digest type</td>
- </tr>
- <tr>
- <td><tt>06</tt></td>
- <td><tt>bad_identity</tt></td>
- <td>unsupported identity type</td>
- </tr>
- <tr>
- <td><tt>07</tt></td>
- <td><tt>bad_siglength</tt></td>
- <td>bad signature length</td>
- </tr>
- <tr>
- <td><tt>08</tt></td>
- <td><tt>bad signature</tt></td>
- <td>extension field signature not verified</td>
- </tr>
- <tr>
- <td><tt>09</tt></td>
- <td><tt>cert_not_verified</tt></td>
- <td>certificate signature not verified</td>
- </tr>
- <tr>
- <td><tt>0a</tt></td>
- <td><tt>cert_expired</tt></td>
- <td>host certificate expired</td>
- </tr>
- <tr>
- <td><tt>0b</tt></td>
- <td><tt>bad_cookie</tt></td>
- <td>bad or missing cookie</td>
- </tr>
- <tr>
- <td><tt>0c</tt></td>
- <td><tt>bad_leapseconds</tt></td>
- <td>bad or missing leapseconds values</td>
- </tr>
- <tr>
- <td><tt>0d</tt></td>
- <td><tt>cert_missing</tt></td>
- <td>bad or missing certificate</td>
- </tr>
- <tr>
- <td><tt>0e</tt></td>
- <td><tt>bad_group_key</tt></td>
- <td>bad or missing group key</td>
- </tr>
- <tr>
- <td><tt>0f</tt></td>
- <td><tt>proto_error</tt></td>
- <td>protocol error</td>
- </tr>
-</table>
+<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 or upon arrival of an automatic server discovery packet. They are are demobilized by timeout or when preempted by a "better" server, as described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. Ephemeral associations are mobilized upon arrival of broadcast or multicast server 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 on 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 <a href="#burst">burst options</a> and <a href="orphan.html">orphan mode</a> 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">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>
+<p>Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The <tt>minpoll</tt> and <tt>maxpoll</tt> options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.</p>
+<h4 id="symact">Symmetric Active/Passive Mode</h4>
+<p>Symmetric active/passive mode is intended for configurations were a clique
+ of low-stratum peers operate as mutual backups for each other. Each peer operates
+ with one or more primary reference sources, such as a reference clock, or a set
+ of secondary (stratum, 2) servers known to be reliable and authentic. Should
+ one of the peers lose all reference sources or simply cease operation, the
+ other peers will automatically reconfigure so that time and related values
+ can flow from the surviving peers to all hosts in the subnet. In some contexts
+ this would be described as a "push-pull" operation, in that the
+ peer either pulls or pushes the time and related values depending on the particular
+ configuration.</p>
+<p>A symmetric active peer sends a symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.</p>
+<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or IPv4 or IPv6 address. The <tt>burst</tt> and <tt>iburst</tt> options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.</p>
+<p>As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the <tt>minpoll</tt> and <tt>maxpoll</tt> options.</p>
+<h4 id="broad">Broadcast/Multicast Modes</h4>
+<p>NTP broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode can be used with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast packets do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the <a href="discover.html">Automatic NTP Configuration Options</a> page.</p>
+<p>A server is configured to send broadcast or multicast messages using the <tt>broadcast</tt> command and specifying the subnet address for broadcast or the multicast group address for multicast. A broadcast client is enabled using the <tt>broadcastclient</tt> command, while a multicast client is enabled using the <tt>multicstclient</tt> command and specifying the multicast group address. Multiple commands of either type can be used. However, the association is not mobilized until the first broadcast or multicast message is actually received.</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 Management</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. 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 specification 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>With fast, lightly loaded LANs and modern processors, the nominal Allan intercept is about 500 s. In these cases the expected errors can be further reduced using a poll exponent of 4 (16 s). In the case of the pulse-per-second (PPS) driver, this is the recommended value.</li>
+ <li>With symmetric modes the most stable behavior results when both peers are configured in symmetric active mode with matching poll intervals of 6 (64 s).</li>
+ <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 hr) and 17 (36 hr), respectively.</li>
+</ul>
+<h4 id="burst">Burst Options</h4>
+<p>Occasionally it is necessary to send packets temporarily 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 program sends a burst of several packets at 2-s intervals. In either case the poll program 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. Additional details are on the <a href="poll.html">Poll Program</a> page.</p>
+<p>There are two burst options where a single poll event triggers a burst. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands, but not with reference clock drivers nor symmetric mode peers. 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, as in PPP or ISDN services. In general, this option is recommended for <tt>server</tt> and <tt>pool</tt> commands. A burst is sent only when the server is unreachable; in particular, when first starting up. Ordinarily, the clock is set within a few seconds after the first received packet. See the <a href="clock.html">Clock State Machine</a> page for further details about the startup behavior.</p>
+<p>The <tt>burst</tt> option is useful in cases of severe network
+ jitter or when the network attachment requires an initial calling or training
+ sequence. This option is recommended when the minimum poll exponent is larger than 10 (1024 s). A burst is sent only when the server is reachable. The number of packets in the burst is determined by the poll interval
+ so that the average interval between packets (headway) is no less than the minimum poll interval for the association.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
projects / thirdparty / ntp.git / commitdiff
