<h4>Association Modes</h4>
<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the <a href="confopt.htm">Configuration Options</a> and <a href="authopt.htm">Authentication Options</a> pages and in the papers, reports, memoranda and briefings at <a href="http://www.ntp.org">www.ntp.org</a>.</p>
<p>There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message.</p>
- <p>Ordinarily, successful mobilization of an ephemeral association requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric-key or public-key cryptography, as described in the <a href="authopt.htm">Authentication Options</a> page. The cryptographic means insure an unbroken chain of trust between the dependent client and the primary servers at the root of the synchronization subnet. We call this chain the provenance of the client and define new vocabulary as to proventicate a client or provide proventic credentials. Once mobilized, ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) the server refreshes the key media without notifying the client.</p>
+ <p>Ordinarily, successful mobilization of an ephemeral association requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric-key or public-key cryptography, as described in the <a href="authopt.htm">Authentication Options</a> page. The cryptographic means insure an unbroken chain of trust between the dependent client and the primary servers at the root of the synchronization subnet. We call this chain the <i>provenance</i> of the client and define new vocabulary as to proventicate a client or provide proventic credentials. Once mobilized, ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) the server refreshes the key media without notifying the client.</p>
<p>There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP Multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and proventic values and means of configuration. Following is a summary of the operations in each mode.</p>
<h4>Client/Server Mode</h4>
- <p>Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and proventic values from the server. A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or address; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme. In addition, two burst modes described below can be used in appropriate cases.</p>
+ <p>Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and proventic values from the server. A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme. In addition, two burst modes described below can be used in appropriate cases.</p>
<h4>Symmetric Active/Passive Mode</h4>
<p>Symmetric active/passive mode is intended for configurations were a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a radio clock, or a subset of secondary servers known to be reliable and proventicated. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and proventication values can flow from the surviving peers to all the others in the clique. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and proventic values depending on the particular configuration.</p>
- <p>Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.</p>
+ <p>Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer IPv4 or IPv6 DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.</p>
<h4>Broadcast/Multicast Modes</h4>
- <p>Broadcast mode in both NTPv3 and NTPv4 is limited to directly connected subnets such as Ethernets which support broadcast technology. Ordinarily, this technology does not operate beyond the first hop router or gateway. Where service is intended beyond the local subnet, IP multicasting can be used where supported by the operating system and the routers support the Internet Group Management Protocol (IGMP). Most current kernels and available routers do support IP multicast technology, although service providers are sometimes reluctant to deploy it.</p>
- <p>Broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population. A broadcast server is configured using the <tt>broadcast</tt> command and a local subnet broadcast address. A broadcast client is configured using the <tt>broadcastclient</tt> command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.</p>
- <p>The server generates broadcast messages continuously at intervals specified by the <tt>minpoll</tt> keyword and with a time-to-live span specified by the <tt>ttl</tt> keyword. A NTPv4 broadcast client responds to the first proventicated message received by waiting a short interval to avoid implosion at the server. Then, the client polls the server in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles over a 10-s interval during which both the synchronization and cryptographic protocols run concurrently. When the next broadcast message is received after the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages.</p>
+ <p>IPv4 broadcast mode in both NTPv3 and NTPv4 is limited to directly connected subnets such as Ethernets which support broadcast technology. Ordinarily, this technology does not operate beyond the first hop router or gateway. In IPv6 and where service is intended beyond the local subnet, IP multicasting can be used where supported by the operating system and the routers support the Internet Group Management Protocol (IGMP). Most current kernels and available routers do support IP multicast technology, although service providers are sometimes reluctant to deploy it.</p>
+ <p>IPv4 broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population on the same subnet. A broadcast server is configured using the <tt>broadcast</tt> command and a IPv4 local subnet broadcast address. A broadcast client is configured using the <tt>broadcastclient</tt> command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.</p>
+ <p>The server generates broadcast messages continuously at intervals specified by the <tt>minpoll</tt> keyword and with a time-to-live span specified by the <tt>ttl</tt> keyword. A broadcast client responds to the first message received by waiting a short interval to avoid implosion at the server. Then, the client polls the server in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages.</p>
<h4>Multicasting</h4>
- <p>Multicasting can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a IPv4 or IPv6 multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa. The IANA has assigned multicast group address IPv4 224.0.1.1 and IPv6 fc05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
- <p>A multicast client is configured using the <tt>broadcast</tt> command, but with a multicast group address instead of a local subnet broadcast address. However, there is a subtle difference between broadcasting and multicasting. Broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate <tt>broadcast</tt> command applies to each one separately. This provides a way to limit exposure in a firewall, for example.</p>
+ <p>Multicasting can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a IPv4 or IPv6 multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa. The IANA has assigned multicast group address IPv4 224.0.1.1 and IPv6 FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
+ <p>A multicast client is configured using the <tt>broadcast</tt> command, but with a multicast group address instead of a local subnet broadcast address. However, there is a subtle difference between IPv4 broadcasting and multicasting. IPv4 broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate <tt>broadcast</tt> command applies to each one separately. This provides a way to limit exposure in a firewall, for example. For IPv6 the same distinction can be made using prefix FF02 for link-local and FF05 for site-local.</p>
<p>IP multicasting is a different paradigm. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which may require these messages emit from one or all interfaces, but carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple <tt>broadcast</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.</p>
<h4>Manycasting</h4>
<p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes client associations with some number of the "best" of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="manyopt.htm">Automatic NTP Configuration Options</a> page.</p>
<h4>Burst Modes</h4>
- <p>There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the usual one. The <tt>burst</tt> mode sends a burst when the server is reachable, while the <tt>iburst</tt> mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. Provisions are made to delay the second packet in the burst in order to allow a modem to complete a call. Received server packets update the NTPv4 clock filter, which selects the best (most accurate) time values. When the last client packet in the burst is sent, the next received server packet updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.</p>
- <p>The <tt>iburst</tt> keyword can be configured for cases where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within 10 s after the first message.</p>
+ <p>There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the usual one. The <tt>burst</tt> mode sends a burst when the server is reachable, while the <tt>iburst</tt> mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. The <tt>calldelay</tt> command can be used to increase the interval between the first and second packets in the burst in order to allow a modem to complete a call. Received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.</p>
+ <p>The <tt>iburst</tt> keyword can be configured for cases where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first message.</p>
<p>The <tt>burst</tt> keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. It should only be used where the poll interval is expected to settle to values at or above 1024 s.</p>
<hr>
<a href="index.htm"><img src="pic/home.gif" alt="gif" align="left"></a>
<p>We make house calls and bring our own bugs.<br clear="left">
</p>
<hr>
- <p>Once the NTP software distribution has been compiled and installed and the configuration file constructed, the next step is to verify correct operation and fix any bugs that may result. Usually, the command line that starts the daemon is included in the system startup file, so it is executed only at system boot time; however, the daemon can be stopped and restarted from root at any time. Usually, no command-line arguments are required, unless special actions described in the <tt><a href="ntpd.htm">ntpd</a></tt> page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.</p>
+ <p>Once the NTP software distribution has been compiled and installed and the configuration file constructed, the next step is to verify correct operation and fix any bugs that may result. Usually, the command line that starts the daemon is included in the system startup file, so it is executed only at system boot time; however, the daemon can be stopped and restarted from root at any time. Usually, no command-line arguments are required, unless special actions described in the <a href="ntpd.htm"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page are required. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.</p>
<h4>Initial Startup</h4>
- <p>The best way to verify correct operation is using the <
tt><a href="ntpq.htm">ntpq</a></tt> and <tt><a href="ntpdc.htm">ntpdc</a></tt> utility programs, either on the server itself or from another machine elsewhere in the network. The <tt>ntpq</tt> program implements the management functions specified in the NTP specification <a href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">RFC-1305, Appendix A</a>. The <tt>ntpdc</tt> program implements additional functions not provided in the standard. Both programs can be used to inspect the state variables defined in the specification and, in the case of <tt>ntpdc</tt>, additional ones of interest. In addition, the <tt>ntpdc</tt> program can be used to selectively reconfigure and enable or disable some functions while the daemon is running.</p>
+ <p>The best way to verify correct operation is using the <
a href="ntpq.htm"><tt>ntpq</tt> - standard NTP query program</a> and <a href="ntpdc.htm"><tt>ntpdc</tt> - special NTP query program</a> utility programs, either on the server itself or from another machine elsewhere in the network. The <tt>ntpq</tt> program implements the management functions specified in the NTP specification <a href="http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps">RFC-1305, Appendix A</a>. The <tt>ntpdc</tt> program implements additional functions not provided in the standard. Both programs can be used to inspect the state variables defined in the specification and, in the case of <tt>ntpdc</tt>, additional ones of interest. In addition, the <tt>ntpdc</tt> program can be used to selectively reconfigure and enable or disable some functions while the daemon is running.</p>
<p>In extreme cases with elusive bugs, the daemon can operate in two modes, depending on the presence of the <tt>-d</tt> command-line debug switch. If not present, the daemon detaches from the controlling terminal and proceeds autonomously. If one or more <tt>-d</tt> switches are present, the daemon does not detach and generates special output useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single <tt>-d</tt> does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles. With a little experience, the volume of output can be reduced by piping the output to <tt>grep</tt> and specifying the keyword of the trace you want to see.</p>
<p>Some problems are immediately apparent when the daemon first starts running. The most common of these are the lack of a UDP port for NTP (123) in the Unix <tt>/etc/services</tt> file (or equivalent in some systems). <b>Note that NTP does not use TCP in any form.</b> Other problems are apparent in the system log file. The log file should show the startup banner, some cryptic initialization data and the computed precision value. The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the Unix <tt>ping</tt> command.</p>
- <p>When first started, the daemon normally polls the servers listed in the configuration file at 64-s intervals. In order to allow a sufficient number of samples for the NTP algorithms to reliably discriminate between truechimer servers and possible falsetickers, at least four valid messages from the majority of servers and peers listed in the configuration file is required before the daemon can set the local clock. However, if the difference between the client time and server time is greater than the panic threshold, which defaults to 1000 s, the daemon will send a message to the system log and shut down without setting the clock. It is necessary to set the local clock to within the panic threshold first, either manually by eyeball and wristwatch and the Unix <tt>date</tt> command, or by the <tt>ntpdate</tt> or <tt>ntpd -q</tt> commands. The panic threshold can be changed by the <tt>tinker panic</tt> command discribed on the <a href="miscopt.htm">Miscellaneous Options</a> page. The panic threshold can be disabled entirely by the <tt>-g</tt> command line option described on the <a href="ntpd.htm">ntpd - Network Time Protocol (NTP) daemon</a> page.</p>
- <p>If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. The step threshold can be changed by the <tt>tinker step</tt> command discribed on the <a href="miscopt.htm">Miscellaneous Options</a> page. The step threshold can be disabled entirely by the <tt>-x</tt> command line option described on the <a href="ntpd.htm">ntpd - Network Time Protocol (NTP) daemon</a> page. In this case the clock will never be stepped; however, users should understand the implications for doing this in a distributed data network where all processing must be tightly synchronized. See the <a href="leap.htm">NTP Timescale and Leap Seconds</a> page for further information. If a step adjustment is made, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.</p>
+ <p>When first started, the daemon normally polls the servers listed in the configuration file at 64-s intervals. In order to allow a sufficient number of samples for the NTP algorithms to reliably discriminate between truechimer servers and possible falsetickers, at least four valid messages from at least one server or peer listed in the configuration file is required before the daemon can set the local clock. However, if the difference between the client time and server time is greater than the panic threshold, which defaults to 1000 s, the daemon will send a message to the system log and shut down without setting the clock. It is necessary to set the local clock to within the panic threshold first, either manually by eyeball and wristwatch and the Unix <tt>date</tt> command, or by the <tt>ntpdate</tt> or <tt>ntpd -q</tt> commands. The panic threshold can be changed by the <tt>tinker panic</tt> command discribed on the <a href="miscopt.htm">Miscellaneous Options</a> page. The panic threshold can be disabled entirely by the <tt>-g</tt> command line option described on the <a href="ntpd.htm">ntpd</a> page.</p>
+ <p>If the difference between local time and server time is less than the panic threshold but greater than the step threshold, which defaults to 125 ms, the daemon will perform a step adjustment; otherwise, it will gradually slew the clock to the nominal time. The step threshold can be changed by the <tt>tinker step</tt> command discribed on the <a href="miscopt.htm">Miscellaneous Options</a> page. The step threshold can be disabled entirely by the <tt>-x</tt> command line option described on the <a href="ntpd.htm">ntpd</a> page. In this case the clock will never be stepped; however, users should understand the implications for doing this in a distributed data network where all processing must be tightly synchronized. See the <a href="http://www.eecis.udel.edu/~mills/leap.htm">NTP Timescale and Leap Seconds</a> page for further information. If a step adjustment is made, the clock discipline algorithm will start all over again, requiring another round of at least four messages as before. This is necessary so that all servers and peers operate on the same set of time values.</p>
<p>The clock discipline algorithm is designed to avoid large noise spikes that might occur on a congested network or access line. If an offset sample exceeds the step threshold, it is ignored and a timer started. If a later sample is below the step threshold, the counter is reset. However, if the counter is greater than the stepout interval, which defaults to 900 s, the next sample will step or slew the time as directed. The stepout threshold can be changed by the <tt>tinker stepout</tt> command discribed on the <a href="miscopt.htm">Miscellaneous Options</a> page.</p>
- <p>If, as discussed later on this page, for some reason the hardware clock oscillator frequency error is very large, the time errors upon first startup of the daemon may increase over time until exceeding the step threshold, which requires another step correction. However, due to provisions that reduce vulnerability to noise spikes, the second correction will not be done until after the stepout threshold. When the frequency error is very large, it may take a number of cycles like this until converging on the nominal frequency correction. After this, and at one-hour intervals, the correction is written to the <tt>ntp.drift</tt> file, which is read upon subsequent restarts, so the herky-jerky cycles should not recur.</p>
+ <p>If for some reason the hardware clock oscillator frequency error is very large, the time offset when the daemon is started for the first time may increase over time until exceeding the step threshold, which requires a frequency adjustment and another step correction. However, due to provisions that reduce vulnerability to noise spikes, the second correction will not be done until after the stepout threshold. When the frequency error is very large, it may take a number of cycles like this until converging on the nominal frequency correction. If the frequency error is over 500 PPM, convergence will never occur and occasional resets will occur indefinitely. After converging, and at one-hour intervals after that, the correction is written to the <tt>ntp.drift</tt> file, which is read upon subsequent restarts, so the herky-jerky cycles should not recur.</p>
<h4>Verifying Correct Operation</h4>
<p>After starting the daemon, run the <tt>ntpq</tt> program using the <tt>-n</tt> switch, which will avoid possible distractions due to name resolution problems. Use the <tt>pe</tt> command to display a billboard showing the status of configured peers and possibly other clients poking the daemon. After operating for a few minutes, the display should be something like:</p>
<pre>
+uclpc.cairn.net pogo.udel.edu 2 u 37 64 177 212.111 -0.551 0.187
*pogo.udel.edu .GPS1. 1 u 95 128 377 0.607 0.123 0.027
</pre>
- <p>The host names or addresses shown in the <tt>remote</tt> column correspond to the server and peer entries listed in the configuration file; however, the DNS names might not agree if the names listed are not the canonical DNS names. The <tt>refid</tt> column shows the current source of synchronization, while the <tt>st</tt> column reveals the stratum, <tt>t</tt> the type (<tt>u</tt> = unicast, <tt>m</tt> = multicast, <tt>l</tt> = local, <tt>-</tt> = don't know), and <tt>poll</tt> the poll interval in seconds. The <tt>when</tt> column shows the time since the peer was last heard in seconds, while the <tt>reach</tt> column shows the status of the reachability register (see RFC-1305) in octal. The remaining entries show the latest delay, offset and jitter in milliseconds. Note that in NTP Version 4 what used to be the <tt>dispersion</tt> column has been replaced by the <tt>jitter</tt> column.</p>
+ <p>The host names or addresses shown in the <tt>remote</tt> column correspond to the server and peer entries listed in the configuration file; however, the DNS names might not agree if the names listed are not the canonical DNS names. IPv4 addresses are shown in dotted quad notation, while IPv6 addresses are shown alarmingly. The <tt>refid</tt> column shows the current source of synchronization, while the <tt>st</tt> column reveals the stratum, <tt>t</tt> the type (<tt>u</tt> = unicast, <tt>m</tt> = multicast, <tt>l</tt> = local, <tt>-</tt> = don't know), and <tt>poll</tt> the poll interval in seconds. The <tt>when</tt> column shows the time since the peer was last heard in seconds, while the <tt>reach</tt> column shows the status of the reachability register (see RFC-1305) in octal. The remaining entries show the latest delay, offset and jitter in milliseconds. Note that in NTP Version 4 what used to be the <tt>dispersion</tt> column has been replaced by the <tt>jitter</tt> column.</p>
<p>As per the NTP specification RFC-1305, when the <tt>stratum</tt> is between 0 and 15 for a NTP server, the <tt>refid</tt> field shows the server DNS name or, if not found, the IP address in dotted-quad. When the <tt>stratum</tt> is any value for a reference clock, this field shows the identification string assigned to the clock. However, until the client has synchronized to a server, or when the <tt>stratum</tt> for a NTP server is 0 (appears as 16 in the billboards), the status cannot be determined. As a help in debugging, the <tt>refid</tt> field is set as follows.</p>
<p>Peer Variables</p>
<dl>
<p>If the <tt>ntpq</tt> or <tt>ntpdc</tt> programs do not show that messages are being received by the daemon or that received messages do not result in correct synchronization, verify the following:</p>
<ol>
<li>Verify the <tt>/etc/services</tt> file host machine is configured to accept UDP packets on the NTP port 123. NTP is specifically designed to use UDP and does not respond to TCP.
- <li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems.
+ <li>Check the system log for <tt>ntpd</tt> messages about configuration errors, name-lookup failures or initialization problems. Check to be sure that only one copy of <tt>ntpd</tt> is running.
<li>Verify using <tt>ping</tt> or other utility that packets actually do make the round trip between the client and server. Verify using <tt>nslookup</tt> or other utility that the DNS server names do exist and resolve to valid Internet addresses.
<li>Using the <tt>ntpdc</tt> program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something may be wrong in the host network or interface configuration. If this counter does increment, but the received counter does not increment, something may be wrong in the network or the server NTP daemon may not be running or the server itself may be down or not responding.
<li>If both the sent and received counters do increment, but the <tt>reach</tt> values in the <tt>pe</tt> billboard with <tt>ntpq</tt> continues to show zero, received packets are probably being discarded for some reason. If this is the case, the cause should be evident from the <tt>flash</tt> variable as discussed above and on the <tt>ntpq</tt> page.
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html>
-<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Automatic NTP Configuration Options</title>
-</head>
-<body>
-<h3>Automatic NTP Configuration Options</h3>
-
-<img align="left" src="pic/alice51.gif" alt="gif"><a href=
-"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
-Adventures in Wonderland</i>, Lewis Carroll</a>
-
-<p>Make sure who your friends are.<br clear="left">
-</p>
-
-<hr>
-<h4>Manycasting</h4>
-
-<p>Manycasting is a automatic discovery and configuration paradigm
-new to NTPv4. It is intended as a means for a multicast client to
-troll the nearby network neighborhood to find cooperating manycast
-servers, validate them using cryptographic means and evaluate their
-time values with respect to other servers that might be lurking in
-the vicinity. The intended result is that each manycast client
-mobilizes client associations with some number of the "best" of the
-nearby manycast servers, yet automatically reconfigures to sustain
-this number of servers should one or another fail.</p>
-
-<p>Note that the manycasting paradigm does not coincide with the
-anycast paradigm described in RFC-1546, which is designed to find a
-single server from a clique of servers providing the same service.
-The manycast paradigm is designed to find a plurality of redundant
-servers satisfying defined optimality criteria.</p>
-
-<p>Manycasting can be used with either symmetric key or public key
-cryptography. The public key infrastructure (PKI) offers the best
-protection against compromised keys and is generally considered
-stronger, at least with relatively large key sizes. It is
-implemented using the Autokey protocol and the OpenSSL
-cryptographic library available from <a href=
-"http://www.openssl.org">http://www.openssl.org</a>. The library
-can also be used with other NTPv4 modes as well and is highly
-recommended, especially for broadcast modes.</p>
-
-<p>A persistent manycast client association is configured using the
-<tt>manycastclient</tt> command, which is similar to the <tt>
-server</tt> command but with a multicast (class D) group address
-instead of an ordinary IP (class A, B, C) address. When more
-servers are needed, it broadcasts manycast client messages to this
-address at the minimum feasible rate and minimum feasible
-time-to-live (TTL) hops, depending on how many servers have already
-been found. There can be as many manycast client associations as
-different group address, each one serving as a template for a
-future ephemeral unicast client/server association.</p>
-
-<p>Manycast servers configured with the <tt>manycastserver</tt>
-command listen on the specified group address for manycast client
-messages. Note the distinction between manycast client, which
-actively broadcasts messages, and manycast server, which passively
-responds to them. If a manycast server is in range of the current
-time-to-live and is itself synchronized to a valid source and
-operating at a stratum level equal to or lower than the manycast
-client, it replies to the manycast client message with an ordinary
-unicast server message.</p>
-
-<p>The manycast client receiving this message mobilizes an
-ephemeral client/server association according to the matching
-manycast client template, but only if cryptographically
-authenticated and the server stratum is less than or equal to the
-client stratum. Authentication is explicitly required and either
-symmetric key or public key (Autokey) can be used. Then, the client
-polls the server at its unicast address in burst mode in order to
-reliably set the host clock and validate the source. This normally
-results in a volley of eight client/server cycles over a 30-s
-interval during which both the synchronization and cryptographic
-protocols run concurrently. Following the volley, the client runs
-the NTP intersection and clustering algorithms, which act to
-discard all but the "best" associations according to stratum and
-synchronization distance. The surviving associations then continue
-in ordinary client/server mode.</p>
-
-<p>The manycast client polling strategy is designed to reduce as
-much as possible the volume of manycast client messages and the
-effects of implosion due to near-simultaneous arrival of manycast
-server messages. The strategy is determined by the <tt>
-manycastclient</tt>, <tt>tos</tt> and <tt>ttl</tt> configuration
-commands. The manycast poll interval is normally eight times the
-system poll interval, which starts out at the <tt>minpoll</tt>
-value specified in the <tt>manycastclient</tt>, command and, under
-normal circumstances, increments to the <tt>maxpolll</tt> value
-specified in this command. Initially, the TTL is set at the minimum
-hops specified by the <tt>ttl</tt> command. At each retransmission
-the TTL is increased until reaching the maximum hops specified by
-this command or a sufficient number client associations have been
-found. Further retransmissions use the same TTL.</p>
-
-<p>The quality and reliability of the suite of associations
-discovered by the manycast client is determined by the NTP
-mitigation algorithms and the <tt>minclock</tt> and <tt>
-minsane</tt> values specified in the <tt>tos</tt> configuration
-command. At least <tt>minsane</tt> candidate servers must be
-available and the mitigation algorithms produce at least <tt>
-minclock</tt> survivors in order to synchronize the clock.
-Byzantine agreement principles require at least four candidates in
-order to correctly discard a single falseticker. For legacy
-purposes, <tt>minsane</tt> defaults to 1 and <tt>minclock</tt>
-defaults to 3. For manycast service <tt>minsane</tt> should be
-explicitly set to 4. assuming at least that number of servers are
-available.</p>
-
-<p>If at least <tt>minclock</tt> servers are found, the manycast
-poll interval is immediately set to eight times <tt>maxpoll</tt>.
-If less than <tt>minclock</tt> servers are found when the TTL has
-reached the maximum hops, the manycast poll interval is doubled.
-For each transmission after that, the poll interval is doubled
-again until reaching the maximum of eight times <tt>maxpoll</tt>.
-Further transmissions use the same poll interval and TTL values.
-Note that while all this is going on, each client/server
-association found is operating normally it its own system poll
-interval.</p>
-
-<p>Administratively scoped multicast boundaries are normally
-specified by the network router configuration, which is beyond the
-scope of the description here. By default, the increment for TTL
-hops is 32 starting from 31; however, the <tt>ttl</tt>
-configuration command can be used to modify the values to match the
-router scoping.</p>
-
-<p>It is often useful to narrow the range of acceptable servers
-which can be found by manycast client associations. Because
-manycast servers respond only when the client stratum is equal to
-or greater than the server stratum, primary (stratum 1) servers
-fill find only primary servers in TTL range, which is probably the
-most common objective. However, unless configured otherwise, all
-manycast clients in TTL range will eventually find all primary
-servers in TTL range, which is probably not the most common
-objective in large networks. The <tt>tos</tt> command can be used
-to modify this behavior. Servers with stratum below <tt>floor</tt>
-or above <tt>ceiling</tt> specified in the <tt>tos</tt> command are
-strongly discouraged during the selection process; however, these
-servers may be temporally accepted if the number of servers within
-TTL range is less than <tt>minclock</tt>.</p>
-
-<p>The above actions occur for each manycast client message, which
-repeats at the designated poll interval. However, once the
-ephemeral client association is mobilized, subsequent manycast
-server replies are discarded, since they will fail the message
-digest test. If during a poll interval the number of client
-associations falls below <tt>minclock</tt>, all manycast client
-prototype associations are reset to the initial poll interval and
-TTL hops and operation resumes from the beginning. It is important
-to avoid frequent manycast client messages, since each one requires
-all manycast servers in TTL range to respond. The result could well
-be an implosion, either minor or major, depending on the number of
-servers in range. The recommended value for <tt>maxpoll</tt> is 12
-(4,096 s).</p>
-
-<p>It is possible and frequently useful to configure a host as both
-manycast client and manycast server. A number of hosts configured
-this way and sharing a common group address will automatically
-organize themselves in an optimum configuration based on stratum
-and synchronization distance. For example, consider an NTP subnet
-of two primary servers and a hundred or more dependent clients.
-With two exceptions, all servers and clients have identical
-configuration files including both <tt>multicastclient</tt> and
-<tt>multicastserver</tt> commands using, for instance, multicast
-group address 239.1.1.1. One exception is that each primary server
-configuration file must include commands for the primary reference
-source such as a GPS receiver.</p>
-
-<p>The remaining configuration files for all secondary servers and
-clients have the same configuration files, except for the <tt>
-tos</tt> command, which is specific for each stratum level. For
-stratum 1 and stratum 2 servers, that command is not necessary. For
-stratum 3 and above servers the <tt>floor</tt> value is set to the
-intended stratum number. Thus, all stratum 3 configuration files
-are identical, all stratum 4 files are identical and so forth. Note
-that</p>
-
-<p>Once operations have stabilized in this scenario, the primary
-servers will find the primary reference source and each other,
-since they both operate at the same stratum (1), but not with any
-secondary server or client, since these operate at a higher
-stratum. The secondary servers will find the servers at the same
-stratum level. If one of the primary servers loses its GPS
-receiver, it will continue to operate as a client and other clients
-will time out the corresponding association and re-associate
-accordingly.</p>
-
-<p>Some administrators prefer to avoid running <tt>ntpd</tt>
-continuously and run either <tt>ntpdate</tt> or <tt>ntpd -q</tt> as
-a cron job. In either case the servers must be configured in
-advance and the program fails if none are available when the cron
-job runs. A really slick application of manycast is with <tt>ntp
--q</tt>. The program wakes up, scans the local landscape looking
-for the usual suspects, selects the best from among the rascals,
-sets the clock and then departs. Servers do not have to be
-configured in advance and all clients throughout the network can
-have the same configuration file.</p>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<h3>Manycast Interactions with Autokey</h3>
-
-<p>Each time a manycast client sends a client mode packet to a
-multicast group address, all manycast servers in scope generate a
-reply including the host name and status word. The manycast clients
-then run the Autokey protocol, which collects and verifies all
-certificates involved. Following the burst interval all but three
-survivors are cast off, but the certificates remain in the local
-cache. It often happens that several complete signing trails from
-the client to the primary servers are collected in this way.</p>
-
-<p>About once an hour or less often if the poll interval exceeds
-this, the client regenerates the Autokey key list. This is in
-general transparent in client/server mode. However, about once per
-day the server private value used to generate cookies is refreshed
-along with all manycast client associations. In this case all
-cryptographic values including certificates is refreshed. If a new
-certificate has been generated since the last refresh epoch, it
-will automatically revoke all prior certificates that happen to be
-in the certificate cache. At the same time, the manycast scheme
-starts all over from the beginning and the expanding ring shrinks
-to the minimum and increments from there while collecting all
-servers in scope.</p>
-
-<h3>Manycast Options</h3>
-
-<dl>
-<dt><tt>tos [ ceiling <i>ceiling</i> | floor <i>floor</i> |
-minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt></dt>
-
-<dd>This command affects the clock selection and clustering
-algorithms. It can be used to select the quality and quantity of
-peers used to synchronize the system clock and is most useful in
-manycast mode. The variables operate as follows:</dd>
-
-<dd>
-<dl>
-<dt><tt>ceiling <i>ceiling</i></tt></dt>
-
-<dd>Peers with strata above <i>ceiling</i> will be discarded if
-there are at least <i>minclock</i> peers remaining. This value
-defaults to 15, but can be changed to any number from 1 to 15.</dd>
-
-<dt><tt>cohort [ 0 | 1 ]</tt></dt>
-
-<dd>This is a binary flag which enables (0) or disables (1)
-manycast server replies to manycast clients with the same stratum
-level. This is useful to reduce implosions where large numbers of
-clients with the same stratum level are present. The default is to
-enable these replies.</dd>
-
-<dt><tt>floor <i>floor</i></tt></dt>
-
-<dd>Peers with strata below <i>floor</i> will be discarded if there
-are at least <i>minclock</i> peers remaining. This value defaults
-to 1, but can be changed to any number from 1 to 15.</dd>
-
-<dt><tt>minclock <i>minclock</i></tt></dt>
-
-<dd>The clustering algorithm repeatedly casts out outlyer
-associations until no more than <i>minclock</i> associations
-remain. This value defaults to 3, but can be changed to any number
-from 1 to the number of configured sources.</dd>
-
-<dt><tt>minsane <i>minsane</i></tt></dt>
-
-<dd>This is the minimum number of candidates available to the clock
-selection algorithm in order to produce one or more truechimers for
-the clustering algorithm. If fewer than this number are available,
-the clock is undisciplined and allowed to run free. The default is
-1 for legacy purposes. However, according to principles of
-Byzantine agreement, <i>minsane</i> should be at least 4 in order
-to detect and discard a single falseticker.</dd>
-</dl>
-</dd>
-
-<dt><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>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"gif"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-<mills@udel.edu></a></address>
-</body>
-</html>
+<html>
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Automatic NTP Configuration Options</title>
+ </head>
+
+ <body>
+ <h3>Automatic NTP Configuration Options</h3>
+ <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>Make sure who your friends are.<br clear="left">
+ </p>
+ <hr>
+ <h4>Manycasting</h4>
+ <p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes client associations with some number of the "best" of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail.</p>
+ <p>Note that the manycasting paradigm does not coincide with the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p>
+ <p>Manycasting can be used with either symmetric key or public key cryptography. The public key infrastructure (PKI) offers the best protection against compromised keys and is generally considered stronger, at least with relatively large key sizes. It is implemented using the Autokey protocol and the OpenSSL cryptographic library available from <a href="http://www.openssl.org">http://www.openssl.org</a>. The library can also be used with other NTPv4 modes as well and is highly recommended, especially for broadcast modes.</p>
+ <p>A persistent manycast client association is configured using the <tt>manycastclient</tt> command, which is similar to the <tt>server</tt> command but with a multicast (IPv4 class D or IPv6 prefix <tt>FF</tt>) group address. The IANA has designated IPv4 address 224.1.1.1 and IPv6 address FF05::101 (site local) for NTP. When more servers are needed, it broadcasts manycast client messages to this address at the minimum feasible rate and minimum feasible time-to-live (TTL) hops, depending on how many servers have already been found. There can be as many manycast client associations as different group address, each one serving as a template for a future ephemeral unicast client/server association.</p>
+ <p>Manycast servers configured with the <tt>manycastserver</tt> command listen on the specified group address for manycast client messages. Note the distinction between manycast client, which actively broadcasts messages, and manycast server, which passively responds to them. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies to the manycast client message with an ordinary unicast server message.</p>
+ <p>The manycast client receiving this message mobilizes an ephemeral client/server association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. Authentication is explicitly required and either symmetric key or public key (Autokey) can be used. Then, the client polls the server at its unicast address in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client runs the NTP intersection and clustering algorithms, which act to discard all but the "best" associations according to stratum and synchronization distance. The surviving associations then continue in ordinary client/server mode.</p>
+ <p>The manycast client polling strategy is designed to reduce as much as possible the volume of manycast client messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The strategy is determined by the <tt>manycastclient</tt>, <tt>tos</tt> and <tt>ttl</tt> configuration commands. The manycast poll interval is normally eight times the system poll interval, which starts out at the <tt>minpoll</tt> value specified in the <tt>manycastclient</tt>, command and, under normal circumstances, increments to the <tt>maxpolll</tt> value specified in this command. Initially, the TTL is set at the minimum hops specified by the <tt>ttl</tt> command. At each retransmission the TTL is increased until reaching the maximum hops specified by this command or a sufficient number client associations have been found. Further retransmissions use the same TTL.</p>
+ <p>The quality and reliability of the suite of associations discovered by the manycast client is determined by the NTP mitigation algorithms and the <tt>minclock</tt> and <tt>minsane</tt> values specified in the <tt>tos</tt> configuration command. At least <tt>minsane</tt> candidate servers must be available and the mitigation algorithms produce at least <tt>minclock</tt> survivors in order to synchronize the clock. Byzantine agreement principles require at least four candidates in order to correctly discard a single falseticker. For legacy purposes, <tt>minsane</tt> defaults to 1 and <tt>minclock</tt> defaults to 3. For manycast service <tt>minsane</tt> should be explicitly set to 4. assuming at least that number of servers are available.</p>
+ <p>If at least <tt>minclock</tt> servers are found, the manycast poll interval is immediately set to eight times <tt>maxpoll</tt>. If less than <tt>minclock</tt> servers are found when the TTL has reached the maximum hops, the manycast poll interval is doubled. For each transmission after that, the poll interval is doubled again until reaching the maximum of eight times <tt>maxpoll</tt>. Further transmissions use the same poll interval and TTL values. Note that while all this is going on, each client/server association found is operating normally it the system poll interval.</p>
+ <p>Administratively scoped multicast boundaries are normally specified by the network router configuration and, in the case of IPv6, the link/site scope prefix. By default, the increment for TTL hops is 32 starting from 31; however, the <tt>ttl</tt> configuration command can be used to modify the values to match the scope rules.</p>
+ <p>It is often useful to narrow the range of acceptable servers which can be found by manycast client associations. Because manycast servers respond only when the client stratum is equal to or greater than the server stratum, primary (stratum 1) servers fill find only primary servers in TTL range, which is probably the most common objective. However, unless configured otherwise, all manycast clients in TTL range will eventually find all primary servers in TTL range, which is probably not the most common objective in large networks. The <tt>tos</tt> command can be used to modify this behavior. Servers with stratum below <tt>floor</tt> or above <tt>ceiling</tt> specified in the <tt>tos</tt> command are strongly discouraged during the selection process; however, these servers may be temporally accepted if the number of servers within TTL range is less than <tt>minclock</tt>.</p>
+ <p>The above actions occur for each manycast client message, which repeats at the designated poll interval. However, once the ephemeral client association is mobilized, subsequent manycast server replies are discarded, since that would result in a duplicate association. If during a poll interval the number of client associations falls below <tt>minclock</tt>, all manycast client prototype associations are reset to the initial poll interval and TTL hops and operation resumes from the beginning. It is important to avoid frequent manycast client messages, since each one requires all manycast servers in TTL range to respond. The result could well be an implosion, either minor or major, depending on the number of servers in range. The recommended value for <tt>maxpoll</tt> is 12 (4,096 s).</p>
+ <p>It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance. For example, consider an NTP subnet of two primary servers and a hundred or more dependent clients. With two exceptions, all servers and clients have identical configuration files including both <tt>multicastclient</tt> and <tt>multicastserver</tt> commands using, for instance, multicast group address 239.1.1.1. The only exception is that each primary server configuration file must include commands for the primary reference source such as a GPS receiver.</p>
+ <p>The remaining configuration files for all secondary servers and clients have the same contents, except for the <tt>tos</tt> command, which is specific for each stratum level. For stratum 1 and stratum 2 servers, that command is not necessary. For stratum 3 and above servers the <tt>floor</tt> value is set to the intended stratum number. Thus, all stratum 3 configuration files are identical, all stratum 4 files are identical and so forth.</p>
+ <p>Once operations have stabilized in this scenario, the primary servers will find the primary reference source and each other, since they both operate at the same stratum (1), but not with any secondary server or client, since these operate at a higher stratum. The secondary servers will find the servers at the same stratum level. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.</p>
+ <p>Some administrators prefer to avoid running <tt>ntpd</tt> continuously and run either <tt>ntpdate</tt> or <tt>ntpd -q</tt> as a cron job. In either case the servers must be configured in advance and the program fails if none are available when the cron job runs. A really slick application of manycast is with <tt>ntpd -q</tt>. The program wakes up, scans the local landscape looking for the usual suspects, selects the best from among the rascals, sets the clock and then departs. Servers do not have to be configured in advance and all clients throughout the network can have the same configuration file.</p>
+ <h3>Manycast Interactions with Autokey</h3>
+ <p>Each time a manycast client sends a client mode packet to a multicast group address, all manycast servers in scope generate a reply including the host name and status word. The manycast clients then run the Autokey protocol, which collects and verifies all certificates involved. Following the burst interval all but three survivors are cast off, but the certificates remain in the local cache. It often happens that several complete signing trails from the client to the primary servers are collected in this way.</p>
+ <p>About once an hour or less often if the poll interval exceeds this, the client regenerates the Autokey key list. This is in general transparent in client/server mode. However, about once per day the server private value used to generate cookies is refreshed along with all manycast client associations. In this case all cryptographic values including certificates is refreshed. If a new certificate has been generated since the last refresh epoch, it will automatically revoke all prior certificates that happen to be in the certificate cache. At the same time, the manycast scheme starts all over from the beginning and the expanding ring shrinks to the minimum and increments from there while collecting all servers in scope.</p>
+ <h3>Manycast Options</h3>
+ <dl>
+ <dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} |floor <i>floor</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt>
+ <dd>This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows:
+ <dd>
+ <dl>
+ <dt><tt>ceiling <i>ceiling</i></tt>
+ <dd>Peers with strata above <i>ceiling</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 15, but can be changed to any number from 1 to 15.
+ <dt><tt>cohort { 0 | 1 }</tt>
+ <dd>This is a binary flag which enables (0) or disables (1) manycast server replies to manycast clients with the same stratum level. This is useful to reduce implosions where large numbers of clients with the same stratum level are present. The default is to enable these replies.
+ <dt><tt>floor <i>floor</i></tt>
+ <dd>Peers with strata below <i>floor</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15.
+ <dt><tt>minclock <i>minclock</i></tt>
+ <dd>The clustering algorithm repeatedly casts out outlyer associations until no more than <i>minclock</i> associations remain. This value defaults to 3, but can be changed to any number from 1 to the number of configured sources.
+ <dt><tt>minsane <i>minsane</i></tt>
+ <dd>This is the minimum number of candidates available to the clock selection algorithm in order to produce one or more truechimers for the clustering algorithm. If fewer than this number are available, the clock is undisciplined and allowed to run free. The default is 1 for legacy purposes. However, according to principles of Byzantine agreement, <i>minsane</i> should be at least 4 in order to detect and discard a single falseticker.
+ </dl>
+
+ <dt><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.
+ </dl>
+ <hr>
+ <a href="index.htm"><img src="pic/home.gif" alt="gif" align="left"></a>
+ <address><a href="mailto:mills@udel.edu">David L. Mills <mills@udel.edu></a></address>
+ </body>
+
+</html>
\ No newline at end of file
-<html><head><title>
-Time and Time Interval Measurement with Application to Computer and
-Network Performance Evaluation
-</title></head><body><h3>
-Time and Time Interval Measurement with Application to Computer and
-Network Performance Evaluation
-</h3><hr>
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<p>The technical memorandum: <cite>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</cite><a href="http://www.eecis.udel.edu/~mills/database/memos/memo96a.ps">(PostScript) </a> describes a number of techniques for conducting experiments typical of computer network and transmission systems engineering.
+<html>
-<p>In most experiments in which time is involved, it is necessary to develop estimates of time, frequency and measurement errors from a series of time measurements between the clocks of a number of computers and ancillary devices interconnected by some kind of computer network. However, time is not a physical quantity, such as mass, nor can it be measured relative to an absolute frame of reference, such as velocity. The only way to measure time in our universe is to compare the reading of one clock, which runs according to its own timescale, with another clock, which runs according to a given timescale, at some given instant or epoch. The errors arise from the precision of time comparisons and the accuracy of frequency estimates between the timescales involved.
+ <head>
+ <title>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</title>
+ </head>
-<p>The usual data collected during a performance run of some experiment might include time offsets, time delays, frequency offsets and various error statistics. While time offsets between two clocks can be measured directly, frequency offsets can be estimated only from two or more time offsets made over some time interval in the experiment. In practice, a sequence of time comparisons can be performed over the lifetime of the experiment and the instantaneous frequency estimated either in real time with a recurrence relation, or retrospectively with a polynomial fit to the data.
+ <body>
+ <h3>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</h3>
+ <hr>
+ <p>The technical memorandum: <cite>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</cite><a href="http://www.eecis.udel.edu/~mills/database/memos/memo96a.ps">(PostScript) </a>describes a number of techniques for conducting experiments typical of computer network and transmission systems engineering.</p>
+ <p>In most experiments in which time is involved, it is necessary to develop estimates of time, frequency and measurement errors from a series of time measurements between the clocks of a number of computers and ancillary devices interconnected by some kind of computer network. However, time is not a physical quantity, such as mass, nor can it be measured relative to an absolute frame of reference, such as velocity. The only way to measure time in our universe is to compare the reading of one clock, which runs according to its own timescale, with another clock, which runs according to a given timescale, at some given instant or epoch. The errors arise from the precision of time comparisons and the accuracy of frequency estimates between the timescales involved.</p>
+ <p>The usual data collected during a performance run of some experiment might include time offsets, time delays, frequency offsets and various error statistics. While time offsets between two clocks can be measured directly, frequency offsets can be estimated only from two or more time offsets made over some time interval in the experiment. In practice, a sequence of time comparisons can be performed over the lifetime of the experiment and the instantaneous frequency estimated either in real time with a recurrence relation, or retrospectively with a polynomial fit to the data.</p>
+ <p>Estimating time and frequency errors in real time has been studied by a distinct subspecies of physicists who have made a career of the technology involved. Various means including autoregressive models, Kalman filters and simple weighted-average algorithms are used extensively by national standards laboratories to model cesium-clock ensembles. These techniques have been adapted to computer network and transmission engineering problems as well. This memorandum explores issues in performing experiments of this type and summarizes various techniques found useful in practice.</p>
+ <hr>
+ <a href="index.htm"><img src="pic/home.gif" align="left"></a>
+ <address><a href="mailto:mills@udel.edu">David L. Mills <mills@udel.edu></a></address>
+ </body>
-<p>Estimating time and frequency errors in real time has been studied by a distinct subspecies of physicists who have made a career of the technology involved. Various means including autoregressive models, Kalman filters and simple weighted-average algorithms are used extensively by national standards laboratories to model cesium-clock ensembles. These techniques have been adapted to computer network and transmission engineering problems as well. This memorandum explores issues in performing experiments of this type and summarizes various techniques found useful in practice.
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
+</html>
\ No newline at end of file
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html>
-<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Miscellaneous Options</title>
-</head>
-<body>
-<h3>Miscellaneous Options</h3>
-
-<img align="left" src="pic/boom3.gif" alt="gif"><a href=
-"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
-Walt Kelly</a>
-
-<p>We have three, now looking for more.<br clear="left">
-</p>
-
-<hr>
-<dl>
-<dt><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. The default
-when this command is not used is 0.004 seconds.</dd>
-
-<dt><tt>calldelay <i>delay</i></tt></dt>
-
-<dd>This option controls the delay in seconds between the first and
-second packets sent in burst or iburst mode to allow additional
-time for a modem or ISDN call to complete.</dd>
-
-<dt><tt>driftfile <i>driftfile</i></tt></dt>
-
-<dd>This command specifies the name of the file used to record the
-frequency offset of the local clock oscillator. If the file exists,
-it is read at startup in order to set the initial frequency offset
-and then updated once per hour with the current frequency offset
-computed by the daemon. If the file does not exist or this command
-is not given, the initial frequency offset is assumed zero. In this
-case, it may take some hours for the frequency to stabilize and the
-residual timing errors to subside.
-
-<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>
-</dd>
-
-<dt><tt>enable [ auth | bclient | calibrate | kernel | monitor |
-ntp | pps | stats]</tt><br>
-<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.htm"><tt>
-ntpdc</tt></a> utility program.</dd>
-
-<dd>
-<dl>
-<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.htm">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.htm">
-Monitoring Options</a> page for further information. The default
-for this flag is disable</dd>
-</dl>
-</dd>
-
-<dt><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><tt>logconfig <i>configkeyword</i></tt></dt>
-
-<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. By default, all output is turned on. 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.</dd>
-
-<dd>Informational messages (<tt>info</tt>) control configuration
-information. Event messages (<tt>events</tt>) control logging of
-events (reachability, synchronization, alarm conditions).
-Statistical output is controlled with the <tt>statistics</tt>
-keyword. The final message group is the status messages. This
-describes mainly the synchronizations status. Configuration
-keywords are formed by concatenating the message class with the
-event class. The <tt>all</tt> prefix can be used instead of a
-message class. A message class may also be followed by the <tt>
-all</tt> keyword to enable/disable all messages of the respective
-message class.</dd>
-
-<dd>Thus, a minimal log configuration could look like this:
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<p><tt>logconfig=syncstatus +sysevents</tt></p>
-
-<p>This would just list the synchronizations state of <tt>ntpd</tt>
-and the major system events. For a simple reference server, the
-following minimum message configuration could be useful:</p>
-
-<p><tt>logconfig=syncall +clockall</tt></p>
-
-<p>This configuration will list all clock information and
-synchronization information. All other events and messages about
-peers, system events and so on is suppressed.</p>
-</dd>
-
-<dt><tt>logfile <i>logfile</i></tt></dt>
-
-<dd>This command specifies the location of an alternate log file to
-be used instead of the default system <tt>syslog</tt>
-facility.</dd>
-
-<dt><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.</dd>
-
-<dt><tt>tinker [ allan <i>allan</i> | dispersion <i>dispersion</i>
-| huffpuff | <i>huffpuff</i> | minpoll <i>minpoll</i> | panic <i>
-panic</i> | step <i>step</i> | stepout <i>stepout</i> ]</tt></dt>
-
-<dd>This command can be used to alter several system variables in
-very exceptional circumstances. It should occur in the
-configuration file before any other configuration options. The
-default values of these variables have been carefully optimized for
-a wide range of network speeds and reliability expectations. In
-general, they interact in intricate ways that are hard to predict
-and some combinations can result in some very nasty behavior. Very
-rarely is it necessary to change the default values; but, some
-folks can't resist twisting the knobs anyway and this command is
-for them. Emphasis added: twisters are on their own and can expect
-no help from the support group.
-
-<p>The variables operate as follows:</p>
-</dd>
-
-<dd>
-<dl>
-<dt><tt>allan <i>allan</i></tt></dt>
-
-<dd>The argument becomes the new value for the minimum Allan
-intercept, which is a parameter of the PLL/FLL clock discipline
-algorithm. The value in log2 seconds defaults to 7 (1024 s), which
-is also the lower limit.</dd>
-
-<dt><tt>dispersion <i>dispersion</i></tt></dt>
-
-<dd>The argument becomes the new value for the dispersion increase
-rate, normally .000015 s/s.</dd>
-
-<dt><tt>huffpuff <i>huffpuff</i></tt></dt>
-
-<dd>The argument becomes the new value for the experimental
-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). There
-is no default, since the filter is not enabled unless this command
-is given.</dd>
-
-<dt><tt>minpoll <i>minpoll</i></tt></dt>
-
-<dd>The argument becomes the new value for the minimum poll
-interval used when configuring multicast client, manycast client
-and , symmetric passive mode association. The value in log2 seconds
-defaults to 6 (64 s) and has a lower limit of 4 (16 s).</dd>
-
-<dt><tt>panic <i>panic</i></tt></dt>
-
-<dd>The argument is the panic threshold, normally 1000 s. If set to
-zero, the panic sanity check is disabled and a clock offset of any
-value will be accepted.</dd>
-
-<dt><tt>step <i>step</i></tt></dt>
-
-<dd>The argument is the step threshold, normally 0.128 s. If set to
-zero, step adjustments will never occur. In general, if the intent
-is only to avoid step adjustments, the step threshold should be
-left alone and the <tt>-x</tt> command line option be used
-instead.</dd>
-
-<dt><tt>stepout <i>stepout</i></tt></dt>
-
-<dd>The argument becomes the new value for the watchdog timeout,
-normally 900 s.</dd>
-</dl>
-</dd>
-
-<dt><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.
-
-<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>
-</dd>
-
-<dt><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>
-
-<h4>Files</h4>
-
-<tt>ntp.drift</tt> frequency compensation (PPM)
-
-<hr>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"gif"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-<mills@udel.edu></a></address>
-</body>
-</html>
+<html>
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Miscellaneous Options</title>
+ </head>
+
+ <body>
+ <h3>Miscellaneous Options</h3>
+ <img src="pic/boom3.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <p>We have three, now looking for more.<br clear="left">
+ </p>
+ <hr>
+ <dl>
+ <dt><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. The default when this command is not used is 0.004 seconds.
+ <dt><tt>calldelay <i>delay</i></tt>
+ <dd>This option controls the delay in seconds between the first and second packets sent in burst or iburst mode to allow additional time for a modem or ISDN call to complete.
+ <dt><tt>driftfile <i>driftfile</i></tt>
+ <dd>This command specifies the name of the file used to record the frequency offset of the local clock oscillator. If the file exists, it is read at startup in order to set the initial frequency offset and then updated once per hour with the current frequency offset computed by the daemon. If the file does not exist or this command is not given, the initial frequency offset is assumed zero. In this case, it may take some hours for the frequency to stabilize and the residual timing errors to subside.
+ <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>
+ <dt><tt>enable [ auth | bclient | calibrate | kernel | monitor | ntp | pps | stats]</tt><br>
+ <tt>disable [ auth | bclient | calibrate | kernel | monitor | ntp | pps | stats ]</tt>
+ <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.htm"><tt>ntpdc</tt></a> utility program.
+ <dd>
+ <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.htm">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.htm">Monitoring Options</a> page for further information. The default for this flag is disable
+ </dl>
+ <dt><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><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. By default, all output is turned on. 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>).
+ <p>Configuration keywords are formed by concatenating the message class with the event class. The <tt>all</tt> prefix can be used instead of a message class. A message class may also be followed by the <tt>all</tt> keyword to enable/disable all messages of the respective message class.Thus, a minimal log configuration could look like this:</p>
+ <p><tt>logconfig=syncstatus +sysevents</tt></p>
+ <p>This would just list the synchronizations state of <tt>ntpd</tt> and the major system events. For a simple reference server, the following minimum message configuration could be useful:</p>
+ <p><tt>logconfig=syncall +clockall</tt></p>
+ <p>This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.</p>
+ <p><tt>logfile <i>logfile</i></tt></p>
+ <p>This command specifies the location of an alternate log file to be used instead of the default system <tt>syslog</tt> facility.</p>
+ <dt><tt>setvar <i>variable</i> [default]</tt>
+ <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><tt>tinker [ allan <i>allan</i> | dispersion <i>dispersion</i> | huffpuff | <i>huffpuff</i> | minpoll <i>minpoll</i> | panic <i>panic</i> | step <i>step</i> | stepout <i>stepout</i> ]</tt>
+ <dd>This command can be used to alter several system variables in very exceptional circumstances. It should occur in the configuration file before any other configuration options. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. In general, they interact in intricate ways that are hard to predict and some combinations can result in some very nasty behavior. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs anyway and this command is for them. Emphasis added: twisters are on their own and can expect no help from the support group.
+ <p>The variables operate as follows:</p>
+ <dd>
+ <dl>
+ <dt><tt>allan <i>allan</i></tt>
+ <dd>The argument becomes the new value for the minimum Allan intercept, which is a parameter of the PLL/FLL clock discipline algorithm. The value in log2 seconds defaults to 7 (1024 s), which is also the lower limit.
+ <dt><tt>dispersion <i>dispersion</i></tt>
+ <dd>The argument becomes the new value for the dispersion increase rate, normally .000015 s/s.
+ <dt><tt>huffpuff <i>huffpuff</i></tt>
+ <dd>The argument becomes the new value for the experimental 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). There is no default, since the filter is not enabled unless this command is given.
+ <dt><tt>minpoll <i>minpoll</i></tt>
+ <dd>The argument becomes the new value for the minimum poll interval used when configuring multicast client, manycast client and , symmetric passive mode association. The value in log2 seconds defaults to 6 (64 s) and has a lower limit of 4 (16 s).
+ <dt><tt>panic <i>panic</i></tt>
+ <dd>The argument is the panic threshold, normally 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>The argument is the step threshold, normally 0.128 s. If set to zero, step adjustments will never occur. In general, if the intent is only to avoid step adjustments, the step threshold should be left alone and the <tt>-x</tt> command line option be used instead.
+ <dt><tt>stepout <i>stepout</i></tt>
+ <dd>The argument becomes the new value for the watchdog timeout, normally 900 s.
+ </dl>
+ <dt><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><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.
+ </dl>
+ <h4>Files</h4>
+ <tt>ntp.drift</tt> frequency compensation (PPM)
+ <hr>
+ <a href="index.htm"><img src="pic/home.gif" alt="gif" align="left"></a>
+ <address><a href="mailto:mills@udel.edu">David L. Mills <mills@udel.edu></a></address>
+ </body>
+
+</html>
\ No newline at end of file
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html>
-<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Monitoring Options</title>
-</head>
-<body>
-<h3>Monitoring Options</h3>
-
-<img align="left" src="pic/pogo8.gif" alt="gif"><a href=
-"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
-Walt Kelly</a>
-
-<p>The pig watches the logs.<br clear="left">
-</p>
-
-<hr>
-<h4>Monitoring Support</h4>
-
-<tt>ntpd</tt> includes a comprehensive monitoring facility suitable
-for continuous, long term recording of server and client
-timekeeping performance. See the <tt>statistics</tt> command below
-for a listing and example of each type of statistics currently
-supported. Statistic files are managed using file generation sets
-and scripts in the ./scripts directory of this distribution. Using
-these facilities and Unix <tt>cron</tt> jobs, the datacan be
-automatically summarized and archived for retrospective analysis.
-
-<h4>Monitoring Commands</h4>
-
-<dl>
-<dt><tt>statistics <i>name</i> [...]</tt></dt>
-
-<dd>Enables writing of statistics records. Currently, four kinds of
-<i><tt>name</tt></i>statistics are supported.</dd>
-
-<dd>
-<dl>
-<dt><tt>clockstats</tt></dt>
-
-<dd>Enables recording of clock driver statistics information. Each
-update received from a clock driver appends a line of the following
-form to the file generation set named <tt>clockstats</tt>:</dd>
-
-<dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt></dd>
-
-<dd>The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight). The next field shows
-the clock address in dotted-quad notation, The final field shows
-the last timecode received from the clock in decoded ASCII format,
-where meaningful. In some clock drivers a good deal of additional
-information can be gathered and displayed as well. See information
-specific to each clock for further details.</dd>
-
-<dt><tt>cryptostats</tt></dt>
-
-<dd>This option requires the OpenSSL cryptographic software
-library. It enables recording of cryptographic public key protocol
-information. Each message received by the protocol module appends a
-line of the following form to the file generation set named <tt>
-cryptostats</tt>:</dd>
-
-<dd><tt>49213 525.624 127.127.4.1 <i>message</i></tt></dd>
-
-<dd>The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight). The next field shows
-the peer address in dotted-quad notation, The final <tt><i>
-message</i></tt> field includes the message type and certain
-ancillary information. See the <a href="authopt.htm">Authentication
-Options</a> page for further information.</dd>
-
-<dt><tt>loopstats</tt></dt>
-
-<dd>Enables recording of loop filter statistics information. Each
-update of the local clock outputs a line of the following form to
-the file generation set named <tt>loopstats</tt>:</dd>
-
-<dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733
-0.0133806</tt></dd>
-
-<dd>The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight). The next five fields
-show time offset (seconds), frequency offset (parts per million -
-PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
-discipline time constant.</dd>
-
-<dt><tt>peerstats</tt></dt>
-
-<dd>Enables recording of peer statistics information. This includes
-statistics records of all peers of a NTP server and of special
-signals, where present and configured. Each valid update appends a
-line of the following form to the current element of a file
-generation set named <tt>peerstats</tt>:</dd>
-
-<dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000
-0.001424877 0.000958674</tt></dd>
-
-<dd>The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight). The next two fields
-show the peer address in dotted-quad notation and status,
-respectively. The status field is encoded in hex in the format
-described in Appendix A of the NTP specification RFC 1305. The
-final four fields show the offset, delay, dispersion and RMS
-jitter, all in seconds.</dd>
-
-<dt><tt>rawstats</tt></dt>
-
-<dd>Enables recording of raw-timestamp statistics information. This
-includes statistics records of all peers of a NTP server and of
-special signals, where present and configured. Each NTP message
-received from a peer or clock driver appends a line of the
-following form to the file generation set named <tt>
-rawstats</tt>:</dd>
-
-<dd><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000
-3102453281.58622800031 02453332.540806000
-3102453332.541458000</tt></dd>
-
-<dd>The first two fields show the date (Modified Julian Day) and
-time (seconds and fraction past UTC midnight). The next two fields
-show the remote peer or clock address followed by the local address
-in dotted-quad notation, The final four fields show the originate,
-receive, transmit and final NTP timestamps in order. The timestamp
-values are as received and before processing by the various data
-smoothing and mitigation algorithms.</dd>
-</dl>
-</dd>
-
-<dt><tt>statsdir <i>directory_path</i></tt></dt>
-
-<dd>Indicates the full path of a directory where statistics files
-should be created (see below). This keyword allows the (otherwise
-constant) <tt>filegen</tt> filename prefix to be modified for file
-generation sets, which is useful for handling statistics logs.</dd>
-
-<dt><tt>filegen <i>name</i> [file <i>filename</i>] [type <i>
-typename</i>] [link | nolink] [enable | disable]</tt></dt>
-
-<dd>Configures setting of generation file set <i>name</i>.
-Generation file sets provide a means for handling files that are
-continuously growing during the lifetime of a server. Server
-statistics are a typical example for such files. Generation file
-sets provide access to a set of files used to store the actual
-data. At any time at most one element of the set is being written
-to. The type given specifies when and how data will be directed to
-a new element of the set. This way, information stored in elements
-of a file set that are currently unused are available for
-administrational operations without the risk of disturbing the
-operation of <tt>ntpd</tt>. (Most important: they can be removed to
-free space for new data produced.)</dd>
-
-<dd>Note that this command can be sent from the <tt>ntpdc</tt>
-program running at a remote location.</dd>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<dd>
-<dl>
-<dt><i><tt>name</tt></i></dt>
-
-<dd>This is the type of the statistics records, as shown in the
-<tt>statistics</tt> command.</dd>
-</dl>
-</dd>
-
-<dd><tt>file <i>filename</i></tt></dd>
-
-<dd>
-<dl>
-<dd>This is the file name for the statistics records. Filenames of
-set members are built from three concatenated elements <i><tt>
-prefix</tt></i>, <i><tt>filename</tt></i> and <i><tt>
-suffix</tt></i>:</dd>
-
-<dd>
-<dl>
-<dt><i><tt>prefix</tt></i></dt>
-
-<dd>This is a constant filename path. It is not subject to
-modifications via the <tt>filegen</tt> option. It is defined by the
-server, usually specified as a compile-time constant. It may,
-however, be configurable for individual file generation sets via
-other commands. For example, the prefix used with <tt>
-loopstats</tt> and <tt>peerstats</tt> generation can be configured
-using the <tt>statsdir</tt> option explained above.</dd>
-
-<dt><i><tt>filename</tt></i></dt>
-
-<dd>This string is directly concatenated to the prefix mentioned
-above (no intervening <tt>/</tt> (slash)). This can be modified
-using the <tt>file</tt> argument to the <tt>filegen</tt> statement.
-No <tt>..</tt> elements are allowed in this component to prevent
-filenames referring to parts outside the filesystem hierarchy
-denoted by <tt>prefix</tt>.</dd>
-
-<dt><i><tt>suffix</tt></i></dt>
-
-<dd>This part is reflects individual elements of a file set. It is
-generated according to the type of a file set.</dd>
-</dl>
-</dd>
-</dl>
-</dd>
-
-<dd><tt>type <i>typename</i></tt></dd>
-
-<dd>
-<dl>
-<dd>A file generation set is characterized by its type. The
-following types are supported:</dd>
-
-<dd>
-<dl>
-<dt><tt>none</tt></dt>
-
-<dd>The file set is actually a single plain file.</dd>
-
-<dt><tt>pid</tt></dt>
-
-<dd>One element of file set is used per incarnation of a <tt>
-ntpd</tt> server. This type does not perform any changes to file
-set members during runtime, however it provides an easy way of
-separating files belonging to different <tt>ntpd</tt> server
-incarnations. The set member filename is built by appending a <tt>
-.</tt> (dot) to concatenated <i>prefix</i> and <i>filename</i>
-strings, and appending the decimal representation of the process ID
-of the <tt>ntpd</tt> server process.</dd>
-
-<dt><tt>day</tt></dt>
-
-<dd>One file generation set element is created per day. A day is
-defined as the period between 00:00 and 24:00 UTC. The file set
-member suffix consists of a <tt>.</tt> (dot) and a day
-specification in the form <tt>YYYYMMdd. YYYY</tt> is a 4-digit year
-number (e.g., 1992). <tt>MM</tt> is a two digit month number. <tt>
-dd</tt> is a two digit day number. Thus, all information written at
-10 December 1992 would end up in a file named <tt><i>prefix
-filename</i>.19921210</tt>.</dd>
-
-<dt><tt>week</tt></dt>
-
-<dd>Any file set member contains data related to a certain week of
-a year. The term week is defined by computing day-of-year modulo 7.
-Elements of such a file generation set are distinguished by
-appending the following suffix to the file set filename base: A
-dot, a 4-digit year number, the letter <tt>W</tt>, and a 2-digit
-week number. For example, information from January, 10th 1992 would
-end up in a file with suffix <tt>.1992W1</tt>.</dd>
-
-<dt><tt>month</tt></dt>
-
-<dd>One generation file set element is generated per month. The
-file name suffix consists of a dot, a 4-digit year number, and a
-2-digit month.</dd>
-
-<dt><tt>year</tt></dt>
-
-<dd>One generation file element is generated per year. The filename
-suffix consists of a dot and a 4 digit year number.</dd>
-
-<dt><tt>age</tt></dt>
-
-<dd>This type of file generation sets changes to a new element of
-the file set every 24 hours of server operation. The filename
-suffix consists of a dot, the letter <tt>a</tt>, and an 8-digit
-number. This number is taken to be the number of seconds the server
-is running at the start of the corresponding 24-hour period.
-Information is only written to a file generation by specifying <tt>
-enable</tt>; output is prevented by specifying <tt>
-disable</tt>.</dd>
-</dl>
-</dd>
-</dl>
-</dd>
-
-<dd><tt>link | nolink</tt></dd>
-
-<dd>
-<dl>
-<dd>It is convenient to be able to access the current element of a
-file generation set by a fixed name. This feature is enabled by
-specifying <tt>link</tt> and disabled using <tt>nolink</tt>. If
-<tt>link</tt> is specified, a hard link from the current file set
-element to a file without suffix is created. When there is already
-a file with this name and the number of links of this file is one,
-it is renamed appending a dot, the letter <tt>C</tt>, and the pid
-of the <tt>ntpd</tt> server process. When the number of links is
-greater than one, the file is unlinked. This allows the current
-file to be accessed by a constant name.</dd>
-</dl>
-</dd>
-
-<dd><tt>enable | disable</tt></dd>
-
-<dd>
-<dl>
-<dd>Enables or disables the recording function.</dd>
-</dl>
-</dd>
-</dl>
-
-<hr>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"gif"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-<mills@udel.edu></a></address>
-</body>
-</html>
+<html>
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Monitoring Options</title>
+ </head>
+
+ <body>
+ <h3>Monitoring Options</h3>
+ <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>, Walt Kelly</a>
+ <p>The pig watches the logs.<br clear="left">
+ </p>
+ <hr>
+ <h4>Monitoring Support</h4>
+ <tt>ntpd</tt> includes a comprehensive monitoring facility suitable for continuous, long term recording of server and client timekeeping performance. See the <tt>statistics</tt> command below for a listing and example of each type of statistics currently supported. Statistic files are managed using file generation sets and scripts in the ./scripts directory of this distribution. Using these facilities and Unix <tt>cron</tt> jobs, the datacan be automatically summarized and archived for retrospective analysis.
+ <h4>Monitoring Commands</h4>
+ <dl>
+ <dt><tt>statistics <i>name</i> [...]</tt>
+ <dd>Enables writing of statistics records. Currently, four kinds of <i><tt>name</tt></i>statistics are supported.
+ <dd>
+ <dl>
+ <dt><tt>clockstats</tt>
+ <dd>Enables recording of clock driver statistics information. Each update received from a clock driver appends a line of the following form to the file generation set named <tt>clockstats</tt>:
+ <dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt>
+ <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next field shows the clock address in dotted-quad notation, The final field shows the last timecode received from the clock in decoded ASCII format, where meaningful. In some clock drivers a good deal of additional information can be gathered and displayed as well. See information specific to each clock for further details.
+ <dt><tt>cryptostats</tt>
+ <dd>This option requires the OpenSSL cryptographic software library. It enables recording of cryptographic public key protocol information. Each message received by the protocol module appends a line of the following form to the file generation set named <tt>cryptostats</tt>:
+ <dd><tt>49213 525.624 127.127.4.1 <i>message</i></tt>
+ <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next field shows the peer address in dotted-quad notation, The final <tt><i>message</i></tt> field includes the message type and certain ancillary information. See the <a href="authopt.htm">Authentication Options</a> page for further information.
+ <dt><tt>loopstats</tt>
+ <dd>Enables recording of loop filter statistics information. Each update of the local clock outputs a line of the following form to the file generation set named <tt>loopstats</tt>:
+ <dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806</tt>
+ <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next five fields show time offset (seconds), frequency offset (parts per million - PPM), RMS jitter (seconds), Allan deviation (PPM) and clock discipline time constant.
+ <dt><tt>peerstats</tt>
+ <dd>Enables recording of peer statistics information. This includes statistics records of all peers of a NTP server and of special signals, where present and configured. Each valid update appends a line of the following form to the current element of a file generation set named <tt>peerstats</tt>:
+ <dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674</tt>
+ <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the peer address in dotted-quad notation and status, respectively. The status field is encoded in hex in the format described in Appendix A of the NTP specification RFC 1305. The final four fields show the offset, delay, dispersion and RMS jitter, all in seconds.
+ <dt><tt>rawstats</tt>
+ <dd>Enables recording of raw-timestamp statistics information. This includes statistics records of all peers of a NTP server and of special signals, where present and configured. Each NTP message received from a peer or clock driver appends a line of the following form to the file generation set named <tt>rawstats</tt>:
+ <dd><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000</tt>
+ <dd>The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the remote peer or clock address followed by the local address in dotted-quad notation, The final four fields show the originate, receive, transmit and final NTP timestamps in order. The timestamp values are as received and before processing by the various data smoothing and mitigation algorithms.
+ </dl>
+ <dt><tt>statsdir <i>directory_path</i></tt>
+ <dd>Indicates the full path of a directory where statistics files should be created (see below). This keyword allows the (otherwise constant) <tt>filegen</tt> filename prefix to be modified for file generation sets, which is useful for handling statistics logs.
+ <dt><tt>filegen <i>name</i> [file <i>filename</i>] [type <i>typename</i>] [link | nolink] [enable | disable]</tt>
+ <dd>Configures setting of generation file set <i>name</i>. Generation file sets provide a means for handling files that are continuously growing during the lifetime of a server. Server statistics are a typical example for such files. Generation file sets provide access to a set of files used to store the actual data. At any time at most one element of the set is being written to. The type given specifies when and how data will be directed to a new element of the set. This way, information stored in elements of a file set that are currently unused are available for administrational operations without the risk of disturbing the operation of <tt>ntpd</tt>. (Most important: they can be removed to free space for new data produced.)
+ <dd>Note that this command can be sent from the <tt>ntpdc</tt> program running at a remote location.
+ <dd>
+ <dl>
+ <dt><i><tt>name</tt></i>
+ <dd>This is the type of the statistics records, as shown in the <tt>statistics</tt> command.
+ </dl>
+ <dd><tt>file <i>filename</i></tt>
+ <dd>
+ <dl>
+ <dd>This is the file name for the statistics records. Filenames of set members are built from three concatenated elements <i><tt>prefix</tt></i>, <i><tt>filename</tt></i> and <i><tt>suffix</tt></i>:
+ <dd>
+ <dl>
+ <dt><i><tt>prefix</tt></i>
+ <dd>This is a constant filename path. It is not subject to modifications via the <tt>filegen</tt> option. It is defined by the server, usually specified as a compile-time constant. It may, however, be configurable for individual file generation sets via other commands. For example, the prefix used with <tt>loopstats</tt> and <tt>peerstats</tt> generation can be configured using the <tt>statsdir</tt> option explained above.
+ <dt><i><tt>filename</tt></i>
+ <dd>This string is directly concatenated to the prefix mentioned above (no intervening <tt>/</tt> (slash)). This can be modified using the <tt>file</tt> argument to the <tt>filegen</tt> statement. No <tt>..</tt> elements are allowed in this component to prevent filenames referring to parts outside the filesystem hierarchy denoted by <tt>prefix</tt>.
+ <dt><i><tt>suffix</tt></i>
+ <dd>This part is reflects individual elements of a file set. It is generated according to the type of a file set.
+ </dl>
+ </dl>
+ <dd><tt>type <i>typename</i></tt>
+ <dd>
+ <dl>
+ <dd>A file generation set is characterized by its type. The following types are supported:
+ <dd>
+ <dl>
+ <dt><tt>none</tt>
+ <dd>The file set is actually a single plain file.
+ <dt><tt>pid</tt>
+ <dd>One element of file set is used per incarnation of a <tt>ntpd</tt> server. This type does not perform any changes to file set members during runtime, however it provides an easy way of separating files belonging to different <tt>ntpd</tt> server incarnations. The set member filename is built by appending a <tt>.</tt> (dot) to concatenated <i>prefix</i> and <i>filename</i> strings, and appending the decimal representation of the process ID of the <tt>ntpd</tt> server process.
+ <dt><tt>day</tt>
+ <dd>One file generation set element is created per day. A day is defined as the period between 00:00 and 24:00 UTC. The file set member suffix consists of a <tt>.</tt> (dot) and a day specification in the form <tt>YYYYMMdd. YYYY</tt> is a 4-digit year number (e.g., 1992). <tt>MM</tt> is a two digit month number. <tt>dd</tt> is a two digit day number. Thus, all information written at 10 December 1992 would end up in a file named <tt><i>prefix filename</i>.19921210</tt>.
+ <dt><tt>week</tt>
+ <dd>Any file set member contains data related to a certain week of a year. The term week is defined by computing day-of-year modulo 7. Elements of such a file generation set are distinguished by appending the following suffix to the file set filename base: A dot, a 4-digit year number, the letter <tt>W</tt>, and a 2-digit week number. For example, information from January, 10th 1992 would end up in a file with suffix <tt>.1992W1</tt>.
+ <dt><tt>month</tt>
+ <dd>One generation file set element is generated per month. The file name suffix consists of a dot, a 4-digit year number, and a 2-digit month.
+ <dt><tt>year</tt>
+ <dd>One generation file element is generated per year. The filename suffix consists of a dot and a 4 digit year number.
+ <dt><tt>age</tt>
+ <dd>This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename suffix consists of a dot, the letter <tt>a</tt>, and an 8-digit number. This number is taken to be the number of seconds the server is running at the start of the corresponding 24-hour period. Information is only written to a file generation by specifying <tt>enable</tt>; output is prevented by specifying <tt>disable</tt>.
+ </dl>
+ </dl>
+ <dd><tt>link | nolink</tt>
+ <dd>
+ <dl>
+ <dd>It is convenient to be able to access the current element of a file generation set by a fixed name. This feature is enabled by specifying <tt>link</tt> and disabled using <tt>nolink</tt>. If <tt>link</tt> is specified, a hard link from the current file set element to a file without suffix is created. When there is already a file with this name and the number of links of this file is one, it is renamed appending a dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server process. When the number of links is greater than one, the file is unlinked. This allows the current file to be accessed by a constant name.
+ </dl>
+ <dd><tt>enable | disable</tt>
+ <dd>
+ <dl>
+ <dd>Enables or disables the recording function.
+ </dl>
+ </dl>
+ <hr>
+ <a href="index.htm"><img src="pic/home.gif" alt="gif" align="left"></a>
+ <address><a href="mailto:mills@udel.edu">David L. Mills <mills@udel.edu></a></address>
+ </body>
+
+</html>
\ No newline at end of file
projects / thirdparty / ntp.git / commitdiff
