+* Documentation updates from Dave Mills.
* Mitigation and PPS cleanup from Dave Mills.
(4.2.5p161) 2009/03/31 Released by Harlan Stenn <stenn@ntp.org>
* Documentation updates from Dave Mills.
<h3>Command Index</h3>
<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: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">15:17</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="250">Sunday, March 02, 2008</csobj></p>
- <br clear="left">
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 2:56<!-- #EndDate -->
+ UTC</p>
+<br clear="left">
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/accopt.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/authopt.txt"></script>
<h3>Event Messages and Status Words</h3>
<img src="pic/alice47.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>Caterpillar knows all the error codes, which is more than most of us do.</p>
- <p>Last update:<csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="237"> July 5, 2008</csobj></p>
- <br clear="left">
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 2:42<!-- #EndDate -->
+ UTC</p>
+ <br clear="left">
<h4>Related Links</h4>
-
<p><script type="text/javascript" language="javascript" src="scripts/install.txt"></script></p>
+ <p><script type="text/javascript" language="javascript" src="scripts/install.txt"></script></p>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a>
<h3>The Network Time Protocol (NTP) Distribution</h3>
<img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">16:21</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="289">Wednesday, March 12, 2008</csobj></p>
- <p>Note: These pages are being updated and may appear a little scruffy for awhile.</p>
- <br clear="left">
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 2:53<!-- #EndDate -->
+ UTC</p>
+<br clear="left">
<h4>Related Links</h4>
<ul>
<li>A list of all links is on the <a href="sitemap.html">Site Map</a> page.</li>
<h3>Miscellaneous Options</h3>
<img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>We have three, now looking for more.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">23:15</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="289">Wednesday, March 12, 2008</csobj></p>
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 3:28<!-- #EndDate -->
+ UTC</p>
<br clear="left">
- <h4>Related Links</h4>
+ <h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/miscopt.txt"></script>
<hr>
<dl>
- <dt id="broadcastdelay"><tt>broadcastdelay <i>seconds</i></tt>
- <dd>The broadcast and multicast modes require a special calibration to determine the network delay between the local and remote servers. Ordinarily, this is done automatically by the initial protocol exchanges between the client and server. In some cases, the calibration procedure may fail due to network or server access controls, for example. This command specifies the default delay to be used under these circumstances. Typically (for Ethernet), a number between 0.003 and 0.007 seconds is appropriate.
- <dt id="driftfile"><tt>driftfile <i>driftfile</i> { <i>tolerance</i> ]</tt>
- <dd>This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator. This is the same operation as the <tt>-f</tt> command linke option. If the file exists, it is read at startup in order to set the initial frequency and then updated once per hour or more with the current frequency computed by the daemon. If the file name is specified, but the file itself does not exist, the starts with an initial frequency of zero and creates the file when writing it for the first time. If this command is not given, the daemon will always start with an initial frequency of zero.
- <p>The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version. This implies that <tt>ntpd</tt> must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.</p>
- <p>The parameter <tt>tolerance</tt> is the wander threshold to skip writing the new value. If the value of wander computed from recent frequency changes is greater than this threshold the file will be updated once per hour. If below the threshold, the file will not be written.</p>
+ <dt id="broadcastdelay"><tt>broadcastdelay <i>seconds</i></tt></dt>
+ <dd>The broadcast and multicast modes require a special calibration to determine the network delay between the local and remote servers. Ordinarily, this is done automatically by the initial protocol exchanges between the client and server. In some cases, the calibration procedure may fail due to network or server access controls, for example. This command specifies the default delay to be used under these circumstances. Typically (for Ethernet), a number between 0.003 and 0.007 seconds is appropriate.</dd>
+ <dt id="driftfile"><tt>driftfile <i>driftfile</i> { <i>tolerance</i> ]</tt></dt>
+ <dd>This command specifies the complete path and name of the file used to record the frequency of the local clock oscillator. This is the same operation as the <tt>-f</tt> command linke option. If the file exists, it is read at startup in order to set the initial frequency and then updated once per hour or more with the current frequency computed by the daemon. If the file name is specified, but the file itself does not exist, the starts with an initial frequency of zero and creates the file when writing it for the first time. If this command is not given, the daemon will always start with an initial frequency of zero.</dd>
+ <dd>The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version. This implies that <tt>ntpd</tt> must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.</dd>
+ <dd>The parameter <tt>tolerance</tt> is the wander threshold to skip writing the new value. If the value of wander computed from recent frequency changes is greater than this threshold the file will be updated once per hour. If below the threshold, the file will not be written.</dd>
<dt id="enable"><tt>enable [ auth | bclient | calibrate | kernel | monitor | ntp | pps | stats]</tt><br>
- <tt>disable [ auth | bclient | calibrate | kernel | monitor | ntp | pps | stats ]</tt>
+ <tt>disable [ auth | bclient | calibrate | kernel | monitor | ntp | pps | stats ]</tt></dt>
<dd>Provides a way to enable or disable various system options. Flags not mentioned are unaffected. Note that all of these flags can be controlled remotely using the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program.
<dl>
- <dt><tt>auth</tt>
- <dd>Enables the server to synchronize with unconfigured peers only if the peer has been correctly authenticated using either public key or private key cryptography. The default for this flag is enable.
- <dt><tt>bclient</tt>
- <dd>Enables the server to listen for a message from a broadcast or multicast server, as in the <tt>multicastclient</tt> command with default address. The default for this flag is disable.
- <dt><tt>calibrate</tt>
- <dd>Enables the calibrate feature for reference clocks. The default for this flag is disable.
- <dt><tt>kernel</tt>
- <dd>Enables the kernel time discipline, if available. The default for this flag is enable if support is available, otherwise disable.
- <dt><tt>monitor</tt>
- <dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program and the <tt>monlist</tt> command or further information. The default for this flag is enable.
- <dt><tt>ntp</tt>
- <dd>Enables time and frequency discipline. In effect, this switch opens and closes the feedback loop, which is useful for testing. The default for this flag is enable.
- <dt><tt>pps</tt>
- <dd>Enables the pulse-per-second (PPS) signal when frequency and time is disciplined by the precision time kernel modifications. See the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page for further information. The default for this flag is disable.
- <dt><tt>stats</tt>
- <dd>Enables the statistics facility. See the <a href="monopt.html">Monitoring Options</a> page for further information. The default for this flag is disable
+ <dt><tt>auth</tt></dt>
+ <dd>Enables the server to synchronize with unconfigured peers only if the peer has been correctly authenticated using either public key or private key cryptography. The default for this flag is enable.</dd>
+ <dt><tt>bclient</tt></dt>
+ <dd>Enables the server to listen for a message from a broadcast or multicast server, as in the <tt>multicastclient</tt> command with default address. The default for this flag is disable.</dd>
+ <dt><tt>calibrate</tt></dt>
+ <dd>Enables the calibrate feature for reference clocks. The default for this flag is disable.</dd>
+ <dt><tt>kernel</tt></dt>
+ <dd>Enables the kernel time discipline, if available. The default for this flag is enable if support is available, otherwise disable.</dd>
+ <dt><tt>monitor</tt></dt>
+ <dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program and the <tt>monlist</tt> command or further information. The default for this flag is enable.</dd>
+ <dt><tt>ntp</tt></dt>
+ <dd>Enables time and frequency discipline. In effect, this switch opens and closes the feedback loop, which is useful for testing. The default for this flag is enable.</dd>
+ <dt><tt>pps</tt></dt>
+ <dd>Enables the pulse-per-second (PPS) signal when frequency and time is disciplined by the precision time kernel modifications. See the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page for further information. The default for this flag is disable.</dd>
+ <dt><tt>stats</tt></dt>
+ <dd>Enables the statistics facility. See the <a href="monopt.html">Monitoring Options</a> page for further information. The default for this flag is disable.</dd>
</dl>
- <dt id="includefile"><tt>includefile <i>includefile</i></tt>
- <dd>This command allows additional configuration commands to be included from a separate file. Include files may be nested to a depth of five; upon reaching the end of any include file, command processing resumes in the previous configuration file. This option is useful for sites that run <tt>ntpd</tt> on multiple hosts, with (mostly) common options (e.g., a restriction list).
- <dt id="leapfile"><tt>leapfile <i>leapfile</i></tt>
- <dd>This command loads the NIST leapseconds file and initializes the leapsecond values for the next leapsecond time, expiration time and TAI offset. The file can be obtained directly from NIST national time servers using <tt>ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.
+ <dt id="includefile"><tt>includefile <i>includefile</i></tt></dt>
+ <dd>This command allows additional configuration commands to be included from a separate file. Include files may be nested to a depth of five; upon reaching the end of any include file, command processing resumes in the previous configuration file. This option is useful for sites that run <tt>ntpd</tt> on multiple hosts, with (mostly) common options (e.g., a restriction list).</dd>
+ <dt id="leapfile"><tt>leapfile <i>leapfile</i></tt></dt>
+ <dd>This command loads the NIST leapseconds file and initializes the leapsecond values for the next leapsecond time, expiration time and TAI offset. The file can be obtained directly from NIST national time servers using <tt>ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.</dd>
<p>While not strictly a security function, the Autokey protocol provides means to securely retrieve the current or updated leapsecond values from a server.</p>
<dt id="logconfig"><tt>logconfig <i>configkeyword</i></tt>
<dd>This command controls the amount and type of output written to the system <tt>syslog</tt> facility or the alternate <tt>logfile</tt> log file. All <i><tt>configkeyword</tt></i> keywords can be prefixed with <tt>=</tt>, <tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the <tt>syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages. <tt>syslog messages</tt> can be controlled in four classes (<tt>clock</tt>, <tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>). Within these classes four types of messages can be controlled: informational messages (<tt>info</tt>), event messages (<tt>events</tt>), statistics messages (<tt>statistics</tt>) and status messages (<tt>status</tt>).
</dl>
<dt id="logfile"><tt>logfile <i>logfile</i></tt>
<dd>This command specifies the location of an alternate log file to be used instead of the default system <tt>syslog</tt> facility. This is the same operation as the <tt>-l </tt>command line option.
- <dt id="phone"><tt>phone <i>dial</i>1 <i>dial</i>2 ...</tt>
- <dd>This command is used in conjunction with the ACTS modem driver (type 18). The arguments consist of a maximum of 10 telephone numbers used to dial USNO, NIST or European time services. The Hayes command ATDT is normally prepended to the number, which can contain other modem control codes as well.
- <dt id="setvar"><tt>setvar <i>variable</i> [default]</tt>
+ <dt id="phone"><tt>phone <i>dial</i>1 <i>dial</i>2 ...</tt></dt>
+ <dd>This command is used in conjunction with the ACTS modem driver (type 18). The arguments consist of a maximum of 10 telephone numbers used to dial USNO, NIST or European time services. The Hayes command ATDT is normally prepended to the number, which can contain other modem control codes as well.</dd>
+ <dt id="setvar"><tt>setvar <i>variable</i> [default]</tt></dt>
<dd>This command adds an additional system variable. These variables can be used to distribute additional information such as the access policy. If the variable of the form <tt><i>name</i> = <i>value</i></tt> is followed by the <tt>default</tt> keyword, the variable will be listed as part of the default system variables (<tt>ntpq rv</tt> command). These additional variables serve informational purposes only. They are not related to the protocol other that they can be listed. The known protocol variables will always override any variables defined via the <tt>setvar</tt> mechanism. There are three special variables that contain the names of all variable of the same group. The <tt>sys_var_list</tt> holds the names of all system variables. The <tt>peer_var_list</tt> holds the names of all peer variables and the <tt>clock_var_list</tt> holds the names of the reference clock variables.
- <dt id="tinker"><tt>tinker [ allan <i>allan</i> | dispersion <i>dispersion</i> | freq <i>freq</i> | huffpuff <i>huffpuff</i> | panic <i>panic</i> | step <i>step</i> | stepout <i>stepout</i> ]</tt>
+ <dt id="tinker"><tt>tinker [ allan <i>allan</i> | dispersion <i>dispersion</i> | freq <i>freq</i> | huffpuff <i>huffpuff</i> | panic <i>panic</i> | step <i>step</i> | stepout <i>stepout</i> ]</tt></dt>
<dd>This command alters certain system variables used by the clock discipline algorithm. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. The options are as follows:
<p><tt>allan <i>allan</i></tt></p>
<dl>
<dd>Spedifies the Allan intercept, which is a parameter of the PLL/FLL clock discipline algorithm, in seconds with default 1500 s.
- <dt><tt>dispersion <i>dispersion</i></tt>
+ <dt><tt>dispersion <i>dispersion</i></tt></dt>
<dd>Specifies the dispersion increase rate in parts-per-million (PPM) with default 15 PPM.<dt><tt>freq <i>freq</i></tt>
<dd>Spedifies the frequency offset in parts-per-million (PPM) with default the value in the frequency file.<dt><tt>huffpuff <i>huffpuff</i></tt>
<dd>Spedifies the huff-n'-puff filter span, which determines the most recent interval the algorithm will search for a minimum delay. The lower limit is 900 s (15 m), but a more reasonable value is 7200 (2 hours).<dt><tt>panic <i>panic</i></tt>
<dd>Spedifies the panic threshold in seconds with default 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted.<dt><tt>step <i>step</i></tt>
<dd>Spedifies the step threshold in seconds with default 0.128 s. If set to zero, step adjustments will never occur. Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than the default.<dt><tt>stepout <i>stepout</i></tt>
<dd>Specifies the stepout threshold in seconds with default 900 s. It If set to zero, popcorn spikes will not be suppressed.</dl>
- <dt id="tos"><tt>tos [ beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> ]</tt> <dd>This command alters certain system variables used by the the clock selection and clustering algorithms. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in dynamic server discovery schemes. The options are as follows:
+ <dt id="tos"><tt>tos [ beacon <i>beacon</i> | ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | maxclock <i>maxclock </i>| maxdist <i>maxdist</i> | minclock <i>minclock</i> | mindist <i>mindist </i>| minsane <i>minsane</i> | orphan <i>stratum</i> ]</tt></dt>
+ <dd>This command alters certain system variables used by the the clock selection and clustering algorithms. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in dynamic server discovery schemes. The options are as follows:</dd>
<dl>
- <dt><tt>beacon <i>beacon</i></tt>
- <dd>The manycast server sends packets at intervals of 64 s if less than <tt>maxclock</tt> servers are available. Otherwise, it sends packets at the <i><tt>beacon</tt></i> interval in seconds. The default is 3600 s. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details. <dt><tt>ceiling <i>ceiling</i></tt>
- <dd>Specify the maximum stratum (exclusive) for acceptable server packets. The default is 16. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details. <dt><tt>cohort { 0 | 1 }</tt>
- <dd>Specify whether (1) or whether not (0) a server packet will be accepted for the same stratum as the client. The default is 0. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.
- <dt><tt>floor <i>floo r</i></tt>
- <dd>Specify the minimum stratum (inclusive) for acceptable server packest. The default is 1. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.
- <dt><tt>maxclock <i>maxclock</i></tt> <dd>Specify the maximum number of servers retained by the server discovery schemes. The default is 10. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.
- <dt><tt>maxdist <i>maxdistance</i></tt>
- <dd>Specify the synchronization distance threshold used by the clock selection algorithm. The default is 1.5 s. This determines both the minimum number of packets to set the system clock and the maximum roundtrip delay. It can be decreased to improve reliability or increased to synchronize clocks on the Moon or planets.<dt><tt>minclock <i>minclock</i></tt>
- <dd>Specify the number of servers used by the clustering algorithm as the minimum to include on the candidate list. The default is 3. This is also the number of servers to be averaged by the combining algorithm.<dt><tt>mindist <i>mindistance</i></tt>
- <dd>Specify the increment used by the selection algorithm to augment the correctness interval. The default is .005 s. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the increment to insure the intersection interval is always nonempty.<dt><tt>minsane <i>minsane</i></tt>
- <dd>Specify the number of servers used by the selection algorithm as the minimum to set the system clock. The default is 1 for legacy purposes; however, for critical applications the value should be somewhat higher but less than <tt>minclock</tt>.
- <dt><tt>orphan <i>stratum</i></tt>
- <dd>Specify the orphan stratum with default 16. If less than 16 this is the stratum assumed by the root servers. See the <a href="assoc.html">Association Management</a> page for further details.
- </dl><dt id="trap"><tt>trap <i>host_address</i> [port <i>port_number</i>] [interface <i>interface_address</i>]</tt>
- <dd>This command configures a trap receiver at the given host address and port number for sending messages with the specified local interface address. If the port number is unspecified, a value of 18447 is used. If the interface address is not specified, the message is sent with a source address of the local interface the message is sent through. Note that on a multihomed host the interface used may vary from time to time with routing changes.
- <p>The trap receiver will generally log event messages and other information from the server in a log file. While such monitor programs may also request their own trap dynamically, configuring a trap receiver will ensure that no messages are lost when the server is started.</p>
- <dt id="ttl"><tt>ttl <i>hop</i> ...</tt>
- <dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31.
+ <dt><tt>beacon <i>beacon</i></tt></dt>
+ <dd>The manycast server sends packets at intervals of 64 s if less than <tt>maxclock</tt> servers are available. Otherwise, it sends packets at the <i><tt>beacon</tt></i> interval in seconds. The default is 3600 s. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.</dd>
+ <dt><tt>ceiling <i>ceiling</i></tt></dt>
+ <dd>Specify the maximum stratum (exclusive) for acceptable server packets. The default is 16. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.</dd>
+ <dt><tt>cohort { 0 | 1 }</tt></dt>
+ <dd>Specify whether (1) or whether not (0) a server packet will be accepted for the same stratum as the client. The default is 0. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.</dd>
+ <dt><tt>floor <i>floor</i></tt></dt>
+ <dd>Specify the minimum stratum (inclusive) for acceptable server packest. The default is 1. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.</dd>
+ <dt><tt>maxclock <i>maxclock</i></tt></dt>
+ <dd>Specify the maximum number of servers retained by the server discovery schemes. The default is 10. See the <a href="manyopt.html">Automatic Server Discovery</a> page for further details.</dd>
+ <dt><tt>maxdist <i>maxdistance</i></tt></dt>
+ <dd>Specify the synchronization distance threshold used by the clock selection algorithm. The default is 1.5 s. This determines both the minimum number of packets to set the system clock and the maximum roundtrip delay. It can be decreased to improve reliability or increased to synchronize clocks on the Moon or planets.</dd>
+ <dt><tt>minclock <i>minclock</i></tt></dt>
+ <dd>Specify the number of servers used by the clustering algorithm as the minimum to include on the candidate list. The default is 3. This is also the number of servers to be averaged by the combining algorithm.</dd>
+ <dt><tt>mindist <i>mindistance</i></tt></dt>
+ <dd>Specify the increment used by the selection algorithm to augment the correctness interval. The default is .005 s. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the increment to insure the intersection interval is always nonempty.</dd>
+ <dt><tt>minsane <i>minsane</i></tt></dt>
+ <dd>Specify the number of servers used by the selection algorithm as the minimum to set the system clock. The default is 1 for legacy purposes; however, for critical applications the value should be somewhat higher but less than <tt>minclock</tt>.</dd>
+ <dt><tt>orphan <i>stratum</i></tt></dt>
+ <dd>Specify the orphan stratum with default 16. If less than 16 this is the stratum assumed by the root servers. See the <a href="assoc.html">Association Management</a> page for further details.</dd>
+ </dl>
+ <dt id="trap"><tt>trap <i>host_address</i> [port <i>port_number</i>] [interface <i>interface_address</i>]</tt></dt>
+ <dd>This command configures a trap receiver at the given host address and port number for sending messages with the specified local interface address. If the port number is unspecified, a value of 18447 is used. If the interface address is not specified, the message is sent with a source address of the local interface the message is sent through. Note that on a multihomed host the interface used may vary from time to time with routing changes.</dd>
+ <dd>The trap receiver will generally log event messages and other information from the server in a log file. While such monitor programs may also request their own trap dynamically, configuring a trap receiver will ensure that no messages are lost when the server is started.</dd>
+ <dt id="ttl"><tt>ttl <i>hop</i> ...</tt></dt>
+ <dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31.</dd>
</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<h3>Monitoring Options</h3>
<img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>Pig was hired to watch the logs.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:47</csobj> UTC <csobj format="LongDate" h="25" locale="00 000409" region="0" t="DateTime" w="0"></csobj></p>
- <br clear="left">
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 2:46<!-- #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/monopt.txt"></script>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
<html>
+<head>
+<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
+<title>Mitigation Rules and the prefer Keyword</title>
+<link href="scripts/style.css" type="text/css" rel="stylesheet">
+</head>
+<body>
+
+<h3>Mitigation Rules and the <tt>prefer</tt> Keyword</h3>
+
+<img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+<p>Listen carefully to what I say; it is very complicated.</p>
+<p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 2:47<!-- #EndDate -->
+UTC</p>
+<br clear="left">
+
+<h4>Related Links</h4>
+
+<script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
+
+<h4>Table of Contents</h4>
+
+<ul>
+
+<li class="inline"><a href="#intro">Introduction</a></li>
+<li class="inline"><a href="#peer">Peer Classification</a></li>
+<li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a></li>
+<li class="inline"><a href="#miti">Mitigation Rules</a></li>
+<li class="inline"><a href="#mins">The <tt>minsane</tt> Option</a></li>
+
+</ul>
+
+<hr>
+
+<h4 id="intro">Introduction</h4>
+
+<p>This page summarizes the criteria for choosing from among a number of potential
+ sources suitable contributors to the clock discipline process. The criteria are very meticulous, since they have to handle many different scenarios that may be optimized for peculiar circumstances, including some scenarios designed to support planetary and deep space missions.</p>
+
+<p>Recall the suite of NTP data acquisition and grooming algorithms as these algorithms proceed in five phases. Phase one discovers the available sources and mobilizes an association for each candidate found. These candidates can result from explicit configuration, broadcast discover or the pool and manycast autonomous configuration schemes. Phase two grooms the selectable candidates excluding those sources showing one or more of the following errors</p>
+
+<ol>
+
+<li>A stratum error occurs if (1) the source had never been synchronized or (2) the stratum of the source is below the <tt>floor</tt> option or not below the <tt>ceiling</tt> option specified by the <tt>tos</tt> command. The default value for these options are 0 and 16, respectively.</li>
+
+<li>A distance error occurs for a remote source if the root distance is not below the distance threshold <tt>maxdist</tt> option of the <tt>tos</tt> command. The default value for this option is 1.5 s for networks including only the Earth, but this should be increased to 2.5 s for networks including the Moon.</li>
+
+<li>A loop error occurs if the source is synchronized to the client of if the source is synchronized to the same source as the client.</li>
+
+<li>An unreachable error occurs if the source is unreachable or if the <tt>server</tt> or <tt>peer</tt> command for the source includes the <tt>noselect</tt> option.</li>
+
+</ol>
+
+<p>Phase three uses an intersection algorithm to select the truechimers from among the candidates, leaving behind the falsetickers. Phase four uses a clustering algorithm to cast off statistically insignificant outliers from the truechimers until a set of survivors not less than the number specified as the <tt>minclock</tt> option of the <tt>tos</tt> command, with default 3. Phase five uses a set of mitigation rules to select from among the survivors a system peer from which a set of system statistics can be inherited and passed along to a dependent client population. The system offset developed from these algorithms can discipline the system clock either using the <tt>ntpd</tt> clock discipline algorithm or enable the kernel to discipline the clock directly, as described on the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. Phase five is the topic of this page.</p>
+
+<h4 id="peer">Peer Classification</h4>
+
+<p>The behavior of the various algorithms and mitigation rules involved depends on how the various synchronization sources are classified. This depends on whether the source is local or remote and if local the type of source. The following classes are defined:</p>
+
+<ol>
+
+<li>A remote server or peer is classified simply as a server. All others are classified as a device driver of one kind or another. In general, one or more sources of either or both types will be configured in each installation.</li>
+
+<li>If all sources have been lost and the orphan stratum specified by the <tt>orphan</tt> option of the <tt>tos</tt> command, a pseudo-source called the <i>orphan parent</i> is created. Dependent orphan children will see the orphan parent as if synchronized to a primary server at the orphan stratum.</li>
+
+<li>When the PPS Clock Discipline driver (type 22) is configured, it is designated the <i>PPS driver.</i> This driver provides precision clock discipline only within +-0.5 s, so is always associated with another source or sources that provide the seconds numbering function.</li>
+
+<li>When the Undisciplined Local Clock driver (type 1) is configured, it is designated the <i>local driver</i>. This driver is used either as a backup source (stratum greater than zero) should all sources fail, or as the primary source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lockclock</tt> scheme, or another synchronization protocol such as the Digital Time Synchronization Service (DTSS).</li>
+
+<li>When the Automated Computer Time Service driver (type 18) is configured, it is designated the <i>modem driver</i>. This is used either as a backup source, should all other sources fail, or as the (only) primary source.</li>
+
+</ol>
+
+<h4 id="prefer">The <tt>prefer</tt> Peer</h4>
+
+<p>The mitigation rules are designed to provide an intelligent selection of the system peer from among the survivors of different types. When used with the <tt>server</tt> or <tt>peer</tt> commands, the <tt>prefer</tt> option designates one or more survivors as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; however, if more than one source is so designated, they are used in the order specified in the configuration file; that is, if the first one becomes unselectable, the second one is used and so forth. This order of priority is also applicable to multiple modem drivers and even multiple local drivers, although that would not normally be useful.</p>
+
+<p>The prefer scheme works on the set of truechimers produced by the intersection algorithms. Ordinarily, any one of them can in principle provide correct time; however, due to various latency variations, not all can provide the most accurate and stable time. The clustering algorithm, which is invoked at this point, operates in one or more rounds to cast off the statistically least significant to the current ensemble until no more than the <tt>minclock</tt> option of the <tt>tos</tt> command are left.</p>
+
+<p>In the prefer scheme the clustering algorithm is modified so that the prefer peer is never discarded; on the contrary, its potential removal becomes a rounds-termination condition. However, the prefer peer can still be discarded by the intersection algorithm as a falseticker. To avoid this, it is usually wise to increase the <tt>mindist</tt> option of the <tt>tos</tt> command from the default .005 s to something like .05 s. s.</p>
+
+<p>Along with this behavior, the clock selection procedures are modified so that the combining algorithm is not used when a prefer peer is present. Instead, the offset of the prefer peer is used exclusively as the synchronization source. In the usual case involving a radio clock and a flock of remote stratum-1 peers, and with the radio clock designated a prefer peer, the result is that the high quality radio time disciplines the server clock as long as the radio itself remains operational and with valid time, as determined from the remote peers, sanity checks and intersection algorithm.</p>
+
+<h4 id="miti">Mitigation Rules</h4>
+
+<p>As the selection algorithm scans the associations for selectable candidates, the modem driver, local driver and PPS driver, are segregated for later, but only if not designated a prefer peer. If so designated, a driver is included among the selectable candidate population along with the others. In addition if orphan servers are found the parent with the lowest distnace is segregated for later; the others are discarded. Here, distance is defined as the IPv4 address of the first four octets of the hashed IPv6 address. The resulting candidates, including the first prefer peer found, are processed by the intersection and clustering algorithms to yield a possibly empty set of survivors. The clustering algorithm ranks the survivors by synchronization distance and designates the survivor with the lowest distance as the potential system peer.</p>
+
+<p>The mitigation algorithm proceeds in three steps in turn.</p>
+
+<ol>
+
+<li>If there are no survivors, the modem driver becomes the only survivor if there is one. If not, the orphan parent becomes the only survivor if there is one. If not, the local driver becomes the only survivor if there is one. If the number of survivors at this point is less than the <tt>minsane</tt> option of the <tt>tos</tt> command, the algorithm is terminated and the system variables remain unchanged. Note that <tt>minsane</tt> is by default 1, but can set at any value including 0.</li>
+
+<li>If the only survivor is the orphan parent, it becomes the system peer and its clock offset and jitter are inherited by the corresponding system variables. Note that by design all the orphan children sharing the same set of potential orphan parents will select the same parent. Otherwise, if the prefer peer is among the survivors, it becomes the system peer and its clock offset and jitter are inherited by the corresponding system variables. If not, the combining algorithm computes these variables from the survivor population.</li>
+
+<li>If there is a PPS driver and the system clock offset produced in step two is less than 0.4 s, the PPS driver is selectable and operation continues in two contingencies. If there is a prefer peer, or if overridden by the <tt>flag1</tt> option of the <tt>fudge</tt> command for the PPS driver, the PPS driver becomes the system peer and its offset and jitter are inherited by the system variables.</li>
+
+</ol>
+
+<p>If none of the above is the case, the data are disregarded and the system variables remain as they are.</p>
+
+<h4 id="mins">The <tt>minsane</tt> Option</H4>
+
+<p> The <tt>minsane</tt> option of the <tt>tos</tt> command, the <tt>prefer</tt> option of the <tt>server</tt> and <tt>peer</tt> commands and the <tt>flag1</tt> option of the <tt>fudge</tt> command for the PPS driver can be used in conjunction with the mitigation rules to provide many useful configurations. The <tt>minsane</tt> option specifies the minimum number of survivors required to synchronized the system clock. The <tt>prefer</tt> option designates the prefer peer. The <tt>flag1</tt> option enables the PPS driver even if no prefer peer is available.</p>
+
+<p>In the intended mode of operation, a GPS clock driver is configured along with the PPS driver and the GPS driver set as the prefer peer. If the serial timecode of the GPS driver is within 0.4 s of the PPS driver, the PPS driver disciplines the system clock. If no GPS satellites are in view, or if the antenna is disconnected, this condition is visible to the GPS driver, which then indicates this by ceasing updates to the <tt>ntpd</tt> daemon. The result is that the GPS driver becomes unreachable and in turn the PPS driver is disabled. This is the preferred behavior, as the holdover stability of the PPS signal from the GPS receiver is no better than the system clock stability.</p>
+
+<p>As in the above scenario, if the <tt>minsane</tt> option is set to 0 and there is a prefer peer, it can be used in the same manner. However, this would normally disable the PPS driver if the prefer peer were to become unavailable. This behavior can be altered with the <tt>flag1</tt> option for the PPS driver. In the default case (dim) the behavior is as above; if lit, the prefer peer is disregarded and the PPS driver is enabled no matter what the state of the prefer peer or if there is no designated prefer peer.</p>
+
+<p>A scenario where the latter behavior can be most useful is for a planetary
+ orbiter fleet, for instance in the vicinity of Mars, where contact between
+ orbiters is only one or two times per Sol (Mars day). These orbiters have a
+ precise timing reference based on a Ultra Stable Oscillator (USO) with accuracy
+ in the order of a Cesium oscillator. A PPS signal is derived from the USO and
+ can be disciplined from Earth on rare occasion or from another orbiter via NTP.
+ In the above scenario the PPS signal disciplines the spacecraft clock between
+ NTP updates.</p>
+
+<p>In a similar scenario a PPS signal can be used to discipline the clock between
+ updates produced by the modem driver. This would provide precise synchronization
+ without needing the Internet at all.</p>
- <head>
- <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
- <title>Mitigation Rules and the prefer Keyword</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
-
- <body>
- <h3>Mitigation Rules and the <tt>prefer</tt> Keyword</h3>
- <img src="pic/alice11.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"> from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
- <p>Listen carefully to what I say; it is very complicated.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:20</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="308">Wednesday, January 02, 2008</csobj></p>
- <br clear="left">
- <h4>Related Links</h4>
- <script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
- <h4>Table of Contents</h4>
- <ul>
- <li class="inline"><a href="#intro">Introduction</a></li>
- <li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a></li>
- <li class="inline"><a href="#peer">Peer Classification</a></li>
- <li class="inline"><a href="#miti">Mitigation Rules</a></li>
- </ul>
- <hr>
- <h4 id="intro">Introduction</h4>
- <p>The mechanics of the NTP algorithms which select the best data sample from each available server and the best subset of the server population have been finely crafted to resist network jitter, faults in the network or server operations, and to deliver the best possible accuracy. Most of the time these algorithms do a good job without requiring explicit manual tailoring of the configuration file. However, there are times when the accuracy can be improved by some careful tailoring. The following sections explain how to do this using explicit configuration items and special signals, when available, that are generated by some radio clocks and laboratory instruments.</p>
- <p>In order to provide robust backup sources, primary (stratum-1) servers are usually operated in a diversity configuration, in which the server operates with a number of remote servers in addition to one or more radio or modem clocks. In these configurations the suite of algorithms used in NTP to refine the data from each peer separately and to select and combine the data from a number of servers and clocks. As the result of these algorithms, a set of <i>survivors</i> are identified which can presumably provide the most reliable and accurate time. Ordinarily, the individual clock offsets of the survivors are combined on a weighted average basis to produce an offset used to control the system clock.</p>
- <p>However, because of small but significant systematic time offsets between the survivors, it is in general not possible to achieve the lowest jitter and highest stability in these configurations. This happens because the selection algorithm tends to <i>clockhop</i> between survivors of substantially the same quality, but showing small systematic offsets between them. In addition, there are a number of configurations involving pulse-per-second (PPS) signals, modem backup services and other special cases, so that a set of mitigation rules becomes necessary to select a single peer from among the survivors. These rules are based on a set of special characteristics of the various remote servers and reference clock drivers specified in the configuration file.</p>
- <h4 id="prefer">The <tt>prefer</tt> Peer</h4>
- <p>The mitigation rules are designed to provide an intelligent selection between various sources of substantially the same statistical quality without compromising the normal operation of the NTP algorithms. While they have been implemented in NTP Version 4 and will be incorporated in the NTP Version 4 specification when published, they are not in the NTP Version 3 specification RFC-1305. The rules are based on the concept of <i>prefer peer</i>, which is specified by including the <tt>prefer</tt> keyword with the associated <tt>server</tt> or <tt>peer</tt> command in the configuration file. This keyword can be used with any server or peer, but is most commonly used with a radio clock. While the rules do not forbid it, it does not seem useful to designate more than one peer as preferred, since the additional complexities to mitigate among them do not seem justified from on-air experience.</p>
- <p>The prefer scheme works on the set of peers that have survived the sanity checks and intersection algorithms of the clock selection procedures. Ordinarily, the members of this set can be considered <i>truechimers</i> and any one of them could in principle provide correct time; however, due to various error contributions, not all can provide the most accurate and stable time. The job of the clustering algorithm, which is invoked at this point, is to select the best subset of the survivors providing the least variance in the combined ensemble average, compared to the variance in each member of the subset separately. The detailed operation of the clustering algorithm, which is given in RFC-1305, is beyond the scope of discussion here. It operates in rounds, where a survivor, presumably the worst of the lot, is discarded in each round until one of several termination conditions is met. An example terminating condition is when the number of survivors is about to be reduced below three.</p>
- <p>In the prefer scheme the clustering algorithm is modified so that the prefer peer is never discarded; on the contrary, its potential removal becomes a termination condition. If the original algorithm were about to toss out the prefer peer, the algorithm terminates immediately. The prefer peer can still be discarded by the sanity checks and intersection algorithm, of course, but it will always survive the clustering algorithm. If it does not survive or for some reason it fails to provide updates, it will eventually become unreachable and the clock selection will remitigate to select the next best source.</p>
- <p>Along with this behavior, the clock selection procedures are modified so that the combining algorithm is not used when a prefer peer is present. Instead, the offset of the prefer peer is used exclusively as the synchronization source. In the usual case involving a radio clock and a flock of remote stratum-1 peers, and with the radio clock designated a prefer peer, the result is that the high quality radio time disciplines the server clock as long as the radio itself remains operational and with valid time, as determined from the remote peers, sanity checks and intersection algorithm.</p>
- <h4 id="peer">Peer Classification</h4>
- <p>In order to understand the effects of the various intricate schemes involved, it is necessary to understand some arcane details on how the algorithms decide on a synchronization source when more than one source is available. This is done on the basis of a set of explicit mitigation rules, which define special classes of remote serves and local radio clocks as a function of configuration declarations and clock driver type:</p>
- <ol>
- <li>The prefer peer is designated using the <tt>prefer</tt> keyword with the <tt>server</tt> or <tt>peer</tt> commands. All other things being equal, this peer will be selected for synchronization over all other survivors of the clock selection procedures.</li>
- <li>When a PPS signal is connected via the PPS Clock Discipline driver (type 22), this is called the <i>PPS peer</i>. This driver provides precision clock corrections only within one second, so is always operated in conjunction with another server or radio clock driver, which provides the seconds numbering. The PPS peer is active only under conditions explained below.</li>
- <li>When the Undisciplined Local Clock driver (type 1) is configured, this is called the <i>local clock peer</i>. This is used either as a backup reference source (stratum greater than zero), should all other synchronization sources fail, or as the primary reference source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lockclock</tt> scheme, or another synchronization protocol, such as the Digital Time Synchronization Service (DTSS).</li>
- <li>When a modem driver such as the Automated Computer Time Service driver (type 18) is configured, this is called the <i>modem peer</i>. This is used either as a backup reference source, should all other primary sources fail, or as the (only) primary reference source.</li>
- <li>Where support is available, the PPS signal may be processed directly by the kernel, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. This is called the <i>kernel discipline</i>. The PPS signal can discipline the kernel in both frequency and time. The frequency discipline is active as long as the PPS interface device and signal itself is operating correctly, as determined by the kernel algorithms. The time discipline is active only under conditions explained below.</li>
- </ol>
- <p>Reference clock drivers operate in the manner described in the <a href="refclock.html">Reference Clock Drivers</a> page and its dependencies. The drivers are ordinarily operated at stratum zero, so that as the result of ordinary NTP operations, the server itself operates at stratum one, as required by the NTP specification. In some cases described below, the driver is intentionally operated at an elevated stratum, so that it will be selected only if no other survivor is present with a lower stratum. In the case of the PPS peer or kernel time discipline, these sources appear active only if the prefer peer has survived the intersection and clustering algorithms, as described below, and its clock offset relative to the current local clock is less than a specified value, currently 128 ms.</p>
- <p>The modem clock drivers are a special case. Ordinarily, the update interval between modem calls to synchronize the system clock is many times longer than the interval between polls of either a remote server or local radio clock. In order to provide the best stability, the operation of the clock discipline algorithm changes gradually from a phase-lock mode at the shorter update intervals to a frequency-lock mode at the longer update intervals. If remote servers or local radio clocks together with a modem peer operate in the same client, the following things can happen.</p>
- <p>First the clock selection algorithm can select one or more remote servers or local radio clocks and the clock discipline algorithm will optimize for the shorter update intervals. Then, the selection algorithm can select the modem peer, which requires a much different optimization. The intent in the design is to allow the modem peer to control the system clock either when no other source is available or, if the modem peer happens to be marked as prefer, then it always controls the clock, as long as it passes the sanity checks and intersection algorithm. There still is room for suboptimal operation in this scheme, since a noise spike can still cause a clockhop either way. Nevertheless, the optimization function is slow to adapt, so that a clockhop or two does not cause much harm.</p>
- <p>The local clock driver is another special case. Normally, this driver is eligible for selection only if no other source is available. When selected, vernier adjustments introduced via the configuration file or remotely using the <tt><a href="ntpdc.html">ntpdc</a> </tt>program can be used to trim the local clock frequency and time. However, if the local clock driver is designated the prefer peer, this driver is always selected and all other sources are ignored. This behavior is intended for use when the kernel time is controlled by some means external to NTP, such as the NIST <tt>lockclock</tt> algorithm or another time synchronization protocol such as DTSS. In this case the only way to disable the local clock driver is to mark it unsynchronized using the leap indicator bits. In the case of modified kernels with the <tt>ntp_adjtime()</tt> system call, this can be done automatically if the external synchronization protocol uses it to discipline the kernel time.</p>
- <h4 id="miti">Mitigation Rules</h4>
- <p>The mitigation rules apply in the intersection and clustering algorithms described in the NTP specification. The intersection algorithm first scans all peers with a persistent association and includes only those that satisfy specified sanity checks. In addition to the checks required by the specification, the mitigation rules require either the local-clock peer or modem peer to be included only if marked as the prefer peer. The intersection algorithm operates on the included population to select only those peers believed to represent the correct time. If one or more peers survive the algorithm, processing continues in the clustering algorithm. Otherwise, if there is a modem peer, it is declared the only survivor; otherwise, if there is a local-clock peer, it is declared the only survivor. Processing then continues in the clustering algorithm.</p>
- <p>The clustering algorithm repeatedly discards outlyers in order to reduce the residual jitter in the survivor population. As required by the NTP specification, these operations continue until either a specified minimum number of survivors remain or the minimum select dispersion of the population is greater than the maximum peer dispersion of any member. The mitigation rules require an additional terminating condition which stops these operations at the point where the prefer peer is about to be discarded.</p>
- <p>The mitigation rules establish the choice of <i>system peer</i>, which determines the stratum, reference identifier and several other system variables which are visible to clients of the server. In addition, they establish which source or combination of sources control the local clock.</p>
- <ol>
- <li>If there is a prefer peer and it is the local-clock peer or the modem peer; or, if there is a prefer peer and the kernel time discipline is active, choose the prefer peer as the system peer and its offset as the system clock offset. If the prefer peer is the local-clock peer, an offset can be calculated by the driver to produce a frequency offset in order to correct for systematic frequency errors. In case a source other than NTP is controlling the system clock, corrections determined by NTP can be ignored by using the <tt>disable pll</tt> in the configuration file. If the prefer peer is the modem peer, it must be the primary source for the reasons noted above. If the kernel time discipline is active, the system clock offset is ignored and the corrections handled directly by the kernel.</li>
- <li>If the above is not the case and there is a PPS peer, then choose it as the system peer and its offset as the system clock offset.</li>
- <li>If the above is not the case and there is a prefer peer (not the local-clock or modem peer in this case), then choose it as the system peer and its offset as the system clock offset.</li>
- <li>If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to clockhopping, when switching the system peer would not materially improve the time accuracy.</li>
- <li>If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification.</li>
- </ol>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+<hr>
+<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
</html>
\ No newline at end of file
<h3>Site Map</h3>
<img src="pic/alice15.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice in Wonderland</i>, Lewis Carroll</a>
<p>Welcome to the tea party.</p>
- <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">02:10</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="252">Monday, March 03, 2008</csobj></p>
- <br clear="left">
- <h4>Related Links</h4>
+ <p>Last update:
+ <!-- #BeginDate format:En2m -->08-Apr-2009 2:54<!-- #EndDate -->
+ UTC<br clear="left">
+ </p>
+ <h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/install.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/manual.txt"></script>
<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
projects / thirdparty / ntp.git / commitdiff
