diff options
Diffstat (limited to 'html/prefer.html')
| -rw-r--r-- | html/prefer.html | 221 |
1 files changed, 155 insertions, 66 deletions
diff --git a/html/prefer.html b/html/prefer.html index 00225d1dbbdb..67a6816cf3e6 100644 --- a/html/prefer.html +++ b/html/prefer.html @@ -1,72 +1,161 @@ <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> - <html> +<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> +<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 -->22-Apr-2009 14:04<!-- #EndDate --> +UTC</p> +<br clear="left"> + +<h4>Related Links</h4> + +<script type="text/javascript" language="javascript" src="scripts/misc.txt"></script> + +<h4>Table of Contents</h4> + +<ul> + +<li class="inline"><a href="#intro">Introduction</a></li> +<li class="inline"><a href="#peer">Peer Classification</a></li> +<li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a></li> +<li class="inline"><a href="#miti">Mitigation Rules</a></li> +<li class="inline"><a href="#mins">The <tt>minsane</tt> Option</a></li> + +</ul> + +<hr> + +<h4 id="intro">Introduction</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. Phase two grooms the selectable candidates 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 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>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. + Phase five uses a set of mitigation rules 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 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="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 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>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, + the offset of the prefer peer is used exclusively as the final synchronization + source. In the common case involving a radio clock and a flock of remote backup + servers, and with the radio clock designated a prefer peer, the result is that + the radio clock normally disciplines the system clock as long as the radio itself + 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 selection 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, a 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 intersection to produce a possibly empty set of truechimers. The clustering algorithm ranks the truechimers first by stratum then by synchronization distance and designates the survivor with the lowest distance as the potential 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 combining algorithm and is mitigated separately.</p> + +<p>At this point we have the following contributors to the system clock discipline:</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> +</ul> + +<p>The mitigation algorithm proceeds in three steps in turn.</p> + +<ol> + +<li>If there are no survivors, the modem driver becomes the only survivor if there is one. If not, the local driver becomes the only survivor if there is one. If not, the orphan parent becomes the only survivor if there is one. If the number of survivors at this point is less than the <tt>minsane</tt> option of the <tt>tos</tt> command, the algorithm is terminated and the system variables remain unchanged. Note that <tt>minsane</tt> is by default 1, but can be set at any value including 0.</li> + +<li>If the prefer peer is among the survivors, it becomes the system peer and its clock offset and jitter are inherited by the corresponding system variables. Otherwise, the combining algorithm computes these variables from the survivor population.</li> + +<li>If there is a PPS driver and the system clock offset at this point is less than 0.4 s, and if there is a prefer peer among the survivors or if the PPS peer is designated as a prefer peer, the PPS driver becomes the system peer and its offset and jitter are inherited by the system variables, thus overriding any variables already computed. Note that a PPS driver is present only if PPS signals are actually being received and enabled by the associated driver.</li> + +</ol> + +<p>If none of the above is the case, the data are disregarded and the system variables remain as they are.</p> + +<h4 id="mins">The <tt>minsane</tt> Option</H4> + +<p> The <tt>minsane</tt> option of the <tt>tos</tt> command, the <tt>prefer</tt> option of the <tt>server</tt> and <tt>peer</tt> commands and the <tt>flag</tt> options of the <tt>fudge</tt> command for the PPS driver can be used with the mitigation rules to provide many useful configurations. The <tt>minsane</tt> option specifies the minimum number of survivors required to synchronized the system clock. The <tt>prefer</tt> option designates the prefer peer. The driver-dependent <tt>flag</tt> options enable the PPS driver for various conditions.</p> + +<p>A common scenario is a GPS driver with a serial timecode and PPS signal. The + PPS signal is disabled until the system clock has been set by some means, not + necessarily the GPS driver. If the serial timecode is within 0.4 s of the PPS + 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> + +<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> - <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> - - <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: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:49</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p> - <br clear="left"> - <h4>Related Links</h4> - <script type="text/javascript" language="javascript" src="scripts/links10.txt"></script> - <h4>Table of Contents</h4> - <ul> - <li class="inline"><a href="#intro">Introduction</a> - <li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a> - <li class="inline"><a href="#peer">Peer Classification</a> - <li class="inline"><a href="#miti">Mitigation Rules</a> - <li class="inline"><a href="#pps">Using the Pulse-per-Second (PPS) Signal</a> - </ul> - <hr> - <h4 id="intro">Introduction</h4> - <p>The mechanics of the NTP algorithms which select the best data sample from each available server and the best subset of the server population have been finely crafted to resist network jitter, faults in the network or server operations, and to deliver the best possible accuracy. Most of the time these algorithms do a good job without requiring explicit manual tailoring of the configuration file. However, there are times when the accuracy can be improved by some careful tailoring. The following sections explain how to do this using explicit configuration items and special signals, when available, that are generated by some radio clocks and laboratory instruments.</p> - <p>In order to provide robust backup sources, primary (stratum-1) servers are usually operated in a diversity configuration, in which the server operates with a number of remote servers in addition to one or more radio or modem clocks. In these configurations the suite of algorithms used in NTP to refine the data from each peer separately and to select and combine the data from a number of servers and clocks. As the result of these algorithms, a set of <i>survivors</i> are identified which can presumably provide the most reliable and accurate time. Ordinarily, the individual clock offsets of the survivors are combined on a weighted average basis to produce an offset used to control the system clock.</p> - <p>However, because of small but significant systematic time offsets between the survivors, it is in general not possible to achieve the lowest jitter and highest stability in these configurations. This happens because the selection algorithm tends to <i>clockhop</i> between survivors of substantially the same quality, but showing small systematic offsets between them. In addition, there are a number of configurations involving pulse-per-second (PPS) signals, modem backup services and other special cases, so that a set of mitigation rules becomes necessary to select a single peer from among the survivors. These rules are based on a set of special characteristics of the various remote servers and reference clock drivers specified in the configuration file.</p> - <h4 id="prefer">The <tt>prefer</tt> Peer</h4> - <p>The mitigation rules are designed to provide an intelligent selection between various sources of substantially the same statistical quality without compromising the normal operation of the NTP algorithms. While they have been implemented in NTP Version 4 and will be incorporated in the NTP Version 4 specification when published, they are not in the NTP Version 3 specification RFC-1305. The rules are based on the concept of <i>prefer peer</i>, which is specified by including the <tt>prefer</tt> keyword with the associated <tt>server</tt> or <tt>peer</tt> command in the configuration file. This keyword can be used with any server or peer, but is most commonly used with a radio clock. While the rules do not forbid it, it does not seem useful to designate more than one peer as preferred, since the additional complexities to mitigate among them do not seem justified from on-air experience.</p> - <p>The prefer scheme works on the set of peers that have survived the sanity checks and intersection algorithms of the clock selection procedures. Ordinarily, the members of this set can be considered <i>truechimers</i> and any one of them could in principle provide correct time; however, due to various error contributions, not all can provide the most accurate and stable time. The job of the clustering algorithm, which is invoked at this point, is to select the best subset of the survivors providing the least variance in the combined ensemble average, compared to the variance in each member of the subset separately. The detailed operation of the clustering algorithm, which is given in RFC-1305, is beyond the scope of discussion here. It operates in rounds, where a survivor, presumably the worst of the lot, is discarded in each round until one of several termination conditions is met. An example terminating condition is when the number of survivors is about to be reduced below three.</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 termination condition. If the original algorithm were about to toss out the prefer peer, the algorithm terminates immediately. The prefer peer can still be discarded by the sanity checks and intersection algorithm, of course, but it will always survive the clustering algorithm. If it does not survive or for some reason it fails to provide updates, it will eventually become unreachable and the clock selection will remitigate to select the next best source.</p> - <p>Along with this behavior, the clock selection procedures are modified so that the combining algorithm is not used when a prefer peer is present. Instead, the offset of the prefer peer is used exclusively as the synchronization source. In the usual case involving a radio clock and a flock of remote stratum-1 peers, and with the radio clock designated a prefer peer, the result is that the high quality radio time disciplines the server clock as long as the radio itself remains operational and with valid time, as determined from the remote peers, sanity checks and intersection algorithm.</p> - <h4 id="peer">Peer Classification</h4> - <p>In order to understand the effects of the various intricate schemes involved, it is necessary to understand some arcane details on how the algorithms decide on a synchronization source when more than one source is available. This is done on the basis of a set of explicit mitigation rules, which define special classes of remote serves and local radio clocks as a function of configuration declarations and clock driver type:</p> - <ol> - <li>The prefer peer is designated using the <tt>prefer</tt> keyword with the <tt>server</tt> or <tt>peer</tt> commands. All other things being equal, this peer will be selected for synchronization over all other survivors of the clock selection procedures. - <li>When a PPS signal is connected via the PPS Clock Discipline driver (type 22), this is called the <i>PPS peer</i>. This driver provides precision clock corrections only within one second, so is always operated in conjunction with another server or radio clock driver, which provides the seconds numbering. The PPS peer is active only under conditions explained below. - <li>When the Undisciplined Local Clock driver (type 1) is configured, this is called the <i>local clock peer</i>. This is used either as a backup reference source (stratum greater than zero), should all other synchronization sources fail, or as the primary reference 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>When a modem driver such as the Automated Computer Time Service driver (type 18) is configured, this is called the <i>modem peer</i>. This is used either as a backup reference source, should all other primary sources fail, or as the (only) primary reference source. - <li>Where support is available, the PPS signal may be processed directly by the kernel, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. This is called the <i>kernel discipline</i>. The PPS signal can discipline the kernel in both frequency and time. The frequency discipline is active as long as the PPS interface device and signal itself is operating correctly, as determined by the kernel algorithms. The time discipline is active only under conditions explained below. - </ol> - <p>Reference clock drivers operate in the manner described in the <a href="refclock.html">Reference Clock Drivers</a> page and its dependencies. The drivers are ordinarily operated at stratum zero, so that as the result of ordinary NTP operations, the server itself operates at stratum one, as required by the NTP specification. In some cases described below, the driver is intentionally operated at an elevated stratum, so that it will be selected only if no other survivor is present with a lower stratum. In the case of the PPS peer or kernel time discipline, these sources appear active only if the prefer peer has survived the intersection and clustering algorithms, as described below, and its clock offset relative to the current local clock is less than a specified value, currently 128 ms.</p> - <p>The modem clock drivers are a special case. Ordinarily, the update interval between modem calls to synchronize the system clock is many times longer than the interval between polls of either a remote server or local radio clock. In order to provide the best stability, the operation of the clock discipline algorithm changes gradually from a phase-lock mode at the shorter update intervals to a frequency-lock mode at the longer update intervals. If remote servers or local radio clocks together with a modem peer operate in the same client, the following things can happen.</p> - <p>First the clock selection algorithm can select one or more remote servers or local radio clocks and the clock discipline algorithm will optimize for the shorter update intervals. Then, the selection algorithm can select the modem peer, which requires a much different optimization. The intent in the design is to allow the modem peer to control the system clock either when no other source is available or, if the modem peer happens to be marked as prefer, then it always controls the clock, as long as it passes the sanity checks and intersection algorithm. There still is room for suboptimal operation in this scheme, since a noise spike can still cause a clockhop either way. Nevertheless, the optimization function is slow to adapt, so that a clockhop or two does not cause much harm.</p> - <p>The local clock driver is another special case. Normally, this driver is eligible for selection only if no other source is available. When selected, vernier adjustments introduced via the configuration file or remotely using the <tt><a href="ntpdc.html">ntpdc</a> </tt>program can be used to trim the local clock frequency and time. However, if the local clock driver is designated the prefer peer, this driver is always selected and all other sources are ignored. This behavior is intended for use when the kernel time is controlled by some means external to NTP, such as the NIST <tt>lockclock</tt> algorithm or another time synchronization protocol such as DTSS. In this case the only way to disable the local clock driver is to mark it unsynchronized using the leap indicator bits. In the case of modified kernels with the <tt>ntp_adjtime()</tt> system call, this can be done automatically if the external synchronization protocol uses it to discipline the kernel time.</p> - <h4 id="miti">Mitigation Rules</h4> - <p>The mitigation rules apply in the intersection and clustering algorithms described in the NTP specification. The intersection algorithm first scans all peers with a persistent association and includes only those that satisfy specified sanity checks. In addition to the checks required by the specification, the mitigation rules require either the local-clock peer or modem peer to be included only if marked as the prefer peer. The intersection algorithm operates on the included population to select only those peers believed to represent the correct time. If one or more peers survive the algorithm, processing continues in the clustering algorithm. Otherwise, if there is a modem peer, it is declared the only survivor; otherwise, if there is a local-clock peer, it is declared the only survivor. Processing then continues in the clustering algorithm.</p> - <p>The clustering algorithm repeatedly discards outlyers in order to reduce the residual jitter in the survivor population. As required by the NTP specification, these operations continue until either a specified minimum number of survivors remain or the minimum select dispersion of the population is greater than the maximum peer dispersion of any member. The mitigation rules require an additional terminating condition which stops these operations at the point where the prefer peer is about to be discarded.</p> - <p>The mitigation rules establish the choice of <i>system peer</i>, which determines the stratum, reference identifier and several other system variables which are visible to clients of the server. In addition, they establish which source or combination of sources control the local clock.</p> - <ol> - <li>If there is a prefer peer and it is the local-clock peer or the modem peer; or, if there is a prefer peer and the kernel time discipline is active, choose the prefer peer as the system peer and its offset as the system clock offset. If the prefer peer is the local-clock peer, an offset can be calculated by the driver to produce a frequency offset in order to correct for systematic frequency errors. In case a source other than NTP is controlling the system clock, corrections determined by NTP can be ignored by using the <tt>disable pll</tt> in the configuration file. If the prefer peer is the modem peer, it must be the primary source for the reasons noted above. If the kernel time discipline is active, the system clock offset is ignored and the corrections handled directly by the kernel. - <li>If the above is not the case and there is a PPS peer, then choose it as the system peer and its offset as the system clock offset. - <li>If the above is not the case and there is a prefer peer (not the local-clock or modem peer in this case), then choose it as the system peer and its offset as the system clock offset. - <li>If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to clockhopping, when switching the system peer would not materially improve the time accuracy. - <li>If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification. - </ol> - <h4 id="pps">Using the Pulse-per-Second (PPS) Signal</h4> - <p>Most radio clocks are connected using a serial port operating at speeds of 9600 bps or higher. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character, like carriage-return <tt><cr></tt>, is limited to a millisecond or two. However, some radios produce a PPS signal which can be used to improve the accuracy with typical workstation servers to the order of microseconds. The details of how this can be accomplished are discussed in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The following paragraphs discuss how the PPS signal is affected by the mitigation rules.</p> - <p>First, it should be pointed out that the PPS signal is inherently ambiguous, in that it provides a precise seconds epoch, but does not provide a way to number the seconds. In principle and most commonly, another source of synchronization, either the timecode from an associated radio clock, or even one or more remote NTP servers, is available to perform that function. In all cases, a specific, configured peer or server must be designated as associated with the PPS signal. This is done using the <tt>prefer</tt> keyword as described previously. The PPS signal can be associated in this way with any peer, but is most commonly used with the radio clock generating the PPS signal.</p> - <p>The PPS signal can be used in two ways to discipline the local clock, one using a special PPS driver described in the <a href="drivers/driver22.html">PPS Clock Discipline</a> page, the other using PPS signal support in the kernel, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. In either case, the signal must be present and within nominal jitter and wander error tolerances. In addition, the associated prefer peer must have survived the sanity checks and intersection algorithms and the dispersion settled below 1 s. This insures that the radio clock hardware is operating correctly and that, presumably, the PPS signal is operating correctly as well. Second, the absolute offset of the local clock from that peer must be less than 128 ms, or well within the 0.5-s unambiguous range of the PPS signal itself. In the case of the PPS driver, the time offsets generated from the PPS signal are propagated via the clock filter to the clock selection procedures just like any other peer. Should these pass the sanity checks and intersection algorithms, they will show up along with the offsets of the prefer peer itself. Note that, unlike the prefer peer, the PPS peer samples are not protected from discard by the clustering algorithm. These complicated procedures insure that the PPS offsets developed in this way are the most accurate, reliable available for synchronization.</p> - <p>The PPS peer remains active as long as it survives the intersection algorithm and the prefer peer is reachable; however, like any other clock driver, it runs a reachability algorithm on the PPS signal itself. If for some reason the signal fails or displays gross errors, the PPS peer will either become unreachable or stray out of the survivor population. In this case the clock selection remitigates as described above.</p> - <p>When kernel support for the PPS signal is available, the PPS signal is interfaced to the kernel serial driver code via a modem control lead. As the PPS signal is derived from external equipment, cables, etc., which sometimes fail, a good deal of error checking is done in the kernel to detect signal failure and excessive noise. The way in which the mitigation rules affect the kernel discipline is as follows.</p> - <p>PPS support requires the PPS driver (type 22) and PPSAPI interface described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. In order to operate, the prefer peer must be designated and the kernel support enabled by the <tt>enable pps</tt> command in the configuration file and the signal must be present and within nominal jitter and wander error tolerances. In the NTP daemon, the PPS discipline is active only when the prefer peer is among the survivors of the clustering algorithm, and its absolute offset is within 128 ms, as determined by the PPS driver. Under these conditions the kernel disregards updates produced by the NTP daemon and uses its internal PPS source instead. The kernel maintains a watchdog timer for the PPS signal; if the signal has not been heard or is out of tolerance for more than some interval, currently two minutes, the kernel discipline is declared inoperable and operation continues as if it were not present.</p> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> +<hr> +<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> </body> </html>
\ No newline at end of file |