</div>
<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field. The key can be change to a password, such as <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</p>
<p>When <tt>ntpd</tt> is started, it reads the keys file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
-<h4 id="windows">Microsoft Windows Authentication</h4>
-<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="accopt.html#restrict">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
+<h4>Microsoft Windows Authentication</h4>
+<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="authopt.html">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
<h4 id="pub">Public Key Cryptography</h4>
<p>See the <a href="autokey.html">Autokey Public-Key Authentication</a> page.</p>
<hr>
<em></em>
<h3>Clock Cluster Algorithm</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->03-Dec-2011 14:58<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->13-Apr-2012 16:35<!-- #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 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>
+<p>The clock cluster algorithm processes the truechimers produced by the clock select algorithm to produce a list of <em>survivors</em>. 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 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 θ(<em>i</em>), be the offset and λ(<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>
+ <p><em>d<sub>i</sub></em>(<em>j</em>) = |θ(<em>j</em>) − θ(<em>i</em>)| λ(<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> where θ(<em>i)</em> is the peer offset of the <em>i</em>th entry and θ(<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 φ<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 φ<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 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> > <font face="symbol">j</font><sub><em>min</em></sub>, select jitter dominates peer jitter,the algorithm prunes candidate 1. 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> < <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>
+<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 φ<sub><em>max</em></sub> be the maximum select jitter and φ<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 φ<sub><em>max</em></sub> = φ<sub>S</sub>(1). Candidate 4 has the lowest peer jitter, so φ<sub><em>min</em></sub> = φ<sub>R</sub>(4). Since φ<sub><em>max</em></sub> > φ<sub><em>min</em></sub>, select jitter dominates peer jitter,the algorithm prunes candidate 1. In (b), φ<sub><em>max</em></sub> = φ<sub>S</sub>(3) and φ<sub><em>min </em></sub>=φ<sub>R</sub>(4). Since φ<sub><em>max</em></sub> < φ<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 λ 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>
<body>
<h3>Clock Discipline Algorithm</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->02-Nov-2011 6:39<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->19-Apr-2012 17:30<!-- #EndDate -->
UTC</p>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">General Overview</a></li>
<li class="inline"><a href="#pll">Phase-Lock Loop Operations</a></li>
<li class="inline"><a href="#loop">Loop Dynamics</a></li>
+ <li class="inline"><a href="#house">Clock Initialization and Management</a></li>
</ul>
<hr>
<h4 id="intro">General Overview</h4>
<h4 id="pll">Clock Discipline Operations</h4>
<p>A block diagram of the clock discipline is shown in Figure 1. The timestamp of a reference clock or remote server is compared with the timestamp of the system clock, represented as a variable frequency oscillator (VFO), to produce a raw offset sample <em>V<sub>d</sub></em>. Offset samples are processed by the clock filter to produce a filtered update <em>V<sub>s</sub></em>. The loop filter implements a type-2 proportional-integrator controller (PIC). The PIC can minimize errors in both time and frequency using predictors <em>x</em> and <em>y</em>, respectively. The clock adjust process samples these predictors once each second for the daemon discipline or once each tick interrupt for the kernel discipline to produce the system clock update <em>V<sub>c</sub></em>.</p>
<p>In PLL mode the frequency predictor is an integral of the offset over past updates, while the phase predictor is the offset amortized over time in order to avoid setting the clock backward. In FLL mode the phase predictor is not used, while the frequency predictor is similar to the NIST <em>lockclock</em> algorithm. In this algorithm, the frequency predictor is computed as a fraction of the current offset divided by the time since the last update in order to minimize the offset at the next update.</p>
-<p>The discipline response in PLL mode is determined by the <em>time constant</em>, which results in a "stiffness" depending on the jitter of the available sources and the wander of the system clock oscillator. The scaled time constant is also used as the poll interval by the poll processes. However, in NTP symmetric mode, each peer manages its own poll interval and the two might not be the same. In such cases either peer uses the minimum of its own poll interval and that of the other peer, which is included in the NTP packet header.</p>
+<p>The discipline response in PLL mode is determined by the <em>time constant</em>, which results in a "stiffness" depending on the jitter of the available sources and the wander of the system clock oscillator. The scaled time constant is also used as the poll interval described on the <a href="poll.html">Poll Program</a> page. However, in NTP symmetric mode, each peer manages its own poll interval and the two might not be the same. In such cases either peer uses the minimum of its own poll interval and that of the other peer, which is included in the NTP packet header.</p>
<h4 id="loop">Loop Dynamics</h4>
-<p> It is necessary to verify the PLL is stable and satisfies the Nyquist criterion, which requires that the sampling rate be at least twice the bandwidth. In this case the bandwidth can be approximated by the reciprocal of the time constant. At a poll exponent of 6, the poll interval is 64 s and the time constant 2048 s. The Nyquist criterion requires the sample interval to be not more than half the time constant or 1024 s. The clock filter guarantees at least one sample in eight poll intervals, so the sample interval is not more than 512 s. This would be described as oversampling by a factor of two. Finally, the PLL parameters have been chosen for a damping factor of 2, which results in a much faster risetime than with critical damping, but results in modest overshoot of 6 percent.</p>
+<p> It is necessary to verify that the clock discipline algorithm is stable and satisfies the Nyquist criterion, which requires that the sampling rate be at least twice the bandwidth. In this case the bandwidth can be approximated by the reciprocal of the time constant. In the NTP specification and reference implementation, time constants and poll intervals are expressed as exponents of 2. By construction, the time constant exponent is five times the poll interval exponent. Thus, the default poll exponent of 6 corresponds to a poll interval of 64 s and a time constant of 2048 s. A change in the poll interval changes the time constant by a corresponding amount.. The Nyquist criterion requires the sample interval to be not more than half the time constant or 1024 s. The clock filter guarantees at least one sample in eight poll intervals, so the sample interval is not more than 512 s. This would be described as oversampling by a factor of two. Finally, the PLL parameters have been chosen for a damping factor of 2, which results in a much faster risetime than with critical damping, but results in modest overshoot of 6 percent.</p>
<p> It is important to understand how the dynamics of the PLL are affected by the time constant and poll interval. At the default poll interval of 64 s and a step offset change of 100 ms, the time response crosses zero in about 50 min and overshoots about 6 ms, as per design. Ordinarily, a step correction would causes a temporary frequency surge of about 5 PPM, which along with the overshoot slowly dissipates over a few hours.</p>
-<p>However, the clock state machine used with the discipline algorithm avoids this transient at startup. It does this using a previously saved frequency file, if present, or by measuring the oscillator frequency, if not. It then quickly amortizes the residual offset at startup without affecting the oscillator frequency. In this way the offset error is less than 0.5 ms within 5 min
if the file is present and within 10 min if not. See the <a href="clock.html">Clock State Machine</a> page for further details.</p>
+<p>However, the clock state machine used with the discipline algorithm avoids this transient at startup. It does this using a previously saved frequency file, if present, or by measuring the oscillator frequency, if not. It then quickly amortizes the residual offset at startup without affecting the oscillator frequency. In this way the offset error is less than 0.5 ms within 5 min
, if the file is present, and within 10 min if not. See the <a href="clock.html">Clock State Machine</a> page for further details.</p>
<p>Since the PLL is linear, the response with different offset step amplitudes and poll intervals has the same characteristic shape, but scaled differently in amplitude and time. The response scales exactly with step amplitude, so that the response to a 10-ms step has the same shape as at 64 s, but with amplitude compressed by one-tenth. The response scales exactly with poll interval, so that response at a poll interval of 8 s has the same shape as at 64 s, but with time compressed by one-eighth.</p>
-<p>In the NTP specification and reference implementation, poll intervals are expressed as exponents of 2. The clock discipline time constant is proportional to the poll interval by a factor of 32. Thus, a poll exponent of 6 corresponds to a poll interval of 64 s and a time constant of 2048 s. A change in the poll interval changes the time constant by a corresponding amount.</p>
-<p> The optimum time constant, and thus the poll interval, depends on the network time jitter and the oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. For typical Internet paths, the two error characteristics intersect at a point called the Allan intercept, which represents the ideal time constant. With a compromise Allan intercept of 2000 s, the optimum poll interval is about 64 s, which corresponds to a compromise poll exponent of 6. For fast LANs with modern computers, the Allan intercept is somewhat lower, so a compromise poll exponent of 3 (8 s) is appropriate. An intricate, heuristic algorithm is used to manage the actual poll interval within a specified range. Details are on the <a href="poll.html">Poll Program</a> page.</p>
+<p>The optimum time constant, and thus the poll interval, depends on the network time jitter and the oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. For typical Internet paths, the two error characteristics intersect at a point called the <em>Allan intercept</em>, which represents the optimum time constant. With a compromise Allan intercept of 2048 s, the optimum poll interval is about 64 s, which corresponds to a compromise poll exponent of 6. For fast LANs with modern computers, the Allan intercept is somewhat lower at around 512 s, so a compromise poll exponent of 4 (16 s) is appropriate. An intricate, heuristic algorithm is used to manage the actual poll interval within a specified range. Details are on the <a href="poll.html">Poll Program</a> page.</p>
<p>In the NTPv4 specification and reference implementation a state machine is used to manage the system clock under exceptional conditions, as when the daemon is first started or when encountering severe network congestion. In extreme cases not likely to be encountered in normal operation, the system time can be stepped forward or backward more than 128 ms. Further details are on the <a href="clock.html">Clock State Machine</a> page.</p>
+<h4 id="house">Clock Initialization and Management</h4>
+<p>If left running continuously, an NTP client on a fast LAN in a home or office environment can maintain synchronization nominally within one millisecond. When the ambient temperature variations are less than a degree Celsius, the clock oscillator frequency is disciplined to within one part per million (PPM), even when the clock oscillator native frequency offset is 100 PPM or more.</p>
+<p> For laptops and portable devices when the power is turned off, the battery backup clock offset error can increase as much as one second per day. When power is restored after several hours or days, the clock offset and oscillator frequency errors must be resolved by the clock discipline algorithm, but this can take several hours without specific provisions.</p>
+<p> 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 provisions. A detailed discussion of these provisions 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 convergence 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 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 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 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 usually 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>
</body>
<h3>NIST/USNO/PTB Modem Time Services</h3>
<p>Autjhor: David L. Mills (mills@udel.edu)<br>
Last update:
- <!-- #BeginDate format:En2m -->03-Sep-2010 17:59<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->10-Nov-2012 14:14<!-- #EndDate -->
UTC</p>
<hr>
<h4>Synopsis</h4>
<p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available. It can also be configured to operate full period.</p>
<p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delays, which can reach 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p>
<p>This driver requires a 9600-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. The actual line speed ranges from 1200 bps with USNO to 14,400 bps with NIST. The modem setup string is hard-coded in the driver and may require changes for nonstandard modems or special circumstances.</p>
-<p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpdc</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p>
-<p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpdc</tt>.</p>
+<p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpq</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p>
+<p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpq</tt>.</p>
<p>The driver automatically recognizes the message format of each modem time service. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p>
<p>Ordinarily, the serial port is connected to a modem; however, if fudge <tt>flag3</tt> is set, it can be connected directly to a Spectracom WWV or GPS radio for testing or calibration. The Spectracom radio can be connected via a modem if the radio is connfigured to send time codes continuoulsly at 1-s intervals. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p>
<p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. The recommended settings are 12 (1.1 hours) for <tt>minpoll</tt> and 17 (36 hours) for <tt>maxpoll</tt>. Ordinarily, the poll interval will start at <tt>minpoll</tt> and ramp up to <tt>maxpoll</tt> in a day or two.</p>
<p>
The accuracy depends on the receiver used. Inexpensive GPS models are
available with a claimed PPS signal accuracy of
- 1 <font face="Symbol">m</font>s or better relative to the broadcast
+ 1 μs or better relative to the broadcast
signal. However, in most cases the actual accuracy is limited by the
precision of the timecode and the latencies of the serial interface and
operating system.
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
This driver synchronizes the computer time using shortwave radio transmissions from NIST time/frequency stations <a href="http://www.bldrdoc.gov/timefreq/stations/wwv.html">WWV</a> in Ft. Collins, CO, and <a href="http://www.bldrdoc.gov/timefreq/stations/wwvh.htm">WWVH</a> in Kauai, HI. Transmissions are made continuously on 2.5, 5, 10 and 15 MHz from both stations and on 20 MHz from WWV. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically by the driver as propagation conditions change throughout the day and season. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.
-<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 187 PPM (.0187 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
+<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and μ-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 187 PPM (.0187 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
<p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 2479 km from the transmitter, the predicted two-hop propagation delay varies from 9.3 ms in sunlight to 9.0 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p>
<p>After calibration relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.1 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
-<p>The driver processes 8-kHz
<font face="symbol">m</font>-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in the broadcast signal. The WWV signal format is described in NIST Special Publication 432 (Revised 1990) and also available on the <a href="http://tf.nist.gov/stations/wwvtimecode.htm">WWV/H web site</a>. It consists of three elements, a 5-ms, 1000-Hz pulse, which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse, which occurs at the beginning of each minute, and a pulse-width modulated 100-Hz subcarrier for the data bits, one bit per second. The WWVH format is identical, except that the 1000-Hz pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for the time of century plus seven bits for the daylight savings time (DST) indicator, leap warning indicator and DUT1 correction.</p>
+<p>The driver processes 8-kHz
μ-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in the broadcast signal. The WWV signal format is described in NIST Special Publication 432 (Revised 1990) and also available on the <a href="http://tf.nist.gov/stations/wwvtimecode.htm">WWV/H web site</a>. It consists of three elements, a 5-ms, 1000-Hz pulse, which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse, which occurs at the beginning of each minute, and a pulse-width modulated 100-Hz subcarrier for the data bits, one bit per second. The WWVH format is identical, except that the 1000-Hz pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for the time of century plus seven bits for the daylight savings time (DST) indicator, leap warning indicator and DUT1 correction.</p>
<p>The demodulation and decoding algorithms used by this driver are based on a machine language program developed for the TAPR DSP93 DSP unit, which uses the TI 320C25 DSP chip. The analysis, design and performance of the program for this unit is described in: Mills, D.L. A precision radio clock for WWV transmissions. Electrical Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp. Available from <a href="http://www.eecis.udel.edu/%7emills/reports.html">www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver, the original program was rebuilt in the C language and adapted to the NTP driver interface. The algorithms have been modified to improve performance, especially under weak signal conditions and to provide an automatic frequency and station selection feature.</p>
<p>As in the original program, the clock discipline is modelled as a Markov process, with probabilistic state transitions corresponding to a conventional clock and the probabilities of received decimal digits. The result is a performance level with very high accuracy and reliability, even under conditions when the minute beep of the signal, normally its most prominent feature, can barely be detected by ear using a communications receiver.</p>
<h4>Baseband Signal Processing</h4>
<p>Once the clock is set, it continues to provide correct timecodes as long as the signal metric is above threshold, as described in the previous section. As long as the clock is correctly set or verified, the system clock offsets are provided once each minute to the reference clock interface, where they are processed using the same algorithms as with other reference clocks and remote servers.</p>
<p>It may happen as the hours progress around the clock that WWV and WWVH signals may appear alone, together or not at all. When the driver has mitigated which station and frequency is best, it sets the reference identifier to the string WV<i>f</i> for WWV and WH<i>f</i> for WWVH, where <i>f</i> is the frequency in megahertz. If the propagation delays have been properly set with the <tt>fudge time1</tt> (WWV) and <tt>fudge time2</tt> (WWVH) commands in the configuration file, handover from one station to the other is seamless.</p>
<p>Operation continues as long as the signal metric from at least one station on at least one frequency is acceptable. A consequence of this design is that, once the clock is set, the time and frequency are disciplined only by the second synch pulse and the clock digits themselves are driven by the clock state machine. If for some reason the state machine drifts to the wrong second, it would never resynchronize. To protect against this most unlikely situation, if after two days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.</p>
-<p>Once the system clock been set correctly it will continue to read correctly even during the holdover interval, but with increasing dispersion. Assuming the system clock frequency can be disciplined within 1 PPM, it can coast without signals for several days without exceeding the NTP step threshold of 128 ms. During such periods the root distance increases at 15 <font face="Symbol">m</font>s per second, which makes the driver appear less likely for selection as time goes on. Eventually, when the distance due all causes exceeds 1 s, it is no longer suitable for synchronization. Ordinarily, this happens after about 18 hours with no signals. The <tt>tinker maxdist</tt> configuration command can be used to change this value.</p>
+<p>Once the system clock been set correctly it will continue to read correctly even during the holdover interval, but with increasing dispersion. Assuming the system clock frequency can be disciplined within 1 PPM, it can coast without signals for several days without exceeding the NTP step threshold of 128 ms. During such periods the root distance increases at 15 μs per second, which makes the driver appear less likely for selection as time goes on. Eventually, when the distance due all causes exceeds 1 s, it is no longer suitable for synchronization. Ordinarily, this happens after about 18 hours with no signals. The <tt>tinker maxdist</tt> configuration command can be used to change this value.</p>
<h4>Autotune</h4>
<p>The driver includes provisions to automatically tune the radio in response to changing radio propagation conditions throughout the day and night. The radio interface is compatible with the ICOM CI-V standard, which is a bidirectional serial bus operating at TTL levels. The bus can be connected to a standard serial port using a level converter such as the CT-17. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will activate the autotune function and tune the radio to each operating frequency in turn while attempting to acquire minute synch from either WWV or WWVH. However, the driver is liberal in what it assumes of the configuration. If the <tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus is inoperative, the driver quietly gives up with no harm done.</p>
The fields beginning with <tt>yyyy</tt> and extending through <tt>du</tt> are decoded from the received data and are in fixed-length format. The remaining fields are in variable-length format. The fields are as follows:
<dl>
<dt><tt>s</tt></dt>
- <dd>The synch indicator is initially <tt>?</tt> before the clock is set, but turns to space when all nine digits of the timecode are correctly set and the decoder is synchronized to the station within 125 <font face="Symbol">m</font>s.</dd>
+ <dd>The synch indicator is initially <tt>?</tt> before the clock is set, but turns to space when all nine digits of the timecode are correctly set and the decoder is synchronized to the station within 125 μs.</dd>
<dt><tt>q</tt></dt>
<dd>The quality character is a four-bit hexadecimal code showing which alarms have been raised. Each bit is associated with a specific alarm condition according to the following:
<dl>
<dt><tt>0x8</tt></dt>
- <dd>synch alarm. The decoder is not synchronized to the station within 125 <font face="Symbol">m</font>s.</dd>
+ <dd>synch alarm. The decoder is not synchronized to the station within 125 μs.</dd>
<dt><tt>0x4</tt></dt>
<dd>Digit error alarm. Less than nine decimal digits were found in the last minute.</dd>
<dt><tt>0x2</tt></dt>
<dt><tt>du</tt></dt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.</dd>
<dt><tt>lset</tt></dt>
- <dd>Before the clock is set, the interval since last set is the number of minutes since the driver was started; after the clock is set, this is number of minutes since the decoder was last synchronized to the station within 125 <font face="Symbol">m</font>s.</dd>
+ <dd>Before the clock is set, the interval since last set is the number of minutes since the driver was started; after the clock is set, this is number of minutes since the decoder was last synchronized to the station within 125 μs.</dd>
<dt><tt>agc</tt></dt>
<dd>The audio gain shows the current codec gain setting in the range 0 to 255. Ordinarily, the receiver audio gain control should be set for a value midway in this range.</dd>
<dt><tt>ident</tt></dt>
Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
<p>This driver synchronizes the computer time using the Inter-Range Instrumentation Group (IRIG) standard time distribution signal. This signal is generated by several radio clocks, including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom, Symmetricom and TrueTime, among others, although it is often an add-on option. The signal is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.</p>
-<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation, only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 250 PPM (.025 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
+<p>The driver requires an audio codec or sound card with sampling rate 8 kHz and μ-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation, only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 250 PPM (.025 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p>
<p>For proper operation the IRIG signal source should be configured for analog signal levels, not digital TTL levels. In most radios the IRIG signal is driven ±10 V behind 50 Ohms. In such cases the cable should be terminated at the line-in port with a 50-Ohm resistor to avoid overloading the codec. Where feasible, the IRIG signal source should be operated with signature control so that, if the signal is lost or mutilated, the source produces an unmodulated signal, rather than possibly random digits. The driver automatically rejects the data and declares itself unsynchronized in this case. Some devices, in particular Spectracom radio/satellite clocks, provide additional year and status indication; other devices may not.</p>
-<p>In general and without calibration, the driver is accurate within 500 <font face="symbol">m</font>s relative to the IRIG time. After calibrating relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is less than 20 <font face="symbol">m</font>s with standard deviation 10 <font face="symbol">m</font>s. Most of this is due to residuals after filtering and averaging the raw codec samples, which have an inherent jitter of 125 <font face="symbol">m</font>s. The processor load due to the driver is 0.6 percent on the P4.</p>
+<p>In general and without calibration, the driver is accurate within 500 μs relative to the IRIG time. After calibrating relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is less than 20 μs with standard deviation 10 μs. Most of this is due to residuals after filtering and averaging the raw codec samples, which have an inherent jitter of 125 μs. The processor load due to the driver is 0.6 percent on the P4.</p>
<p>However, be acutely aware that the accuracy with Solaris 2.8 and beyond has been seriously degraded to the order of several milliseconds. The Sun kernel driver has a sawtooth modulation with amplitude over 5 ms P-P and period 5.5 s. This distortion is especially prevalent with Sun Blade 1000 and possibly other systems.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
<p>The IRIG signal format uses an amplitude-modulated carrier with pulse-width modulated data bits. For IRIG-B, the carrier frequency is 1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy, generally within a few tens of microseconds relative to IRIG time, it can also generate a significant processor load with older workstations. Generally, the accuracy with IRIG-E is about ten times worse than IRIG-B, but the processor load is somewhat less. Technical details about the IRIG formats can be found in <a href="http://handle.dtic.mil/100.2/ADA346250">IRIG Standard 200-98</a>.</p>
-<p>The driver processes 8000-Hz <font face="symbol">m</font>-law companded samples using separate signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector and automatic threshold corrector. An infinite impulse response (IIR) 1000-Hz bandpass filter is used for IRIG-B and an IIR 130-Hz lowpass filter for IRIG-E. These are intended for use with noisy signals, such as might be received over a telephone line or radio circuit, or when interfering signals may be present in the audio passband. The driver determines which IRIG format is in use by sampling the amplitude of each filter output and selecting the one with maximum signal.</p>
+<p>The driver processes 8000-Hz μ-law companded samples using separate signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector and automatic threshold corrector. An infinite impulse response (IIR) 1000-Hz bandpass filter is used for IRIG-B and an IIR 130-Hz lowpass filter for IRIG-E. These are intended for use with noisy signals, such as might be received over a telephone line or radio circuit, or when interfering signals may be present in the audio passband. The driver determines which IRIG format is in use by sampling the amplitude of each filter output and selecting the one with maximum signal.</p>
<p>Cycle crossings relative to the corrected slice level determine the width of each pulse and its value - zero, one or position identifier (PI). The data encode ten characters (20 BCD digits) which determine the second, minute, hour and day of the year and with some IRIG generators the year and synchronization condition. The comb filter exponentially averages the corresponding samples of successive baud intervals in order to reliably identify the reference carrier cycle.</p>
<p>A type-II phase-lock loop (PLL) performs additional integration and interpolation to accurately determine the zero crossing of that cycle, which determines the reference timestamp. A pulse-width discriminator demodulates the data pulses, which are then encoded as the BCD digits of the timecode. The timecode and reference timestamp are updated once each second with IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved for later processing. At poll intervals of 64 s, the saved samples are processed by a median filter and used to update the system clock.</p>
<h4>Monitor Data</h4>
shortwave receiver can be tuned manually to one of these frequencies or, in
the case of ICOM receivers, the receiver can be tuned automatically as propagation
conditions change throughout the day and season.</p>
-<p>The driver can be compiled to use either an audio codec or soundcard, or a Bell 103-compatible, 300-b/s modem or modem chip, as described on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. If compiled for a modem, the driver uses it to receive the radio signal and demodulate the data. If compiled for the audio codec, it requires a sampling rate of 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC. In this implementation, only one audio driver and codec can be supported on a single machine.</p>
+<p>The driver can be compiled to use either an audio codec or soundcard, or a Bell 103-compatible, 300-b/s modem or modem chip, as described on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. If compiled for a modem, the driver uses it to receive the radio signal and demodulate the data. If compiled for the audio codec, it requires a sampling rate of 8 kHz and μ-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC. In this implementation, only one audio driver and codec can be supported on a single machine.</p>
<p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 625 km from the transmitter, the predicted one-hop propagation delay varies from 2.8 ms in sunlight to 2.6 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p>
<p>After calibration relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.2 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p>
<p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p>
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p>
<h4>Technical Overview</h4>
-<p>The driver processes 8-kHz <font face="symbol">m</font>-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. The single format B burst is considered correct only if every character matches its repetition in the burst. For the eight format A bursts, a majority decoder requires more than half of the 16 repetitions for each digit decode to the same value. Every character in every burst provides an independent timestamp upon arrival with a potential total of 60 timestamps for each minute.</p>
+<p>The driver processes 8-kHz μ-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. The single format B burst is considered correct only if every character matches its repetition in the burst. For the eight format A bursts, a majority decoder requires more than half of the 16 repetitions for each digit decode to the same value. Every character in every burst provides an independent timestamp upon arrival with a potential total of 60 timestamps for each minute.</p>
<p>The CHU timecode format is described on the <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/chu_e.html">CHU website</a>. A timecode is assembled when all bursts have been received in each minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the majority decoder declares success. Once the driver has synchronized for the first time, it will appear reachable and selectable to discipline the system clock. It is normal on occasion to miss a minute or two due to signal fades or noise. If eight successive minutes are missed, the driver is considered unreachable and the system clock will free-wheel at the latest determined frequency offset. Since the signals are almost always available during some period of the day and the NTP clock discipline algorithms are designed to work well even with long intervals between updates, it is unlikely that the system clock will drift more than a few milliseconds during periods of signal loss.</p>
<h4>Baseband Signal Processing</h4>
<p>The program consists of four major parts: the DSP modem, maximum-likelihood UART, burst assembler and majority decoder. The DSP modem demodulates Bell 103 modem answer-frequency signals; that is, frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). It consists of a 500-Hz bandpass filter centered on 2125 Hz followed by a limiter/discriminator and raised-cosine lowpass filter optimized for the 300-b/s data rate. </p>
<body>
<h3>Clock Filter Algorithm</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->02-Dec-2011 21:25<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Jun-2012 18:02<!-- #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 ±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>Figure 1 shows a typical <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 ±0.5, representing the limits of sample variation. 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>The clock filter algorithm works best when the delays are statistically identical in the reciprocal directions between the server and client. This is apparent in Figure 1, where the scattergram is symmetric about the x axis through the apex sample. In configurations where the delays are not reciprocal, or where the transmission delays on the two directions are traffic dependent, this may not be the case. A common case with DSL links is when downloading or uploading a large file. During the download or upload process, the delays may be significantly different resulting in large errrors. However, these errors can be largely eliminated using samples near the limb lines, as described on the <a href="huffpuff.html">Huff-n'-Puff Filter</a> page.</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 associated offset and delay samples. Subsequently, the dispersion sample in each stage is increased at a fixed rate of 15 μ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 "infinity" 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>
+<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 "infinity" 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 s.</p>
+<p> As samples enter the register, the peer dispersion drops from 16 s to 8 s, 4 s, 2 s, and so forth. In practice, the synchronization distance, which is equal to one-half the delay plus 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. For additional information on statistacl principles and performance metrics, see the <a href="stats.html">Performance Metrics</a> page.</p>
+<p> 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>Figure 2. Raw (left) and Filtered (right) Offsets</p>
</div>
</div>
<p>Figure 1 shows how the huff-n'-puff filter works. Recall from the <a href="filter.html">Clock Filter Algorithm</a> page that the wedge scattergram plots sample points (<em>x</em>, <em>y</em>) corresponding to the measured delay and offset, and that the limb lines are at slope ±0.5. Note in the figure that the samples are clustered close to the upper limb line, representing heavy traffic in the download direction. The apparent offset <i>y</i><sub>0</sub> is near zero at the minimum delay <i>x</i><sub>0</sub>, which is near 0.1s. Thus, for a point (<em>x</em>, <em>y</em>), the true offset is</p>
<blockquote>
- <p> <font face="symbol">q</font> = <em>y</em> <font face="symbol">-</font> (<em>x </em><font face="symbol">- </font><i>x</i><sub>0</sub>) / 2 for <em>y</em> > <i>y</i><sub>0</sub> at or near the upper limb line or<br>
- <font face="symbol">q</font> = <em>y</em> <font face="symbol">+</font> (<em>x </em><font face="symbol">- </font><i>x</i><sub>0</sub>) / 2 for <em>y</em> < <i>y</i><sub>0</sub> at or near the lower limb line.</p>
+ <p> θ = <em>y</em> <font face="symbol">-</font> (<em>x </em><font face="symbol">- </font><i>x</i><sub>0</sub>) / 2 for <em>y</em> > <i>y</i><sub>0</sub> at or near the upper limb line or<br>
+ θ = <em>y</em> <font face="symbol">+</font> (<em>x </em><font face="symbol">- </font><i>x</i><sub>0</sub>) / 2 for <em>y</em> < <i>y</i><sub>0</sub> at or near the lower limb line.</p>
</blockquote>
-<p>In either case the associated delay is <font face="symbol">d</font> = <em>x</em>.</p>
+<p>In either case the associated delay is δ = <em>x</em>.</p>
<p>In the interior of the wedge scattergram far from the limb lines, the corrections are less effective and can lead to significant errors if the area between the limb lines is heavily populated.</p>
<hr>
<p><script type="text/javascript" language="javascript" src="scripts/footer.txt"></script></p>
<hr>
<p>The technical report [2], which is a revision and update of an earlier report [3], describes an engineering model for a precision clock discipline function for a generic operating system. The model is the same hybrid phase/frequecy-lock feedback loop used by <tt>ntpd</tt>, but implemented in the kernel. The code described in [2] is included in Solaris and Digital/Compaq/HP Tru64. It provides two system calls <tt>ntp_gettime()</tt> and <tt>ntp_adjtime()</tt> and can discipline the system clock with microsecond resolution. However, newer hardware and kernels with the same system calls can discipline the clock with nanosecond resolution. The new code described in [1] is in FreeBSD, Linux and Tru64. The software and documentation, including a simulator used to verify correct behavior, but not involving licensed code, is available in the <a href="ftp://ftp.udel.edu/pub/ntp/software/nanokernel.tar.gz">nanokernel.tar.gz</a> distribution</p>
<p>Ordinarily, the kernel clock discipline function is used with the NTP daemon, but could be used for other purposes. The <a href="ntptime.html"><tt>ntptime</tt></a> utility program can be used to control it manually.</p>
-<p>The kernel model also provides support for an external precision timing source, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The new system calls are used by the <a href="kernpps.html">PPSAPI interface</a> and in turn by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver (type 22) to provide synchronization limited in principle only by the accuracy and stability of the external timing source. Typical results with the PPS signal from a GPS receiver and a modern computer are in the 3 <font face="symbol">m</font>s range.</p>
+<p>The kernel model also provides support for an external precision timing source, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The new system calls are used by the <a href="kernpps.html">PPSAPI interface</a> and in turn by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver (type 22) to provide synchronization limited in principle only by the accuracy and stability of the external timing source. Typical results with the PPS signal from a GPS receiver and a modern computer are in the 3 μs range.</p>
<h4>References</h4>
<ol>
<li>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.pdf">PDF</a>, Slides: <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.html">HTML</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ppt">PowerPoint</a></li>
<body>
<h3>Leap Second Processing</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->07-Sep-2010 17:25<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->31-May-2012 20:56<!-- #EndDate -->
UTC</p>
<hr>
<p>About every eighteen months the International Earth Rotation Service (IERS) issues a bulletin announcing the insertion of a leap second in the Universal Coordinated Time (UTC) timescale. Ordinarily, this happens at the end of the last day of June or December; but, in principal, it could happen at the end of any month. While these bulletins are available on the Internet at <a href="http://www.iers.org">www.iers.org</a>, advance notice of leap seconds is also available in signals broadcast from national time and frequency stations, in GPS signals and in telephone modem services. Many, but not all, reference clocks recognize these signals and many, but not all, drivers for them can decode the signals and set the leap bits in the timecode accordingly. This means that many, but not all, primary servers can pass on these bits in the NTP packet heard to dependent secondary servers and clients. Secondary servers can pass these bits to their dependents and so on throughout the NTP subnet.</p>
<p> A leap second is inserted following second 59 of the last minute of the day and becomes second 60 of that day. A leap second is deleted by omitting second 59 of the last minute of the day, although this has never happened and is highly unlikely to happen in future. So far as is known, there are no provisions in the Unix or Windows libraries to account for this occasion other than to to affect the conversion of an NTP datestamp or timestamp to conventional civil time.</p>
<p>When an update is received from a reference clock or downstratum server, the leap bits are inspected for all survivors of the cluster algorithm. If the number of survivors showing a leap bit is greater than half the total number of survivors, a pending leap condition exists until the end of the current month.</p>
<p>When no means are available to determine the leap bits from a reference clock or downstratum server, a leapseconds file can be downloaded from time.nist.gov and installed using the <a href="miscopt.html#leapfile">leapfile</a> command. The file includes a list of historic leap second and the NTP time of insertion. It is parsed by the <tt>ntpd</tt> daemon at startup and the latest leap time saved for future reference. Each time the clock is set, the current time is compared with the last leap time. If the current time is later than the last leap time, nothing further is done. If earlier, the leap timer is initialized with the time in seconds until the leap time and counts down from there. When the leap timer is less than one month, a pending leap condition exists until the end of the current month. If the leapseconds file is present, the leap bits for reference clocks and downstratum servers are ignored.</p>
-<p>If the precision time kernel support is
installed and enabled, at the begriming of the day of the leap event the leap bits are set in the Unix <tt>ntp_adjtime()</tt> system call to arm the kernel for the leap at the end of the day. The kernel automatically inserts one second exactly at the time of the leap, after which the leap bits are turned off. If the kernel support is not availed or disabled, the leap is implemented as a crude hack by setting the clock back one second using the Unix <tt>settimeofday() </tt>system call, which effectively repeats the last second. Note however that in any case setting the time backwards by one second does not actually set the system clock backwards, but effectively stalls the clock for one second. These points are expanded in the white paper <a href="http://www.eecis.udel.edu/~mills/leap.html">The NTP Timescale and Leap Seconds</a>. If the leap timer is less than one day, the leap bits are set for dependent servers and clients.</p>
+<p>If the precision time kernel support is
available and enabled, at the beginning of the day of the leap event, the leap bits are set by the Unix <tt>ntp_adjtime()</tt> system call to arm the kernel for the leap at the end of the day. The kernel automatically inserts one second exactly at the time of the leap, after which the leap bits are turned off. If the kernel support is not availed or disabled, the leap is implemented as a crude hack by setting the clock back one second using the Unix <tt>settimeofday() </tt>system call, which effectively repeats the last second. Note however that in any case setting the time backwards by one second does not actually set the system clock backwards, but effectively stalls the clock for one second. These points are expanded in the white paper <a href="http://www.eecis.udel.edu/~mills/leap.html">The NTP Timescale and Leap Seconds</a>. If the leap timer is less than one day, the leap bits are set for dependent servers and clients.</p>
<p>As an additional feature when the NIST leap seconds file is installed, it is possible to determine the number of leap seconds inserted in UTC since UTC began on 1 January 1972. This represents the offset between International Atomic Time (TAI) and UTC. If the precision time kernel modifications are available and enabled, the TAI offset is available to application programs using the <tt>antipasti()</tt> system call. If the Auto key public-key cryptography feature is installed, the TAI offset is automatically propagated along with other cryptographic media to dependent servers and clients.</p>
<hr>
<p><script type="text/javascript" language="javascript" src="scripts/footer.txt"></script></p>
<head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Poll Program</title>
+<title>Poll Process</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
</head>
<body>
-<h3>Poll Program</h3>
+<h3>Poll Process</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->31-Jul-2011 15:34<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->20-Apr-2012 19:21<!-- #EndDate -->
UTC</p>
<hr>
-<p>
Each poll process sends NTP packets at intervals determined by the poll program. The program is designed to provide a sufficient update rate for thc clock discipline algorithm, while minimizing network overhead. The program is designed to operate over a poll exponent range between 3 (8 s) and 17 (36 hr). The minimum and maximum poll exponent within this range can be set using the <tt>minpoll</tt> and <tt>maxpoll</tt> options of the <a href="confopt.html#option"><tt>server</tt></a> command, with default 6 (64 s) and 10 (1024 s), respectively.</p>
-<p> The poll interval is managed by a heuristic algorithm developed over several years of experimentation. It depends on an exponentially weighted average of clock offset differences, called <em>clock jitter</em>, and a jiggle counter, which is initially set to zero. When a clock update is received and the offset exceeds the clock jitter by a factor of 4, the jiggle counter is increased by the poll exponent; otherwise, it is decreased by twice the poll exponent. If the jiggle counter is greater than an arbitrary threshold of 30, it is reset to 0 and the the poll exponent is increased by 1. If the jiggle counter is less than -30, it is set to 0 and the poll exponent decreased by 1. In effect, the algorithm has a relatively slow reaction to good news, but a relatively fast reaction to bad news.</p>
-<p>As an option of the <a href="confopt.html#option"><tt>server</tt></a> command, instead of a single packet, the poll program can send a burst of six packets at 2-s intervals. This is designed to reduce the time to synchronize the clock at initial startup (<tt>iburst</tt>) and/or to reduce the phase noise at the longer poll intervals (<tt>burst</tt>). The <tt>iburst</tt> option is effective only when the server is unreachable, while the <tt>burst</tt> option is effective only when the server is reachable.</p>
-<p>For the <tt>iburst</tt> option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the <tt>burst</tt> option, the number of packets in the burst is determined by the difference between the current poll exponent and the minimum poll exponent as a power of 2. For instance, with the default minimum poll exponent of 6 (64 s), only a single packet is sent for every poll, while the full number of eight packets is sent at poll exponents of 9 (512 s) or more. This insures that the average headway will never exceed the minimum headway.</p>
+<p>
The poll process sends NTP packets at intervals determined by the clock discipline algorithm. The process is designed to provide a sufficient update rate to maximize accuracy while minimizing network overhead. The process is designed to operate over a poll exponent range between 3 (8 s) and 17 (36 hr). The minimum and maximum poll exponent within this range can be set using the <tt>minpoll</tt> and <tt>maxpoll</tt> options of the <a href="confopt.html#option"><tt>server</tt></a> command, with default 6 (64 s) and 10 (1024 s), respectively.</p>
+<p> The poll interval is managed by a heuristic algorithm developed over several years of experimentation. It depends on an exponentially weighted average of clock offset differences, called <em>clock jitter</em>, and a jiggle counter, which is initially set to zero. When a clock update is received and the offset exceeds the clock jitter by a factor of 4, the jiggle counter is increased by the poll exponent; otherwise, it is decreased by twice the poll exponent. If the jiggle counter is greater than an arbitrary threshold of 30, it is reset to 0 and the the poll exponent is increased by 1. If the jiggle counter is less than -30, it is set to 0 and the poll exponent decreased by 1. In effect, the algorithm has a relatively slow reaction to good news, but a relatively fast reaction to bad news.</p>
+<p>As an option of the <a href="confopt.html#option"><tt>server</tt></a> command, instead of a single packet, the poll process can send a burst of several packets at 2-s intervals. This is designed to reduce the time to synchronize the clock at initial startup (<tt>iburst</tt>) and/or to reduce the phase noise at the longer poll intervals (<tt>burst</tt>). The <tt>iburst</tt> option is effective only when the server is unreachable, while the <tt>burst</tt> option is effective only when the server is reachable. The two options are independent of each other and both can be enabled at the same time.</p>
+<p>For the <tt>iburst</tt> option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the <tt>burst</tt> option, the number of packets in the burst is determined by the difference between the current poll exponent and the minimum poll exponent as a power of 2. For instance, with the default minimum poll exponent of 6 (64 s), only one packet is sent for every poll, while the full number of eight packets is sent at poll exponents of 9 (512 s) or more. This insures that the average headway will never exceed the minimum headway.</p>
<p>The burst options can result in increased load on the network if not carefully designed. Both options are affected by the provisions described on the <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a> page. In addition, when <tt>iburst</tt> or <tt>burst</tt> are enabled, the first packet of the burst is sent, but the remaining packets sent only when the reply to the fist packet is received. If no reply has been received after a timeout set by the <tt>minpoll</tt> option, the first packet is sent again. This means that, even if a server is unreachable, the network load is no more than at the minimum poll interval.</p>
<p>To further reduce the network load when a server is unreachable, an unreach timer is incremented by 1 at each poll interval, but is set to 0 as each packet is received. If the timer exceeds the <em>unreach threshold</em> set at 10, the poll exponent is incremented by 1 and the unreach timer set to 0. This continues until the poll exponent reaches the maximum set by the <tt>maxpoll</tt> option.</p>
<hr>
-<p><script type="text/javascript" language="javascript" src="scripts/footer.txt"></script></p>
+<p>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+</p>
</body>
</html>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
-<p>Most radio clocks are connected using a serial port operating at speeds of 9600 bps. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character such as carriage-return <tt><cr></tt>, is normally limited to 100 <font face="symbol">m</font>s. Using carefully crafted averaging techniques, the NTP algorithms can whittle this down to a few tens of microseconds. However, some radios produce a pulse-per-second (PPS) signal which can be used to improve the accuracy to a few microseconds. This page describes the hardware and software necessary for NTP to use the PPS signal.</p>
+<p>Most radio clocks are connected using a serial port operating at speeds of 9600 bps. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character such as carriage-return <tt><cr></tt>, is normally limited to 100 μs. Using carefully crafted averaging techniques, the NTP algorithms can whittle this down to a few tens of microseconds. However, some radios produce a pulse-per-second (PPS) signal which can be used to improve the accuracy to a few microseconds. This page describes the hardware and software necessary for NTP to use the PPS signal.</p>
<p> The PPS signal can be connected in either of two ways. On FreeBSD systems (with the PPS_SYNC and pps kernel options) it can be connected directly to the ACK pin of a parallel port. This is the preferred way, as it requires no additional hardware. Alternatively, it can be connected via the DCD pin of a serial port. However, the PPS signal levels are usually incompatible with the serial port interface signals. Note that NTP no longer supports connection via the RD pin of a serial port.</p>
<div align="center">
<p><img src="pic/gadget.jpg" alt="gif"></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>
+<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 -->16-Dec-2011 20:58<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->18-Jul-2012 16:41<!-- #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">General Overview</a></li>
- <li class="inline"><a href="#combine">Combine Algorithm</a></li>
- <li class="inline"><a href="#clockhop">Anti-Clockhop Algorithm</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>
+ <li class="inline"><a href="#intro">1. Introduction and Overview</a></li>
+ <li class="inline"><a href="#combine">2. Combine Algorithm</a></li>
+ <li class="inline"><a href="#clockhop">3. Anti-Clockhop Algorithm</a></li>
+ <li class="inline"><a href="#peer">4. Peer Classification</a></li>
+ <li class="inline"><a href="#prefer">5. 5. The <tt>prefer</tt> Peer</a></li>
+ <li class="inline"><a href="#miti">6. Mitigation Rules</a></li>
+ <li class="inline"><a href="#mins">7. The <tt>minsane</tt> Option</a></li>
</ul>
<hr>
-<h4 id="intro">General Overview</h4>
-<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>
+<h4 id="intro">1. Introduction and Overview</h4>
+<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. For additional information on statistical principles and performance metrics, see the <a href="stats.html">Performance Metrics</a> page.</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 an
tdiscipline 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 using 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> 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 Algorithm</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 prune 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 an
d discipline the system 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 mitigation 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 using 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">2. 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 <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 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 the <em>old peer</em>, and thecurrently selected server the <em>candidate peer</em>. The anti-clockhop algorithm is called immediately after the combine algorithm. The metric used to select the candidate peer is formed as the root distance plus product of the stratum times the <tt>mindist</tt> variable. It is used to select the minimum survivor on the list produced by the clock cluster algorithm. 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>
+<h4 id="clockhop">3. 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 current system peer, unless it becomes stale or has significant offset relative to other candidates on the survivor list.</p>
+<p>For the purposes of the following description, call the last selected system peer the <em>old peer</em>, and the currently selected source the <em>candidate peer</em>. At each update, the candidate peer is selected as the first peer on the survivor list sorted by increasing root distance. The algorithm initializes the -<em>clockhop threshold</em> with the value of <tt>mindist</tt>, by default 1 ms. </p>
+<p>The anti-clockhop algorithm is called immediately after the combine algorithm. If there was no old peer or the old and candidate peers are the same, the candidate peer becomes the system peer. If the old peer and the candidate peer are different, the algorithm measures the difference between the offset of the old peer and the candidate peer. If the difference exceeds the clockhop threshold, the candidate peer becomes the system peer and the clockhop threshold is restored to its original value. If the difference is less than the clockhop threshold, the old peer continues as the system peer. However, at each subsequent update, the algorithm reduces the clockhop threshold by half. Should operation continue in this way, the candidate peer will eventually become the system peer.</p>
+<h4 id="peer">4. 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 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>A selectable association configured for a remote server or peer is classified as a <i>client association</i>. All other selectable associations are classified as <i>device driver associations</i> of one kind or another. In general, one or more sources of either type will be available 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 can become 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 on the <a href="orphan.html">Orphan Mode</a> page, all orphan children will select the same orphan parent for synchronization.</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 ±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>. 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>
+<h4 id="prefer">5. 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>
<p>The cluster algorithm works on the set of truechimers produced by the select algorithm. At each round the algorithm casts off the survivor least likely to influence the choice of system peer. If selectable, the prefer peer is never discarded; on the contrary, its potential removal becomes a termination condition. However, the prefer peer can still be discarded by the select algorithm as a falseticker; otherwise, the prefer peer becomes the system peer.</p>
<p>Ordinarily, the combine algorithm computes a weighted average of the survivor
- offsets to produce the final offset. However, if a prefer
+ offset and jitter to produce the final values. However, if a prefer
peer is among the survivors, the combine algorithm is not used. Instead,
- the offset of the prefer peer is used exclusively as the final offset. 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 offset and jitter of the prefer peer are used exclusively as the final values. 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
the radio clock 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>
+ the combined backup sources continue to discipline the system clock.</p>
+<h4 id="miti">6. 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 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>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 <a href="miscopt.html#tos"><tt>tos</tt></a> command, the <tt>prefer</tt> option of the <tt>server</tt> and <tt>peer</tt> commands and the <tt>flag</tt> option of the <tt>fudge</tt> command for a selected 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 synchronize the system clock. The <tt>prefer</tt> option operates as described in previous sections. The <tt>flag</tt> option enables the PPS signal for the selected driver.</p>
+<h4 id="mins">7. The <tt>minsane</tt> Option</H4>
+<p> The <tt>minsane</tt> option of the <a href="miscopt.html#tos"><tt>tos</tt></a> command, the <tt>prefer</tt> option of the <tt>server</tt> and <tt>peer</tt> commands and the <tt>flag</tt> option of the <tt>fudge</tt> command for a selected 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 synchronize the system clock. The <tt>prefer</tt> option operates as described in previous sections. The <tt>flag</tt> option enables the PPS signal for the selected driver.</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
<p>While it is possible that certain configurations do not need a configuration file, most do. The file, called by default <tt>/etc/ntp.conf</tt>, need only contain one command specifying a remote server, for instance</p>
<p><tt>server foo.bar.com</tt></p>
<p>Choosing an appropriate remote server is somewhat of a black art, but a
- suboptimal choice is seldom a problem. The simplest is to use the
+ suboptimal choice is seldom a problem. The simplest and best is to use the
Server Pool Scheme on the <a href="discover.html">Automatic Server Discovery</a> page. There
are about two dozen public time servers operated by the <a href="http://tf.nist.gov/tf-cgi/servers.cgi">National
Institutes of Science and Technology (NIST)</a>, <a href="http://tycho.usno.navy.mil/ntp.html">US
Naval Observatory (USNO)</a>, <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/network_time_protocol_e.html"> Canadian
Metrology Centre (CMC)</a> and many others available on the Internet. Lists
- of public primary and secondary NTP servers maintained on the <a href="http://support.ntp.org/bin/view/Servers/WebHome">Public
- NTP Time Servers</a> page, which is updated frequently.The lists are sorted
+ of public primary and secondary NTP servers maintained on the <a href="http://support.ntp.org/Servers/WebHome">Public
+ NTP Time Servers</a> page, which is updated frequently. The lists are sorted
by country and, in the case of the US, by state. Usually, the best
choice is the nearest in geographical terms, but the terms of engagement
specified in each list entry should be carefully respected.</p>
<img src="pic/boom4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>Our junior managers and the administrators.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->06-Nov-2011 20:00<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->21-Apr-2012 16:27<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a></li>
- <li class="inline"><a href="#guard">Guard Time</a></li>
- <li class="inline"><a href="#mah">Average Headway Time</a></li>
+ <li class="inline"><a href="#guard">Minimum Headway Time</a></li>
+ <li class="inline"><a href="#mah">Minimum Average Headway Time</a></li>
<li class="inline"><a href="#kiss">The Kiss-o'-Death Packet</a></li>
<li class="inline"><a href="#ref">References</a></li>
</ul>
<li>Upon receiving a Kiss-o'-Death packet (KoD, see below), immediately reduce the sending rate.</li>
</ul>
<p>Rate management involves four algorithms to manage resources: (1) poll rate control, (2) burst control, (3) average headway time and (4) guard time. The first two algorithms are described on the <a href="poll.html">Poll Program</a> page; the remaining two are described in following sections.</p>
-<h4 id="guard">Guard Time</h4>
-<p>The headway is defined as the interval between the last packet sent or received and the next packet. The minimum headway is called the guard time. In the reference implementation, if the received headway is less than the guard time, the packet is discarded. The guard time defaults to 2 s, but this can be changed using the <tt>minimum</tt> option of the <a href="accopt.html#discard"><tt>discard</tt></a> command. By design, the minimum interval between <tt>burst</tt> and <tt>iburst</tt> packets sent by any client is 2 s, which does not violate this constraint. Packets sent by other implementations that violate this constraint will be dropped and a KoD packet returned, if enabled.</p>
-<h4 id="mah">Average Headway Time</h4>
-<p>There are two features in the reference implementation to manage the minimum
interval between one packet and the next, and thus the maximum rate. The transmit throttle limits the rate for transmit packets, while the receive discard limits the rate for receive packets. These features make use of a pair of counters: a client output counter for each association and a server input counter for each distinct client IP address. For each packet received, the input counter increments by a value equal to the minimum average headway (MAH) and then decrements by one each second. For each packet transmitted, the output counter increments by the MAH and then decrements by one each second. The default MAH is 8 s, but this can be changed using the <tt>average</tt> option of the <a href="accopt.html#discard"><tt>discard</tt></a> command.</p>
+<h4 id="guard">Minimum Headway Time</h4>
+<p>The headway is defined for each source as the interval between the last packet sent or received and the next packet for that source. The minimum receive headway is defined as the guard time. In the reference implementation, if the receive headway is less than the guard time, the packet is discarded. The guard time defaults to 2 s, but this can be changed using the <tt>minimum</tt> option of the <a href="accopt.html#discard"><tt>discard</tt></a> command. By design, the minimum interval between <tt>burst</tt> and <tt>iburst</tt> packets sent by any client is 2 s, which does not violate this constraint. Packets sent by other implementations that violate this constraint will be dropped and a KoD packet returned, if enabled.</p>
+<h4 id="mah">Minimum Average Headway Time</h4>
+<p>There are two features in the reference implementation to manage the minimum
average headway time between one packet and the next, and thus the maximum average rate for each source. The transmit throttle limits the rate for transmit packets, while the receive discard limits the rate for receive packets. These features make use of a pair of counters: a client output counter for each association and a server input counter for each distinct client IP address. For each packet received, the input counter increments by a value equal to the minimum average headway (MAH) and then decrements by one each second. For each packet transmitted, the output counter increments by the MAH and then decrements by one each second. The default MAH is 8 s, but this can be changed using the <tt>average</tt> option of the <a href="accopt.html#discard"><tt>discard</tt></a> command.</p>
<p>If the <tt>iburst</tt> or <tt>burst</tt> options are present, the poll algorithm sends a burst of packets instead of a single packet at each poll opportunity. The NTPv4 specification requires that bursts contain no more than eight packets. Starting from an output counter value of zero, the maximum counter value, called the ceiling, can be no more than eight times the MAH. However, if the burst starts with a counter value other than zero, there is a potential to exceed the ceiling. This can result from protocol restarts and/or Autokey protocol operations. In these cases the poll algorithm throttles the output rate by computing an additional headway time so that the next packet sent will not exceed the ceiling. Designs such as this are often called leaky buckets.</p>
<p>The reference implementation uses a special most-recently used (MRU) list of entries, one entry for each distinct client IP address found. Each entry includes the IP address, input counter and process time at the last packet arrival. As each packet arrives, the IP source address is compared to the IP address in each entry in turn. If a match is found the entry is removed and inserted first on the list. If the IP source address does not match any entry, a new entry is created and inserted first, possibly discarding the last entry if the list is full. Observers will note this is the same algorithm used for page replacement in virtual memory systems. However, in the virtual memory algorithm the entry of interest is the last, whereas here the entry of interest is the first.</p>
<p> The input counter for the first entry on the MRU list, representing the current input packet, is decreased by the interval since the entry was last referenced, but not below zero. If the input counter is greater than the ceiling, the packet is discarded. Otherwise, the counter is increased by the MAH and the packet is processed. The result is, if the client maintains an average headway greater than the ceiling and transmits no more than eight packets in a burst, the input counter will not exceed the ceiling. Packets sent by other implementations that violate this constraint will be dropped and a KoD packet returned, if enabled.</p>
<p> In order to make sure the client notices the KoD packet, the server sets the receive and transmit timestamps to the transmit timestamp of the client packet. Thus, even if the client ignores all except the timestamps, it cannot do any useful time computations. KoD packets themselves are rate limited to no more than one packet per guard time, in order to defend against flood attacks.</p>
<h4 id="ref">References</h4>
<ol>
-<li>Mills, D.L., J. Levine, R. Schmidt and D. Plonka. Coping with overload on the Network Time Protocol public servers. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Washington DC, December 2004), 5-16. Paper: <a href="http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf">PDF</a>, Slides:<a href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.ppt">PowerPoint</a></li>
+
<li>Mills, D.L., J. Levine, R. Schmidt and D. Plonka. Coping with overload on the Network Time Protocol public servers. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Washington DC, December 2004), 5-16. Paper: <a href="http://www.eecis.udel.edu/~mills/database/papers/ptti/ptti04a.pdf">PDF</a>, Slides:<a href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti04.ppt">PowerPoint</a></li>
</ol>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<p>Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, driver ID, device name and serial line speed. For those drivers without specific documentation, please contact the author listed in the <a href="copyright.html">Copyright Notice</a> page.</p>
<ul>
<li class="inline"><a href="drivers/driver1.html">Type 1</a> Undisciplined Local Clock (<tt>LOCAL</tt>)</li>
+ <li class="inline"><a href="drivers/driver2.html">Type 2</a> Trak 8820 GPS Receiver (<tt>GPS_TRAK</tt>)</li>
<li class="inline"><a href="drivers/driver3.html">Type 3</a> PSTI/Traconex 1020 WWV/WWVH Receiver (<tt>WWV_PST</tt>)</li>
<li class="inline"><a href="drivers/driver4.html">Type 4</a> Spectracom WWVB/GPS Receivers (<tt>WWVB_SPEC</tt>)</li>
<li class="inline"><a href="drivers/driver5.html">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers (<tt>TRUETIME</tt>)</li>
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/onwire.html'>Analysis and Simulation of the NTP On-Wire Protocols</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/proximity.html'>Time Synchroization for Space Data Links</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/security.html'>NTP Security Analysis</a></li>\
+<li class='inline'><a href='http://www.eecis.udel.edu/~mills/ptp.html'>IEEE 1588 Precision Time Protocol (PTP)</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autocfg.html'>Autonomous Configuration</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/autokey.html'>Autonomous Authentication</a></li>\
<li class='inline'><a href='http://www.eecis.udel.edu/~mills/proto.html'>Autokey Protocol</a></li>\
<li class='inline'><a href='cluster.html'>Clock Cluster Algorithm</a></li>\
<li class='inline'><a href='prefer.html'>Mitigation Rules and the <tt>prefer</tt> Keyword</a></li>\
<li class='inline'><a href='discipline.html'>Clock Discipline Algorithm</a></li>\
-<li class='inline'><a href='poll.html'>Poll Program</a></li>\
+<li class='inline'><a href='poll.html'>Poll Process</a></li>\
<li class='inline'><a href='clock.html'>Clock State Machine</a></li>\
<li class='inline'><a href='leap.html'>Leap Second Processing</a></li>\
<li class='inline'><a href='sitemap.html'>Site Map</a></li>\
<em></em>
<h3>Clock Select Algorithm</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->16-Dec-2011 13:54<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->13-Apr-2012 14:58<!-- #EndDate -->
UTC</p>
<hr>
<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 source if the root distance (also known a
s 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>distance error</em> occurs for a source if the root distance (also known a
d 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 first 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>
+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 θ<sub>0</sub> and root distance λ, this defines a <em>correctness interval</em> [θ<sub>0</sub> − λ, θ<sub>0</sub> + λ] of points where the true value of θ 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 <em>smallest interval containing points from the largest number of correctness intervals.</em> An algorithm that finds the intersection interval was devised by Keith Marzullo in his doctoral dissertation. It was first implemented in the Digital Time Synchronization Service (DTSS) for the VMS operating system for the VAX.
+<p> While the NTP algorithm is based on DTSS, it remains to establish which point in the correctness interval represents the best estimate of the offset for each candidate. The best point is at the midpoint θ<sub>0</sub> 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>
</div>
-<p>Figure 1 shows correctness intervals for each of four candidates A, B, C and D. We need to find the maximum number of candidates that contain points in common. The result is the interval labeled DTSS. In the figure there are three truechimers A, B and C, and one falseticker D. In theory, any point in the intersection interval can represent the true time. The clock is considered correct if the number of truechimers found in this way are greater than half the total number of candidates.</p>
-<p>The question remains, which is the best point to represent the true time of each interval? Fortunately, we already have the maximum likelihood estimate at the midpoint of each correctness interval. But, while the midpoint of candidate C is outside the intersection interval, its correctness interval contains points in common with the intersection interval, so the candidate is a truechimer and the midpoint is chosen to represent its time.</p>
+<p>Figure 1 shows correctness intervals for each of four candidates A, B, C and D. We need to find the maximum number of candidates that contain points in common. The result is the interval labeled DTSS. In the figure there are three truechimers A, B and C, and one falseticker D. In DTSS any point in the intersection interval can represent the true time; however, as shown below, this may throw away valuable statistical information. In any case, the clock is considered correct if the number of truechimers found in this way are greater than half the total number of candidates.</p>
+<p>The question remains, which is the best point to represent the true time of each correctness interval? Fortunately, we already have the maximum likelihood estimate at the midpoint of each correctness interval. But, while the midpoint of candidate C is outside the intersection interval, its correctness interval contains points in common with the intersection interval, so the candidate is a truechimer and the midpoint is chosen to represent its time.</p>
<p>The DTSS correctness assertions do not consider how best to represent the truechimer time. To support the midpoint choice, consider the selection algorithm as a method to reject correctness intervals that cannot contribute to the final outcome; that is, they are falsetickers. The remaining correctness intervals can contribute to the final outcome; that is, they are truechimers. Samples in the intersection interval are usually of very low probability and thus poor estimates for truechimer time. On the other hand, the midpoint sample produced by the clock filter algorithm is the maximum likelihood estimate and thus best represents the truechimer time.</p>
<div align="center"><img src="pic/flt6.gif" alt="gif">
<p>Figure 2. Clock Select Algorithm</p>
</div>
-<p> The algorithm operates as shown in Figure 2. Let <em>m</em> be the number of candidates and <em>f</em> the number of falsetickers, initially zero. Move a pointer from the leftmost endpoint towards the rightmost endpoint in Figure 1 and count the number of candidates, stopping when that number reaches <em>m</em> - <em>f</em>; this is the left endpoint of the intersection interval. Then, do the same, but moving from the rightmost endpoint towards the leftmost endpoint; this is the right endpoint of the intersection interval. If the left endpoint is greater than the right endpoint; i.e., the interval appears backwards. increase <em>f</em> by 1. If <em>f</em> is less than <em>n</em> / 2, try again; otherwise, the algorithm fails and no truechimers could be found.</p>
-<p>The clock select algorithm then scans the associations. If the right endpoint of the correctness interval for a candidate is greater than the left endpoint of the intersection interval, or if the left endpoint of the correctness interval is less than the right endpoint of the intersection interval, the candidate is a truechimer; otherwise, it is a falseticker.</p>
+<p> The algorithm operates as shown in Figure 2. Let <em>m</em> be the number of candidates and <em>f</em> the number of falsetickers, initially zero. Move a pointer from the leftmost endpoint towards the rightmost endpoint in Figure 1 and count the number of candidates, stopping when that number reaches <em>m</em> − <em>f</em>; this is the left endpoint of the intersection interval. Then, do the same, but moving from the rightmost endpoint towards the leftmost endpoint; this is the right endpoint of the intersection interval. If the left endpoint is less than the right endpoint, the intersection interval has been found. Otherwise, increase <em>f</em> by 1. If <em>f</em> is less than <em>n</em> / 2, try again; otherwise, the algorithm fails and no truechimers could be found.</p>
+<p>The clock select algorithm again scans the correctness intervals. If the right endpoint of the correctness interval for a candidate is greater than the left endpoint of the intersection interval, or if the left endpoint of the correctness interval is less than the right endpoint of the intersection interval, the candidate is a truechimer; otherwise, it is a falseticker.</p>
<p>In practice, with fast LANs and modern computers, the correctness interval can be quite small, especially when the candidates are multiple reference clocks. In such cases the intersection interval might be empty, due to insignificant differences in the reference clock offsets. To avoid this, the size of the correctness interval is padded to the value of <tt>mindist</tt>, with default 1 ms. This value can be changed using the <tt>mindist</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>
<body>
<h3>How NTP Works</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->15-Dec-2011 16:30<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->18-Aug-2012 19:04<!-- #EndDate -->
UTC</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/special.txt"></script>
+<script type="text/javascript" language="javascript" src="scripts/external.txt"></script>
<h4>Table of Contents</h4>
<ul>
- <li class="inline"><a href="#intro">Introduction and Overview</a></li>
- <li class="inline"><a href="#scale">NTP Timescale and Data Formats</a></li>
- <li class="inline"><a href="#budget">Statistics Budget</a></li>
- <li class="inline"><a href="#quality">Quality of Service</a></li>
- <li class="inline"><a href="#house">Clock Initialization and Management</a></li>
+ <li class="inline"><a href="#intro">1. Introduction and Overview</a></li>
+ <li class="inline"><a href="#scale">2. NTP Timescale and Data Formats</a></li>
+ <li class="inline"><a href="#arch">3. Architecture and Algorithms</a></li>
</ul>
<hr>
-<h4 id="intro">Introduction and Overview</h4>
+<h4 align="center">Abstract</h4>
<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>
+ <p align="left"> This page and its dependencies contain 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>. While this page and its dependencies are primarily concerned with NTP, additional information on related protocols can be found in the white papers <a href="http://www.eecis.udel.edu/~mills/ptp.html">IEEE 1588 Precision Time Protocol (PTP)</a> and <a href="http://www.eecis.udel.edu/~mills/proximity.html">Time Synchronization for Space Data Links</a>. Note that reference to a page in this document collection is to a page in the collection, while reference to a <em>white paper</em> is to a document at the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> web site.</p>
</blockquote>
-<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>
+<h4 id="intro">1. Introduction and Overview</h4>
+
+<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet currently 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, directly or indirectly, 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>
+<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 and white papers on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page. An executive summary suitable for management and planning purposes is in the white paper <a href="http://www.eecis.udel.edu/~mills/exec.html">Executive Summary: Computer Network Time Synchronization</a>.</p>
+<h4 id="scale">2. NTP Timescale and Data Formats</h4>
+<p>NTP clients and servers synchronize to the Coordinated Universal Time (UTC) timescale used by national laboratories and disseminated by radio, satellite and telephone modem. This is a global timescale independent of geographic position. There are no provisions to correct for local time zone or daylight savings time; however, these functions can be performed by the operating system on a per-user basis.</p>
+<p> The UT1 timescale, upon which UTC is based, is determined by the rotation of the Earth about its axis. The Earth rotation is gradually slowing down relative to International Atomic Time (TAI). In order to rationalize UTC with respect to TAI, a leap second is inserted at intervals of about 18 months, as determined by the International Earth Rotation Service (IERS). Reckoning with leap seconds in the NTP timescale is described in the white paper <a href="http://www.eecis.udel.edu/~mills/leap.html">The NTP Timescale and Leap Seconds</a>.</p>
+<p>The historic insertions are documented in the <tt>leap-seconds.list</tt> file, which can be downloaded from the NIST FTP servers. 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>. Implementation details are described on the <a href="leap.html">Leap Second Processing</a> page.</p>
+<div align="center">
+<img src="pic/time1.gif" alt="gif">
+<p>Figure 1. NTP Data Formats</p>
+</div>
+<p>Figure 1 shows two NTP time formats, a 64-bit <em>timestamp</em> format and a 128-bit <em>datestamp</em> format. The datestamp 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="arch">3. Architecture and Algorithms</h4>
<div align="center">
<p><img src="pic/fig_3_1.gif" alt="gif"></p>
- <p>Figure 1. NTP Daemon Processes and Algorithms</p>
+ <p>Figure 2. NTP Daemon Processes and Algorithms</p>
</div>
-<p>The overall organization of the NTP
design is shown in Figure 1. It is useful in this context to consider the design as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. Packets are exchanged between the client and server using the <em>on-wire protocol</em> described in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>. The protocol is resistant to lost, replayed or spoofed packets.</p>
-<p> The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The intervals are managed as described on the <a href="poll.html">Poll Program</a> page to maximize accuracy while minimizing network load. The peer process receives NTP packets and performs the packet sanity tests of the <a href="decode.html#flash">flash status word</a>. The flash status word reports in addition the results of various access control and security checks described in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>.</p>
+<p>The overall organization of the NTP
architecture is shown in Figure 2. It is useful in this context to consider the implementation as both a client of upstream (lower stratum) servers and as a server for downstream (higher stratum) clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. Packets are exchanged between the client and server using the <em>on-wire protocol</em> described in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>. The protocol is resistant to lost, replayed or spoofed packets.</p>
+<p> The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The intervals are managed as described on the <a href="poll.html">Poll Process</a> page to maximize accuracy while minimizing network load. The peer process receives NTP packets and performs the packet sanity tests described on the <a href="decode.html">Event Messages and Status Words</a> page and <a href="decode.html#flash">flash status word</a>. The flash status word reports in addition the results of various access control and security checks described in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>. A sophisticated traffic monitoring facility described on the <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a> page protects against denial-of-service (DoS) attacks.</p>
<p>Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process runs the on-wire protocol that uses four raw timestamps: the <em>origin timestamp</em> <em>T</em><sub>1</sub> upon departure of the client request, the <em>receive timestamp</em> <em>T</em><sub>2</sub> upon arrival at the server, the <em>transmit timestamp</em> <em>T</em><sub>3</sub> upon departure of the server reply, and the <em>destination timestamp</em> <em>T</em><sub>4</sub> upon arrival at the client. These timestamps, which are recorded by the <tt>rawstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command, are used to calculate the clock offset and roundtrip delay samples:</p>
<div align="center">
<p>offset = [(<em>T</em><sub>2</sub> -<em> T</em><sub>1</sub>) + (<em>T</em><sub>3</sub> - <em>T</em><sub>4</sub>)] / 2,<br>
delay = (<em>T</em><sub>4</sub> - <em>T</em><sub>1</sub>) - (<em>T</em><sub>3</sub> - <em>T</em><sub>2</sub>).</p>
</div>
-<p>The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page selects the offset and delay samples most likely to produce accurate results. Those servers that have passed the sanity tests are declared <em>selectable</em>. From the selectable population the statistics are used by the algorithm described on the <a href="select.html">Clock Select Algorithm</a> page to determine a number of <em>truechimers</em> according to correctness principles. From the truechimer population the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page determines a number of <em>survivors</em> on the basis of statistical clustering principles. The algorithms described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page combine the survivor offsets, designate one of them as the <em>system peer</em> and produces the final offset used by the algorithm described on the <a href="discipline.html">Clock Discipline Algorithm</a> page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. For additional details about these algorithms, see the Architecture Briefing on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
-<h4 id="scale">NTP Timescale and Data Formats</h4>
-<p>NTP clients and servers synchronize to the Coordinated Universal Time (UTC) timescale used by national laboratories and disseminated by radio, satellite and telephone modem. This is a global timescale independent of geographic position. There are no provisions for local time zone or daylight savings time; however, these functions can be performed by the operating system on a per-user basis.</p>
-<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 relative to International Attomic Time (TAI). In order to rationalize UTC with respect to TAI, 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 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 source. 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</tt> 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 a valid 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. When a source becomes unreachable, a dummy sample with "infinite" dispersion is inserted in the shift register at each poll, thus displacing old samples. This causes the peeer dispersion to increase eventually to infinity.</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>
-<h4 id="quality">Quality of Service</h4>
-<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 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 continues 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>
-<h4 id="house">Clock Initialization and Management</h4>
-<p>If left running continuously, an NTP client on a fast LAN in a home or office environment can maintain synchronization nominally within one millisecond. When the ambient temperature variations are less than a degree Celsius, the clock oscillator frequency is disciplined to within one part per million (PPM), even when the clock oscillator native frequency offset is 100 PPM or more.</p>
-<p> For laptops and portable devices when the power is turned off, the battery backup clock offset error can increase as much as one second per day. When power is restored after several hours or days, the clock offset and oscillator frequency errors must be resolved by the clock discipline algorithm, but this can take several hours without specific provisions.</p>
-<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 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>
+<p>In this description the transmit timestamps <em>T</em><sub>1</sub> and <em>T</em><sub>3</sub> are <em>softstamps</em> measured by the inline code. Softstamps are subject to various queuing and processing delays. A more accurate measurement uses <em>drivestamps</em>, as described on the <a href="xleave.html">NTP Interleaved Modes</a> page. These issues along with mathematical models are discussed in the white paper <a href="http://www.eecis.udel.edu/~mills/time.html">NTP Timestamp Calculations</a>.</p>
+<p>The offset and delay statistics for one or more peer processes are processed by a suite of mitigation algorithms. The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page selects the offset and delay samples most likely to produce accurate results. Those servers that have passed the sanity tests are declared <em>selectable</em>. From the selectable population the statistics are used by the algorithm described on the <a href="select.html">Clock Select Algorithm</a> page to determine a number of <em>truechimers</em> according to Byzantine agreement and correctness principles. From the truechimer population the algorithm described on the <a href="cluster.html">Clock Cluster Algorithm</a> page determines a number of <em>survivors</em> on the basis of statistical clustering principles.</p>
+<p> The algorithms described on the <a href="prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page combine the survivor offsets, designate one of them as the <em>system peer</em> and produces the final offset used by the algorithm described on the <a href="discipline.html">Clock Discipline Algorithm</a> page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command. For additional details about these algorithms, see the Architecture Briefing on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page. For additional information on statistacl principles and performance metrics, see the <a href="stats.html">Performance Metrics</a> page.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>You need a little magic.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->15-May-2011 1:30<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->06-Jun-2012 14:59<!-- #EndDate -->
UTC</p>
<br clear="left">
<hr>
<p>In the protocol described in the NTP specification and reference implementation up to now, the transmit timestamp, which is captured before the message digest is computed and the packet queued for output, is properly called as a <em>softstamp</em> The receive timestamp, which is captured after the input driver interrupt routine and before the packet is queued for input, is properly called a <em>drivestamp</em>. For enhanced accuracy it is desirable to capture the transmit timestamp as close to the wire as possible; for example, after the output driver interrupt routine.</p>
<p> In other words, we would like to replace the transmit softstamp with a drivestamp, but the problem is the transmit drivestamp is available only after the packet has been sent. A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation. In interleaved modes the transmit drivestamp for one packet is actually carried in the immediately following packet. The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.</p>
-<p> The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine. In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies. The difference between the two timestamps, which is called the interleaved or output delay, varies from 16 <font face="symbol">m</font>s for a dual-core Pentium running FreeBSD 6.1 to 1100 <font face="symbol">m</font>s for a Sun Blade 1500 running Solaris 10.</p>
+<p> The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine. In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies. The difference between the two timestamps, which is called the interleaved or output delay, varies from 16 μs for a dual-core Pentium running FreeBSD 6.1 to 1100 μs for a Sun Blade 1500 running Solaris 10.</p>
<p>Interleaved mode can be used only in NTP symmetric and broadcast modes.
It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> configuration
commands. A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary and interleaved broadcast clients can use the same packets. An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in interleaved mode. </p>
-<p>As demonstrated in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">Interleaved
- Synchronization Protocols for LANs and Space Data Links</a>.</p>
+<p>As demonstrated in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper <a href="http://www.eecis.udel.edu/~mills/proximity.html">Time Synchronization for Space Data Links</a>.</p>
<hr>
<div align="center"> <img src="pic/pogo1a.gif" alt="gif"> </div>
<br>
projects / thirdparty / ntp.git / commitdiff
