[ntp:bk-ntp-dev-send] ***SPAM*** BitKeeper diffs

Harlan Stenn stenn at whimsy.udel.edu
Sat Oct 20 05:34:40 UTC 2007


#### ChangeSet ####
2007-10-20 01:32:29-04:00, stenn at whimsy.udel.edu 
  Documentation updates from Dave Mills

==== ChangeLog ====
2007-10-20 01:30:05-04:00, stenn at whimsy.udel.edu +1 -0
  Documentation updates from Dave Mills

--- 1.129/ChangeLog	2007-10-19 02:57:04 -04:00
+++ 1.130/ChangeLog	2007-10-20 01:30:05 -04:00
@@ -1,3 +1,4 @@
+* Documentation updates from Dave Mills.
 * -ledit cleanup for ntpdc and ntpq.
 * Association and other cleanup from Dave Mills.
 * NTP_UNREACH changes from Dave Mills.

==== html/assoc.html ====
2007-10-20 01:30:16-04:00, stenn at whimsy.udel.edu +39 -30
  Documentation updates from Dave Mills

--- 1.22/html/assoc.html	2007-08-17 01:35:18 -04:00
+++ 1.23/html/assoc.html	2007-10-20 01:30:16 -04:00
@@ -13,7 +13,7 @@
 		<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: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">02:59</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="266">Tuesday, August 14, 2007</csobj></p>
+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:43</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="307">Friday, October 19, 2007</csobj></p>
 		<br clear="left">
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
@@ -22,45 +22,54 @@
 			<li class="inline"><a href="#modes">Association Modes</a>
 			<li class="inline"><a href="#client">Client/Server Mode</a>
 			<li class="inline"><a href="#symact">Symmetric Active/Passive Mode</a>
-			<li class="inline"><a href="#broad">Broadcast/Multicast Modes</a>
-			<li class="inline"><a href="#umlt">Multicasting</a>
+			<li class="inline"><a href="#broad">Broadcast Mode</a>
+			<li class="inline"><a href="#mult">Multicast Mode</a>
+			<li class="inline"><a href="#many">Manycast Mode</a>
 			<li class="inline"><a href="#orphan">Orphan Mode</a>
 			<li class="inline"><a href="#burst">Burst Modes</a>
 		</ul>
 		<hr>
 		<h4 id="modes">Association Modes</h4>
-		<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the various modes of operation; additional information is available on the <a href="confopt.html">Configuration Options</a> and <a href="authopt.html">Authentication Options</a> pages and in the papers, reports, memoranda and briefings at <a href="http://www.ntp.org">www.ntp.org</a>.</p>
-		<p>There are three types of associations: persistent associations, which result from configuration file commands, and preemptable and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unavailable. Preemptable and ephemeral associations are mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message. Preemptable associations differ from ephemeral associations in that the former can be demobilized by the mitigation algorithms when a &quot;better&quot; server comes along, while the latter can be demobilized only by protocol error or timeout.</p>
-		<p>Ordinarily, successful mobilization of preemptable or ephemeral associations requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric key or public key cryptography, as described in the <a href="authopt.html">Authentication Options</a> page. </p>
-		<p>There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and cryptographic values and means of configuration.</p>
-		<p>The original NTPv3 authentication scheme is applicable in all mode, ass well as the new NTPv4 Autokey authentication scheme. In addition, the orphan and burst modes described below can be used in appropriate cases. Following is a summary of the operations in each mode.</p>
+		<p>This page describes the various modes of operation provided in NTPv4.  Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the automatic server discovery schemes are described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. While this page outlines the main issues about authenitcaion and server discovery, the details are beyond the scope of the discussion on this page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.</p>
+		<p>There are three types of associations in NTP: persistent, preemptable and ephemeral. 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>prempt</tt> flag and are demobilized by timeout or error or when displaced by a &quot;better&quot; server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.</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>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, manycast and pool described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. In addition, the orphan and burst modes described on this page can be used in appropriate cases. Following is a summary of the operations in each mode.</p>
 		<h4 id="client">Client/Server Mode</h4>
-		<p>Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a &quot;pull&quot; operation, in that the client pulls the time and cryptographic values from the server. A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration.</p>
-		<p>The IBURST&nbsp;mode described later on this page is recommended for use by  clients, as this speeds up initial synchronization from several minutes to several seconds. The BURST&nbsp;mode described later on this page us useful to improve jitter on very noisy dial-up or ISDN&nbsp;network links. This mode should always be used when the maximum expected poll interval is above 1024 s.</p>
+		<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 client 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 &quot;pull&quot; operation, in that the client pulls the time and related values from the server.</p>
+		<p>A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration. The <tt>iburst</tt>&nbsp;mode described later on this page is recommended for use by clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt>&nbsp;mode described later on this page is useful to improve jitter on very noisy dial-up or ISDN&nbsp;network links. This mode should always be used when the maximum expected poll interval is above 1024 s.</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 radio clock, or a subset of secondary servers known to be reliable and authenticated. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and proventication values can flow from the surviving peers to all the others in the clique. In some contexts this would be described as a &quot;push-pull&quot; operation, in that the peer either pulls or pushes the time and proventic values depending on the particular configuration.</p>
-		<p>Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer IPv4 or IPv6 DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated.</p>
-		<p>The BURST&nbsp;and IBURST&nbsp;modes should not be used in symetric- modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages. In those topologies where symmetric modes are indicates, it is generally best to set the maximum poll interval to the valu of the minimum poll interval. </p>
-		<h4 id="broad">Broadcast/Multicast Modes</h4>
-		<p>IPv4 broadcast mode in both NTPv3 and NTPv4 is limited to directly connected subnets such as Ethernets which support broadcast technology. Ordinarily, this technology does not operate beyond the first hop router or gateway. In IPv6 and where service is intended beyond the local subnet, IP multicasting can be used where supported by the operating system and the routers support the Internet Group Management Protocol (IGMP). Most current kernels and available routers do support IP multicast technology, although service providers are sometimes reluctant to deploy it.</p>
-		<p>IPv4 broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population on the same subnet. A broadcast server is configured using the <tt>broadcast</tt> command and a IPv4 local subnet broadcast address. A broadcast client is configured using the <tt>broadcastclient</tt> command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated.</p>
-		<p>The server generates broadcast messages continuously at intervals specified by the <tt>minpoll</tt> keyword and with a time-to-live span specified by the <tt>ttl</tt> keyword. A broadcast client responds to the first message received by waiting a short interval to avoid implosion at the server. Then, the client polls the server in IBURST mode in order to quickly set the host clock and validate the source. This normally results in a volley of eight client/server cycles at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages. If for some reason the broadcast server does not respond to client messages, the client 
 will time out the volley and continue in listen-only mode with a default propagation delay.</p>
-		<h4 id="umlt">Multicasting</h4>
-		<p>Multicasting can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a IPv4 or IPv6 multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa. The IANA has assigned multicast group address IPv4 224.0.1.1 and IPv6 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 with a multicast group address instead of a broadcast address. A multicast client is configured using the <tt>multicastclient</tt> command with a multicast group address. However, there is a subtle difference between IPv4 broadcasting and multicasting. IPv4 broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate <tt>broadcast</tt> command applies to each one separately. This provides a way to limit exposure in a firewall, for example. For IPv6 the same distinction can be made using link-local prefix FF02 for each interface and site-local FF05 for all interfacesl.</p>
-		<p>IP multicasting is a different paradigm. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which may require these messages emit from one or all interfaces, but carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple <tt>broadcast</tt> or <tt>multicastclient</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.</p>
-		<h4 id="many">Manycasting</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 radio clock, or a subset of secondary 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 the others in the clique. In some contexts this would be described as a &quot;push-pull&quot; operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.</p>
+		<p>In symmetric mode a persistent peer sends a symmetric active (mode 1) message to a specified peer. If a matching persistent association is available, the peer returns a symetric active message as well. If no matchine association is avaialable, the peer mobilizes a ephemeral associaition and returnes a symmetric passive (mode) message.  Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric 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&nbsp;name or IPv4 or IPv6 address. The <tt>burst</tt>&nbsp;and <tt>iburst</tt>&nbsp;modes 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. In symmetric cliques it is generally best to set the maximum poll interval of each member to the same value.</p>
+		<h4 id="broad">Broadcast Mode</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 is supported with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast mode does not operate beyond a level-3 router. Where service is intended beyond a level-3 router, the multicast mode described in the next section can be used.</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.</p>
+		<p>A broadcast client is configured using the <tt>broadcastclient</tt> command. While a broadcast message can be received on any interface, the <tt>restrict</tt> command described on the Access Control Options can be used to filter out unwanted addresses. Since an intruder can impersonate a broadcast or multicast server and inject false time values, broadcast mode should always be cryptographically authenticated.</p>
+		<p>In operation 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> commands, respectively. Not all kernels support the  <tt>ttl</tt> command.</p>
+		<p>A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. The client then polls the server in client/server and iburst modes in order to quickly authenticate the server, set the host clock and calibrate the broadcast message propagation delay. This normally results in a volley of eight 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 client messages, the client will time out and continue in listen-only mode with a default propagation delay.</p>
+		<h4 id="mult">Multicast Mode</h4>
+		<p>NTP&nbsp;multicast mode can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa.</p>
+		<p>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 interfacesl.</p>
+		<p>By design, multicast messages travel from the sender via a shortest-path or shared spanning tree to the receivers, which may require these messages emit from one or more local interfaces. It is possible to configure multiple multicast groups using multiple <tt>broadcast</tt> or <tt>multicastclient</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.</p>
+		<h4 id="many">Manycast Mode</h4>
 		<p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast 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 manycast client mobilizes client associations with some number of the &quot;best&quot; of the nearby anycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
+		<p>The <tt>manycastclient</tt> command specifies that the host is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified <i><tt>address</tt></i> and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the <tt>server </tt>command. The remaining servers are discarded as if never heard.</p>
 		<h4 id="orphan">Orphan Mode</h4>
-		Orphan mode is designed for use in private networks with no connectivity to public time servers and without access to a radio clock or modem time service. It is also useful as backup when such support is available but for one reason or another it fails or becomes seriously degraded. Under conditions when all synchronization sources are lost, the network automatically reorganizes so that all synchronization is ultimately dependent on a single orphan host which need not be explicitly selected in advance. In this design the network time might not be synchronized to UTC, but all network hosts will follow the orphan host time.
-		<p>Orphan mode is similar to the local clock driver; but, unlike the local clock driver, there can be more than one orphan host that potentially can assume that role with selection determined by an election algorithm command. Typically, one or more hosts near or at the root of the synchronization tree are assigned an orphan stratum using the <tt>tos orphan</tt> command. During initialization orphan hosts are assigned a random metric conveyed between hosts at orphan stratum level in the root delay field of the NTP packet header.</p>
-		<p>If the orphan hosts have access to servers at lower stratum levels, they operate in the usual way and with strict adherence to the NTP&nbsp;protocol rules. If not and they communicate with each other, the host with the lowest root delay becomes the root server and the remaining hosts in the network use the NTP protocol to determine the network topology. When the original connectivity is restored, the topology is restored.</p>
-		<p>Two scenarios will clarify how orphan mode can be used to provide smart backup. The first, scenario includes two secondary servers normally synchronized to different public Internet primary servers and connected to the same Ethernet LAN. Each are configured with <tt>broadcast</tt> and <tt>broadcastclient</tt> commands and in addition the <tt>tos orphan</tt> command. If one of the primary servers becomes unavailable, the associated LAN&nbsp;server will resynchronize to the other LAN&nbsp;server as a consequence of normal NTP&nbsp;operations. If both primary servers become unavailable, both LAN&nbsp;servers will eventually become orphan hosts with the root server selected as the one with the lowest root distance. Other non-orphan hosts will synchronize to the root server using normal NTP&nbsp;operations.</p>
-		<p>The second scenario includes three secondary servers A, B and C, each normally synchronized to public primary NTP&nbsp;servers or to radio clocks and to the same Ethernet LAN. These servers operate in symmetric modes in a circular topology; active A server is B, active B server is C and active C server is A. Each server is configured with the <tt>tos orphan</tt> command. While this topology provides a massive degree of redundancy and survivability, the interesting case is when all primary servers are unavailable. The eventual result is the same as the previous scenario; all three servers or orphans and the one with the lowest root delay becomes the root server.</p>
+		<p>Sometimes an NTP&nbsp;subnet becomes isolated from all UTC&nbsp;sources such as a local reference clock or Internet time server. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC&nbsp;timescale. Previously, this function was provided by the local clock driver to  simulate a UTC&nbsp;source. A server with this driver could be used to syunchronize other hosts in the subnet directly or indirectly.</p>
+		<p>There are many disadvantages using the local clock driver, primarily that the subnet is vulnerable to single-point failures and multiple server  redundancy is not possible. Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC&nbsp;source with multiple servers and provides seamless switching as servers fail and recover.</p>
+		<p>A common configuration for private networks that might become isolated from UTC&nbsp;sources is to operate one or more core servers at the same lowest stratum to synchronize other hosts in the&nbsp;subnet. Good practice is to configure each core server as backup for the others using symmetric or broadcast modes. As long as at least one core server can reach a UTC&nbsp;source, the entire subnet can synchronize to it. However, if no UTC source is available, one of the core servers can provide a simulated UTC source for all other hosts in the subnet. However, only one core server can simulate the UTC&nbsp;source and all direct dependents must select the same one, called the orphan parent.</p>
+		<p>A host is enabled for orphan mode using the <tt>tos orphan <i>stratum</i></tt> command, where <tt><i>stratum</i></tt> is some stratum less than 16 and greater than any anticipated stratum that might occur with configured Internet time servers. However, sufficient headroom should remain so every subnet host dependent on the orphan parent has stratum less than 16. These are the same consideration that guides the local clock driver stratum selection.</p>
+		<p>A server with no sources and operating at the orphan stratum shows offset zero, root dispersion zero and reference ID&nbsp;127.0.0.1, (Unix loopback address. While primary (stratum 1)&nbsp;servers ordinarily show root delay zero, orphan servers show a value randomized when the association is mobilized. The orphan children; that is, those hosts operating at the orphan stratum plus one, chose the orphan parent as the orphan server with the smallest value.</p>
+		<p>For orphan mode to work well, each core server with available sources should operate at the same stratum, although the scheme works when they are not. Each potential orphan parent and each orphan child should include the same tos command in the configuration file. Each orphan child should include in the configuration file all root servers.</p>
+		<p>For example, consider a configuration where several campus secondary (stratum 2) servers are configured to use public Internet primary servers and with each other using symmetric or broadcast modes. For symmetric mode each core server is configured in symmetic-active mode with each other core server. For broadcast mode each core server is configured in both broadcast server and broadcast client modes. Orphan children operate in any mode with all core servers. Only the core servers and potential orphan children need to be enabled for orphan mode.</p>
+		<p>In normal operation subnet hosts operate below stratum 5, so the subnet is automatically configured as described in the NTP&nbsp;specification. If all UTC&nbsp;sources are lost, all core servers become orphans and the orphan children will select the same core server to become the orphan parent.</p>
 		<h4 id="burst">Burst Modes</h4>
-		<p>There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal poll interval. The <tt>burst</tt> mode sends a burst when the server is reachable, while the <tt>iburst</tt> mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. The <tt>calldelay</tt> command can be used to increase the interval between the first and second packets in the burst in order to allow a modem to complete a call, for instance. 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 sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.</p>
-		<p>The <tt>iburst</tt> keyword is used where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first message.</p>
-		<p>The <tt>burst</tt> keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. In general, It should only be used where the poll interval is expected to settle to values at or above 1024 s.</p>
+		<p>There are two burst modes 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 and not with reference clock drivers. The <tt>burst</tt> keyword sends a burst when the server is reachable, while the <tt>iburst</tt> keyword sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. The <tt>calldelay</tt> command can be used to increase the interval between the first and second packets of 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 select 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> mode 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. Outlyers 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>
+		<p>The <tt>burst</tt> mode can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training sequence. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. In general, It should only be used where the minimum poll interval is 10 (1024 s) or greater.</p>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>

==== html/confopt.html ====
2007-10-20 01:30:18-04:00, stenn at whimsy.udel.edu +35 -35
  Documentation updates from Dave Mills

--- 1.37/html/confopt.html	2007-07-23 01:31:10 -04:00
+++ 1.38/html/confopt.html	2007-10-20 01:30:18 -04:00
@@ -13,7 +13,7 @@
 		<h3>Server Options</h3>
 		<img src="pic/boom3a.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
 		<p>The chicken is getting configuration advice.</p>
-		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:57</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 10, 2005</csobj></p>
+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:19</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 15, 2007</csobj></p>
 		<br clear="left">
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
@@ -25,55 +25,55 @@
 			<li class="inline"><a href="#bug">Bugs</a>
 		</ul>
 		<hr>
-		<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>
+		<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>
+		<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 &quot;:&quot; 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">Configuration Commands</h4>
-		<p>The various modes are determined by the command keyword and the required IP address. Addresses are classed by type as (s) a remote server or peer (IPv4 class A, B and C), (b) the broadcast address of a local interface, (m) a multicast address (IPv4 class D), or (r) a reference clock address (127.127.x.x). The options that can be used with these commands are listed below.</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 support of the IPv4 address family. IPv6 addresses can be identified by the presence of colons &quot;:&quot; 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>
-		<p>There are three types of associations: persistent, preemptable and ephemeral. 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>prempt</tt> flag and are demobilized by timeout or error. Ephemeral associations are mobilized upon arrival of designated messages and demobilized by timeout or error.</p>
 		<dl>
 			<dt><tt>server <i>address</i> [options ...]</tt><br>
 				<tt>peer <i>address</i> [</tt><tt>options ...]<br>
 					broadcast <i>address</i> [options ...]</tt><br>
-				<tt>manycastclient <i>address</i> [options ...]</tt>
-			<dd>These four commands specify the time server name or address to be used and the mode in which to operate. The <i>address</i> can be either a DNS name or a IP address in dotted-quad notation. Additional information on association behavior can be found in the <a href="assoc.html">Association Management</a> page.
-				<dl>
+				<tt>manycastclient <i>address</i> [options ...]<br>
+				</tt><tt>pool <i>address</i> [options ...]</tt>
+			<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>
-					<dd>For type s and r addresses (only), this command normally 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 association is mobilized instead. In client mode the client clock can synchronize to the remote server or local reference clock, but the remote server can never be synchronized to the client clock. This command should NOT be used for type <tt>b</tt> or <tt>m</tt> addresses. <dt><tt>peer</tt>
-					<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active mode association with the specified remote peer. In this mode the local clock can be synchronized to the remote peer or the remote peer can be synchronized to the local clock. This is useful in a network of servers where, depending on various failure scenarios, either the local or remote peer may be the better source of time. This command should NOT be used for type <tt>b</tt>, <tt>m</tt> or <tt>r</tt> addresses.
+					<dd>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.<dt><tt>peer</tt>
+					<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active mode association with the specified remote peer.
 					<dt><tt>broadcast</tt>
-					<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this command mobilizes a persistent broadcast mode association. Multiple commands can be used to specify multiple local broadcast interfaces (subnets) and/or multiple multicast groups. Note that local broadcast messages go only to the interface associated with the subnet specified, but multicast messages go to all interfaces.
-					<dd>In broadcast mode the local server sends periodic broadcast messages to a client population at the <i><tt>address</tt></i> specified, which is usually the broadcast address on (one of) the local network(s) or a multicast address assigned to NTP. The IANA has assigned the multicast group address IPv4 224.0.1.1 and IPv6 ff05::101 (site local) exclusively to NTP, but other nonconflicting addresses can be used to contain the messages within administrative boundaries. Ordinarily, this specification applies only to the local server operating as a sender; for operation as a broadcast client, see the <tt>broadcastclient</tt> or <tt>multicastclient</tt> commands below.
-					<dt><tt>manycastclient</tt>
-					<dd>For type <tt>m</tt> addresses (only), this command mobilizes a preemptable manycast client mode association for the multicast group address specified. In this mode a specific address must be supplied which matches the address used on the <tt>manycastserver</tt> command for the designated manycast servers. The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to avoid spraying large areas of the Internet with these messages and causing a possibly massive implosion of replies at the sender.
-					<dd>The <tt>manycastclient</tt> command specifies that the host is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified <i><tt>address</tt></i> and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the <tt>server </tt>command. The remaining servers are discarded as if never heard.
-				</dl>
+					<dd>For type b and m ddresses (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.<dt><tt>manycastclient</tt>
+					<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.<dt><tt>pool</tt>
+					<dd>For type s messages (only) this command mobilizes a client mode association for servers implementing the pool automatic server discovery scheme described on the <a href="assoc.html">Association Management</a> page. The address is a DNS name in the form <tt><i>area</i>.pool.ntp.org</tt>, where <tt><i>area</i></tt> is a qualifier designating the server geographic area such as <tt>us</tt> or <tt>europe</tt>.</dl>
 		</dl>
 		<h4 id="opt">Command Options</h4>
 		<dl>
 			<dt><tt>autokey</tt>
-			<dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the autokey scheme described in the <a href="authopt.html">Authentication Options</a> page. This option is valid with all commands.<dt><tt>burst</tt>
-			<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 with only the <tt>server</tt> command and is a recommended option with this command when the <tt>maxpoll</tt> option is 11 or greater. <dt><tt>iburst</tt>
-			<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 with only the <tt>server</tt> command and is a recommended option with this command.<dt><tt>key</tt> <i><tt>key</tt></i>
-			<dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified <i><tt>key</tt></i> identifier with values from 1 to 65534, inclusive. The default is to include no encryption field. This option is valid with all commands.<dt><tt>minpoll <i>minpoll</i></tt><br>
-				<tt>maxpoll <i>maxpoll</i></tt>
-			<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 (1,024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit of 17 (36.4 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 4 (16 s). These option are valid only with the <tt>server</tt> and <tt>peer</tt> commands.<dt><tt>noselect</tt>
-			<dd>Marks the server as unused, except for display purposes. The server is discarded by the selection algorithm. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.<dt><tt>preempt</tt>
-			<dd>Specifies the association as preemptable rather than the default persistent. This option is valied only with the <tt>server</tt> command.<dt><tt>prefer</tt>
-			<dd>Marks the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the <a href="prefer.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.<dt><tt>true</tt>
-			<dd>Force 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.<dt><tt>ttl <i>ttl</i></tt>
-			<dd>This option is used only with broadcast server and manycast client modes. It specifies the time-to-live <i><tt>ttl</tt></i> to use on broadcast server and multicast server and the maximum <i><tt>ttl</tt></i> for the expanding ring search with manycast client packets. Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator.
-			<dt><tt>version <i>version</i></tt>
-			<dd>Specifies the version number to be used for outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default. This option is valid only with the <tt>server,</tt> <tt>peer</tt> and <tt>broadcast</tt> commands.
-			<dt><tt>dynamic</tt>
-			<dd>Allows a server/peer to be configured even if it is not reachable at configuration time. It is assumed that at some point in the future the network environment changes so that this server/peer can be reached. This option is useful to configure servers/peers on mobile systems with intermittent network access (e.g. wlan clients).
-		</dl>
+			<dd>Send and receive packets authenticated by the Aautokey scheme described in the <a href="authopt.html">Authentication Options</a> page. This option is valid only with <tt>server</tt> and <tt>peer</tt> commands and type s addresses. It is incompatible with the <tt>key</tt> option.<dt><tt>burst</tt>
+			<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 only 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).
+			<dt><tt>iburst</tt>
+			<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.<dt><tt>key</tt> <i><tt>key</tt></i>
+			<dd>Send and receive packets authenticated by the symmetric key scheme described in the <a href="authopt.html">Authentication Options</a> page. This option is valid only with <tt>server</tt> and <tt>peer</tt> commands and type s addresses. The <i><tt>key</tt></i> specifies the key identifier with values from 1 to 65534, inclusive. This option is incompatible with the <tt>autokey</tt> option.
+			
+			<dt><tt>minpoll <i>minpoll<br>
+					</i></tt><tt>maxpoll <i>maxpoll</i></tt>
+			<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 4 (16 s). These option are valid only with the <tt>server</tt> and <tt>peer</tt> commands and type s addresses.
+			<dt><tt>mode <i>option</i></tt>
+			<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 the <tt>server</tt> command and type r addresses.<dt><tt>noselect</tt>
+			<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.<dt><tt>preempt</tt>
+			<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.<dt><tt>prefer</tt>
+			<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.
+			<dt><tt>true</tt>
+			<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.
+			<dt><tt>ttl <i>ttl</i></tt>
+			<dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> commmand 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.<dt><tt>version <i>version</i></tt>
+			<dd>Specifies the version number to be used for outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.<dt><tt>dynamic</tt>
+			<dd>Allows a server/peer to be configured even if it is not reachable at configuration time. It is assumed that at some point in the future the network environment changes so that this server/peer can be reached. This option is useful to configure servers/peers on mobile systems with intermittent network access (e.g. wlan clients). Note: the current implemenation does not support this option.</dl>
 		<h4 id="aux">Auxilliary Commands</h4>
 		<dl>
 			<dt><tt>broadcastclient [novolley]</tt>
-			<dd>This command enables reception of broadcast server messages to any local interface (type <tt>b</tt>) address. Ordinarily, upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, after which it continues in listen-only mode. If the <tt>novolley</tt> keyword is present, the exchange is not used and the value specified in the <tt>broadcastdelay</tt> command is used or, if the <tt>broadcastdelay</tt> command is not used, the default 4.0 ms. 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.<dt><tt>manycastserver <i>address</i> [...]</tt>
-			<dd>This command enables reception of manycast client messages to the multicast group address(es) (type <tt>m</tt>) specified. At least one address is required. The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication Options</a> page.
+			<dd>Enable reception of broadcast server messages to any local interface (type b address). Ordinarily, upon receiving a 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 the <tt>novolley</tt> keyword is present, the exchange is not used and the value specified in the <tt>broadcastdelay</tt> command is used or, if the <tt>broadcastdelay</tt> command is not used, the default 4.0 ms. 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.<dt><tt>manycastserver <i>address</i> [...]</tt>
+			<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.
 			<dt><tt>multicastclient <i>address</i> [...]</tt>
-			<dd>This command enables reception of multicast server messages to the multicast group address(es) (type <tt>m</tt>) 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>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.
 		</dl>
 		<h4 id="bug">Bugs</h4>
 		<p>The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.</p>

==== html/manyopt.html ====
2007-10-20 01:30:20-04:00, stenn at whimsy.udel.edu +6 -38
  Documentation updates from Dave Mills

--- 1.13/html/manyopt.html	2005-10-13 00:32:58 -04:00
+++ 1.14/html/manyopt.html	2007-10-20 01:30:20 -04:00
@@ -5,15 +5,15 @@
 	<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 NTP Configuration Options</title>
+		<title>Automatic Server Discovery Schemes</title>
 		<link href="scripts/style.css" type="text/css" rel="stylesheet">
 	</head>
 
 	<body>
-		<h3>Automatic NTP Configuration Options</h3>
+		<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>
-		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:55</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="275">Tuesday, October 11, 2005</csobj></p>
+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">05:12</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Wednesday, October 17, 2007</csobj></p>
 		<br clear="left">
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
@@ -21,8 +21,7 @@
 		<ul>
 			<li class="inline"><a href="#bcst">Broadcasting</a>
 			<li class="inline"><a href="#mcst">Manycasting</a>
-			<li class="inline"><a href="#orphan">Orphan Mode</a>
-			<li class="inline"><a href="#opt">Server Discovery Options</a>
+			<li class="inline"><a href="#poolt">Pooling</a>
 		</ul>
 		<hr>
 		<h4 id="bcst">Broadcasting</h4>
@@ -43,39 +42,8 @@
 		<p>For example, consider an NTP subnet of two primary servers and several secondary servers and a number of dependent clients. With twoAll servers and clients have identical configuration files including both <tt>multicastclient</tt> and <tt>multicastserver</tt> commands using, for instance, multicast group address 239.1.1.1. Each primary server configuration file must include commands for the primary reference source such as a GPS receiver.</p>
 		<p>The remaining configuration files for all secondary servers and clients have the same contents, except for the <tt>tos</tt> command, which is specific for each stratum level. For stratum 1 and stratum 2 servers, that command is not necessary. For stratum 3 and above servers the <tt>tos floor</tt> value is set to the intended stratum number. Thus, all stratum 3 configuration files use <tt>tos floor 3</tt>, all stratum 4 files use <tt>tos floor 4</tt> and so forth.</p>
 		<p>Once operations have stabilized, the primary servers will find the primary reference source and each other, since they both operate at the same stratum (1), but not with any secondary server or client, since these operate at a higher stratum. The secondary servers will find the servers at the same stratum level. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.</p>
-		<h4 id="orphan">Orphan Mode</h4>
-		<p>Sometimes it is necessary to operate an NTP&nbsp;subnet in isolation, because a local reference clock is unavailable or connectivity to the Internet is not provided. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC&nbsp;timescale. Previously, this function was provided by the local clock driver, which could be configured for a server that could be reached, directly or indirectly from all other servers and clients in the subnet.</p>
-		<p>There are many disadvantages using the local clock driver: multiple source redundancy is not possible and the subnet is vulnerable to single-point failures. Orphan mode is intended to replace the need for the local clock driver. It operates in subnet configurations in all modes, including broadcast, and multiple servers and clients and handles seamless switching as primary sources fail and recover.</p>
-		<p>A server or client is enabled for orphan mode using the <tt>tos orphan <i>stratum</i></tt> command, where <tt><i>stratum</i></tt> is some stratum less than 16 and greater than any anticipated stratum that might occur with ordinary Internet servers. This is the same consideration that guides the local clock driver stratum.</p>
-		<p>As long as the stratum of any orphan is less than the orphan stratum, the servers and clients operate in the normal way. However, if the stratum equals or exceeds this stratum, the server or client is considered an orphan. If under these conditions a host has no sources of the same or lower stratum, it is designated an orphan parent; otherwise, it is considered an orphan child. Orphan parents show offset zero, root delay zero and reference ID&nbsp;127.0.0.1, which of course is the Unix loopback address. Orphan children show the mitigated offset of their servers, root delay randomized over a moderate range and reference ID of their system peer. An important distinction is that the entire subnet operates at the same orphan stratum and that the order of preference is the root delay, not the stratum and root distance as usual.</p>
-		<p>For the most flexible and reliable operation, all servers and clients in the subnet should include the <tt>orphan</tt> command in the configuration file and with the same orphan stratum. This provides mutual redundancy and diversity for all NTP&nbsp;modes of operation, including broadcast.</p>
-		<p>For example, consider the case where several campus secondary (stratum 2) servers are configured for public Internet primary servers and with each other using symmetric modes. These servers provide synchronization with a number of department servers using broadcast mode, where each of these servers is configured as both a broadcast server and broadcast client. Individual workstations on the department LAN&nbsp;are configured as broadcast clients only. All servers (not necessarily the clients) have the <tt>orphan 5</tt> command, for example.</p>
-		<p>In normal operation all servers and clients operate below stratum 5, so operate with the subnet configuration determined by stratum and root distance. If all sources are lost at any stratum level, the server or client continues operation as orphan parent. However, if sources at the orphan stratum are found, the host synchronizes to the source with lowest root delay. Since orphan root delay is determined randomly at startup, loops are avoided, even in broadcast modes where multiple servers are available.</p>
-		<h4 id="opt">Server Discovery Options</h4>
-		<dl>
-			<dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | orphan <i>orphan</i> | maxdistance <i>maxdistance</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt>
-			<dd>This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows:
-				<dl>					<dt><tt>beacon <i>beacon</i></tt>
-					<dd>The manycast server sends packets at intervals of 64 s if less than  <i><tt>maxclock</tt></i> servers are available. Otherwise, it sends packets at the <i><tt>beacon</tt></i> interval in seconds. The default is 3600 s.<dt><tt>ceiling <i>ceiling</i></tt>
-					<dd>Servers with stratum at or above <i>ceiling</i> will be discarded if there are at least <i><tt>minclock</tt></i> peers remaining. This value defaults to 15, but can be changed to any number from 1 to 15.
-					<dt><tt>cohort { 0 | 1 }</tt>
-					<dd>This is a binary flag which enables (0) or disables (1) manycast server replies to manycast clients with the same stratum level. This is useful to reduce implosions where large numbers of clients with the same stratum level are present. The default is to enable these replies.
-					<dt><tt>floor <i>floor</i></tt>
-					<dd>Peers with strata below <i>floor</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15.
-					<dt><tt>orphan <i>stratum</i></tt>
-					<dd>If <tt><i>stratum</i></tt> is set at some value less than 16 a special orphan mode is enterred when no outside source of synchronization is available. To use orphan mode a number of participants are identically configured both as broadcast client and as broadcast server. One or more participants are configured to use an outside source, either a reference clock or another Internet server. When the source or sources fail, the system stratum is set at <tt><i>stratum</i></tt> and a leader is elected to serve as the reference source. When an outside source of synchronization is again available, the orphan mode is disabled.<dt><tt>mindist <i>mindistance</i></tt>
-					<dd>The slection algorithm normally pads each intersection a minimum of one millisecond to avoid needless classification. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the padding. This command can be used for that purpose. As a general rule, set the mindistance to the maximum expected offset plus the maxiumum expected jitter, in seconds.
-					<dt><tt>maxdist <i>maxdistance</i></tt>
-					<dd>The selection algorithm accumulates a number of packets before setting the clock in order to use the best data available. The number is determined by the synchronization distance for each association and a limit called the distance threshold. The synchronization distance starts at 16, then drops by a factor of about two as each packet is received. The default distance threshold is 1.0, which usually results in four packets. Setting maxdistance to some value between 1 and 16 can be used to change the number of packets required. For instance, setting it to 16 will set the clock on the first packet received; howver, setting it to this value essentially disables the mitigation and grooming algorithms.
-					<dt><tt>minclock <i>minclock</i></tt>
-					<dd>The clustering algorithm repeatedly casts out outlyer associations until no more than <i>minclock</i> associations remain. This value defaults to 3, but can be changed to any number from 1 to the number of configured sources.
-					<dt><tt>minsane <i>minsane</i></tt>
-					<dd>This is the minimum number of candidates available to the clock selection algorithm in order to produce one or more truechimers for the clustering algorithm. If fewer than this number are available, the clock is undisciplined and allowed to run free. The default is 1 for legacy purposes. However, according to principles of Byzantine agreement, <i>minsane</i> should be at least 4 in order to detect and discard a single falseticker.
-				</dl>
-			
-			<dt><tt>ttl <i>hop</i> ...</tt>
-			<dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31.
-		</dl>
+		<h4 id="pool"> Pooling</h4>
+		<p>bibbidt</p>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>

==== html/miscopt.html ====
2007-10-20 01:30:21-04:00, stenn at whimsy.udel.edu +22 -1
  Documentation updates from Dave Mills

--- 1.36/html/miscopt.html	2007-07-23 01:31:13 -04:00
+++ 1.37/html/miscopt.html	2007-10-20 01:30:21 -04:00
@@ -12,7 +12,7 @@
 		<h3>Miscellaneous Options</h3>
 		<img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
 		<p>We have three, now looking for more.</p>
-		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">16:01</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="268">Wednesday, July 18, 2007</csobj></p>
+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:47</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 15, 2007</csobj></p>
 		<br clear="left">
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
@@ -98,6 +98,27 @@
 					<dt><tt>stepout <i>stepout</i></tt>
 					<dd>The argument is the stepout timeout, by default 900 s. It can be set to any positive number in seconds. If set to zero, the stepout pulses will not be suppressed.
 				</dl>
+			<dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | orphan <i>orphan</i> | maxdistance <i>maxdistance</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt>
+			<dd>This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows:
+				<dl>					<dt><tt>beacon <i>beacon</i></tt>
+					<dd>The manycast server sends packets at intervals of 64 s if less than  <i><tt>maxclock</tt></i> servers are available. Otherwise, it sends packets at the <i><tt>beacon</tt></i> interval in seconds. The default is 3600 s.<dt><tt>ceiling <i>ceiling</i></tt>
+					<dd>Servers with stratum at or above <i>ceiling</i> will be discarded if there are at least <i><tt>minclock</tt></i> peers remaining. This value defaults to 15, but can be changed to any number from 1 to 15.
+					<dt><tt>cohort { 0 | 1 }</tt>
+					<dd>This is a binary flag which enables (0) or disables (1) manycast server replies to manycast clients with the same stratum level. This is useful to reduce implosions where large numbers of clients with the same stratum level are present. The default is to enable these replies.
+					<dt><tt>floor <i>floor</i></tt>
+					<dd>Peers with strata below <i>floor</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15.
+					<dt><tt>orphan <i>stratum</i></tt>
+					<dd>If <tt><i>stratum</i></tt> is set at some value less than 16 a special orphan mode is enterred when no outside source of synchronization is available. To use orphan mode a number of participants are identically configured both as broadcast client and as broadcast server. One or more participants are configured to use an outside source, either a reference clock or another Internet server. When the source or sources fail, the system stratum is set at <tt><i>stratum</i></tt> and a leader is elected to serve as the reference source. When an outside source of synchronization is again available, the orphan mode is disabled.<dt><tt>mindist <i>mindistance</i></tt>
+					<dd>The slection algorithm normally pads each intersection a minimum of one millisecond to avoid needless classification. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the padding. This command can be used for that purpose. As a general rule, set the mindistance to the maximum expected offset plus the maxiumum expected jitter, in seconds.
+					<dt><tt>maxdist <i>maxdistance</i></tt>
+					<dd>The selection algorithm accumulates a number of packets before setting the clock in order to use the best data available. The number is determined by the synchronization distance for each association and a limit called the distance threshold. The synchronization distance starts at 16, then drops by a factor of about two as each packet is received. The default distance threshold is 1.0, which usually results in four packets. Setting maxdistance to some value between 1 and 16 can be used to change the number of packets required. For instance, setting it to 16 will set the clock on the first packet received; howver, setting it to this value essentially disables the mitigation and grooming algorithms.
+					<dt><tt>minclock <i>minclock</i></tt>
+					<dd>The clustering algorithm repeatedly casts out outlyer associations until no more than <i>minclock</i> associations remain. This value defaults to 3, but can be changed to any number from 1 to the number of configured sources.
+					<dt><tt>minsane <i>minsane</i></tt>
+					<dd>This is the minimum number of candidates available to the clock selection algorithm in order to produce one or more truechimers for the clustering algorithm. If fewer than this number are available, the clock is undisciplined and allowed to run free. The default is 1 for legacy purposes. However, according to principles of Byzantine agreement, <i>minsane</i> should be at least 4 in order to detect and discard a single falseticker.
+				</dl>
+			<dt><tt>ttl <i>hop</i> ...</tt>
+			<dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31.
 			<dt><tt>trap <i>host_address</i> [port <i>port_number</i>] [interface <i>interface_address</i>]</tt>
 			<dd>This command configures a trap receiver at the given host address and port number for sending messages with the specified local interface address. If the port number is unspecified, a value of 18447 is used. If the interface address is not specified, the message is sent with a source address of the local interface the message is sent through. Note that on a multihomed host the interface used may vary from time to time with routing changes.
 				<p>The trap receiver will generally log event messages and other information from the server in a log file. While such monitor programs may also request their own trap dynamically, configuring a trap receiver will ensure that no messages are lost when the server is started.</p>

==== html/scripts/links7.txt ====
2007-10-20 01:30:40-04:00, stenn at whimsy.udel.edu +1 -0
  Documentation updates from Dave Mills

--- 1.3/html/scripts/links7.txt	2007-07-23 01:31:45 -04:00
+++ 1.4/html/scripts/links7.txt	2007-10-20 01:30:40 -04:00
@@ -1,6 +1,7 @@
 document.write("<ul>\
 <li class='inline'><a href='accopt.html'>Access Control Options</a><br>\
 <li class='inline'><a href='authopt.html'>Authentication Options</a><br>\
+<li class='inline'><a href='manyopt.html'>Server Discovery Options</a><br>\
 <li class='inline'><a href='miscopt.html'>Miscellaneous Options</a><br>\
 <li class='inline'><a href='monopt.html'>Monitoring Options</a><br>\
 <li class='inline'><a href='clockopt.html'>Reference Clock Options</a><br>\


More information about the bk-ntp-dev-send mailing list