<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->02-Oct-2010 23:55<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Oct-2010 22:27<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
the algorithm must be ether <tt>SHA</tt> or <tt>SHA1</tt>.</dd>
<dt><tt>host <i>name</i></tt></dt>
<dd>Specifies the string used when constructing the names for the host, sign
- and certificate files generated by the <tt>ntp-keygen</tt> program with the <tt>-s <i>name</i></tt> option.</dd>
+ and certificate files generated by the <tt>ntp-keygen</tt> program with the <tt>-s <i>subject_name</i></tt> option.</dd>
<dt><tt>ident <i>name</i></tt></dt>
- <dd>Specifies the string used in constructing the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>name</i></tt> option.</dd>
+ <dd>Specifies the string used in constructing the identity files generated by the <tt>ntp-keygen</tt> program with the <tt>-i <i>issuer_name</i></tt> option.</dd>
<dt><tt>pw <i>password</i></tt></dt>
<dd>Specifies the password to decrypt files previously encrypted by the <tt>ntp-keygen</tt> program with the <tt>-p</tt> option.</dd>
<dt><tt>randfile <i>file</i></tt></dt>
for a <a href="#trustedkey">trusted key</a>, in the range 1 to
65534, inclusive.</dd>
<dt id="revoke"><tt>revoke [<i>logsec</i>]</tt></dt>
- <dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. These values need to be updated frequently in order to deflect brute-force attacks on the algorithms; however, updating some values is a relatively expensive operation. The default interval is 17 (about 36 h). For poll intervals above the specified interval, the values will be updated for every message sent.</dd>
+ <dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. This command is available only if the AUtokey public key support has been enabled. See the <a href="autokey.html">Autokey Public-Key Authentication</a>a page for further information.</dd>
<dt id="trustedkey"><tt>trustedkey [<i>keyid</i> | (<i>lowid</i> ... <i>highid</i>)] [...]</tt></dt>
<dd>Specifies the key ID(s) which are trusted for the purposes of
authenticating peers with symmetric key cryptography. Key IDs
Walt Kelly</a>
<p>The chicken is getting configuration advice.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->12-Oct-2010 1:14<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Oct-2010 21:22<!-- #EndDate -->
</p>
<br clear="left">
<h4>Related Links</h4>
<dd>Send and receive packets authenticated by the Autokey scheme described
in the <a href="autokey.html">Autokey Public Key Authentication</a> page. This option is mutually exclusive with the <tt>key</tt> option.</dd>
<dt><tt>burst</tt></dt>
- <dd>When the server is reachable, send a burst of
eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command to allow additional time for a modem or ISDN call to complete. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option when the <tt>maxpoll</tt> option is greater than 10 (1024 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
- <dt><tt>iburst</tt></dt>
- <dd>When the server is unreachable, send a burst of
eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the <a href="miscopt.html"><tt>calldelay</tt></a> command to allow additional time for a modem or ISDN call to complete. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option with this command. Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
- <dt><tt>key</tt> <i><tt>key</tt></i></dt>
+ <dd>When the server is reachable, send a burst of
packets instead of the usual one. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option when the <tt>maxpoll</tt> option is greater than 10 (1024 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
+ <dt><tt>iburst</tt></dt>
+ <dd>When the server is unreachable, send a burst of
packets instead of the usual one. This option is valid only with the <tt>server</tt> command and type s addresses. It is a recommended option with this command. Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
+ <dt><tt>key</tt> <i><tt>key</tt></i></dt>
<dd>Send and receive packets authenticated by the symmetric key scheme described in the <a href="authentic.html">Authentication Support</a> page. The <i><tt>key</tt></i> specifies the key identifier with values from 1 to 65534, inclusive. This option is mutually exclusive with the <tt>autokey</tt> option.</dd> <dt><tt>minpoll <i>minpoll<br>
</i></tt><tt>maxpoll <i>maxpoll</i></tt></dt>
<dd>These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two. The maximum poll interval defaults to 10 (1024 s), but can be increased by the <tt>maxpoll</tt> option to an upper limit of 17 (36 hr). The minimum poll interval defaults to 6 (64 s), but can be decreased by the <tt>minpoll</tt> option to a lower limit of 3 (8 s). Additional information about this option is on the <a href="poll.html">Poll Program</a> page.</dd>
<dt><tt>mode <i>option</i></tt></dt>
<dd>Pass the <tt><i>option</i></tt> to a reference clock driver, where <tt><i>option</i></tt> is an integer in the range from 0 to 255, inclusive. This option is valid only with type r addresses.</dd>
<dt><tt>noselect</tt></dt>
- <dd>Marks the server or peer to be ignored by the selection algorithm but visible to the monitoring program. This option is ignored with the <tt>broadcast</tt> command.</dd>
+ <dd>Marks the server or peer to be ignored by the selection algorithm as unreachable, but visible to the monitoring program. This option is valid only with the <tt>server</tt> and <tt>peer</tt> commands.</dd>
<dt><tt>preempt</tt></dt>
<dd>Specifies the association as preemptable rather than the default persistent. This option is ignored with the <tt>broadcast</tt> command and is most useful with the <tt>manycastclient</tt> and <tt>pool</tt> commands.</dd>
<dt><tt>prefer</tt></dt>
<h4 id="aux">Auxiliary Commands</h4>
<dl>
<dt id="broadcastclient"><tt>broadcastclient</tt></dt>
- <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. 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> 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.</dd>
- <dt id="manycastserver"><tt>manycastserver <i>address</i> [...]</tt></dt>
- <dd>Enable reception of manycast client messages (type m)to the multicasts group address(es) (type m) specified. At least one address is required. Note that, in order to avoid accidental or malicious disruption, 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.</dd>
+ <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. 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> 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 volley is required with public key authentication in order to run the Autokey protocol..</dd>
+ <dt id="manycastserver"><tt>manycastserver <i>address</i> [...]</tt></dt>
+ <dd>Enable reception of manycast client messages (type m)
to the multicasts group address(es) (type m) specified. At least one address is required. Note that, in order to avoid accidental or malicious disruption, 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.</dd>
<dt id="multicastclient"><tt>multicastclient <i>address</i> [...]</tt></dt>
<dd>Enable reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. 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.</dd>
</dl>
<img src="pic/alice47.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Caterpillar knows all the error codes, which is more than most of us do.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->14-Oct-2010 3:34<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Oct-2010 16:31<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<p>The flash status word is displayed by the <tt>ntpq</tt> program <tt>rv</tt> command. It consists of a number of bits coded in hexadecimal as follows:</p>
<table width="100%" border="1" cellspacing="2" cellpadding="2">
<tr>
- <td>Code</td>
- <td>Tag</td>
- <td>Message</td>
- <td>Description</td>
+ <td width="10%">Code</td>
+ <td width="15%">Tag</td>
+ <td width="20%">Message</td>
+ <td width="55%">Description</td>
</tr>
<tr>
<td><tt>0001</tt></td>
<td><tt>0004</tt></td>
<td>TEST3</td>
<td><tt>pkt_unsync</tt></td>
- <td>protocol unsynchronized</td>
+ <td>server not synchronized</td>
</tr>
<tr>
<td><tt>0008</tt></td>
<td><tt>0010</tt></td>
<td>TEST5</td>
<td><tt>pkt_auth</tt></td>
- <td>bad authentication</td>
+ <td> authentication failure</td>
</tr>
<tr>
<td><tt>0020</tt></td>
<td>TEST6</td>
<td><tt>pkt_stratum</tt></td>
- <td>bad synch or stratum</td>
+ <td>invalid leap or stratum</td>
</tr>
<tr>
<td><tt>0040</tt></td>
<td>TEST7</td>
<td><tt>pkt_header</tt></td>
- <td>bad header</td>
+ <td> header distance exceeded</td>
</tr>
<tr>
<td><tt>0080</tt></td>
<td>TEST8</td>
<td><tt>pkt_autokey</tt></td>
- <td>bad autokey</td>
+ <td>Autokey sequence error</td>
</tr>
<tr>
<td><tt>0100</tt></td>
<td>TEST9</td>
<td><tt>pkt_crypto</tt></td>
- <td>bad crypto</td>
+ <td>Autokey protocol error</td>
</tr>
<tr>
<td><tt>0200</tt></td>
<td>TEST10</td>
<td><tt>peer_stratum</tt></td>
- <td>peer bad synch or stratum</td>
+ <td> invalid header or stratum</td>
</tr>
<tr>
<td><tt>0400</tt></td>
<td>TEST11</td>
<td><tt>peer_dist</tt></td>
- <td>peer distance threshold exceeded</td>
+ <td> distance threshold exceeded</td>
</tr>
<tr>
<td><tt>0800</tt></td>
<td>TEST12</td>
<td><tt>peer_loop</tt></td>
- <td>peer synchronization loop</td>
+ <td> synchronization loop</td>
</tr>
<tr>
<td><tt>1000</tt></td>
<td>TEST13</td>
<td><tt>peer_unreach</tt></td>
- <td>peer unreachable or nonselectable</td>
+ <td> unreachable or nonselect</td>
</tr>
</table>
<h4 id="kiss">Kiss Codes</h4>
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.6 [en] (Win95; U) [Netscape]">
- <meta name="Author" content="Ganesh Ramasivan">
- <title>Bancomm bc635VME Time and Frequency Processor</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.6 [en] (Win95; U) [Netscape]">
+ <meta name="Author" content="Ganesh Ramasivan">
+ <title>Bancomm bc635VME Time and Frequency Processor</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>bc635VME/bc350VXI Time and Frequency Processor</h3>
- <hr>
- <h4>Synopsis</h4>
- <p>Address: 127.127.16.<i>u</i><br>
- Reference ID: BTFP<br>
- Driver ID: GPS_BANCOMM<br>
- Bancomm Device <tt>/dev/btfp0</tt><br>
- Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x</p>
- <h4>Description</h4>
- <p>This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.</p>
- <p>Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.</p>
- <h4>Additional Information</h4>
- <p><a href="../refclock.html">Reference Clock Drivers</a></p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ <body>
+ <h3>bc635VME/bc350VXI Time and Frequency Processor</h3>
+ <hr>
+ <h4>Synopsis</h4>
+
<p>Address: 127.127.16.<i>u</i><br>
+ Reference ID: BTFP<br>
+ Driver ID: GPS_BANCOMM<br>
+ Bancomm Device <tt>/dev/btfp0</tt><br>
+ Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x</p>
+ <h4>Description</h4>
+
<p>This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.</p>
+
<p>Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.</p>
+ <h4>Additional Information</h4>
+
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <title>Trak 8820 GPS Receiver</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]">
+ <title>Trak 8820 GPS Receiver</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>Trak 8820 GPS Receiver</h3>
- <hr>
- <h4>Synopsis</h4>
- <p>Address: 127.127.2.<i>u</i><br>
- Reference ID: <tt>GPS</tt><br>
- Driver ID: <tt>GPS_TRAK</tt><br>
- Serial Port: <tt>/dev/trak<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
- Features: <tt>tty_clk</tt></p>
- <h4>Description</h4>
- <p>This driver supports the Trak 8820 GPS Station Clock. The claimed accuracy at the 1-PPS output is 200-300 ns relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p>
- <p>For best accuracy, this radio requires the <tt>tty_clk</tt> line discipline, which captures a timestamp at the <tt>*</tt> on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the <tt>\r</tt> ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.</p>
- <p>Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.</p>
- <p>In operation, this driver sends a <tt>RQTS\r</tt> request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:</p>
- <pre>*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
+ <body>
+ <h3>Trak 8820 GPS Receiver</h3>
+ <hr>
+ <h4>Synopsis</h4>
+
<p>Address: 127.127.2.<i>u</i><br>
+ Reference ID: <tt>GPS</tt><br>
+ Driver ID: <tt>GPS_TRAK</tt><br>
+ Serial Port: <tt>/dev/trak<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
+ Features: <tt>tty_clk</tt></p>
+ <h4>Description</h4>
+
<p>This driver supports the Trak 8820 GPS Station Clock. The claimed accuracy at the 1-PPS output is 200-300 ns relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p>
+
<p>For best accuracy, this radio requires the <tt>tty_clk</tt> line discipline, which captures a timestamp at the <tt>*</tt> on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the <tt>\r</tt> ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.</p>
+
<p>Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.</p>
+
<p>In operation, this driver sends a <tt>RQTS\r</tt> request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:</p>
+
<pre>*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
on-time = '*'
ddd = day of year
hh:mm:ss = hours, minutes, seconds
4 > 100 ns
3 > 10 ns
2 < 10 ns</pre>
- The alarm condition is indicated by <tt>0</tt> at <tt>Q</tt>, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed.
- <p>The continuous time mode is disabled using the <tt>RQTX\r</tt> request, following which the radio sends a <tt>RQTX DONE<cr><lf></tt> response. In the normal mode, other control and status requests are effective, including the leap-second status request <tt>RQLS<cr></tt>. The radio responds with <tt>RQLS yy,mm,dd<cr><lf></tt>, where <tt>yy,mm,dd</tt> are the year, month and day. Presumably, this gives the epoch of the next leap second, <tt>RQLS 00,00,00</tt> if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.</p>
- <h4>Monitor Data</h4>
- <p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
- <h4>Fudge Factors</h4>
- <p></p>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
- <dt><tt>time2 <i>time</i></tt>
- <dd>Not used by this driver.
- <dt><tt>stratum <i>number</i></tt>
- <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
- <dt><tt>refid <i>string</i></tt>
- <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
- <dt><tt>flag1 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag2 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag3 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag4 0 | 1</tt>
- <dd>Not used by this driver.
- <p>Additional Information</p>
- <p><a href="../refclock.html">Reference Clock Drivers</a></p>
- </dl>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ The alarm condition is indicated by <tt>0</tt> at <tt>Q</tt>, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed.
+
<p>The continuous time mode is disabled using the <tt>RQTX\r</tt> request, following which the radio sends a <tt>RQTX DONE<cr><lf></tt> response. In the normal mode, other control and status requests are effective, including the leap-second status request <tt>RQLS<cr></tt>. The radio responds with <tt>RQLS yy,mm,dd<cr><lf></tt>, where <tt>yy,mm,dd</tt> are the year, month and day. Presumably, this gives the epoch of the next leap second, <tt>RQLS 00,00,00</tt> if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.</p>
+ <h4>Monitor Data</h4>
+
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
+ <h4>Fudge Factors</h4>
+ <dt><tt>time1 <i>time</i></tt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
+ <dt><tt>time2 <i>time</i></tt>
+ <dd>Not used by this driver.
+ <dt><tt>stratum <i>number</i></tt>
+ <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+ <dt><tt>refid <i>string</i></tt>
+ <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.
+ <dt><tt>flag1 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag2 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag3 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag4 0 | 1</tt>
+ <dd>Not used by this driver.
+
<p>Additional Information</p>
+
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
+ </dl>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <title>TrueTime GPS/GOES/OMEGA Receivers</title>
- <link href="scripts/style.css" type="text/css" rel="stylesheet">
- </head>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
+ <title>TrueTime GPS/GOES/OMEGA Receivers</title>
+ <link href="scripts/style.css" type="text/css" rel="stylesheet">
+ </head>
- <body>
- <h3>TrueTime GPS/GOES/OMEGA Receivers</h3>
- <hr>
- <h4>Synopsis</h4>
- Address: 127.127.5.<i>u</i><br>
- Reference ID: <tt>GPS, OMEGA, GOES</tt><br>
- Driver ID: <tt>TRUETIME</tt><br>
- Serial Port: <tt>/dev/true<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
- Features: <tt>tty_clk</tt>
- <h4>Description</h4>
- <p>This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely others in the same model family that use the same timecode formats.</p>
- <p>Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.</p>
- <p>Timcode format: <tt>ADDD:HH:MM:SSQCL</tt> A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed Quality codes indicate possible error of</p>
- <dl>
- <dt>468-DC GOES Receiver<br>
- GPS-TM/TMD Receiver
- <dd>? +/- 500 milliseconds # +/- 50 milliseconds<br>
- * +/- 5 milliseconds . +/- 1 millisecond<br>
- space less than 1 millisecond
- <dt>OM-DC OMEGA Receiver:
- <dd>> +/- 5 seconds<br>
- ? +/- 500 milliseconds # +/- 50 milliseconds<br>
- * +/- 5 milliseconds . +/- 1 millisecond<br>
- A-H less than 1 millisecond. Character indicates which station is being received as follows<br>
- A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan<br>
- The carriage return start bit begins on 0 seconds and extends to 1 bit time.
- </dl>
- <h4>Notes on 468-DC and OMEGA receiver:</h4>
- <p>Send the clock a <tt>R</tt> or <tt>C</tt> and once per second a timestamp will appear. Send a <tt>R</tt> to get the satellite position once (GOES only).</p>
- <h4>Notes on the 468-DC receiver:</h4>
- <p>Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line</p>
- <p><tt>fudge 127.127.5.0 time1 +0.008 time2 -0.004</tt></p>
- <p>This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.</p>
- <p>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)</p>
- <h4>Monitor Data</h4>
- <p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
- <h4>Fudge Factors</h4>
- <dl>
- <dt><tt>time1 <i>time</i></tt>
- <dd>Specifies the time offset calibration factor, in seconds and fraction, to be used for the West satellite, with default 0.0.
- <dt><tt>time2 <i>time</i></tt>
- <dd>. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, with default 0.0.
- <dt><tt>stratum <i>number</i></tt>
- <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
- <dt><tt>refid <i>string</i></tt>
- <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>TRUE</tt>.
- <dt><tt>flag1 0 | 1</tt>
- <dd>Silence the clock side of ntpd, just reading the clock without trying to write to it.
- <dt><tt>flag2 0 | 1</tt>
- <dd>Generate a debug file /tmp/true%d.
- <dt><tt>flag3 0 | 1</tt>
- <dd>Not used by this driver.
- <dt><tt>flag4 0 | 1</tt>
- <dd>Not used by this driver.
- </dl>
- <h4>Additional Information</h4>
- <p><a href="../refclock.html">Reference Clock Drivers</a></p>
- <hr>
- <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
- </body>
+ <body>
+ <h3>TrueTime GPS/GOES/OMEGA Receivers</h3>
+ <hr>
+ <h4>Synopsis</h4>
+ Address: 127.127.5.<i>u</i><br>
+ Reference ID: <tt>GPS, OMEGA, GOES</tt><br>
+ Driver ID: <tt>TRUETIME</tt><br>
+ Serial Port: <tt>/dev/true<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
+ Features: <tt>tty_clk</tt>
+ <h4>Description</h4>
+
<p>This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely others in the same model family that use the same timecode formats.</p>
+
<p>Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.</p>
+
<p>Timcode format: <tt>ADDD:HH:MM:SSQCL</tt> A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed Quality codes indicate possible error of</p>
+ <dt>468-DC GOES Receiver<br>
+ GPS-TM/TMD Receiver
+ <dd>? +/- 500 milliseconds # +/- 50 milliseconds<br>
+ * +/- 5 milliseconds . +/- 1 millisecond<br>
+ space less than 1 millisecond
+ <dt>OM-DC OMEGA Receiver:
+ <dd>> +/- 5 seconds<br>
+ ? +/- 500 milliseconds # +/- 50 milliseconds<br>
+ * +/- 5 milliseconds . +/- 1 millisecond<br>
+ A-H less than 1 millisecond. Character indicates which station is being received as follows<br>
+ A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan<br>
+ The carriage return start bit begins on 0 seconds and extends to 1 bit time.
+ </dl>
+ <h4>Notes on 468-DC and OMEGA receiver:</h4>
+
<p>Send the clock a <tt>R</tt> or <tt>C</tt> and once per second a timestamp will appear. Send a <tt>R</tt> to get the satellite position once (GOES only).</p>
+ <h4>Notes on the 468-DC receiver:</h4>
+
<p>Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line</p>
+
<p><tt>fudge 127.127.5.0 time1 +0.008 time2 -0.004</tt></p>
+
<p>This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.</p>
+
<p>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)</p>
+ <h4>Monitor Data</h4>
+
<p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
+ <h4>Fudge Factors</h4>
+ <dt><tt>time1 <i>time</i></tt>
+ <dd>Specifies the time offset calibration factor, in seconds and fraction, to be used for the West satellite, with default 0.0.
+ <dt><tt>time2 <i>time</i></tt>
+ <dd>. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, with default 0.0.
+ <dt><tt>stratum <i>number</i></tt>
+ <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+ <dt><tt>refid <i>string</i></tt>
+ <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>TRUE</tt>.
+ <dt><tt>flag1 0 | 1</tt>
+ <dd>Silence the clock side of ntpd, just reading the clock without trying to write to it.
+ <dt><tt>flag2 0 | 1</tt>
+ <dd>Generate a debug file /tmp/true%d.
+ <dt><tt>flag3 0 | 1</tt>
+ <dd>Not used by this driver.
+ <dt><tt>flag4 0 | 1</tt>
+ <dd>Not used by this driver.
+ </dl>
+ <h4>Additional Information</h4>
+
<p><a href="../refclock.html">Reference Clock Drivers</a></p>
+ <hr>
+ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
+ </body>
</html>
\ No newline at end of file
<body>
<h3>How NTP Works</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->14-Oct-2010 3:26<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->14-Oct-2010 16:45<!-- #EndDate -->
UTC</p>
<h4>Related Links</h4>
<script type="text/javascript" language="javascript" src="scripts/special.txt"></script>
<p><img src="pic/fig_3_1.gif" alt="gif"></p>
<p>Figure 1. NTP Daemon Processes and Algorithms</p>
</div>
-<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and performs the packet sanity tests of the <a href="decode.html#flash">flash status word</a>. Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process runs the on-wire protocol that uses four raw timestamps: the <em>origin timestamp</em> <em>T</em><sub>1</sub> upon departure of the client request, the <em>receive timestamp</em> <em>T</em><sub>2</sub> upon arrival at the server, the <em>transmit timestamp</em> <em>T</em><sub>3</sub> upon departure of the server reply, and the <em>destination timestamp</em> <em>T</em><sub>4</sub> upon arrival at the client. These timestamps, which are recorded by the <tt>rawstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command, are used to calculate the clock offset and roundtrip delay samples:</p>
+<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. Packets are exchanged between the client and server using the <em>on-wire protocol</em> described in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>. The protocol is resistant to lost, replayed or spoofed packets.</p>
+<p> The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and performs the packet sanity tests of the <a href="decode.html#flash">flash status word</a>. Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process runs the on-wire protocol that uses four raw timestamps: the <em>origin timestamp</em> <em>T</em><sub>1</sub> upon departure of the client request, the <em>receive timestamp</em> <em>T</em><sub>2</sub> upon arrival at the server, the <em>transmit timestamp</em> <em>T</em><sub>3</sub> upon departure of the server reply, and the <em>destination timestamp</em> <em>T</em><sub>4</sub> upon arrival at the client. These timestamps, which are recorded by the <tt>rawstats</tt> option of the <a href="monopt.html#filegen"><tt>filegen</tt></a> command, are used to calculate the clock offset and roundtrip delay samples:</p>
<div align="center">
<p>offset = [(<em>T</em><sub>2</sub> -<em> T</em><sub>1</sub>) + (<em>T</em><sub>3</sub> - <em>T</em><sub>4</sub>)] / 2<br>
delay = (<em>T</em><sub>4</sub> - <em>T</em><sub>1</sub>) - (<em>T</em><sub>3</sub> - <em>T</em><sub>2</sub>).</p>
projects / thirdparty / ntp.git / commitdiff
