+* Documentation updates from Dave Mills.
(4.2.7p59) 2010/10/02 Released by Harlan Stenn <stenn@ntp.org>
* Documentation updates from Dave Mills.
* Variable name cleanup from Dave Mills.
<img src="pic/alice44.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>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->11-Sep-2010 19:15<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Oct-2010 23:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<img src="pic/alice44.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>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Sep-2010 3:08<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Oct-2010 23:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
+<hr>
<h4>Commands and Options</h4>
<p>Unless noted otherwise, further information about these commands is on the <a href="authentic.html">Authentication Support</a> page.</p>
<dl>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Clock Cluster Algorithm</title>
+<link href="scripts/style.css" type="text/css" rel="stylesheet">
+</head>
+<body>
+<em></em>
+<h3>Clock Cluster Algorithm</h3>
+<p>Last update:
+ <!-- #BeginDate format:En2m -->04-Oct-2010 2:42<!-- #EndDate -->
+ UTC</p>
+<hr>
+<p>The clock cluster algorithm processes the truechimers produced by the clock select algorithm to produce the survivors used by the mitigation algorithms to discipline the system clock. It 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 results. This page discusses the algorithm in detail.</p>
+<p>First, the truechimer candidates are saved on a list of <em>n</em> entries sorted by root distance. For the <em>i</em>th entry on the list, a statistic called the <em>select jitter</em> 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>),</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. Then, the select jitter <font face="symbol">j</font><sub>S</sub>(<em>i</em>) of the <em>i</em>th entry is the root distance of the <em>i</em>th entry times the RMS sum of <em>d<sub>i</sub></em>(<em>j</em>)<em> </em>as <em>j</em> ranges from 1 to <em>n</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 entry. In general, the <em>expected error</em> statistic for the <em>i</em>th entry is the RMS sum of these two components, but that is not needed by the clock cluster algorithm.</p>
+<p>The object at each round is to prune the entry with the largest select jitter 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. The list is always pruned to the <em>maxclock threshold</em> with default 10, but can be set by the <tt>maxclock</tt> option of the <tt>tos</tt> command. This threshold is useful to limit the number of survivors when automatic server discovery schemes are in use.</p>
+<p>The termination condition has two parts. First, if the number of candidates is not greater than the <em>sane threshold</em> set by the <tt>minsane</tt> option of the <tt>tos</tt> command, or not greater than the <em>minclock threshold</em> set by the <tt>minclock</tt> option of the <tt>tos</tt> command, the pruning process terminates. The <tt>minsane</tt> default is 1 and the <tt>minclock</tt> default is 3. These thresholds can be changed to fit special conditions, as described on the Mitigation Rules and the prefer Keyword 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 candidates 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 entries 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><em>, </em>the algorithm prunes candidate 1 and continues. 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 will not reduce select jitter. So, the algorithm terminates with candidates 2, 3 and 4 as survivors.</p>
+<hr>
+<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+</body>
+</html>
<img src="pic/alice38.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carrol</a>
<p>The Mad Hatter says "Bring it on".</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->07-Sep-2010 2:11<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Oct-2010 23:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/miscopt.txt"></script>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+<hr>
+<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
<img src="pic/pogo.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We make house calls and bring our own bugs.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->03-Sep-2010 21:44<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->02-Oct-2010 23:54<!-- #EndDate -->
UTC</p>
-<h4>More Help</h4>
+ <br clear="left">
+ <h4>More Help</h4>
<script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<hr>
<h4>Initial Startup</h4>
<img src="pic/pogo7.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>Racoon is shooting configuration bugs.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Sep-2010 3:45<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->03-Oct-2010 1:48<!-- #EndDate -->
UTC</p>
<br clear="left">
-<hr>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#synopsis">Synopsis</a></li>
<li class="inline"><a href="#detailed">Detailed Description</a></li>
<li class="inline"><a href="#guidelines">Guidelines for Adding Configuration Commands </a></li>
</ul>
+<hr>
<h4 id="synopsis">Synopsis</h4>
<p>The NTP configuration process is driven by a phrase-structure grammar which is used to specify the format of the configuration commands and the actions needed to build an abstract syntax tree (AST). The grammar is fed to a parser generator (Bison) which produces a parser for the configuration file.</p>
<p>The generated parser is used to parse an NTP configuration file and check it for syntax and semantic errors. The result of the parse is an AST, which contains a representation of the various commands and options. This AST is then traversed to set up the NTP daemon to the correct configuration.</p>
<img src="pic/oz2.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>The Wizard of Oz</i>, L. Frank Baum</a>
<p>All in a row.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->04-Sep-2010 14:31<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->03-Oct-2010 1:48<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<li><a href="#configuration">Configuration</a></li>
<li><a href="#sample">Sample Configuration File</a></li>
</ul>
+<hr>
<h4 id="description">Description</h4>
<p>The ntpdsim program is used to simulate and study the behavior of an NTP daemon that derives its time from a number of different simulated time sources (servers). Each simulated server can be configured to have a different time offset, frequency offset, propagation delay, processing delay, network jitter and oscillator wander.</p>
<p>The ntpdsim program runs all the same selection, mitigation, and discipline
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Clock Select Algorithm</title>
+<link href="scripts/style.css" type="text/css" rel="stylesheet">
+</head>
+<body><em></em>
+<h3>Clock Select Algorithm</h3>
+<p>Last update:
+ <!-- #BeginDate format:En2m -->30-Sep-2010 19:59<!-- #EndDate -->
+ UTC</p>
+<hr>
+<p>The clock select algorithm determines from a set of candidates, which are correct (<em>truechimers</em>) and which are not (<em>falsetickers</em>) according to a set of formal correctness assertions. The principles are based on the observation that the maximum error in determining the offset of a candidate cannot exceed one-half the roundtrip delay to the primary reference clock at the time of measurement. This must be increased by the maximum error that can accumulate since then. In NTP the total, called the <em>synchronization distance</em>, is one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here.</p>
+<p>Given the measured offset <font face="symbol">q<sub>0</sub></font> and synchronization distance <font face="symbol">l</font>, this defines a <em>correctness interval</em> [<font face="symbol">q<sub>0</sub></font> - <font face="symbol">l</font>, <font face="symbol">q<sub>0</sub></font> + <font face="symbol">l</font>] of points where the true value of <font face="symbol">q</font> lies somewhere on the interval. The given problem is to determine from a set of correctness intervals, which represent truechimers and which represent falsetickers. The principles must be given a precise definition. The <em>intersection interval</em> is the smallest interval containing points from the largest number of correctness intervals. An algorithm that finds the intersection interval was devised by Keith Marzullo in his doctoral dissertation. It was first implemented in the DTSS (Digital Time Synchronization Service) in the VMS operating system for the VAX.</p>
+<p> While the NTP algorithm is based on DTSS, it remains to establish which point represents the best estimate of the offset for each candidate. The best point is at the midpoint <font face="symbol">q<sub>0</sub></font> of the correctness interval; however, the midpoint might not be within the intersection interval. A candidate with a correctness interval that contains points in the intersection interval is a truechimer and the best offset estimate is the midpoint of its correctness interval. A candidate with a correctness interval that contains no points in the intersection interval is a falseticker.</p>
+<div align="center"><img src="pic/flt3.gif" alt="gif">
+ <p>Figure 1. Intersection Interval</p>
+</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.</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>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 may be empty, due to insignificant differences in the reference clock offsets. To avoid this, the synchronization distance must be at least 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>
+</html>
<body>
<h3>How NTP Works</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->30-Sep-2010 21:39<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->03-Oct-2010 1:48<!-- #EndDate -->
UTC</p>
+<h4>Related Links</h4>
+<script type="text/javascript" language="javascript" src="scripts/special.txt"></script>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction and Overview</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="#prefer">Mitigation Algorithm</a></li>
- <li class="inline"><a href="#clock">Clock Discipline Algorithm</a></li>
- <li class="inline"><a href="#state">Clock State Machine</a></li>
</ul>
<hr>
<h4 id="intro">Introduction and Overview</h4>
<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in late 2010 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
-<p> The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio and telephone mdem. Stratum 2 (secondary) servers at the next higher level are synchronize 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> 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 and telephone modem. Stratum 2 (secondary) servers at the next higher level are synchronize 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 daemon included in this distribution. We refer to this as the <em>reference implementation</em> only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<div align="center">
<p><img src="pic/fig_3_1.gif" alt="gif"></p>
<p>Figure 1. NTP Daemon Processes and Algorithms</p>
</div>
-<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon 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. The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and runs the on-wire protocol that collects four 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 are used to calculate the clock offset and roundtrip delay:</p>
+<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon 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. The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and runs the on-wire protocol that collects 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 as 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:</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 uses a window of offset and delay samples to select the best ones. Those sources that have passed a number of sanity checks 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 Algori
htm</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. For additional details about these algorithms, see the Architecture Briefing on the <a href="htttp://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
+<p>The algorithm described on the <a href="filter.html">Clock Filter Algorithm</a> page uses a window of offset and delay samples to select the best ones. Those sources that have passed a number of sanity checks 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 Algori
thm</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. For additional details about these algorithms, see the Architecture Briefing on the <a href="htttp://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<h4 id="budget">Statistics Budget</h4>
-<p>Each source is characterized by the offset and delay measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm. This algorithm selects the offset sample with the lowest delay, which generally represents the most accurate data, so it and the associated offset sample become the peer variables of the same name. The peer dispersion is determined as a weighted average of the dispersion samples in the shift register. It continues to grow at the same rate as the sample dispersion. Finally, the peer jitter is determined as the root-mean-square (RMS) average of the offset samples in the shift register relative to the selected offset sample.</p>
+<p>Each source is characterized by the offset and delay measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm. This algorithm selects the offset sample with the lowest delay, which generally represents the most accurate data, so it and the associated offset sample become the <em>peer offset</em> and <em>peer delay</em>. The <em>peer dispersion</em> is determined as a weighted average of the dispersion samples in the shift register. It continues to grow at the same rate as the sample dispersion. Finally, the <em>peer jitter</em> is determined as the root-mean-square (RMS) average of the offset samples in the shift register relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter are recorded as the <tt>peerstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</p>
<p> The clock filter algorithm continues to process packets in this way until the source is no longer reachable. Reachability is determined by an eight-bit shift register, which is shifted left by one bit as each poll packet is sent, with 0 replacing the vacated rightmost bit. Each time an update is received, the rightmost bit is set to 1. The source is considered reachable if any bit is set to 1 in the register; otherwise, it is considered unreachable.</p>
<p> A server is considered selectable only if it is reachable and a timing loop would not be created. A timing loop occurs when the server is apparently synchronized to the client or when the server is synchronized to the same server as the client. When a source is unreachable, a dummy sample with "infinite" dispersion is inserted in the shift register at each poll, thus displacing old samples.</p>
-<p>The composition of the survivor population and the system peer selection is redetermined as each update from each source is received. The system variables are copied from the system peer variables of the same name and the system stratum set one greater than the system peer stratum. Like peer dispersion, the system dispersion increases at the same rate so, even if all sources have become unreachable, the daemon appears to upstratum clients at ever increasing dispersion.</p>
+<p>The composition of the survivor population and the system peer selection is redetermined as each update from each source is received. The system variables are copied from the system peer variables of the same name and the system stratum set one greater than the system peer stratum. Like peer dispersion, the system dispersion increases at the same rate so, even if all sources have become unreachable, the daemon appears to dependent clients at ever increasing dispersion. It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.</p>
<h4 id="quality">Quality of Service</h4>
-<p>Of interest in this discussion is how the protocol determines the quality of service from a particular reference clock or remote server. It is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error is determined from various jitter components; it represents the nominal error in determining the mean clock offset. However, it is not relevant to the discussion to follow. Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify this presentation, certain minor contribution s to the maximum error statistic are ignored. Elsewhere in this documentation the maximum error is called <em>synchronization distance</em>.</p>
-<p>The maximum error is computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion. </p>
-<p>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. A common consequences is when an upstream server loses all sources and its maximum error apparent to clients begins to increase. The clients are not aware of this condition and continues to accept synchronization as long as the maximum error is less than the select threshold.</p>
+<p>Of interest in this discussion is how the protocol determines the quality of service from a particular reference clock or remote server. It is determined from two statistics, <em>expected error</em> and <em>maximum error.</em> Expected error is determined from various jitter components; it represents the nominal error in determining the mean clock offset. The mitigation algorithms deliver two important statistics, <em>system offset</em> and <em>system jitter</em>. These statistics are determined by the mitigation algorithms's from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported as the <tt>loopstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command.</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 this presentation, certain minor contribution s to the maximum error statistic are ignored. Elsewhere in this documentation the maximum error is called <em>synchronization distance</em>. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the <tt>ntp_gettimeofday()</tt> kernel system call. See the <a href="kern.html">Kernel Model for Precision Timekeeping</a> page for further information.</p>
+<p>The maximum error is computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.</p>
+<p>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 consequences is when an upstream server loses all sources and its maximum error apparent to dependent clients begins to increase. The clients are not aware of this condition and continues to accept synchronization as long as the maximum error is less than the select threshold.</p>
<p>Although it might seem counter-intuitive, 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 select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. 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 of the 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="prefer">Mitigation Algorithms</h4>
-<p>Some daemon configurations include a combination of reference clocks and remote servers in order to provide redundancy and backup. For example, a modem reference clock may furnish backup for a GPS reference clock, but used only if the GPS clock fails. In addition, the local clock might be used if all sources fail, or orphan mode might be used instead. The mitigation algorithms provide an orderly selection in such cases. Another function of these algorithms is when multiple sources of the same type are available, but for one reason or another, one or more of them are preferred over the others. Finally, some reference clocks provide a pulse-per-second (PPS) signal to augment the serial timecode. The mitigation algorithms have to figure out when the PPS signal is valid and which reference clock is to number the seconds. These intricate algorithms are described on the <a href="prefer.html">Mitigation Algorithms and the <tt>prefer</tt> Keyword</a> page.</p>
-<h4 id="clock">Clock Discipline Algorithm</h4>
-<p>At the heart of the NTP specification and reference implementation is the clock discipline algorithm, which is best described as an adaptive parameter, hybrid phase/frequency-lock feedback loop. It is an intricately crafted algorithm that automatically adapts for optimum performance while minimizing network overhead. Further details are on the <a href="discipline.html">Clock Discipline</a> page.</p>
-<h4 id="state">Clock State Machine</h4>
-<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. When the frequency file is present at startup is that the residual offset error is less than 0.5 ms within 300 s. When the frequency file is not present, this result is achieved within 600 s. Further details are on the <a href="clock.html">Clock State Machine</a> page.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
projects / thirdparty / ntp.git / commitdiff
