<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 -->25-Sep-2010 3:35<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->29-Oct-2010 19:45<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<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 specified by the <tt>tos</tt> 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 <tt>tos</tt> 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 of if the source is synchronized to the same source as the client.</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 an intersection algorithm to select the truechimers from
among the candidates, leaving behind the falsetickers. A server or peer configured
with the <tt>true</tt> option is ipso facto a truechimer independent of this
algorithm. Phase four uses a clustering algorithm to cast off statistical outliers
- from the truechimers until a set of survivors not less than the number specified
- as the <tt>minclock</tt> option of the <tt>tos</tt> command, with default 3.</p>
-<p> Phase five uses a set of algorithms and mitigation rules to rank the survivors to prodce combined statistics used to discipline the clock, as well as to select from among the survivors
+ from the truechimers until a set 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 <tt>tos</tt> command.</p>
+<p> Phase five uses a set of algorithms and mitigation rules to rank the survivors to produce combined statistics used to discipline the clock, as well as to select from among the survivors
a system peer from which a set of system statistics can be inherited and passed
- along to a dependent client population. The algorithms and rules are the main toopic of this page. The clock offset developed from these
+ along to a dependent client population. 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 <tt>ntpd</tt> clock
discipline algorithm 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.
Phase five is the topic of this page.</p>
<h4 id="combine">Combine Algorithm</h4>
<p>The cluster algorithm produces a list of survivors ranked by increasing synchronization distance. The combine algorithm uses this list to produce a weighted average of both offset and jitter. Absent other considerations discussed later, the combined offset is used to discipline the clock, while the combined jitter is combined with other components to produce the system jitter statistic inherited by dependent clients.</p>
-<p>The combine algorithm uses a weight factor for each survivor computed as the select threshold minus the synchronization distance. Since the select algorithm refects candidates with synchronization distance greater than the select threshold, the weight factor is always positive. The system jitter is calculated as the RMS weighted differences between the offset of each survivor and the offset of the first candidate on the survivor list. </p>
-<h4 id="clockhop">Anti-Clockhp Algorityhm</h4>
-<p>Generally speaking, the best candidate for the system peer is the first candidate on the survivor list, as this has the smallest synchronization distance. However, it can cause some trauma in downstream clients when the system peer is changed frequectly, so some care is taken to insure that a change does not occur, unless to do so would materially improve quality. Frequently when there are two or more servers avaialbe with substantially the same synchronization distance, one or another will show up at the head of the survivor list followed closely by the others of substantially the same distance. The object of the anti-clockhop algorithm is to avoid reselecting the system peer unless it becomes stale or significally worse than the candidate at the head of the list.</p>
-<p>Previously, the algorithm has remembered the last selected system peer or whether there was none. In addition, the algorithm has initialized the anticlockhop threshold with the value of the mindisp statistic, by default 1 ms. To help compact this duscussion, we will call the last selected systm peer the <em>old peer</em>, and the peer at the head of the survivor peer the <em>candidate peer</em>. 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 candidate peer. If the difference exceeds the anticlockhop threshold, the candidate peer becomes the system peer and the anticlochop threshold restored to its original value. If not, the old peer continues as the system peer. However, at each subsequent call, the algorithm reduces the anticlockhop threshold by half. Should operation continue in this way, the canddate peer will eventually become the system peer.</p>
-<p>The anti-clockhop algorithm is most effective in cases where multiple primary servers are available on fast LANs with modern computers. Typical offset differences in such cases are less than 0.5 ms and clockhops are much less frequent than if the algorithm is not used..</p>
+<p>The 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. The system jitter is calculated as the RMS weighted differences between the offset of each survivor and the offset of the first candidate on the survivor list. </p>
+<h4 id="clockhop">Anti-Clockhop Algorithm</h4>
+<p>Generally speaking, the best candidate for the system peer is the first candidate on the survivor list, as this has the smallest synchronization distance. However, it can cause some trauma in downstream clients when the system peer is changed frequently, so some care is taken to insure that a change does not occur, unless to do so would materially improve quality. Frequently when there are two or more servers available with substantially the same synchronization distance, one or another will show up at the head of the survivor list followed closely by the others of substantially the same distance. The object of the anti-clockhop algorithm is to avoid reselecting the system peer unless it becomes stale or significantly worse than the candidate at the head of the list.</p>
+<p>Previously, the algorithm has remembered the last selected system peer or whether there was none. In addition, the algorithm has initialized the anti-clockhop threshold with the value of the <tt>mindist</tt> statistic, by default 1 ms. 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 peer the <em>candidate peer</em>. 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 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 most effective in cases where multiple primary servers are available on fast LANs with modern computers. Typical offset differences in such cases are less than 0.5 ms and clockhops are much less frequent than if the algorithm is not used.</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>If all sources have been lost and the orphan stratum has been specified by the <tt>orphan</tt> option of the <tt>tos</tt> command, a pseudo-source called the <i>orphan parent</i> is created with offset and jitter both zero. Dependent orphan children will see the orphan parent as if synchronized to a server at the orphan stratum.If the only survivor is the orphan parent, it becomes the system peer and its clock offset and jitter are inherited by the corresponding system variables. Note that by design 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 operated as a PPS driver as well. The PPS driver provides precision clock discipline only within +-0.5 s, so is always associated with another source or sources that provide the seconds numbering function.</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 operated as a PPS driver as well. The PPS driver provides precision clock discipline only within ±0.4 s, so 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>lockclock</tt> scheme, or another synchronization protocol such as the 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 (only) primary source.</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 survivors of different types. When used with the <tt>server</tt> or <tt>peer</tt> commands, the <tt>prefer</tt> option designates one or more survivors 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; that is, if the first one becomes unselectable, 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>
<p>The clustering algorithm works on the set of truechimers produced by the intersection algorithms. Ordinarily, any one of them can in principle provide correct time; however, due to various latency variations, not all can provide the most accurate and stable time. The clustering algorithm, processes the truechimers in one or more rounds to cast off a statistical outlier until no more than the <tt>minclock</tt> option of the <tt>tos</tt> command are left. The default for this option is 3.</p>
-<p>In the prefer scheme the clustering algorithm is modified so that the prefer peer is never discarded; on the contrary, its potential removal becomes a rounds-termination condition. However, the prefer peer can still be discarded by the intersection algorithm as a falseticker. To avoid this, it is usually wise to increase the <tt>mindist</tt> option of the <tt>tos</tt> command from the default .005 s to something like .05 s.</p>
+<p>In the prefer scheme the cluster algorithm is modified so that the prefer peer is never discarded; on the contrary, its potential removal becomes a rounds-termination condition. However, the prefer peer can still be discarded by the intersection algorithm as a falseticker. To avoid this, it is usually wise to increase the <tt>mindist</tt> option of the <tt>tos</tt> command from the default .005 s to something like .05 s.</p>
<p>Ordinarily, the combining algorithm computes a weighted average of the survivor
offsets to produce the final synchronization source. However, if a prefer
peer is among the survivors, the combining algorithm is not used. Instead,
signal, the GPS driver is designated the PPS driver and the PPS signal disciplines
the system clock. If no GPS satellites are in view, or if the PPS signal is
disconnected, the GPS driver stops updating the system clock and so eventually
- becomes unreachable and replaced by other sources..</p>
+ becomes unreachable and replaced by other sources.</p>
<p>Whether or not the GPS driver disables the PPS signal when unreachable is
at the discretion of the driver. Ordinarily, the PPS signal would be disabled in this case; however, When the GPS receiver has a precision holdover oscillator, the driver may elect to continue PPS operation. In this case the PPS signal continues to discipline the system clock.</p>
<p> </p>
projects / thirdparty / ntp.git / commitdiff
