+* Documentation cleanup from Dave Mills.
(4.2.5p188) 2009/07/15 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1245] Broken xmt time sent in fast_xmit() of 4.2.5p187.
(4.2.5p187) 2009/07/11 Released by Harlan Stenn <stenn@ntp.org>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Access Control Options</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
+<style type="text/css">
+<!--
+.style1 {
+ color: #FF0000;
+ font-weight: bold;
+}
+-->
+</style>
</head>
<body>
<p>The skunk watches for intruders and sprays.</p>
<p>Last update:
-<!-- #BeginDate format:En2m -->10-Jul-2009 14:53<!-- #EndDate -->
+<!-- #BeginDate format:En2m -->14-Jul-2009 20:34<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4 id="acx">Access Control Support</h4>
-<p>The <tt>ntpd</tt> daemon implements a general purpose access control list (ACL) containing address/match entries sorted first by increasing address values and and then by increasing mask values. A match occurs when the bitwise AND of the mask and the packet source address is equal to the bitwise AND of the mask and address in the list. The list is searched in order with the last match found defining the restriction flags associated with the entry.</p>
+<p>The <tt>ntpd</tt> daemon implements a general purpose access control list
+ (ACL) containing address/match entries sorted first by increasing address
+ values and then by increasing mask values. A match occurs when the bitwise
+ AND of the mask and the packet source address is equal to the bitwise AND of
+ the mask and address in the list. The list is searched in order with the last
+ match found defining the restriction flags associated with the entry.</p>
<p>An example may clarify how it works. Our campus has two class-B networks,
128.4 for the ECE and CIS departments and 128.175 for the rest of campus.
-Subnet 128.4.1 homes critical services like class rosters and spread sheets.
-A suitable ACL might be</p>
+Let's assume (not true!) that subnet 128.4.1 homes critical services like class
+ rosters and spread sheets. A suitable ACL might be</p>
<pre>
restrict default nopeer # deny new associations
restrict 128.175.0.0 255.255.0.0 # allow campus access
restrict 128.4.0.0 255.255.0.0 none # allow ECE and CIS access
-restrict 128.4.1.0 255.255.255.0 notrust # require auth
+restrict 128.4.1.0 255.255.255.0 notrust # require authentication on subnet 1
restrict time.nist.gov # allow access
</pre>
<dl>
<dt id="discard"><tt>discard [ average <i>avg</i> ][ minimum <i>min</i> ] [ monitor <i>prob</i> ]</tt></dt>
-<dd>Set the parameters of the rate control facility which protects the server from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets that violate these limits are discarded. If in addition the <tt>kod</tt> restriction is present, a kiss-o'-death packet is returned.</dd>
+<dd>Set the parameters of the rate control facility which protects the server
+ from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets
+ that violate these limits are discarded. If in addition the <tt>kod</tt> restriction
+ is present, a kiss-o'-death packet is returned.</dd>
<dd><dl>
time) in log<sub>2</sub> s with default 3.</dd>
<dt><tt>minimum <i>min</i></tt></dt>
-<dd>Specify the minimum interpacket spacing (guard time) in log<sub>2</sub> s with default 1.</dd>
+<dd>Specify the minimum interpacket spacing (guard time) in log<sub>2</sub> s
+ with default 1.</dd>
<dt><tt>monitor</tt></dt>
-<dd>Specify the probability of discard for packets that overflow the rate-control window. This is a performance optimization for servers with aggregate arrivals of 1000 packets per second or more.</dd>
+<dd>Specify the probability of discard for packets that overflow the rate-control
+ window. This is a performance optimization for servers with aggregate arrivals
+ of 1000 packets per second or more.</dd>
</dl></dd>
<dt id="restrict"><tt>restrict <i>address</i> [mask <i>mask</i>] [<i>flag</i>][...]</tt></dt>
-<dd>The <tt><i>address</i></tt> argument expressed in dotted-quad form is the address of a host or network. Alternatively, the <tt><i>address</i></tt> argument can be a valid host DNS name. The <tt><i>mask</i></tt> argument expressed in dotted-quad form defaults to 255.255.255.255, meaning that the <tt><i>address</i></tt> is treated as the address of an individual host. A default entry (address 0.0.0.0, mask 0.0.0.0) is always included and is always the first entry in the list. Note that the text string <tt>default</tt>, with no mask option, may be used to indicate the default entry.</dd>
-
-<dd>In the current implementation, <i><tt>flag</tt></i> always restricts access, i.e., an entry with no flags indicates no restrictions. The flags are not orthogonal, in that more restrictive flags will often make less restrictive ones redundant. The flags can generally be classed into two categories, those which restrict time service and those which restrict informational queries and attempts to do run-time reconfiguration of the server. One or more of the following flags may be specified:</dd>
-
+<dd>The <tt><i>address</i></tt> argument expressed in dotted-quad form is the
+ address of a host or network. Alternatively, the <tt><i>address</i></tt> argument
+ can be a valid host DNS name. The <tt><i>mask</i></tt> argument expressed in
+ dotted-quad form defaults to 255.255.255.255, meaning that the <tt><i>address</i></tt> is
+ treated as the address of an individual host. A default entry (address 0.0.0.0,
+ mask 0.0.0.0) is always included and is always the first entry in the list.
+ Note that the text string <tt>default</tt>, with no mask option, may be used
+ to indicate the default entry.</dd>
+
+<dd>Some flags have the effect to deny service, some have the effect to
+ enable service and some are conditionedl by other flags. The flags. are
+ not orthogonal, in that more restrictive flags will often make less restrictive
+ ones redundant. The flags that deny service are classed in two categories, those
+ that restrict time service and those that restrict informational queries and
+ attempts to do run-time reconfiguration of the server. One or more of the following
+ flags may be specified:</dd>
<dd><dl>
<dt><tt>flake</tt></dt>
-<dd>Discard received NTP packets with probability 0.1; that is, on average drop one packet in ten. This is for testing and amusement. The name comes from Bob Braden's <i>flakeway</i>, which once did a similar thing for early Internet testing.</dd>
+<dd>Discard received NTP packets with probability 0.1; that is, on average drop
+ one packet in ten. This is for testing and amusement. The name comes from Bob
+ Braden's <i>flakeway</i>, which once did a similar thing for early Internet
+ testing.</dd>
<dt><tt>ignore</tt></dt>
<dd>Deny packets of all kinds, including <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>kod</tt></dt>
-<dd>Send a kiss-o'-death (KoD) packet if the <tt>limited</tt> flag is present and a packet violates the rate limits established by the <tt>discard</tt> command. KoD packets are themselves rate limited for each source address separately. Packets that violate the rate limit are discarded.</dd>
+<dd>Send a kiss-o'-death (KoD) packet if the <tt>limited</tt> flag is present
+ and a packet violates the rate limits established by the <tt>discard</tt> command.
+ KoD packets are themselves rate limited for each source address separately.
+ If this flag is not present, packets that violate the rate limits are discarded.</dd>
<dt><tt>limited</tt></dt>
-<dd>Deny time service if the packet violates the rate limits established by the <tt>discard</tt> command. This does not apply to <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
+<dd>Deny time service if the packet violates the rate limits established by the <tt>discard</tt> command.
+ This does not apply to <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>lowpriotrap</tt></dt>
-<dd>Declare traps set by matching hosts to be low priority. The number of traps a server can maintain is limited (the current limit is 3). Traps are usually assigned on a first come, first served basis, with later trap requestors being denied service. This flag modifies the assignment algorithm by allowing low priority traps to be overridden by later requests for normal priority traps.</dd>
-
+<dd>Declare traps set by matching hosts to be low priority. The number of traps
+ a server can maintain is limited (the current limit is 3). Traps are usually
+ assigned on a first come, first served basis, with later trap requestors being
+ denied service. This flag modifies the assignment algorithm by allowing low
+ priority traps to be overridden by later requests for normal priority traps.</dd>
+<dt><tt>mssntp</tt></dt>
+<dd>Enable Microsoft Windows MS-SNTP authenitcation using Active Directory services.
+ <span class="style1">Note: Potential users should be aware that these services
+ involve a TCP connection to another process that could potentially block,
+ denying services to other users. Therefore, this flag should be used only
+ for a dedicated server with no clients other than MS-SNTP.</span></dd>
<dt><tt>nomodify</tt></dt>
-<dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries which attempt to modify the state of the server (i.e., run time reconfiguration). Queries which return information are permitted.</dd>
+<dd>Deny <tt>ntpq</tt> and <tt>ntpdc</tt> queries which attempt to modify the
+ state of the server (i.e., run time reconfiguration). Queries which return information
+ are permitted.</dd>
<dt><tt>noquery</tt></dt>
<dd>Deny <tt>ntpq</tt> and <tt>ntpq</tt> queries. Time service is not affected.</dd>
<dt><tt>nopeer</tt></dt>
-<dd>Deny packets which would result in mobilizing a new association. This includes broadcast, symmetric-active and manycast client packets when a configured association does not exist.</dd>
+<dd>Deny packets that might mobilize an association unless authenticated. This
+ includes broadcast, symmetric-active and manycast server packets when a configured
+ association does not exist. Note that this flag does not apply to packets
+ that do not attempt to mobilize an association. </dd>
<dt><tt>noserve</tt></dt>
<dd>Deny all packets except <tt>ntpq</tt> and <tt>ntpdc</tt> queries.</dd>
<dt><tt>notrap</tt></dt>
-<dd>Decline to provide mode 6 control message trap service to matching hosts. The trap service is a subsystem of the <tt>ntpdc</tt> control message protocol which is intended for use by remote event logging programs.</dd>
+<dd>Decline to provide mode 6 control message trap service to matching hosts.
+ The trap service is a subsystem of the <tt>ntpdc</tt> control message protocol
+ which is intended for use by remote event logging programs.</dd>
<dt><tt>notrust</tt></dt>
-<dd>Deny packets that are not cryptographically authenticated.</dd>
-
-<dt><tt>mssntp</tt></dt>
-<dd>Enable Windows Active Directory authentication. See the <a href="authopt.html">Authentication Options
- page.</a></dd>
+<dd>Deny packets that are not cryptographically authenticated. Note carefully
+ how this flag interacts with the <tt>auth</tt> option of the <tt>enable</tt> and <tt>disable</tt> commands.
+ If <tt>auth</tt> is enables, which is the default, authentication is required
+ for all packets that might mobilize an association.
+ If <tt>auth</tt> is
+ disabled, but the <tt>notrust</tt> flag is not present, an association can be
+ mobilized whether or not authenticated. If <tt>auth</tt> is disabled, but the <tt>notrust</tt> flag
+ is present, authentication is required only for the specified address/mask
+ range. </dd>
+
+<dt><tt>nssntp</tt></dt>
+<dd>Enable Windows Active Director authentication. See the <a href="authopt.html">Authentication
+ Options page.</a></dd>
<dt><tt>ntpport</tt></dt>
<dt><tt>non-ntpport</tt></dt>
- <dd>This is actually a match algorithm modifier, rather than a restriction flag. Its presence causes the restriction entry to be matched only if the source port in the packet is the standard NTP UDP port (123). Both <tt>ntpport</tt> and <tt>non-ntpport</tt> may be specified. The <tt>ntpport</tt> is considered more specific and is sorted later in the list.</dd>
+ <dd>This is actually a match algorithm modifier, rather than a restriction
+ flag. Its presence causes the restriction entry to be matched only if the
+ source port in the packet is the standard NTP UDP port (123). Both <tt>ntpport</tt> and <tt>non-ntpport</tt> may
+ be specified. The <tt>ntpport</tt> is considered more specific and is sorted
+ later in the list.</dd>
<dt><tt>version</tt></dt>
<dd>Deny packets that do not match the current NTP version.</dd>
</dl>
</dd>
-<dd>Default restriction list entries with the flags <tt>ignore, ntpport</tt>, for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present, though if it is otherwise unconfigured; no flags are associated with the default entry (i.e., everything besides your own NTP server is unrestricted).</dd>
+<dd>Default restriction list entries with the flags <tt>ignore, ntpport</tt>,
+ for each of the local host's interface addresses are inserted into the table
+ at startup to prevent the server from attempting to synchronize to its own time.
+ A default entry is also always present, though if it is otherwise unconfigured;
+ no flags are associated with the default entry (i.e., everything besides your
+ own NTP server is unrestricted).</dd>
</dl>
<hr>
</body>
-</html>
+</html>
\ No newline at end of file
<p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
<p>Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The <tt>minpoll</tt> and <tt>maxpoll</tt> options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.</p>
<h4 id="symact">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 set of secondary (stratu, 2) servers known to be reliable and authentic. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and related values can flow from the surviving peers to all hosts in the subnet. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.</p>
+ <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 set
+ of secondary (stratum, 2) servers known to be reliable and authentic. Should
+ one of the peers lose all reference sources or simply cease operation, the
+ other peers will automatically reconfigure so that time and related values
+ can flow from the surviving peers to all hosts in the subnet. In some contexts
+ this would be described as a "push-pull" operation, in that the
+ peer either pulls or pushes the time and related values depending on the particular
+ configuration.</p>
<p>In symmetric active mode a peer symmetric active (mode 1) message to a designated peer. If a matching configured symmetric active association is found, the designated peer returns a symmetric active message. If no matching association is found, the designated peer mobilizes a ephemeral symmetric passive association and returns a symmetric passive (mode 2) message. Since an intruder can impersonate a symmetric active peer and cause a spurious symmetric passive association to be mobilized, symmetric passive mode should always be cryptographically validated.</p>
<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or IPv4 or IPv6 address. The <tt>burst</tt> and <tt>iburst</tt> options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.</p>
<p>As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the <tt>minpoll</tt> and <tt>maxpoll</tt> options.</p>
<hr>
<h4 id="sound">Sound Card Drivers</h4>
<p>There are some applications in which the computer time can be disciplined to an audio signal, rather than a serial timecode and communications port or special purpose bus peripheral. This is useful in such cases where the audio signal is sent over a telephone circuit, for example, or received directly from a shortwave receiver. In such cases the audio signal can be connected via an ordinary sound card or baseboard audio codec. The suite of NTP reference clock drivers currently includes three drivers suitable for these applications. They include a driver for the Inter Range Instrumentation Group (IRIG) signals produced by many radio clocks and timing devices, another for the Canadian time/frequency radio station CHU and a third for the NIST time/frequency radio stations WWV and WWVH. The radio drivers are designed to work with ordinary inexpensive shortwave radios and may be one of the least expensive ways to build a good primary time server.</p>
- <p>All three drivers make ample use of sophisticated digital signal processing algorithms designed to efficiently extract timing signals from noise and interference. The radio station drivers in particular implement optimum linear demodulation and decoding techniques, including maximum-likelihood and soft-decision methods. The documentation page for each driver contains an in-depth discussion on the algorithms and performance expectations. In some cases the algorithms are further analyzed, modelled and evaluated in a technical report.</p>
+ <p>All three drivers make ample use of sophisticated digital signal processing
+ algorithms designed to efficiently extract timing signals from noise and interference.
+ The radio station drivers in particular implement optimum linear demodulation
+ and decoding techniques, including maximum-likelihood and soft-decision methods.
+ The documentation page for each driver contains an in-depth discussion on
+ the algorithms and performance expectations. In some cases the algorithms
+ are further analyzed, modeled and evaluated in a technical report.</p>
<p>Currently, the audio drivers work with with Sun operating systems and audio codecs, including SunOS 4.1.3 and Solaris from 2.6 and probably all others in between. They also work with FreeBSD from 4.1 with compatible sound card. In fact, the interface is quite generic and support for other systems, in particular the various Unix generics, should not be difficult. Volunteers are solicited.</p>
<p>The audio drivers include a number of common features designed to groom input signals, suppress spikes and normalize signal levels. An automatic gain control (AGC) feature provides protection against overdriven or underdriven input signals. It is designed to maintain adequate demodulator signal amplitude while avoiding occasional noise spikes. In order to assure reliable operation, the signal level must be in the range where the audio gain control is effective. In general, this means the input signal level must be such as to cause the AGC to set the gain somewhere in the middle of the range from 0 to 255, as indicated in the timecode displayed by the <tt>ntpq</tt> program.</p>
<p>The IRIG and WWV drivers operate by disciplining a logical clock based on the codec sample clock to the audio signal as received. This is done by stuffing or slipping samples as required to maintain exact frequency to the order of 0.1 PPM. In order for the driver to reliably lock on the audio signal, the sample clock frequency tolerance must be less than 250 PPM (.025 percent) for the IRIG driver and half that for the WWV driver. The largest error observed so far is about 60 PPM, but it is possible some sound cards or codecs may exceed that value. In any case, the configuration file command <tt>tinker codec</tt> command can be used to change the systematic offset in units of 125 PPM.</p>
<p>Shortwave (3-30 MHz) radio propagation phenomena are well known to shortwave enthusiasts. The phenomena generally obey the following rules:</p>
<ul>
<li>The optimum frequency is higher in daytime than nighttime, stays high longer on summer days and low longer on winter nights.
- <li>Transitions between daytime and nightime conditions generally occur somewhat after sunrise and sunset at the midpoint of the path from transmitter to receiver.
+ <li>Transitions between daytime and nighttime conditions generally occur somewhat
+ after sunrise and sunset at the midpoint of the path from transmitter to
+ receiver.
<li>Ambient noise (static) on the lower frequencies follows the thunderstorm season, so is higher on summer afternoons and evenings.
<li>The lower frequency bands are best for shorter distances, while the higher bands are best for longer distances.
<li>The optimum frequencies are higher at the peak of the 11-year sunspot cycle and lower at the trough. The current sunspot cycle began at the minimum in late 2006 and should reach its peak in 2012.</ul>
</table>
<h4 id="setup">Setup and Debugging Aids</h4>
<p>The audio drivers include extensive setup and debugging support to help hook up the audio signals and monitor the driver operations. The documentation page for each driver describes the various messages that can be produced either in real time or written to the <tt>clockstats</tt> file for later analysis. Of particular help in verifying signal connections and compatibility is a provision to monitor the signal via headphones or speaker.</p>
- <p>Connecting radios and IRIG devices to the computer and verifying correct configuration is somewhat of a black art. The signals have to be connected to the correct ports and the signal level maintained within tolerances. Some radios have recorder outputs which produce a microphone-level signal not affected by the volume control. These signals can be connected to the microphone port on the computer. If the radio does not have a recorder output, connect the headphone or speaker output to the line-in port and adjust the volume control so the driver indicates comfortably above the minimum specified and the AGC level somewhere in the middle of the range 0-255. IRIG signals are usually much larger than radio outputs, usually in the range to several volts and may even overload the line-in port. In such cases the signal is designed to drive a cable termineted with a 50-ohm resistor, which results in a level the line-in port can handle..</p>
- <p>It is very easy to underdrive or overdrive the audio codec, in which case the drivers will not synchronize to the signal. The drivers use <tt>fudge flag2</tt> to enable audio monitoring of the input signal. This is useful during setup to confirm the signal is actually reaching the audio codec and generally free of noise and interference. Note that the monitorr volume must be set before the driver is started.</p>
+ <p>Connecting radios and IRIG devices to the computer and verifying correct
+ configuration is somewhat of a black art. The signals have to be connected
+ to the correct ports and the signal level maintained within tolerances. Some
+ radios have recorder outputs which produce a microphone-level signal not affected
+ by the volume control. These signals can be connected to the microphone port
+ on the computer. If the radio does not have a recorder output, connect the
+ headphone or speaker output to the line-in port and adjust the volume control
+ so the driver indicates comfortably above the minimum specified and the AGC
+ level somewhere in the middle of the range 0-255. IRIG signals are usually
+ much larger than radio outputs, usually in the range to several volts and
+ may even overload the line-in port. In such cases the signal is designed to
+ drive a cable terminated with a 50-ohm resistor, which results in a level
+ the line-in port can handle..</p>
+ <p>It is very easy to underdriven or overdrive the audio codec, in which case
+ the drivers will not synchronize to the signal. The drivers use <tt>fudge
+ flag2</tt> to enable audio monitoring of the input signal. This is useful
+ during setup to confirm the signal is actually reaching the audio
+ codec and generally free of noise and interference. Note that the monitor
+ volume must be set before the driver is started.</p>
<p>The drivers write a synthesized timecode to the <tt>clockstats</tt> file each time the clock is set or verified and at other times if verbose monitoring is enabled. The format includes several fixed-length fields defining the UTC time to the millisecond, together with additional variable-length fields specific to each driver. The data include the intervals since the clock was last set or verified, the audio gain and various state variables and counters specific to each driver.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Authentication Options</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
+<style type="text/css">
+<!--
+.style1 { color: #FF0000;
+ font-weight: bold;
+}
+-->
+</style>
</head>
<body>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->03-May-2009 3:25<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Jul-2009 20:49<!-- #EndDate -->
UTC</p>
<br clear="left">
<p>Keys and related information are specified in a keys file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed using an ordinary text editor.</p>
<p>When <tt>ntpd</tt> is first started, it reads the key file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
-
+<p>In addition to the above means, <tt>ntpd</tt> now supports
+ Microsoft Windows MS-SNTP authentication using Active Directory services.
+ This support was contributed by the Samba Team and is still in development.
+ It is enabled using the <tt>mssntp</tt> flag
+ of the <tt>restrict</tt> command described on
+ the <a href="authopt.html">Access Control Options</a> page. <span class="style1">Note:
+ Potential users should be aware that these services involve a TCP connection
+ to another process that could potentially block, denying services to other
+ users. Therefore, this flag should be used only for a dedicated server with
+ no clients other than MS-SNTP.</span></p>
<h4 id="pub">Public Key Cryptography</h4>
<p>NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. These schemes provide strong security against replay with or without message modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
<p>If you find or suspect a security related program bug in this distribution, please send a report to <a href="mailto:security@ntp.org">security@ntp.org</a>. Please do not contact developers directly.</p>
<h4>Non-Security Bug Reporting Procedures</h4>
<p>If you find or suspect a non-security related program bug in this distribution, please send a report to the NTP Public Service Project Bug Tracking System (Bugzilla) at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a>. Bugs reported this way are immediately forwarded to the developers. Please do not contact the developers directly.</p>
- <p>If you find or suspect an error in the program documention pages, please send a report directly to the editor David Mills at <a href="mailto:mills@udel.edu">mills@udel.edu</a>. The master documentation pages are not controlled by the bug tracking system. You are invited to contribute new or revised pages in similar style and format.</p>
+ <p>If you find or suspect an error in the program documentation pages, please
+ send a report directly to the editor David Mills at <a href="mailto:mills@udel.edu">mills@udel.edu</a>.
+ The master documentation pages are not controlled by the bug tracking system.
+ You are invited to contribute new or revised pages in similar style and format.</p>
<p>If you wish to send a report via electronic mail, please remember that your report will be held until one of our volunteers enters it in Bugzilla. The email address for these reports is <a href="mailto:bugs@ntp.org">bugs@ntp.org</a>. You will need to register at <a href="http://bugs.ntp.org/">http://bugs.ntp.org/</a> so that you may participate directly in any e-mail discussion regarding your report.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<br clear="left">
<hr>
<p>Most modern software distributions include an autoconfigure utility which
- cutomizes the build and install configuration according to the specific
+ customizes the build and install configuration according to the specific
hardware, operating system and file system conventions. For NTP this
utility is called <tt>configure</tt>, which is run before building and installing
the program components. For most installations no additional actions
<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active
mode association with the specified remote peer.
<dt><tt>broadcast</tt>
- <dd>For type b and m ddresses (only), this command mobilizes a persistent
- broadcast or multicast server mode association. Note that type b messages
- go only to the interface specified, but type m messages go to all interfaces.
+ <dd>For type b and m addressees (only), this command mobilizes a persistent
+ broadcast or multicast server mode association. Note that type
+ b messages go only to the interface specified, but type m messages go to
+ all interfaces.
<dt><tt>manycastclient</tt>
<dd>For type m addresses (only), this command mobilizes a manycast client
mode association for the multicast group address specified. In this mode
time. It is assumed that at some point in the future the network environment
changes so that this server/peer can be reached. This option is useful
to configure servers/peers on mobile systems with intermittent network
- access (e.g. WLAN clients). Note: the current implemenation does not
+ access (e.g. WLAN clients). Note: the current implementation does not
support this option.
<dt><tt>iburst</tt>
<dd>When the server is unreachable, send a burst of eight packets instead of
the algorithms designed to cast out falsetickers and can allow these sources
to set the system clock. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.
<dt><tt>ttl <i>ttl</i></tt>
- <dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> commmand
+ <dd>This option specifies the time-to-live <i><tt>ttl</tt></i> for the <tt>broadcast</tt> command
and the maximum <i><tt>ttl</tt></i> for the expanding ring search used by the <tt>manycastclient</tt> command.
Selection of the proper value, which defaults to 127, is something of
a black art and should be coordinated with the network administrator.
- This optioon is invalid with type r addresses.<dt><tt>version <i>version</i></tt>
+ This option is invalid with type r addresses.<dt><tt>version <i>version</i></tt>
<dd>Specifies the version number to be used for outgoing NTP packets. Versions
1-4 are the choices, with version 4 the default.
<dt><tt>xleave</tt>
<dl>
<dt id="broadcastclient"><tt>broadcastclient</tt>
<dd>Enable reception of broadcast server messages to any local interface (type
- b address). Ordinarily, upon receiving a broadcast message for the first time,
- the broadcast client measures the nominal server propagation delay using a
- brief client/server exchange, after which it continues in listen-only mode.
+ b address). Ordinarily, upon receiving a broadcast message for the first
+ time, the broadcast client measures the nominal server propagation delay using
+ a brief client/server exchange, after which it continues in listen-only mode.
If a nonzero value is specified in the <tt>broadcastdelay</tt> command, the
- value becomes the delay and the volley is not executed. Note: the <tt>novolley</tt> opion
- has been deprecated for future enhancements. Note that, in order to avoid accidental
- or malicious disruption in this mode, both the server and client should operate
- using symmetric key or public key authentication as described in the <a href="authopt.html">Authentication
+ value becomes the delay and the volley is not executed. Note: the <tt>novolley</tt> option
+ has been deprecated for future enhancements. Note that, in order to avoid
+ accidental or malicious disruption in this mode, both the server and client
+ should operate using symmetric key or public key authentication as described
+ in the <a href="authopt.html">Authentication
Options</a> page. Note that the <tt>novolley</tt> keyword is incompatible with
public key authentication.
<dt id="manycastserver"><tt>manycastserver <i>address</i> [...]</tt>
<p>Other problems are apparent in the system log, which ordinarily shows the startup banner, some cryptic initialization data and the computed precision value. Event messages at startup and during regular operation are sent to the optional <tt>protostats</tt> monitor file, as described on the <a href="decode.html">Event Messages and Status Words</a> page. These and other error messages are sent to the system log, as described on the <a href="msyslog.html"><tt>ntpd</tt> System Log Messages</a> page. In real emergencies the daemon will sent a terminal error message to the system log and then cease operation.</p>
<p>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. The Unix <tt>traceroute</tt> or Windows <tt>tracert</tt> utility can be used to verify a partial or complete path exists. Most problems reported to the NTP newsgroup are not NTP problems, but problems with the network or firewall configuration.</p>
<h4>Verifying Correct Operation</h4>
- <p>Unless using the <tt>iburst</tt> option, the client normally takes a few minutes to synchronize to a server. If the client time at startup happens to be more thatn 1000 s distant from NTP time, the daemon exits with a message to the system log directing the operator to manually set the time within 1000 s and restart. If the time is less than 1000 s but more than 128 s distant, a step correction occurs and the daemon restarts automatically.</p>
- <p>When started for the first time and a frequency file is not present, the daemon enters a special mode in order to calibrate the frequency. This takes 900 s during which the time is not desciplined. When calibration is complete, the daemon creates the frequency file and enters normal mode to amortize whatever residual offset remains.</p>
- <p>The <tt>ntpq</tt> commands <tt>pe</tt>, <tt>as</tt> and <tt>rv</tt> are normally sufficient to verify correct operation and assess nominal performace. The <a href="ntpq.html#pe"><tt>pe</tt></a> command displays a list showing the DNS name or IP address for each association along with selected status and statistics variables. The first character in each line is the tally code, which shows which associations are candidates to set the system clock and of these which one is the system peer. The encoding is shown in the source field of the <a href="decode.html#sys">system status word</a>.</p>
+ <p>Unless using the <tt>iburst</tt> option, the client normally takes a few
+ minutes to synchronize to a server. If the client time at startup happens
+ to be more than 1000 s distant from NTP time, the daemon exits with a message
+ to the system log directing the operator to manually set the time within 1000
+ s and restart. If the time is less than 1000 s but more than 128 s distant,
+ a step correction occurs and the daemon restarts automatically.</p>
+ <p>When started for the first time and a frequency file is not present, the
+ daemon enters a special mode in order to calibrate the frequency. This takes
+ 900 s during which the time is not disciplined. When calibration is complete,
+ the daemon creates the frequency file and enters normal mode to amortize whatever
+ residual offset remains.</p>
+ <p>The <tt>ntpq</tt> commands <tt>pe</tt>, <tt>as</tt> and <tt>rv</tt> are
+ normally sufficient to verify correct operation and assess nominal performance.
+ The <a href="ntpq.html#pe"><tt>pe</tt></a> command displays a list showing
+ the DNS name or IP address for each association along with selected status
+ and statistics variables. The first character in each line is the tally code,
+ which shows which associations are candidates to set the system clock and
+ of these which one is the system peer. The encoding is shown in the source
+ field of the <a href="decode.html#sys">system status word</a>.</p>
<p>The <a href="ntpq.html#as"><tt>as</tt></a> command displays a list of associations and association identifiers. Note the <tt>condition</tt> column, which reflects the tally code. The <a href="ntpq.html#pe"><tt>rv</tt></a> command displays the <a href="ntpq.html#system">system variables</a> billboard, including the <a href="decode.html#sys">system status word</a>. The <a href="ntpq.html#rv"><tt>rv <i>assocID</i></tt></a> command, where <tt><i>assocID</i></tt> is the association ID, displays the <a href="ntpq.html#peer">peer variables</a> billboard, including the <a href="decode.html#peer">peer status word</a>. Note that, except for explicit calendar dates, times are in milliseconds and frequencies are in parts-per-million (PPM).</p>
<p>A detailed explanation of the system, peer and clock variables in the billboards is beyond the scope of this page; however, a comprehensive explanation for each one is in the NTPv4 protocol specification. The following observations will be useful in debugging and monitoring.</p>
<ol>
- <li>The server has successfull synchronized to its sources if the <tt>leap</tt> peer variable has value other than zero. The client has successfully synchronized to the server when the <tt>leap</tt> system variable has value other than zero.
+ <li>The server has successfully synchronized to its sources if the <tt>leap</tt> peer
+ variable has value other than zero. The client has successfully synchronized
+ to the server when the <tt>leap</tt> system variable has value other than
+ zero.
<li>The <tt>reach</tt> peer variable is an 8-bit shift register displayed in octal format. When a valid packet is received, the rightmost bit is lit. When a packet is sent, the register is shifted left one bit with 0 replacing the rightmost bit. If the <tt>reach</tt> value is nonzero, the server is reachable; otherwise, it is unreachable. Note that, even if all servers become unreachable, the system continues to show valid time to dependent applications.
<li>A useful indicator of miscellaneous problems is the <tt>flash</tt> peer variable, which shows the result of 13 sanity tests. It contains the <a href="decode.html#flash">flash status word</a> bits, commonly called flashers, which displays the current errors for the association. These bits should all be zero for a valid server.
<li>The three peer variables <tt>filtdelay</tt>, <tt>filtoffset</tt> and <tt>filtdisp</tt> show the delay, offset and jitter statistics for each of the last eight measurement rounds. These statistics and their trends are valuable performance indicators for the server, client and the network. For instance, large fluctuations in delay and jitter suggest network congestion. Missing clock filter stages suggest packet losses in the network.
<p>Record the time of day and offset displayed by the <tt>ntpq</tt> <a href="ntpq.html#pe"><tt>pe</tt></a> command. Wait for an hour or so and record the time of day and offset. Calculate the frequency as the offset difference divided by the time difference. If the frequency is much above 100 PPM, the <a href="tickadj.html">tickadj</a> program might be useful to adjust the kernel clock frequency below that value. For systems that do not support this program, this might be one using a command in the system startup file.</p>
<h4>Access Controls</h4>
<p>Provisions are included in <tt>ntpd</tt> for access controls which deflect unwanted traffic from selected hosts or networks. The controls described on the <a href="accopt.html">Access Control Options</a> include detailed packet filter operations based on source address and address mask. Normally, filtered packets are dropped without notice other than to increment tally counters. However, the server can be configured to send a "kiss-o'-death" (KOD) packet to the client either when explicitly configured or when cryptographic authentication fails for some reason. The client association is permanently disabled, the access denied bit (TEST4) is set in the flash variable and a message is sent to the system log.</p>
- <p>The access control provisions include a limit on the packet rate from a host or network. If an incoming packet exceeds the limit, it is dropped and a KOD sent to the source. If this occurs after the client association has synchronized, the association is not disabled, but a message is sent to the system log. See the <a href="accopt.html">Access Control Options</a> page for further informatin.</p>
+ <p>The access control provisions include a limit on the packet rate from a
+ host or network. If an incoming packet exceeds the limit, it is dropped and
+ a KOD sent to the source. If this occurs after the client association has
+ synchronized, the association is not disabled, but a message is sent to the
+ system log. See the <a href="accopt.html">Access Control Options</a> page
+ for further information.</p>
<h4>Large Delay Variations</h4>
<p>In some reported scenarios an access line may show low to moderate network delays during some period of the day and moderate to high delays during other periods. Often the delay on one direction of transmission dominates, which can result in large time offset errors, sometimes in the range up to a few seconds. It is not usually convenient to run <tt>ntpd</tt> throughout the day in such scenarios, since this could result in several time steps, especially if the condition persists for greater than the stepout threshold.</p>
<p>Specific provisions have been built into <tt>ntpd</tt> to cope with these problems. The scheme is called "huff-'n-puff and is described on the <a href="miscopt.html">Miscellaneous Options</a> page. An alternative approach in such scenarios is first to calibrate the local clock frequency error by running <tt>ntpd</tt> in continuous mode during the quiet interval and let it write the frequency to the <tt>ntp.drift</tt> file. Then, run <tt>ntpd -q</tt> from a cron job each day at some time in the quiet interval. In systems with the nanokernel or microkernel performance enhancements, including Solaris, Tru64, Linux and FreeBSD, the kernel continuously disciplines the frequency so that the residual correction produced by <tt>ntpd</tt> is usually less than a few milliseconds.</p>
<p>Caterpillar knows all the error codes, which is more than most of us do.</p>
<p>Last update:
-<!-- #BeginDate format:En2m -->09-May-2009 3:31<!-- #EndDate -->
+<!-- #BeginDate format:En2m -->11-Jul-2009 20:34<!-- #EndDate -->
UTC</p>
<br clear="left">
<p>This page lists the status words, event messages and error codes used for <tt>ntpd</tt> reporting and monitoring. Status words are used to display the current status of the running program. There is one system status word and a peer status word for each association. There is a clock status word for each association that supports a reference clock. There is a flash code for each association which shows errors found in the last packet received (pkt) and during protocol processing (peer). These are commonly viewed using the <tt>ntpq</tt> program.</p>
-<p>Significant changes in program state are reported as events. There is one set of system events and a set of peer events for each association. In adition, there is a set of clock events for each association that supports a reference clock. Events are normally reported to the <tt>protostats</tt> monitoring file and optionally to the system log. In addition, if the trap facility is configured, events can be reported to a remote program that can page an administrator.</p>
+<p>Significant changes in program state are reported as events. There is one
+ set of system events and a set of peer events for each association. In addition,
+ there is a set of clock events for each association that supports a reference
+ clock. Events are normally reported to the <tt>protostats</tt> monitoring file
+ and optionally to the system log. In addition, if the trap facility is configured,
+ events can be reported to a remote program that can page an administrator.</p>
<p>This page also includes a description of the error messages produced by the Autokey protocol. These messages are normally sent to the <tt>cryptostats</tt> monitoring file.</p>
<tr>
<td><tt>0b</tt></td>
<td><tt>clock_event</tt></td>
-<td>see ckock status word</td>
+<td>see clock status word</td>
</tr>
<tr>
<h4 id="clock">Clock Status Word</h4>
<p>The clock status word consists of four fields: Unused (0-7), Count (8-11) and Code (12-15). It is reported in the first line of the <tt>clockvar <i>associd</i></tt> display produced by the <tt>ntpq</tt> program.</p>
-vvv
<table width="50%" border="1" cellspacing="2" cellpadding="2">
<tr>
<tr>
<td><tt>0c</tt></td>
<td><tt>bad_leapseconds</tt></td>
-<td>bad or misssing leapseconds values</td>
+<td>bad or missing leapseconds values</td>
</tr>
<tr>
<h3>External Clock Discipline and the Local Clock Driver</h3>
<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">18:38</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="246">Thursday, July 28, 2005</csobj></p>
<hr>
- <p>The NTPv4 implementation includes provisions for an external clock, where the system clock is implemented by some external hardware device. One implementation might take the form of a bus peripheral with a high resolution counter disciplined by a GPS receiver, for example. Another implementation might involve another synchronization protocol, such as the Digital Time Synchronization Service (DTSS), where the system time is disciplined to this protocol and NTP clients of the server obtain synchronization indirectly via the server. A third implementation might be a completely separate clock discipline algorithm and synchronization protocol, such as the <tt>Lockclock</tt> algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.</p>
+ <p>The NTPv4 implementation includes provisions for an external clock, where
+ the system clock is implemented by some external hardware device.
+ One implementation might take the form of a bus peripheral with a high resolution
+ counter disciplined by a GPS receiver, for example. Another implementation
+ might involve another synchronization protocol, such as the Digital Time Synchronization
+ Service (DTSS), where the system time is disciplined to this protocol and
+ NTP clients of the server obtain synchronization indirectly via the server.
+ A third implementation might be a completely separate clock discipline algorithm
+ and synchronization protocol, such as the <tt>Lockclock</tt> algorithm used
+ with NIST Automated Computer Time Service (ACTS) modem synchronized time.</p>
<p>When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon <tt>ntpd</tt> to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail and synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.</p>
<p>Control and monitoring functions for the external clock and driver are implemented using the <a href="drivers/driver1.html">Local Clock (type 1) driver</a> and the <tt>ntp_adjtime()</tt> system call. This system call is implemented by special kernel provisions included in the kernel of several operating systems, including Solaris, Tru64, FreeBSD and Linux, and possibly others. When the external clock is disabled or not implemented, the system call is used to pass time and frequency information, as well as error statistics, to the kernel. Besides disciplining the system time, the same interface can be used by other applications to determine the operating parameters of the discipline.</p>
<p>When the external clock is enabled, <tt>ntpd</tt> does not discipline the system clock, nor does it maintain the error statistics. In this case, the external clock and driver do this using mechanisms unknown to <tt>ntpd</tt>; however, in this case the kernel state variables are retrieved at 64-s intervals by the Local Clock driver and used by the clock selection and mitigation algorithms to determine the system variables presented to other NTP clients and peers. In this way, downstream clients and servers in the NTP subnet can make an intelligent choice when more than one server is available.</p>
<p>In order to implement a reliable mitigation between ordinary NTP sources and the external clock source, a protocol is necessary between the local clock driver and the external clock driver. This is implemented using Boolean variables and certain bits in the kernel clock status word. The Boolean variables include the following:</p>
- <p><tt>ntp_enable</tt>. set/reset by the <tt>enable</tt> command. enables ntp clock discipline</p>
+ <p><tt>ntp_enable</tt>. set/reset by the <tt>enable</tt> command. enables ntpd
+ clock discipline</p>
<p><tt>ntp_contro</tt>l. set during initial configuration if kernel support is available</p>
<p><tt>kern_enable</tt> Set/reset by the <tt>enable</tt> command</p>
- <p>If the <tt>kern_enable</tt> switch is set, the daemon computes the offset, frequency, maximum error, estimated error, time constand and status bits, then provides them to the kernel via <tt>ntp_adjtime()</tt>. If this switch is not set, these values are not passed to the kernel; however, the daemon retrieves their present values and uses them in place of the values computed by the daemon.</p>
+ <p>If the <tt>kern_enable</tt> switch is set, the daemon computes the offset,
+ frequency, maximum error, estimated error, time constant and status bits,
+ then provides them to the kernel via <tt>ntp_adjtime()</tt>. If this switch
+ is not set, these values are not passed to the kernel; however, the daemon
+ retrieves their present values and uses them in place of the values computed
+ by the daemon.</p>
<p>The <tt>pps_update</tt> bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.</p>
- <p>The <tt>pps_contro</tt>l Updated to the current time by kernel support if the PPS signal is enabled and working correctly. Set to zero in the adjust routine if the interval since the last update exceeds 120 s.</p>
+ <p>The <tt>PPS control</tt> Updated to the current time by kernel support if
+ the PPS signal is enabled and working correctly. Set to zero in the adjust
+ routine if the interval since the last update exceeds 120 s.</p>
<p>The <tt>ntp_enable</tt> and <tt>kern_enable</tt> are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The <tt>pps_update</tt> switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The <tt>ntp_control</tt> switch is set during configuration by interrogating the kernel. If both the <tt>kern_enable</tt> and <tt>ntp_control</tt> switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.</p>
<p>The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the <tt>ntp_adjtime()</tt> system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero.</p>
<hr>
</ul>
<hr>
<h4 id="intro">Introduction</h4>
- <p>Many radio clocks used as a primary reference source for NTP servers produce a pulse-per-second (PPS) signal that can be used to improve accuracy to a high degree. However, the signals produced are usually incompatible with the modem interface signals on the serial ports used to connect the signal to the host. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional radio modem designed to decode the radio timecode signals transmitted by the Canadian time and frequency station CHU. A complete set of schematics, PCB artwork, drill templates can be obrtained via the web from ftp.udel.edu as <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
+ <p>Many radio clocks used as a primary reference source for NTP servers produce
+ a pulse-per-second (PPS) signal that can be used to improve accuracy to a
+ high degree. However, the signals produced are usually incompatible with the
+ modem interface signals on the serial ports used to connect the signal to
+ the host. The gadget box consists of a handful of electronic components assembled
+ in a small aluminum box. It includes level converters and a optional radio
+ modem designed to decode the radio timecode signals transmitted by the Canadian
+ time and frequency station CHU. A complete set of schematics, PCB artwork,
+ drill templates can be obtained via the web from ftp.udel.edu as <a href="ftp://ftp.udel.edu/pub/ntp/hardware/gadget.tar.Z">gadget.tar.Z</a>.</p>
<p>The gadget box is assembled in a 5"x3"x2" aluminum minibox containing the level converter and modem circuitry. It includes two subcircuits. One of these converts a TTL positive edge into a fixed-width pulse at EIA levels and is for use with a timecode receiver or oscillator including a TTL PPS output. The other converts the timecode modulation broadcast by Canadian time/frequency standard station CHU into a 300-bps serial character stream at EIA levels and is for use with the <a href="drivers/driver7.html">Radio CHU Audio Demodulator/Decoder</a> driver.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
<img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>You need a little magic.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->19-Apr-2009 19:24<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Jul-2009 20:44<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
<dt><tt>refclock_ioctl</tt> - set serial port control functions</dt>
<dd>This routine attempts to hide the internal, system-specific details of serial ports. It can handle POSIX (<tt>termios</tt>), SYSV (<tt>termio</tt>) and BSD (<tt>sgtty</tt>) interfaces with varying degrees of success. The routine returns one if success and zero if failure.</dd>
<dt><tt>refclock_ppsapi</tt></dt>
- <dd>IThis routine initializes the Pulse-per-Second interface (see below).</dd>
+ <dd>This routine initializes the Pulse-per-Second interface (see below).</dd>
<dt><tt>refclock_pps</tt></dt>
<dd>This routine is called once per second to read the latest PPS offset and save it in the circular buffer (see below).</dd>
</dl>
<h4 id="pps">Pulse-per-Second Interface</h4>
- <p>When the Pulse-per-Second Appliation Interface (RFC 2783) is present, a compact PPS interface is available to all drivers. See the <a href="prefer.html">Mitigation Rules and the Prefer Peer</a> page for further information. To use this ingterface, include the <tt>timeppps.h</tt> and <tt>refclock_atom.h</tt> header files and define the <tt>refclock_atom</tt> structure in the driver private storage. The <tt>timepps.h</tt> file is specific to each operating system and may not be available for some systems.</p>
- <p>To use the interface, call <tt>refclock_ppsapi</tt> from the startup routine passing the device file descriptor and <tt>refclock_atom</tt> structure pointer. Then, call <tt>refclock_pps</tt> from the timer routine passing the association pointer and <tt>refclock_atom</tt> structure pointer. See the <tt>refclock_atom.c</tt> file for examples and calling sequences. If the PPS signal is valid, the offset sample will be save in the circular buffer and a bit set in the association flags word indicating the sample is valid and tthe driver an be selected as a PPS peer. If this bit is set when the poll routine is called, the driver calls the <tt>refclock_receive</tt> routine to process the samples in the circular buffer and update the system clock.</p>
+ <p>When the Pulse-per-Second Application Interface (RFC 2783) is present, a
+ compact PPS interface is available to all drivers. See the <a href="prefer.html">Mitigation
+ Rules and the Prefer Peer</a> page for further information. To use this interface,
+ include the <tt>timeppps.h</tt> and <tt>refclock_atom.h</tt> header files
+ and define the <tt>refclock_atom</tt> structure in the driver private storage.
+ The <tt>timepps.h</tt> file is specific to each operating system and may not
+ be available for some systems.</p>
+ <p>To use the interface, call <tt>refclock_ppsapi</tt> from the startup routine
+ passing the device file descriptor and <tt>refclock_atom</tt> structure pointer.
+ Then, call <tt>refclock_pps</tt> from the timer routine passing the association
+ pointer and <tt>refclock_atom</tt> structure pointer. See the <tt>refclock_atom.c</tt> file
+ for examples and calling sequences. If the PPS signal is valid, the offset
+ sample will be save in the circular buffer and a bit set in the association
+ flags word indicating the sample is valid and the driver an be selected as
+ a PPS peer. If this bit is set when the poll routine is called, the driver
+ calls the <tt>refclock_receive</tt> routine to process the samples in the
+ circular buffer and update the system clock.</p>
<hr>
<div align="center">
<img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->08-Apr-2009 2:53<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Jul-2009 20:00<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<p>This distribution includes a statistics data recording facility which can record performance statistics and events of various types for retrospective analysis. These include time and frequency statistics, significant events and usage statistics described on the <a href="monopt.html">Monitoring Options</a> page.</p>
<p>Some programs included in this distribution use cryptographic algorithms to verify server authenticity. Where local security policy permits relatively weak symmetric key cryptography, the required software is included in this distribution. Where local policy requires stronger public key cryptography, the OpenSSL library available from <a href="http://www.openssl.org">http://www.openssl.org</a> is required. This library is also used by the Secure Shell facility, so is often already installed. Additional details are on the <a href="authopt.html">Authentication Options</a> page.</p>
<p>This distribution includes features that can restrict access in various ways as described on the <a href="accopt.html">Access Control Options</a> page. This can be used to deny service if not authenticated, deny service requiring persistent resources or deny service altogether.</p>
- <p>This distribution includes a simulation framework in which substantially all the runtime NTP operations and most features can be tested and evaluated. This has been very useful in exploring invitro response to unusal circumstances or over time periods impractical invivo. Details are on the <a href="ntpdsim.html">Network Time Protocol (NTP) Simulator</a> page.</p>
+ <p>This distribution includes a simulation framework in which substantially
+ all the runtime NTP operations and most features can be tested and
+ evaluated. This has been very useful in exploring in vitro response
+ to unusual circumstances or over time periods impractical in vivo. Details
+ are on the <a href="ntpdsim.html">Network
+ Time Protocol (NTP) Simulator</a> page.</p>
<h4 id="prob">Resolving Problems</h4>
<p>Like other things in modern Internet life, NTP problems can be devilishly intricate. This distribution includes a number of utilities designed to identify and repair problems using an integrated management protocol supported by the <a href="ntpq.html"><tt>ntpq</tt></a> utility program In addition, the <a href="ntpdc.html"><tt>ntpdc</tt></a> utility program can be useful in some cases.</p>
<p>The <a href="debug.html">NTP Debugging Techniques</a> and <a href="hints.html">Hints and Kinks</a> pages contain useful information for identifying problems and devising solutions. Additional information on reference clock driver construction and debugging is in the <a href="rdebug.html">Debugging Hints for Reference Clock Drivers</a> page.</p>
<p>The use of cryptograpic authentication is always a good idea in any server descovery scheme. Both symmetric key and public key cryptography can be used in the same scenarios as described above for the broadast/multicast scheme.</p>
<h4 id="pool">Server Pool Scheme</h4>
<p>The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several hundred operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers using the NTP mitigation algorithms.</p>
- <p>To support this service the DNS for some volunteer servers as been modified to collect a number of other volunteer servers and return a randomized list in response to a DNS query. The client receiving this list modbilizes some or all of them just as in the other discovery schemes and casts off the excess.</p>
+ <p>To support this service the DNS for some volunteer servers as been
+ modified to collect a number of other volunteer servers and return a
+ randomized list in response to a DNS query. The client receiving this list
+ mobilizes some or all of them just as in the other discovery schemes and casts
+ off the excess.</p>
<p>The pool scheme is configured using one or <tt>pool</tt> commands with the DNS name <tt><i>region</i>.pool.ntp.org</tt>, where <tt><i>region</i></tt> is a region of the world, country of the region or state of the country or even the whole world if absent. The <tt>pool</tt> command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to use a configuration file containing a single line <tt>pool pool.ntp.org</tt>.</p>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
projects / thirdparty / ntp.git / commitdiff
