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

Harlan Stenn stenn at deacon.udel.edu
Sun Dec 11 10:59:31 UTC 2011


#### ChangeSet ####
2011-12-11 05:57:08-05:00, stenn at deacon.udel.edu
  Documentation updates from Dave Mills

==== ChangeLog ====
2011-12-11 05:55:54-05:00, stenn at deacon.udel.edu +1 -0
  Documentation updates from Dave Mills

--- 1.1070/ChangeLog	2011-12-09 14:18:59 -05:00
+++ 1.1071/ChangeLog	2011-12-11 05:55:54 -05:00
@@ -1,3 +1,4 @@
+* Documentation updates from Dave Mills.
 (4.2.7p238) 2011/12/09 Released by Harlan Stenn <stenn at ntp.org>
 * [Bug 2082] from 4.2.6p5-RC3: 3-char refid sent by ntpd 4.2.6p5-RC2
   ends with extra dot.

==== html/cluster.html ====
2011-12-11 05:55:17-05:00, stenn at deacon.udel.edu +4 -3
  Documentation updates from Dave Mills

--- 1.6/html/cluster.html	2011-10-31 15:37:17 -04:00
+++ 1.7/html/cluster.html	2011-12-11 05:55:17 -05:00
@@ -10,21 +10,22 @@
 <em></em>
 <h3>Clock Cluster Algorithm</h3>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->29-Oct-2011  18:54<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->03-Dec-2011  14:58<!-- #EndDate -->
   UTC</p>
 <hr>
 <p>The clock cluster algorithm processes the truechimers produced by the clock select algorithm to produce a list of survivors. These survivors are used by the mitigation algorithms to discipline the system clock. The cluster algorithm operates in a series of rounds, where at each round the truechimer  furthest from the offset centroid is pruned from the population. The rounds are continued until a specified termination condition is met. This page discusses the algorithm in detail.</p>
-<p>First, the truechimer  associations are saved on a list  with each candidate entry identified with index <em>i</em>    (<em>i </em>= 1, ..., <em>n)</em>, where <em>n</em> is the number of candidates. Let  <font face="symbol"> q</font>(<em>i</em>), be the offset and   <font face="symbol">l</font>(<em>i</em>) be the root distance of the <em>i</em>th entry. Recall that the root distance is equal to the root dispersion plus half the root delay. For the <em>i</em>th candidate on the list, a statistic called the <em>select jitter</em> relative to the <em>i</em>th candidate is calculated as follows. Let</p>
+<p>First, the truechimer  associations are saved on an unordered list  with each candidate entry identified with index <em>i</em>    (<em>i </em>= 1, ..., <em>n)</em>, where <em>n</em> is the number of candidates. Let  <font face="symbol"> q</font>(<em>i</em>), be the offset and   <font face="symbol">l</font>(<em>i</em>) be the root distance of the <em>i</em>th entry. Recall that the root distance is equal to the root dispersion plus half the root delay. For the <em>i</em>th candidate on the list, a statistic called the <em>select jitter</em> relative to the <em>i</em>th candidate is calculated as follows. Let</p>
 <div align="center">
   <p><em>d<sub>i</sub></em>(<em>j</em>) = |<font face="symbol">q</font>(<em>j</em>) - <font face="symbol"> q</font>(<em>i</em>)| <font face="symbol">l</font>(<em>i</em>),</p>
 </div>
 <p> where<font face="symbol"> q</font>(<em>i)</em> is the peer offset of the <em>i</em>th entry and <font face="symbol">q</font>(<em>j</em>) is the peer offset of the <em>j</em>th entry, both produced by the clock filter algorithm. The metric used by the cluster algorithm is the select jitter <font face="symbol">j</font><sub>S</sub>(<em>i</em>) computed as the  root mean square (RMS) of the <em>d<sub>i</sub></em>(<em>j</em>)  as <em>j</em> ranges from 1 to <em>n</em>. <em> </em>For the purpose of notation in the example to follow, let <font face="symbol">j</font><sub>R</sub>(<em>i</em>) be the peer jitter computed by the clock filter algorithm for the <em>i</em>th candidate.</p>
 <p>The object at each round is to prune the entry with the largest metric until the termination condition is met. Note that the select jitter must be recomputed at each round, but the peer jitter does not change. At each round the remaining entries on the list represent the survivors of that round. If the candidate to be pruned is  preemptable and the number of candidates is greater than    the <em>maxclock threshold</em>, the association is demobilized.   This is useful in the  schemes described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. The maxclock threshold  default is 10, but it can be changed using the <tt>maxclock</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. Further pruning is subject to the following termination conditions, but no associations will be automatically demobilized.</p>
-<p>The termination condition has two parts. First, if the number of candidates is not greater than the<em> </em><em>minclock threshold</em> set by the <tt>minclock</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command, the pruning process terminates. The<tt> minclock</tt> default is 3, but can be changed  to fit special conditions, as described on the <a href="prefer.html">Mitigation Rules and the prefer Keyword</a> page.</p>
+<p>The termination condition has two parts. First, if the number of survivors is not greater than the<em> </em><em>minclock threshold</em> set by the <tt>minclock</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command, the pruning process terminates. The<tt> minclock</tt> default is 3, but can be changed  to fit special conditions, as described on the <a href="prefer.html">Mitigation Rules and the prefer Keyword</a> page.</p>
 <div align="center"><img src="pic/flt7.gif" alt="gif">
   <p>Figure 1. Cluster Algorithm</p>
 </div>
 <p>The second termination condition is more intricate. Figure 1 shows a round where a candidate of (a) is pruned to yield the candidates of (b). Let <font face="symbol">j</font><sub><em>max</em></sub> be the maximum select jitter and <font face="symbol">j</font><sub><em>min</em></sub> be the minimum peer jitter over all candidates on the list. In (a), candidate 1 has the highest select jitter, so <font face="symbol">j</font><sub><em>max</em></sub> = <font face="symbol"> j</font><sub>S</sub>(1). Candidate 4 has the lowest peer jitter, so <font face="symbol">j</font><sub><em>min</em></sub> = <font face="symbol">j</font><sub>R</sub>(4). Since <font face="symbol">j</font><sub><em>max</em></sub> &gt; <font face="symbol">j</font><sub><em>min</em></sub>, select jitter dominates  peer jitter,the algorithm prunes candidate 1.&#13; In (b), <font face="symbol">j</font><sub><em>max</em></sub> = <font face="symbol">j</font><sub>S</sub>(3) and <font face="symbol">j</font><sub><em>min </em
 ></sub>=<font face="symbol"> j</font><sub>R</sub>(4). Since <font face="symbol">j</font><sub><em>max</em></sub> &lt; <font face="symbol">j</font><sub><em>min</em></sub>, pruning additional candidates does not  reduce select jitter, the algorithm terminates with candidates 2, 3 and 4 as  survivors.</p>
+<p>The survivor list is passed on to the the mitigation algorithms, which combine the survivors, select a system peer, and compute the system statistics passed on to dependent clients. Note the use of root distance <font face="symbol">l</font>  as a weight factor at each round in the clock cluster algorithm. This is to favor the survivors with the lowest root distance and thus the smallest maximum error.</p>
 <hr>
 <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 </body>

==== html/filter.html ====
2011-12-11 05:55:20-05:00, stenn at deacon.udel.edu +7 -6
  Documentation updates from Dave Mills

--- 1.4/html/filter.html	2011-10-31 15:37:17 -04:00
+++ 1.5/html/filter.html	2011-12-11 05:55:20 -05:00
@@ -9,22 +9,23 @@
 <body>
 <h3>Clock Filter Algorithm</h3>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->19-Oct-2011  18:42<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->02-Dec-2011  21:25<!-- #EndDate -->
   UTC</p>
 <hr>
 <p>The clock filter algorithm processes the offset and delay samples produced by the on-wire protocol for each peer process separately. It uses a sliding window of eight samples and picks out the sample with the least expected error. This page describes the algorithm design principles along with an example of typical performance.</p>
 <div align="center"><img src="pic/flt5.gif" alt="gif">
   <p>Figure 1. Wedge Scattergram</p>
 </div>
-<p>Figure 1 shows  a <em>wedge scattergram</em> plotting  sample points of offset versus delay collected over a 24-hr period.  As the delay increases, the  offset variation increases, so the best samples are those at the lowest delay. There are two limb lines at slope &plusmn;0.5, representing the limits of sample variation. This turns out to be useful, as described on the  <a href="huffpuff.html">Huff-n'-Puff Filter</a> page. However, it is apparent that, if a way could be found to find the sample of least delay, it would have the least offset variation and would be the best candidate to synchronize the system clock.</p>
+<p>Figure 1 shows  a <em>wedge scattergram</em> plotting  sample points of offset versus delay collected over a 24-hr period.  As the delay increases, the  offset variation increases, so the best samples are those at the lowest delay. There are two limb lines at slope &plusmn;0.5, representing the limits of sample variation. This turns out to be useful, as described on the  <a href="huffpuff.html">Huff-n'-Puff Filter</a> page. However, it is apparent that, if a way could be found to find the sample of lowest delay, it would have the least offset variation and would be the best candidate to synchronize the system clock.</p>
 <p>In the clock filter algorithm the offset and delay   samples from the on-wire protocol are inserted as the youngest stage of  an eight-stage shift register, thus discarding the oldest stage.  Each time an NTP packet is received from a source, a  dispersion sample is initialized as the sum of the precisions of the server and client. Precision is defined by the latency to read the system clock and varies from 1000 ns to 100 ns in modern machines. The dispersion sample is inserted in the  shift register along with the offset and delay samples.  Subsequently, the dispersion sample  in each stage is increased at a fixed rate of 15 <font face="symbol">m</font>s/s, representing the worst case error due to skew between the server and client clock frequencies.</p>
 <p>In each peer process the  clock filter algorithm  selects the stage with the smallest  delay, which generally represents the most accurate data, and it and the  associated offset sample become the peer variables of the same name. The peer jitter statistic is computed as the root mean square (RMS) differences between the offset samples and the offset of the selected stage.</p>
-<p> The peer dispersion  statistic is determined as a weighted sum of the dispersion samples in the shift register.  Initially, the dispersion of all shift register stages is set to a large number &quot;infinity&quot; equal to 16 s. The weight factor for each stage, starting from the youngest numbered <em>i</em> = 1, is 2<sup>-<em>i</em></sup>, which means the peer dispersion is approximately 16. As samples enter the register, the peer dispersion drops from 16 to 8, 4, 2... and so forth. In practice, the dispersion falls below the select threshold of 1.5 s in about four updates. This gives some time for meaningful comparison between sources, if more than one are available. The dispersion continues to grow at the same  rate as the sample dispersion. As explained elsewhere, when a source becomes unreachable, the poll process inserts a dummy infinity sample in the shift register for each poll sent. After eight polls, the register returns to its original state.</p>
-<div align="center"><img src="pic/flt1.gif" alt="gif"> <img src="pic/flt2.gif" alt="gif">
+<p> The peer dispersion  statistic is determined as a weighted sum of the dispersion samples in the shift register.  Initially, the dispersion of all shift register stages is set to a large number &quot;infinity&quot; equal to 16 s. The weight factor for each stage, starting from the youngest numbered <em>i</em> = 1, is 2<sup>-<em>i</em></sup>, which means the peer dispersion is approximately 16.</p>
+<p> As samples enter the register, the peer dispersion drops from 16 to 8, 4, 2... and so forth. In practice, the dispersion falls below the select threshold of 1.5 s in about four updates. This gives some time for meaningful comparison between sources, if more than one are available. The dispersion continues to grow at the same  rate as the sample dispersion. As explained elsewhere, when a source becomes unreachable, the poll process inserts a dummy infinity sample in the shift register for each poll sent. After eight polls, the register returns to its original state.</p>
+<div align="center"><img src="pic/flt1.gif" alt="gif"> &nbsp; <img src="pic/flt2.gif" alt="gif">
   <p>Figure 2. Raw (left) and Filtered (right) Offsets</p>
 </div>
-<p>Figure 2 shows the  performance of the algorithm using  offsets for a typical Internet path over a 24-hr period. The graph on the left shows the raw offsets produced by the on-wired protocol, while the figure on the right shows the filtered offsets  produced by the  algorithm. If we consider the series formed as the absolute value of the offset samples, the mean error is defined as the mean of this series. Thus, the mean error of the raw samples is 0.724 ms, while the mean error of the filtered series is 0.192 ms. Radio engineers would interpret this as a  processing gain of 11.5 dB.</p>
-<p>The reader may notice the somewhat boxy characteristic of the filtered offsets.  Once a sample is selected, it remains selected until a newer sample with lower delay is available. This commonly occurs when an older selected sample is discarded from the shift register.  The reason for this is to preserve causality; that is, time always moves forward, never  backward. The result can be the loss of up to seven samples in the shift register, or more to the point, the output sample rate can never be less than one in eight input samples. The clock discipline algorithm is specifically designed to operate at this rate.</p>
+<p>Figure 2 shows the  performance of the algorithm  for a typical Internet path over a 24-hr period. The graph on the left shows the raw offsets produced by the on-wired protocol, while the figure on the right shows the filtered offsets  produced by the  clock filter algorithm. If we consider the series formed as the absolute value of the offset samples, the mean error is defined as the mean of this series. Thus, the mean error of the raw samples is 0.724 ms, while the mean error of the filtered series is 0.192 ms. Radio engineers would interpret this as a  processing gain of 11.5 dB.</p>
+<p>The reader might notice the somewhat boxy characteristic of the filtered offsets.  Once a sample is selected, it remains selected until a newer sample with lower delay is available. This commonly occurs when an older selected sample is discarded from the shift register.  The reason for this is to preserve causality; that is, time always moves forward, never  backward. The result can be the loss of up to seven samples in the shift register, or more to the point, the output sample rate can never be less than one in eight input samples. The clock discipline algorithm is specifically designed to operate at this rate.</p>
 <hr>
 <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 </body>

==== html/prefer.html ====
2011-12-11 05:55:27-05:00, stenn at deacon.udel.edu +20 -33
  Documentation updates from Dave Mills

--- 1.28/html/prefer.html	2011-11-06 01:37:00 -04:00
+++ 1.29/html/prefer.html	2011-12-11 05:55:27 -05:00
@@ -3,14 +3,13 @@
 <head>
 <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
 <title>Mitigation Rules and the prefer Keyword</title>
-<link href="scripts/style.css" type="text/css" rel="stylesheet">
-</head>
+<link href="scripts/style.css" type="text/css" rel="stylesheet"></head>
 <body>
 <h3>Mitigation Rules and the <tt>prefer</tt> Keyword</h3>
 <img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
 <p>Listen carefully to what I say; it is very complicated.</p>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->01-Nov-2011  3:24<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->05-Dec-2011  7:21<!-- #EndDate -->
   UTC</p>
 <br clear="left">
 <h4>Related Links</h4>
@@ -27,32 +26,25 @@
 </ul>
 <hr>
 <h4 id="intro">General Overview</h4>
-<p>This page summarizes the criteria for choosing from among a number of potential sources suitable contributors to the clock discipline algorithm. The criteria are very meticulous, since they have to handle many different scenarios that may be optimized for peculiar circumstances, including some scenarios designed to support planetary and deep space missions.</p>
-<p>Recall the suite of NTP data acquisition and grooming algorithms as these algorithms proceed in five phases. Phase one discovers the available sources and mobilizes an association for each candidate found. These candidates can result from explicit configuration, broadcast discovery or the pool and manycast autonomous configuration schemes. See the <a href="discover.html">Automatic Server Discovery Schemes</a> page for further information.</p>
-<p> Phase two refines the selectable   candidates by  excluding those sources showing one or more of the following errors:</p>
-<ol>
-  <li>A stratum error occurs if (1) the source had never been synchronized or (2) the stratum of the source is below the <tt>floor</tt> option or not below the <tt>ceiling</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. The default value for these options are 0 and 16, respectively.</li>
-  <li>A distance error occurs for a remote source if the root distance is not below the distance threshold <tt>maxdist</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. The default value for this option is 1.5 s for networks including only the Earth, but this should be increased to 2.5 s for networks including the Moon.</li>
-  <li>A loop error occurs if the source is synchronized to the client or if the source is synchronized to the same source as the client.</li>
-  <li>An unreachable error occurs if the source is unreachable or if the <tt>server</tt> or <tt>peer</tt> command for the source includes the <tt>noselect</tt> option.</li>
-</ol>
-<p>Phase three uses the algorithm described on the <a href="select.html">Clock Select Algorithmm</a> page to determine the truechimers from among the selectable candidates, leaving behind the falsetickers. A server or peer configured with the <tt>true</tt> option is declared a truechimer independent of this algorithm. Phase four uses the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page to cast off statistical outliers from the truechimers until a number of survivors not less than   <tt>minclock</tt> remain. The <tt>minclock</tt> has default 3, but can be changed with the <tt>minclock</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command.</p>
-<p> Phase five uses a set of algorithms and mitigation rules described on this page. The algorithms rank the survivors to produce  combined statistics used to discipline the clock. The mitigation rules select from among the survivors a system peer from which a set of system statistics can be inherited and passed along to  dependent clients, if any.  The algorithms and rules are the main topic of this page. The clock offset developed from these algorithms can discipline the system clock either using the <a href="discipline.html">clock discipline algorithm</a> or enable the kernel to discipline the system clock directly, as described on the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. </p>
+<p>This page summarizes the criteria for choosing from among the survivors of the clock cluster algorithm  a set of  contributors to the clock discipline algorithm. The criteria are very meticulous, since they have to handle many different scenarios that may be optimized for special circumstances, including some scenarios designed to support planetary and deep space missions.</p>
+<p>Recall the suite of NTP data acquisition and grooming algorithms. These algorithms proceed in five phases. Phase one discovers the available <em>sources</em> and mobilizes an association for each source found. These sources can result from explicit configuration, broadcast discovery or the pool and manycast autonomous configuration schemes. See the <a href="discover.html">Automatic Server Discovery Schemes</a> page for further information.</p>
+<p> Phase two selects the <em> candidates</em> from among the sources  by  excluding those sources showing one or more of the  errors summarized on the  <a href="select.html">Clock Select Algorithmm</a> page and to determine the <em>truechimers</em> from among the  candidates, leaving behind the <em>falsetickers</em>. A server or peer configured with the <tt>true</tt> option is declared a truechimer independent of this algorithm. Phase four uses the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page to trim the statistical outliers from the  truechimers, leaving the <em>survivor list</em><em></em> as result. </p>
+<p> Phase five uses a set of algorithms and mitigation rules to   combined the survivor statistics antdiscipline the systen clock. The mitigation rules select from among the survivors a <em>system peer</em> from which a set of system statistics can be inherited and passed along to  dependent clients, if any.  The algorithms and rules are the main topic of this page. The clock offset developed from these algorithms can discipline the system clock either using the <a href="discipline.html">clock discipline algorithm</a> or enable the kernel to discipline the system clock directly, as described on the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. </p>
 <h4 id="combine">Combine Algorithm</h4>
-<p> The clock combine algorithm uses the survivor list to produce a weighted average of both offset and jitter. Absent other considerations discussed later, the combined offset is used to discipline the system clock, while the combined jitter is augmented with other components to produce the system jitter statistic inherited by dependent clients, if any.</p>
-<p> The clock combine algorithm uses a weight factor for each survivor computed as the select threshold minus the synchronization distance. Since the select algorithm rejects candidates with synchronization distance greater than the select threshold, the weight factor is always positive. This design  favors the survivors at the smaller distance, which have the smaller maximum error statistics.</p>
+<p> The clock combine algorithm uses the survivor list to produce a weighted average of both offset and jitter. Absent other considerations discussed later, the <em>combined offset</em> is used to discipline the system clock, while the <em>combined jitter</em> is augmented with other components to produce the system jitter statistic inherited by dependent clients, if any.</p>
+<p> The clock combine algorithm uses a weight factor for each survivor equal to the reciprocal of the root distance. This is normalized so that the sum of the reciprocals is equal to unity. This design  favors the survivors at the smallest root distance and thus the smallest  maximum  error.</p>
 <h4 id="clockhop">Anti-Clockhop Algorithm</h4>
-<p>The anti-clockhop algorithm is intended for cases where multiple  servers are available on a fast LAN with modern computers. Typical offset differences between servers in such cases are less than 0.5 ms. However,  changes between servers can result in unnecessary system jitter. The object of the anti-clockhop algorithm is to avoid changing  the server unless it becomes stale or the distance increases substantially over other candidates on the list.</p>
-<p>To help compact this discussion, we will call the last selected system peer the <em>old peer</em>, and the peer at the head of the survivor list the <em>candidate peer</em>. The anti-clockhop algorithm is called immediately after the combine algorithm. First, the  survivor list produced by the clock cluster algorithm is  sorted  by increasing synchronization distance. The algorithm then initializes the anti-clockhop threshold with the value of  <tt>mindist</tt>, by default 1 ms. </p>
-<p>If there was no old peer or the old and candidate peers are the same,   the candidate peer becomes the system peer. If not, the algorithm measures the difference between the offset of the old peer and the candidate peer. If the difference exceeds the anti-clockhop threshold, the candidate peer becomes the system peer and the anti-clockhop threshold is restored to its original value. If not, the old peer continues as the system peer. However, at each subsequent call, the algorithm reduces the anti-clockhop threshold by half. Should operation continue in this way, the candidate peer will eventually become the system peer.</p>
+<p>The anti-clockhop algorithm is intended for cases where multiple  servers are available on a fast LAN with modern computers. Typical offset differences between servers in such cases are less than 0.5 ms. However,  changes between servers can result in unnecessary system jitter. The object of the anti-clockhop algorithm is to avoid changing  the current server unless it becomes stale or the offset differences between it and the others on the survivor list becomes substantial.</p>
+<p>To help compact this discussion, we will call the last selected server as the <em>old peer</em>, and the server at the head of the survivor list the <em>candidate peer</em>. The anti-clockhop algorithm is called immediately after the combine algorithm. First, the  survivor list produced by the clock cluster algorithm is  sorted  by increasing root distance. The algorithm then initializes the anti-clockhop threshold with the value of  <tt>mindist</tt>, by default 1 ms. </p>
+<p>If there was no old peer or the old and candidate peers are the same,   the candidate peer becomes the system peer. If not, the algorithm measures the difference between the offset of the old peer and the candidate peer. If the difference exceeds the anti-clockhop threshold, the candidate peer becomes the system peer and the anti-clockhop threshold is restored to its original value. If not, the old peer continues as the system peer. However, at each subsequent update, the algorithm reduces the anti-clockhop threshold by half. Should operation continue in this way, the candidate peer will eventually become the system peer.</p>
 <h4 id="peer">Peer Classification</h4>
 <p>The behavior of the various algorithms and mitigation rules involved depends on how the various synchronization sources are classified. This depends on whether the source is local or remote and if local, the type of source. The following classes are defined:</p>
 <ol>
-  <li>An association configured for a remote server or peer is classified simply as a <i>server</i>. All other associations are classified as a <i>device driver</i> of one kind or another. In general, one or more sources of either or both types will be configured in each installation.</li>
+  <li>An association configured for a remote server or peer is classified  as a <i>server</i>. All other associations are classified as  <i>device drivers</i> of one kind or another. In general, one or more sources of either  type will be configured in each installation.</li>
   <li>If all sources have been lost and one or more hosts on a  common DMZ network have  specified the orphan stratum in the <tt>orphan</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command, each of them becomes an  <i>orphan parent</i>. Dependent orphan children on the same DMZ network will see the orphan parents as if synchronized to a  server at the orphan stratum.  Note that, as described below,  all the orphan children having the same set of orphan parents will select the same parent.</li>
   <li>When a device driver has been configured for pulse-per-second (PPS) signals and PPS signals are being received, it is designated the <i>PPS driver.</i> Note that the Pulse-per-Second driver (type 22) is often used as a PPS driver, but any driver can be configure as a PPS driver if the hardware facilities are available. The PPS driver provides precision clock discipline only within &plusmn;0.4 s, so it is always associated with another source or sources that provide the seconds numbering function.</li>
-  <li>When the Undisciplined Local Clock driver (type 1) is configured, it is designated the <i>local driver</i>. This driver is used either as a backup source (stratum greater than zero) should all sources fail, or as the primary source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lock clock</tt> scheme, or another synchronization protocol such as the IEEE 1588 Precision Time Protocol (PTP) or Digital Time Synchronization Service (DTSS).</li>
-  <li>When the Automated Computer Time Service driver (type 18) is configured, it is designated the <i>modem driver</i>. This is used either as a backup source, should all other sources fail, or as the  primary source if the <tt>prefer</tt> option is present.</li>
+  <li>When the Undisciplined Local Clock driver (type 1) is configured, it is designated the <i>local driver</i>. It can be used either as a backup source (stratum greater than zero) should all sources fail, or as the primary source (stratum zero) whether or not other sources are available if the <tt>prefer</tt> option is present. The local driver can be used when the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lock clock</tt> scheme, or another synchronization protocol such as the IEEE 1588 Precision Time Protocol (PTP) or Digital Time Synchronization Service (DTSS).</li>
+  <li>When the Automated Computer Time Service driver (type 18) is configured, it is designated the <i>modem driver</i>. It is used either as a backup source, should all other sources fail, or as the  primary source if the <tt>prefer</tt> option is present.</li>
 </ol>
 <h4 id="prefer">The <tt>prefer</tt> Peer</h4>
 <p>The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types. When used with the <tt>server</tt> or <tt>peer</tt> commands, the <tt>prefer</tt> option designates one or more sources as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; however, if more than one source is so designated, they are used in the order specified in the configuration file. If the first one becomes un selectable, the second one is considered and so forth. This order of priority is also applicable to multiple PPS drivers, multiple modem drivers and even multiple local drivers, although that would not normally be useful.</p>
@@ -66,20 +58,15 @@
   remains operational. However, if the radio fails or becomes a falseticker,
   the averaged backup sources continue to discipline the system clock.</p>
 <h4 id="miti">Mitigation Rules</h4>
-<p>As the select algorithm scans the associations for selectable candidates, the modem driver and local driver are segregated for later, but only if not designated a prefer peer. If so designated, the driver is included among the candidate population. In addition, if orphan parents are found, the parent with the lowest  metric is segregated for later; the others are discarded. For this purpose the metric is defined as the four-octet IPv4 address or the first four octets of the hashed IPv6 address. The resulting candidates, including any prefer peers found, are processed by the select  algorithm to produce a possibly empty set of truechimers.</p>
-<p> As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The combine algorithm ranks the survivors  by synchronization distance and temporarily designates the first one  as the  system peer.</p>
-<p>If one or more truechimers support a pulse-per-second (PPS) signal and the
-  PPS signal is operating correctly, it is designated a PPS driver. If more than
-  one PPS diver are found, only the first one is used. The PPS driver is not included
-  in the combine algorithm and is mitigated separately.</p>
-<p>At this point  the following contributors to the system clock discipline may be available:</p>
+<p>As the select algorithm scans the associations for selectable candidates, the modem driver and local driver are segregated for later, but only if not designated a prefer peer. If so designated, the driver is included among the candidate population. In addition, if orphan parents are found, the parent with the lowest  metric  is segregated for later; the others are discarded. For this purpose the metric is defined as the four-octet IPv4 address or the first four octets of the hashed IPv6 address. The resulting candidates, including any prefer peers found, are processed by the select  algorithm to produce a possibly empty set of truechimers.</p>
+<p> As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The survivor list is then sorted by increasing root distance   and the first entry   temporarily designated the   system peer. At this point  the following contributors to the system clock discipline may be available:</p>
 <ul>
   <li>(potential) system peer, if there are survivors;</li>
   <li>orphan parent, if present;</li>
-  <li>local driver and zero offset, if present;</li>
-  <li>modem driver and modem offset, if present;</li>
-  <li>prefer peer and offset, if present;</li>
-  <li>PPS driver and offset, if present.</li>
+  <li>local driver, if present;</li>
+  <li>modem driver, if present;</li>
+  <li>prefer peer, if present;</li>
+  <li>PPS driver, if present.</li>
 </ul>
 <p>The mitigation algorithm proceeds in three steps in turn.</p>
 <ol>

==== html/select.html ====
2011-12-11 05:55:30-05:00, stenn at deacon.udel.edu +10 -3
  Documentation updates from Dave Mills

--- 1.4/html/select.html	2011-10-31 15:37:18 -04:00
+++ 1.5/html/select.html	2011-12-11 05:55:30 -05:00
@@ -10,11 +10,18 @@
 <em></em>
 <h3>Clock Select Algorithm</h3>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->19-Oct-2011  18:17<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->04-Dec-2011  14:27<!-- #EndDate -->
   UTC</p>
 <hr>
-<p>The clock select algorithm determines from a set of candidates, which are correct (<em>truechimers</em>) and which are not (<em>falsetickers</em>) according to a set of formal correctness assertions. The principles are based on the observation that the maximum error in determining the offset of a candidate cannot exceed one-half the roundtrip delay to the primary reference clock at the time of measurement. This must be increased by the maximum error that can accumulate since then. In NTP the total, called the <em>synchronization distance</em>, is one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here.</p>
-<p>Given the measured offset <font face="symbol">q<sub>0</sub></font> and synchronization distance <font face="symbol">l</font>, this defines a <em>correctness  interval</em> [<font face="symbol">q<sub>0</sub></font> - <font face="symbol">l</font>, <font face="symbol">q<sub>0</sub></font> + <font face="symbol">l</font>] of points where the true value of <font face="symbol">q</font> lies somewhere on the interval.  The given problem is to determine from a set of correctness intervals, which represent truechimers and which represent falsetickers. The principles must be given a precise definition. The <em>intersection  interval</em> is the smallest interval containing points from the largest  number of correctness intervals. An algorithm that finds the intersection interval   was devised by Keith Marzullo in his doctoral dissertation. It was first implemented in the  DTSS (Digital Time Synchronization Service) in the VMS operating system for the VAX.</p>
+<p>The clock select algorithm determines from a set of sources , which are correct (<em>truechimers</em>) and which are not (<em>falsetickers</em>) according to a set of formal correctness assertions. The principles are based on the observation that the maximum error in determining the offset of a candidate cannot exceed one-half the roundtrip delay to the primary reference clock at the time of measurement. This must be increased by the maximum error that can accumulate since then.  The selection metric, called the <em>root  distance,</em>, is one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here.</p>
+<p>First, a number of sanity checks is performed to sift the selectable candidate from among the source population. The sanity checks are sumarized as follows:.</p>
+<ol>
+  <li>A <em>stratum error</em> occurs if (1) the source had never been synchronized or (2) the stratum of the source is below the <tt>floor</tt> option or not below the <tt>ceiling</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. The default values for these options are 0 and 15, respectively. Note that  15 is a valid stratum, but a server operating at that stratum  cannot synchronize  clients.</li>
+  <li>A <em>distance error</em> occurs for a remote source if the root distance (also known ad synchronization distance) of the source is not below the distance threshold <tt>maxdist</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. The default value for this option is 1.5 s for networks including only the Earth, but this should be increased to 2.5 s for networks including the Moon.</li>
+  <li>A <em>loop</em> <em>error</em> occurs if the source is synchronized to the client. This can occur if two peers are configured with each other in symmetric modes.</li>
+  <li>An <em>unreachable</em> <em>error</em> occurs if the source is unreachable or if the <tt>server</tt> or <tt>peer</tt> command for the source includes the <tt>noselect</tt> option.</li>
+</ol>
+Sources showing one or more of these errors are  considered nonselectable; only  the selectable candidates are considered in the following algorithm. Given the measured offset <font face="symbol">q<sub>0</sub></font> and root distance <font face="symbol">l</font>, this defines a <em>correctness  interval</em> [<font face="symbol">q<sub>0</sub></font> - <font face="symbol">l</font>, <font face="symbol">q<sub>0</sub></font> + <font face="symbol">l</font>] of points where the true value of <font face="symbol">q</font> lies somewhere on the interval.  The given problem is to determine from a set of correctness intervals, which represent truechimers and which represent falsetickers. The principles must be given a precise definition. The <em>intersection  interval</em> is the smallest interval containing points from the largest  number of correctness intervals. An algorithm that finds the intersection interval   was devised by Keith Marzullo in his doctoral dissertation. It was fi
 rst implemented in the  DTSS (Digital Time Synchronization Service) in the VMS operating system for the VAX.
 <p> While the NTP algorithm is based on DTSS, it remains to establish which point  represents the best estimate of the offset for each candidate.  The best point is at the midpoint <font face="symbol">q<sub>0</sub></font> of the correctness interval; however, the midpoint might not be within the intersection interval. A candidate with a correctness interval  that contains points in the intersection interval is a truechimer and the best offset estimate  is the midpoint of its correctness interval. A candidate with a correctness interval that contains no points in the intersection interval is a falseticker.</p>
 <div align="center"><img src="pic/flt3.gif" alt="gif">
   <p>Figure 1. Intersection Interval</p>

==== html/warp.html ====
2011-12-11 05:55:33-05:00, stenn at deacon.udel.edu +12 -12
  Documentation updates from Dave Mills

--- 1.19/html/warp.html	2011-10-31 15:37:18 -04:00
+++ 1.20/html/warp.html	2011-12-11 05:55:33 -05:00
@@ -9,7 +9,7 @@
 <body>
 <h3>How NTP Works</h3>
 <p>Last update:
-  <!-- #BeginDate format:En2m -->23-Oct-2011  16:21<!-- #EndDate -->
+  <!-- #BeginDate format:En2m -->05-Dec-2011  16:26<!-- #EndDate -->
   UTC</p>
 <h4>Related Links</h4>
 <script type="text/javascript" language="javascript" src="scripts/special.txt"></script>
@@ -26,7 +26,7 @@
 <blockquote>
   <p align="left">Note: This document contains a technical description of the Network Time Protocol (NTP) architecture and operation.  It is intended for  administrators, operators and monitoring personnel. Additional information for nontechnical readers can be found in the white paper <a href="http://www.eecis.udel.edu/~mills/exec.html">Executive Summary: Computer Network Time Synchronization</a>.</p>
 </blockquote>
-<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in mid 2011 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
+<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in late 2011 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
 <p> The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio or telephone modem. Stratum 2 (secondary) servers at the next higher level are synchronized to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice.</p>
 <p>This page presents an overview of the NTP implementation included in this software distribution. We refer to this implementation as the <em>reference implementation</em> only because it was  used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
 <div align="center">
@@ -46,17 +46,17 @@
 <p> The UT1 timescale, upon which UTC is based, is determined by the rotation of the Earth about its axis, which is gradually slowing down. In order to rationalize  UTC with respect to UT1, a  leap second is inserted  at intervals of about 18 months, as determined by the  International Earth Rotation Service (IERS). The historic insertions are documented in the <tt>leap-seconds.list</tt> file, which can be downloaded from the NIST FTP server. This file is updated at intervals not exceeding six months. Leap second warnings are disseminated by the national laboratories in the broadcast timecode format. These warnings are propagated from the NTP primary servers via other server to the clients  by the NTP on-wire protocol. The leap second is implemented by the operating system kernel, as described in  the white  paper <a href="http://www.eecis.udel.edu/~mills/leap.html">The NTP Timescale and Leap Seconds</a>.</p>
 <p>There are two NTP time formats, a 64-bit <em>timestamp</em> format and a 128-bit <em>date</em> format. The date format is used internally, while the timestamp format is used in packet headers exchanged between clients and servers. The timestamp format spans 136 years, called an <em>era</em>. The current era began on 1 January 1900, while  the next one begins in 2036. Details on these formats and conversions between them are  in the white paper <a href="http://www.eecis.udel.edu/~mills/y2k.html">The NTP Era and Era Numbering</a>. However, the NTP protocol will synchronize correctly, regardless of era, as long as  the system clock is set initially within  68 years of the correct time. Further discussion on this issue is in the white paper <a href="http://www.eecis.udel.edu/~mills/time.html">NTP Timestamp Calculations</a>. Ordinarily, these formats are not seen by application programs, which convert these NTP formats to native Unix or Windows formats.</p>
 <h4 id="budget">Statistics Budget</h4>
-<p>Each NTP synchronization source is characterized by the   offset and delay   samples measured by the on-wire protocol using the equations above. The  dispersion  sample is initialized with the sum of the server precision and the client precision as each sample is received. The dispersion increases  at a rate of 15 <font face="symbol">m</font>s/s after that. For this purpose, the precision is equal to the latency to read the system clock. The offset, delay and dispersion are called the <em>sample statistics</em>.</p>
-<p> In a window of eight (offset, delay, dispersion) samples, the clock filter algorithm selects the  sample with  minimum  delay, which generally represents the most accurate offset statistic. The selected sample becomes the <em>peer offset</em> and <em>peer delay </em>statistics. The <em>peer dispersion</em> is  a weighted average of the dispersion samples in the window.  It is recalculated as each sample update is received from the server. Between updates, the dispersion continues to grow at the same  rate as the sample dispersion, 15 <font face="symbol">m</font>s/s. Finally, the <em>peer jitter</em> is determined as the root mean square (RMS)  of  the offset samples in the window relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter  statistics are recorded by the <tt>peerstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. Peer variables are displayed by the <tt>rv</tt> command of the <a href
 ="ntpq.html#peer"><tt>ntpq</tt></a> program.</p>
+<p>Each NTP synchronization source is characterized by the   offset and delay   samples measured by the on-wire protocol using the equations above. The  dispersion  sample is initialized with the sum of the server precision and the client precision as each update is received. The dispersion increases  at a rate of 15 <font face="symbol">m</font>s/s after that. For this purpose, the precision is equal to the latency to read the system clock. The offset, delay and dispersion are called the <em>sample statistics</em>.</p>
+<p> In a window of eight (offset, delay, dispersion) samples, the algorithm described on the  <a href="filter.html">Clock Filter Algorithm</a> page selects the  sample with  minimum  delay, which generally represents the most accurate offset statistic. The selected sample becomes the <em>peer offset</em> and <em>peer delay </em>statistics. The <em>peer dispersion</em> is  a weighted average of the dispersion samples in the window.  These quantities are recalculated as each  update is received from the server. Between updates, both the sample dispersion and  peer dispersion continue to grow at the same  rate, 15 <font face="symbol">m</font>s/s. Finally, the <em>peer jitter</em> is determined as the root mean square (RMS)  of  the offset samples in the window relative to the selected offset sample. The peer    statistics are recorded by the <tt>peerstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. Peer variables are displayed by the <tt>rv</t
 t> command of the <a href="ntpq.html#peer"><tt>ntpq</tt></a> program.</p>
 <p> The clock filter algorithm continues to process packets in this way until the source is no longer reachable. Reachability is determined by an eight-bit shift register, which is shifted left by one bit as each poll packet is sent, with 0 replacing the vacated rightmost bit. Each time an update is received, the rightmost bit is set to 1. The source is considered reachable if any bit is set to 1 in the register; otherwise, it is considered unreachable.</p>
-<p>A server is considered selectable only if it is reachable, the dispersion is below the select threshold and a timing loop would not be created. The select threshold is by default 1.5 s, but can be changed by the <tt>maxdist</tt> option of the <a href="miscopt.html#tos"> <tt>tos</tt></a> command. A timing loop occurs when the server is apparently synchronized to the client or when the server is synchronized to the same server as the client. When a source is unreachable, a  dummy sample with  &quot;infinite&quot; dispersion  is inserted in the shift register at each poll, thus displacing old samples.</p>
-<p>The composition of  the survivor population and the system peer selection is re determined as each update from each source is received. The system variables are copied from the  system peer variables of the same name and the system stratum set one greater than the system peer stratum. System variables are displayed by the <tt>rv</tt> command of the <a href="ntpq.html#system"><tt>ntpq</tt></a> program.</p>
-<p> The system  dispersion  increases at the same rate as the peer dispersion,  even if all sources have become unreachable. The server appears to dependent clients at ever increasing dispersion. If the system dispersion exceeds the select threshold as apparent to dependent clients, the server is considered nonselectable It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.</p>
+<p>A server is considered <em>nonselectable</em>  if it is unreachable,  or the <em>peer synchronization distance</em> abbreviated to <em>peer distance</em> (see below) is above the <em>select threshold,</em> or if a timing loop is present. If none of these conditions exist, the server is considered <em>selectable</em>. The select threshold is by default 1.5 s, but can be changed by the <tt>maxdist</tt> option of the <a href="miscopt.html#tos"> <tt>tos</tt></a> command. A timing loop is presentif the server is  synchronized to the client, which can occur, for example, if they  are configured  in symmetric modes with each other. When a source becomes unreachable, a  dummy sample with  &quot;infinite&quot; dispersion  is inserted in the shift register at each poll, thus displacing old samples. This causes the peeer dispersion, and thus the peer distance, to  increase and eventually to exceed the select threshold.</p>
+<p>The composition of  the survivor population and the system peer selection is re determined as each update from each source is received. The system peer and system variables are determined as described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page.  The system variables are copied from the  system peer variables of the same name and the system stratum set one greater than the system peer stratum. The system    statistics are recorded by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. System variables are displayed by the <tt>rv</tt> command of the <a href="ntpq.html#system"><tt>ntpq</tt></a> program.</p>
+<p> The system synchronization distance, usually called the root distance, is defined as half the system peer delay plus the system peer dispersion. Between updates it increases at the same rate as the system  peer dispersion,  even if all sources have become unselectable.  If the server root distance  exceeds the client select threshold, as apparent to dependent clients, the server is considered nonselectable. It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.</p>
 <h4 id="quality">Quality of Service</h4>
-<p>The mitigation algorithms deliver several important statistics, including <em>system offset</em> and <em>system jitter</em>. These statistics are determined by the mitigation algorithms from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</p>
-<p>Of interest in this discussion is how the client determines the quality of service from a particular reference clock or remote server. This is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error, or  system jitter, is determined from various jitter components; it represents the nominal error in determining the mean clock offset. </p>
-<p>Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called <em>synchronization distance</em>. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettime()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
-<p>The maximum error  is  computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>.   The root variables are included in the NTP packet header received from each server. When calculating  maximum error, the  root delay is the sum of the root delay in the packet and the peer  delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.</p>
+<p>The  algorithms described on  the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page deliver several important statistics, including <em>system offset</em> and <em>system jitter</em>. These statistics are determined by the mitigation algorithms from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum-likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate.</p>
+<p>Of interest in the following discussion is how the client determines these statistics  from a survivor population including reference clocks and remote servers. This is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error, also called system jitter, is determined from various jitter components; it represents the nominal error in determining the  clock offset. </p>
+<p>Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called system synchronization distance or root distance. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettime()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
+<p>The maximum error statistic is  computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>.   The root variables are included in the NTP packet header received from each server. When calculating  maximum error, the  root delay is the sum of the root delay in the packet and the peer  delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.</p>
 <p>A source is considered selectable only if its maximum error is less than the <em>select threshold</em>, by default 1.5 s, but can be changed according to client preference using the <tt>maxdist</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command. A common  consequence is when an upstream server loses all sources and its maximum error apparent to dependent clients begins to increase. The clients are not aware of  this condition and  continue to accept synchronization as long as the maximum error is less than the select threshold.</p>
 <p>Although it might seem counterintuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm,  older samples are no longer selectable. This applies also to the clock select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. The reason for these rules is to limit the time delay in the  clock discipline algorithm. This is necessary to  preserve the optimum impulse response and thus the risetime and overshoot.</p>
 <p>This means that not every sample can be used to update the peer variables, and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration for feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.</p>
@@ -66,7 +66,7 @@
 <p>When the client is  restarted after a period when the power is off, the clock  may  have significant error. The provisions described in this section insure that, in all but pathological situations, the startup transient is suppressed to within nominal levels in no more than five minutes after a warm start or ten minutes after a cold start. Following is a summary of these procedures. A detailed discussion of these procedures is on the <a href="clock.html">Clock State Machine</a> page.</p>
 <p>  The reference implementation   measures the clock oscillator frequency  and updates a frequency  file  at intervals of one hour or more, depending on the measured frequency wander. This design is intended to minimize  write cycles in NVRAM that might  be used in a laptop or portable device. In a warm start, the frequency is initialized from this file, which avoids a possibly lengthy discipline time. In a cold start when no frequency file is available, the reference implementation first measures the   oscillator frequency  over a five-min interval. This generally results in a residual frequency error of less than  1 PPM. The measurement interval can be changed using the <tt>stepout</tt> option of the <a href="miscopt.html#tinker"><tt>tinker</tt></a> command.</p>
 <p>In order to further reduce the  clock offset error at restart, the reference implementation  mext disables oscillator frequency discipline and enables clock offset discipline with a small time constant. This  is designed to quickly reduce the clock offset error without causing a frequency surge. This configuration is continued for an interval of five-min, after which the  clock offset error is usually  no more than a millisecond. The  measurement interval can be changed using the <tt>stepout</tt> option of the <a href="miscopt.html#tinker"><tt>tinker</tt></a> command.</p>
-<p>Another  concern at  restart is the  time necessary for  the selection and clustering algorithms to refine and validate the initial  clock offset estimate. Normally, this takes several updates before setting the system clock. As the default minimum poll interval in most configurations is about one minute, it can take several minutes before setting the system clock. The <tt>iburst</tt> option of the <a href="confopt.html#burst"><tt>server</tt></a> command  changes the behavior at restart and is    recommended for client/server configurations.  When this option is enabled, the client  sends a volley of six requests at intervals of two seconds. This insures a reliable estimate is available in about ten seconds before setting the clock. Once this initial volley is complete, the procedures described above are executed.</p>
+<p>Another  concern at  restart is the  time necessary for  the select and cluster algorithms to refine and validate the initial  clock offset estimate. Normally, this takes several updates before setting the system clock. As the default minimum poll interval in most configurations is about one minute, it can take several minutes before setting the system clock. The <tt>iburst</tt> option of the <a href="confopt.html#burst"><tt>server</tt></a> command  changes the behavior at restart and is    recommended for client/server configurations.  When this option is enabled, the client  sends a volley of six requests at intervals of two seconds. This insures a reliable estimate is available in about ten seconds before setting the clock. Once this initial volley is complete, the procedures described above are executed.</p>
 <p>As a result of the above considerations, when a backup source, such as the local clock driver, ACTS modem driver or orphan mode is included in the system configuration, it may happen that one or more of them are selectable before one or more of the  regular sources are selectable. When backup sources are included in the configuration, the  reference implementation waits an interval of several minutes without regular sources before switching to backup sources. This is generally enough to avoid startup transients due to premature switching to backup sources. The interval can be changed using the <tt>orphanwait</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command.</p>
 <hr>
 <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>


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