<dt><tt>RMOT</tt>
<dd>Somebody is tinkering with the association from a remote host running <tt>ntpdc</tt>. Not to worry unless some rascal has stolen your keys.
<dt><tt>STEP</tt>
- <dd>A step change in system time has occured, but the association has not yet resynchronized.
+ <dd>A step change in system time has occurred, but the association has not yet resynchronized.
</dl>
<p>System Kiss Codes</p>
<dl>
<dt><tt>INIT</tt>
<dd>The system clock has not yet synchronized for the first time.
<dt><tt>STEP</tt>
- <dd>A step change in system time has occured, but the system clock has not yet resynchronized.
+ <dd>A step change in system time has occurred, but the system clock has not yet resynchronized.
</dl>
<p>The tattletale symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked <tt>*</tt>, while additional peers designated acceptable for synchronization are marked <tt>+</tt>. Peers marked <tt>*</tt> and <tt>+</tt> are included in the weighted average computation to set the local clock; the data produced by peers marked with other symbols are discarded. See the <tt>ntpq</tt> page for the meaning of these symbols.</p>
<p>Additional details for each peer separately can be determined by the following procedure. First, use the <tt>as</tt> command to display an index of association identifiers, such as</p>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
-</html>
\ No newline at end of file
+</html>
<dt><tt>0x0002</tt>
<dd>Data pulse error. For the data pulse in second 1, either the amplitude or SNR is below threshold (1000 and 10 dB, respectively).
<dt><tt>0x0004</tt>
- <dd>Probe pulse error. Two or more decoding errors have occured for the data pulses in seconds 58, 59 and 1.
+ <dd>Probe pulse error. Two or more decoding errors have occurred for the data pulses in seconds 58, 59 and 1.
</dl>
<p>If none of the scoreboard bits are set, a hit is declared, otherwise a miss. At the end of each probe, the frequency and station with the maximum metric is chosen, with ties going first to the highest frequency and then to WWV in order. During the acquisition phase a station is considered valid only if the metric is above 13; after the clock is synchronized a station is valid only if the metric is above 50. If no stations are valid, the driver ignores all signals and sets the reference ID field to NONE.</p>
<h4>Diagnostics</h4>
<script type="text/javascript" language="javascript" src="../scripts/footer.txt"></script>
</body>
-</html>
\ No newline at end of file
+</html>
<h4>More Help</h4>
<script type="text/javascript" language="javascript" src="scripts/links12.txt"></script>
<hr>
- <p>The <a href="ntpq.html"><tt>ntpq</tt></a> and <a href="ntpdc.html"><tt>ntpdc</tt></a> utility programs can be used to debug reference clocks, either on the server itself or from another machine elsewhere in the network. The server is compiled, installed and started using the configuration file described in the <a href="ntpd.html"><tt>ntpd</tt></a> page and its dependencies. If the clock appears in the <tt>ntpq</tt> utility and <tt>pe</tt> command, no errors have occured and the daemon has started, opened the devices specified and waiting for peers and radios to come up. If not, the first thing to look for are error messages on the system log. These are usually due to improper configuration, missing links or multiple instances of the daemon.</p>
+ <p>The <a href="ntpq.html"><tt>ntpq</tt></a> and <a href="ntpdc.html"><tt>ntpdc</tt></a> utility programs can be used to debug reference clocks, either on the server itself or from another machine elsewhere in the network. The server is compiled, installed and started using the configuration file described in the <a href="ntpd.html"><tt>ntpd</tt></a> page and its dependencies. If the clock appears in the <tt>ntpq</tt> utility and <tt>pe</tt> command, no errors have occurred and the daemon has started, opened the devices specified and waiting for peers and radios to come up. If not, the first thing to look for are error messages on the system log. These are usually due to improper configuration, missing links or multiple instances of the daemon.</p>
<p>It normally takes a minute or so for evidence to appear that the clock is running and the driver is operating correctly. The first indication is a nonzero value in the <tt>reach</tt> column in the <tt>pe</tt> billboard. If nothing appears after a few minutes, the next step is to be sure the RS232 messages, if used, are getting to and from the clock. The most reliable way to do this is with an RS232 tester and to look for data flashes as the driver polls the clock and/or as data arrive from the clock. Our experience is that the overwhelming fraction of problems occurring during installation are due to problems such as miswired connectors or improperly configured device links at this stage.</p>
<p>If RS232 messages are getting to and from the clock, the variables of interest can be inspected using the <tt>ntpq</tt> program and various commands described on the documentation page. First, use the <tt>pe</tt> and <tt>as</tt> commands to display billboards showing the peer configuration and association IDs for all peers, including the radio clock. The assigned clock address should appear in the <tt>pe</tt> billboard and the association ID for it at the same relative line position in the <tt>as</tt> billboard.</p>
<p>Additional information is available with the <tt>rv</tt> and <tt>clockvar</tt> commands, which take as argument the association ID shown in the <tt>as</tt> billboard. The <tt>rv</tt> command with no argument shows the system variables, while the <tt>rv</tt> command with association ID argument shows the peer variables for the clock, as well as other peers of interest. The <tt>clockvar</tt> command with argument shows the peer variables specific to reference clock peers, including the clock status, device name, last received timecode (if relevant), and various event counters. In addition, a subset of the <tt>fudge</tt> parameters is included. The poll and error counters in the <tt>clockvar</tt> billboard are useful debugging aids. The <tt>poll</tt> counts the poll messages sent to the clock, while the <tt>noreply</tt>, <tt>badformat</tt> and <tt>baddate</tt> count various errors. Check the timecode to be sure it matches what the driver expects. This may require consulting the clock hardware reference manual, which is probably pretty dusty at this stage.</p>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
-</html>
\ No newline at end of file
+</html>
projects / thirdparty / ntp.git / commitdiff
