[ntp:bk-ntp-dev-send] BitKeeper diffs

Harlan Stenn stenn at whimsy.udel.edu
Sun Aug 31 03:21:36 UTC 2008


#### ChangeSet ####
2008-08-30 23:19:40-04:00, stenn at whimsy.udel.edu 
  Documentation updates from Dave Mills

==== ChangeLog ====
2008-08-30 23:19:25-04:00, stenn at whimsy.udel.edu +1 -0
  Documentation updates from Dave Mills

--- 1.212/ChangeLog	2008-08-30 23:13:47 -04:00
+++ 1.213/ChangeLog	2008-08-30 23:19:25 -04:00
@@ -1,4 +1,5 @@
 * Changes from Dave Mills:
+  Documentation updates.
   Fix a corner case where a frequency update was reported but not set.
   When LEAP_NOTINSYNC->LEAP_NOWARNING, call crypto_update() if we have
   crypto_flags.

==== html/confopt.html ====
2008-08-30 23:18:11-04:00, stenn at whimsy.udel.edu +1 -1
  Documentation updates from Dave Mills

--- 1.42/html/confopt.html	2008-08-09 17:32:41 -04:00
+++ 1.43/html/confopt.html	2008-08-30 23:18:11 -04:00
@@ -74,7 +74,7 @@
 		    <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>
-			<dd>Operate in interleaved mode (symmetric and broadcast modes only). (see <a href="x;eave.html">NTP Interleaved Modes</a>)
+			<dd>Operate in interleaved mode (symmetric and broadcast modes only). (see <a href="xleave.html">NTP Interleaved Modes</a>)
 		</dl>
 		<h4 id="aux">Auxilliary Commands</h4>                        
 		<dl>

==== html/decode.html ====
2008-08-30 23:18:12-04:00, stenn at whimsy.udel.edu +0 -1
  Documentation updates from Dave Mills

--- 1.2/html/decode.html	2008-07-16 05:11:44 -04:00
+++ 1.3/html/decode.html	2008-08-30 23:18:12 -04:00
@@ -675,7 +675,6 @@
 		</table>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
-		</p>
 	</body>
 
 </html>

==== html/gadget.html ====
2008-08-30 23:18:13-04:00, stenn at whimsy.udel.edu +3 -3
  Documentation updates from Dave Mills

--- 1.2/html/gadget.html	2008-01-26 03:11:48 -05:00
+++ 1.3/html/gadget.html	2008-08-30 23:18:13 -04:00
@@ -19,9 +19,9 @@
 		</p>
 		<h4>table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#intro">Introduction</a>
-			<li class="inline"><a href="#ckt">Circuit Description</a>
-			<li class="inline"><a href="#file">Files</a>
+			<li class="inline"><a href="#intro">Introduction</a></li>
+			<li class="inline"><a href="#ckt">Circuit Description</a></li>
+			<li class="inline"><a href="#file">Files</a></li>
 		</ul>
 		<hr>
 		<h4 id="intro">Introduction</h4>

==== html/howto.html ====
2008-08-30 23:18:13-04:00, stenn at whimsy.udel.edu +3 -2
  Documentation updates from Dave Mills

--- 1.19/html/howto.html	2008-01-26 03:11:49 -05:00
+++ 1.20/html/howto.html	2008-08-30 23:18:13 -04:00
@@ -79,8 +79,9 @@
 			<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.
 		</dl>
 		<hr>
-		<center>
-			<img src="pic/pogo1a.gif" alt="gif"></center>
+		<div align="center">
+			<img src="pic/pogo1a.gif" alt="gif">
+			</div>
 		<br>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>

==== html/index.html ====
2008-08-30 23:18:14-04:00, stenn at whimsy.udel.edu +9 -8
  Documentation updates from Dave Mills

--- 1.37/html/index.html	2008-05-12 01:36:23 -04:00
+++ 1.38/html/index.html	2008-08-30 23:18:14 -04:00
@@ -18,22 +18,23 @@
 		<br clear="left">
 		<h4>Related Links</h4>
 		<ul>
-			<li>A list of all links is on the <a href="sitemap.html">Site Map</a> page.
+			<li>A list of all links is on the <a href="sitemap.html">Site Map</a> page.</li>
 		</ul>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#intro">Introduction</a>
-			<li class="inline"><a href="#build">Building and Installing NTP</a>
-			<li class="inline"><a href="#conf">Configuring Clients and Servers</a>
-			<li class="inline"><a href="#opt">Features and Options</a>
-			<li class="inline"><a href="#prob">Resolving Problems</a>
-			<li class="inline"><a href="#info">Further Information</a>
+			<li class="inline"><a href="#intro">Introduction</a></li>
+			<li class="inline"><a href="#build">Building and Installing NTP</a></li>
+			<li class="inline"><a href="#conf">Configuring Clients and Servers</a></li>
+			<li class="inline"><a href="#opt">Features and Options</a></li>
+			<li class="inline"><a href="#prob">Resolving Problems</a></li>
+			<li class="inline"><a href="#info">Further Information</a></li>
 	</ul>
 		<hr>
 		<h4 id="intro">Introduction</h4>
 		<p>Note: The NTP Version 4 software contained in this distribution is available without charge under the conditions set forth in the <a href="copyright.html">Copyright Notice</a>.</p>
 		<dl>
-		<dd>It is very important that readers understand that the NTP document collection began 25 years ago and remains today a work in progress. It has evolved as new features were invented and old features retired. It has been widely copied, cached and morphed to other formats, including man pages, with varying loss of fidelity. However, these HTML pages are the ONLY authoritative and definitive reference. Readers should always use the collection that comes with the distribution they use. A copy of the online collection at <a href="http://www.ntp.org">www.ntp.org</a> is normally included in the most recent snapshot, but might not agree with an earlier snapshot or release version.</dl>
+		<dd>It is very important that readers understand that the NTP document collection began 25 years ago and remains today a work in progress. It has evolved as new features were invented and old features retired. It has been widely copied, cached and morphed to other formats, including man pages, with varying loss of fidelity. However, these HTML pages are the ONLY authoritative and definitive reference. Readers should always use the collection that comes with the distribution they use. A copy of the online collection at <a href="http://www.ntp.org">www.ntp.org</a> is normally included in the most recent snapshot, but might not agree with an earlier snapshot or release version.</dd>
+		</dl>
 		<p>The Network Time Protocol (NTP) is widely used to synchronize a computer to Internet time servers or other sources, such as a radio or satellite receiver or telephone modem service. It provides accuracies typically less than a millisecond on LANs and up to a few milliseconds on WANs. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.</p>
 		<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in early 2008 includes several thousand  servers in most countries and on every continent of the globe, including Antarctica. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
 		<p>The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice. </p>

==== html/kern.html ====
2008-08-30 23:18:15-04:00, stenn at whimsy.udel.edu +3 -3
  Documentation updates from Dave Mills

--- 1.16/html/kern.html	2008-05-12 01:36:25 -04:00
+++ 1.17/html/kern.html	2008-08-30 23:18:15 -04:00
@@ -22,9 +22,9 @@
 		<p>The kernel model also provides support for an external precision timing source, such as described in the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The new system calls are used by the <a href="kernpps.html">PPSAPI interface</a> and in turn by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver (type 22) to provide synchronization limited in principle only by the accuracy and stability of the external timing source.</p>
 		<h4>References</h4>
 		<ol>
-			<li>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.pdf">PDF</a>, Slides: <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.html">HTML</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ppt">PowerPoint</a>
-			<li>Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kerna.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kerna.pdf">PDF</a>, Body: <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kernb.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kernb.pdf">PDF</a>
-			<li>Mills, D.L. A kernel model for precision timekeeping. Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1589.txt">ASCII</a>
+			<li>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/papers/nano/nano2.pdf">PDF</a>, Slides: <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.html">HTML</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.pdf">PDF</a> | <a href="http://www.eecis.udel.edu/%7emills/database/brief/nano/nano.ppt">PowerPoint</a></li>
+			<li>Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kerna.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kerna.pdf">PDF</a>, Body: <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kernb.ps">PostScript</a> | <a href="http://www.eecis.udel.edu/%7emills/database/reports/kern/kernb.pdf">PDF</a></li>
+			<li>Mills, D.L. A kernel model for precision timekeeping. Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href="http://www.eecis.udel.edu/%7emills/database/rfc/rfc1589.txt">ASCII</a></li>
 		</ol>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>

==== html/keygen.html ====
2008-08-30 23:18:16-04:00, stenn at whimsy.udel.edu +65 -20
  Documentation updates from Dave Mills

--- 1.12/html/keygen.html	2008-07-16 05:11:46 -04:00
+++ 1.13/html/keygen.html	2008-08-30 23:18:16 -04:00
@@ -7,7 +7,7 @@
 		<meta name="generator" content="HTML Tidy, see www.w3.org">
 		<title>ntp-keygen - generate public and private keys</title>
 		<link href="scripts/style.css" type="text/css" rel="stylesheet">
-	</head>
+</head>
 
 	<body>
 		<h3><tt>ntp-keygen</tt> - generate public and private keys</h3>
@@ -20,14 +20,14 @@
 		<h4>Table of Contents</h4>
 		<ul>
 			<li class="inline"><a href="#synop">Synopsis</a>
-			<li class="inline"><a href="#descrip">Description</a>
-			<li class="inline"><a href="#run">Running the program</a>
-			<li class="inline"><a href="#trust">Trusted Hosts and Secure Groups</a>
-			<li class="inline"><a href="#ident">Identity Schemes</a>
+			<li class="inline"><a href="#descrip">Description</a></li>
+			<li class="inline"><a href="#run">Running the program</a></li>
+			<li class="inline"><a href="#trust">Trusted Hosts and Secure Groups</a></li>
+			<li class="inline"><a href="#ident">Identity Schemes</a></li>
 			<li class="inline"><a href="#cmd">Command Line Options</a>
-			<li class="inline"><a href="#rand">Random Seed File</a>
-			<li class="inline"><a href="#fmt">Cryptographic Data Files</a>
-			<li class="inline"><a href="#bug">Bugs</a>
+			<li class="inline"><a href="#rand">Random Seed File</a></li>
+			<li class="inline"><a href="#fmt">Cryptographic Data Files</a></li>
+			<li class="inline"><a href="#bug">Bugs</a></li>
 		</ul>
 		<hr>
 		<h4 id="synop">Synopsis</h4>
@@ -41,25 +41,61 @@
 		<p>All files and links are installed by default in the keys directory <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks. The location of the keys directory can be changed by the <tt>keysdir</tt> configuration command. Normally, encrypted  files for each host are generated by that host and used only by that host, although exceptions exist as noted later on this page.</p>
 		<p>This program directs commentary and error messages to the standard error stream <tt>stderr</tt> and remote files to the standard output stream <tt>stdout</tt> where they can be piped to other aplications or redirected to a file. The names used for generated files and links all begin with the string <tt>ntpkey</tt> and include the file type, generating host and filestamp, as described in the <a href="#fmt">Cryptographic Data Files</a> section below</p>
 		<h4 id="run">Running the Program</h4>
-		<p>To test and gain experience with Autokey concepts, log in as root and change to the keys directory, usually <tt>/usr/local/etc. </tt>When run for the first time, or if all files with names beginning <tt>ntpkey</tt> have been removed, use the <tt>ntp-keygen </tt>command without arguments to generate a default RSA host key and matching RSA-MD5 certificate with expiration date one year hence. If run again, the program uses the same host key, but generates a new certificate with new expiration date one year hence.</p>
-		<p>Run the command on as many hosts as necessary. Designate one of them as the trusted host (TH) using <tt>ntp-keygen</tt>  with the <tt>-T</tt> option and configure it to synchronize from reliable Internet servers. Then configure the other hosts to synchronize to the TH directly or indirectly. A certificate trail is created when Autokey asks the immediately ascendant host towards the root to sign its certificate, which is then provided to the immediately descendant host on request. All group hosts should have acyclic certificate trails ending on the TH.</p>
-		<p>The host key is used to encrypt the cookie when required and so must be RSA type. By default, the host key is also the sign key used to encrypt signatures. A different sign key can be assigned using the <tt>-S</tt> option and this can be either RSA or DSA type. By default, the message digest type is MD5, but any combination of sign key type and message digest type supported by the OpenSSL library can be specified using the <tt>-c</tt> option.</p>
-		<h4 id="trust">Trusted Hosts and Secure Groups</h4>
+		<p>To test and gain experience with Autokey concepts, log in as root and change
+			to the keys directory, usually <tt>/usr/local/etc. </tt>When run for the first
+			time, or if all files with names beginning <tt>ntpkey</tt> have been removed,
+			use the <tt>ntp-keygen </tt>command without arguments to generate a default
+			RSA host key and matching RSA-MD5 certificate with expiration date
+			one year hence. If run again, the program uses the existing keys
+			and parameters and generates a new certificate with new expiration
+			date one year hence; however, the certificate is not generated 
+			if the <tt>-e</tt> or <tt>-q</tt> options
+			are  present..</p>
+	<p>Run the command on as many hosts as necessary. Designate one of them as the trusted host (TH) using <tt>ntp-keygen</tt>  with the <tt>-T</tt> option and configure it to synchronize from reliable Internet servers. Then configure the other hosts to synchronize to the TH directly or indirectly. A certificate trail is created when Autokey asks the immediately ascendant host towards the root to sign its certificate, which is then provided to the immediately descendant host on request. All group hosts should have acyclic certificate trails ending on the TH.</p>
+		<p>The host key is used to encrypt the cookie when required and so must be
+			RSA type. By default, the host key is also the sign key used to encrypt
+			signatures. A different sign key can be assigned using the <tt>-S</tt> option
+			and this can be either RSA or DSA type. By default, the signature
+			message digest type is MD5, but any combination of sign key type
+			and sign digest type supported by the OpenSSL library can be specified
+			using the <tt>-c</tt> option.
+			At the moment, legacy considerations require the NTP packet header
+			digest type  to be MD5.</p>
+	<h4 id="trust">Trusted Hosts and Secure Groups</h4>
 		<p>As described on the <a href="authopt.html">Authentication Options</a> page, an NTP&nbsp;secure group consists of one or more low-stratum THs as the root from which all other group hosts derive synchronization directly or indirectly. For authentication purposes all hosts in a group must have the same group name specified by the <tt>-i</tt> option and matching the <tt>crypto ident</tt> command option. The group name is used in the subject and issuer fields of trusted certificates and when constructing the file names for identity keys. All hosts must have different host names specified by the <tt>-s</tt> option and matching the <tt>crypto host</tt> command option. Host names are used in the subject and issuer fields of nontrusted certificates and when constructing the file names for host and sign keys and certificats. Host and group names are used only for authentication purposes and have nothing to do with DNS&nbsp;names.</p>
 		<h4 id="ident">Identity Schemes</h4>
 		<p>As described on the <a href="authopt.html">Authentication Options</a> page, there are five identity schemes, three of which - IFF, GQ and MV - require identity keys specific to each scheme. There are two files for each scheme, an encrypted keys file and a nonencrypted parameters file. In general, servers use the keys file and clients use the parameters file. In general, servers expecting to support a client population ned the keys file while others need only the parameters file. Both files are generated by the TA on behalf of all servers and clients in the group.</p>
 		<p>The parameters files are public; they can be stored in a public place and sent in the clear. The keys files are encrypted with the local password. To retrieve the keys file, a host sends a mail request to the TA including its local password. The TA encrypts the keys file with this password and returns it as an attachment. The attachment is then copied intact to the keys directory with name given in the first line of the file, but all in lower case and with the filestamp deleted..</p>
-		<p>For example, the TA can generate IFF&nbsp;keys, trusted certificate and parameter using the command</p>
-		<p><tt>ntp-keygen -p <i>local_passwd</i><i> </i>-T&nbsp;-I -e &gt;<i>parameters_file</i></tt></p>
-		<p>where the -e option redirects the <tt><i>parameters_file</i></tt> to the standard output stream for a mail application or stored locally for later distribution. </p>
-		<p><tt><i> </i></tt></p>
+		<p>For example, the TA can generate IFF&nbsp;keys and trusted certificate
+			using the command</p>
+		<p><tt>ntp-keygen -p <i>local_passwd</i> -T -I</tt></p>
+		<p>Once these media have been generated, the TA can then generate the public
+			parameters using the command</p>
+		<tt>ntp-keygen -p local_passwd -e &gt;<i>parameters_file</i></tt></p>
+		<p>where the <tt>-e</tt> option redirects the unencrypted parameters to
+			the standard output stream for a mail application or stored locally
+			for later distribution. In a similar fashion the <tt>-q</tt> option redirects
+			the encrypted server keys to the standard output stream.</p>
+	<p><tt><i></tt></p>
 		<h4 id="cmd">Command Line Options</h4>
 		<dl>
 			<dt><tt>-c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]</tt>
 			<dd>Select certificate and message digest/signature encryption scheme. Note that RSA schemes must be used with a RSA sign key and DSA schemes must be used with a DSA sign key. The default without this option is <tt>RSA-MD5</tt>.
 			<dt><tt>-d</tt>
 			<dd>Enable debugging. This option displays the cryptographic data produced for eye-friendly billboards.<dt><tt>-e</tt>
-			<dd>Generate unencrypted IFF or GQ parameters file from existing key file <tt>IFFkey</tt>. or <tt>GQkey</tt>  file, respectively. The file contents are sent to the standard output stream <tt>stdout</tt>. Note:&nbsp;Unencrypted Q&nbsp;parameter files should be used with caution, as a host in possesion of this file can masquerade as a group member. Use the GQ&nbsp;encrypted keys fiie instead.<dt><tt>-G</tt>
+			<dd>Extract the  IFF or GQ public parameters  from the   <tt>IFFkey</tt>				or <tt>GQkey</tt>  keys
+				file previously specified. Send the unencrypted data to the 
+				standard output stream <tt>stdout</tt>.
+				While the  IFF parameters do not reveal the
+				private group key, &nbsp;the
+			 	GQ parameters  should be used with caution, as
+				they include the group key. Use the <tt>-q</tt> option with password
+				 instead.
+			Note: a new certificate is not generated when this option is present.
+			
+				This allows multiple commands with this option but  without disturbing
+				existing media.
+			<dt><tt>-G</tt>
 			<dd>Generate GQ&nbsp;key file <tt>GQkey </tt>and link <tt>gqkey </tt>for the Guillou-Quisquater (GQ) identity scheme.
 			<dt><tt>-H</tt>
 			<dd>Generate a new public/private host keys <tt>RSAkey</tt>, and link <tt>host</tt>.
@@ -68,13 +104,22 @@
 			<dd>Set the group name to <tt><i>group</i></tt> for generated identity files. This is useful only if the TA&nbsp;is not a group member and is generally considered not a good practice.<dt><tt>-M</tt>
 			<dd>Generate a new MD5 key file.<dt><tt>-P</tt>
 			<dd>Generate a new private certificate used by the PC identity scheme. By default, the program generates public certificates. Note: the PC&nbsp;identity scheme is not recommended for new installations.<dt><tt>-p <i>passwd</i></tt>
-			<dd>Set the password for writing encrypted files to <tt><i>passwd</i></tt>. By default, the write password is the read password.<dt><tt>-q <i>passwd</i></tt>
-			<dd>Set the password for reading encrypted files to <tt><i>passwd</i></tt>. By default,  the read password is the host name.<dt><tt>-S [ RSA | DSA ]</tt>
+			<dd>Set the password for reading and writing encrypted files to <tt><i>passwd</i></tt>.
+				By default, the password is the host name.<dt><tt>-q <i>passwd</i></tt>
+			<dd>Extract the encrypted IFF or GQ server keys from the   <tt>IFFkey</tt>
+				or <tt>GQkey</tt> key file previously generated. The data are
+				sent to the standard output stream <tt>stdout</tt>. Set the password for
+				writing the data, which is also the password to read the data
+				file in another host. By default, the password is the host name.
+			Note: a new certificate is not generated when this option is present.
+				This allows multiple commands with this option but  without disturbing
+				existing media.
+			<dt><tt>-S [ RSA | DSA ]</tt>
 			<dd>Generate a new sign key of the designated type. By default, the sign key is the host key.<dt><tt>-s <i>name</i></tt>
 			<dd>Set the host name to <tt><i>name</i></tt>. This is used in the host and sign key file names, as well as the subject and issuer names in the certificate. It must match the host name specified in the <tt>CRYPTO</tt>&nbsp;configuration command. <dt><tt>-T</tt>
 			<dd>Generate a trusted certificate. By default, the program generates nontrusted certificates.<dt><tt>-V <i>nkeys</i></tt>
 			<dd>Generate server parameters <tt>MV</tt> and <tt><i>nkeys</i></tt> client keys for the Mu-Varadharajan (MV)  identity scheme. Note: support for this option should be considered a work in progress.</dl>
-		<h4 id="rand">Random Seed File</h4>
+	<h4 id="rand">Random Seed File</h4>
 		<p>All cryptographically sound key generation schemes must have means to randomize the entropy seed used to initialize the internal pseudo-random number generator used by the OpenSSL library routines. If a site supports <tt>ssh</tt>, it is very likely that means to do this are already available. The entropy seed used by the OpenSSL library is contained in a file, usually called <tt>.rnd</tt>, which must be available when starting the <tt>ntp-keygen</tt> program or <tt>ntpd</tt> daemon.</p>
 		<p>The OpenSSL library looks for the file using the path specified by the <tt>RANDFILE</tt> environment variable in the user home directory, whether root or some other user. If the <tt>RANDFILE</tt> environment variable is not present, the library looks for the <tt>.rnd</tt> file in the user home directory. Since both the <tt>ntp-keygen</tt> program and <tt>ntpd</tt> daemon must run as root, the logical place to put this file is in <tt>/.rnd</tt> or <tt>/root/.rnd</tt>. If the file is not available or cannot be written, the program exits with a message to the system log.</p>
 		<h4 id="priv">Cryptographic Data Files</h4>

==== html/manyopt.html ====
2008-08-30 23:18:16-04:00, stenn at whimsy.udel.edu +3 -3
  Documentation updates from Dave Mills

--- 1.17/html/manyopt.html	2008-05-12 01:36:26 -04:00
+++ 1.18/html/manyopt.html	2008-08-30 23:18:16 -04:00
@@ -19,9 +19,9 @@
 		<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#bcst">Broadcast/Multicast Scheme</a>
-			<li class="inline"><a href="#mcst">Manycast Scheme</a>
-			<li class="inline"><a href="#poolt">Server Pool Scheme</a>
+			<li class="inline"><a href="#bcst">Broadcast/Multicast Scheme</a></li>
+			<li class="inline"><a href="#mcst">Manycast Scheme</a></li>
+			<li class="inline"><a href="#poolt">Server Pool Scheme</a></li>
 		</ul>
 		<hr>
 		<h4 id="modes">Introduction</h4>

==== html/ntp_conf.html ====
2008-08-30 23:18:18-04:00, stenn at whimsy.udel.edu +10 -9
  Documentation updates from Dave Mills

--- 1.2/html/ntp_conf.html	2008-05-12 01:36:29 -04:00
+++ 1.3/html/ntp_conf.html	2008-08-30 23:18:18 -04:00
@@ -101,8 +101,9 @@
 			<dd>This file is structured as a standard Bison file and consists of three main parts, separated by <tt>%%</tt>:
 		</dl>
 		<ol>
-			<li>The prologue and bison declarations: This section contains a list of the terminal symbols, the non-terminal symbols and the types of these symbols.<li>The rules section: This section contains a description of the actual phrase-structure rules that are used to parse the configuration commands. Each rule consists of a left-hand side (LHS), a right-hand side (RHS) and an optional action. As is standard with phrase-structure grammars, the LHS consists of a single non-terminal symbol. The RHS can contain both terminal and non-terminal symbols, while the optional action can consist of any arbitrary C code.
-			<li>The epilogue: This section is left empty on purpose. It is traditionally used to code the support functions needed to build the ASTs Since, we have moved all the support functions to <b>ntp_config.c</b>, this section is left empty. 
+			<li>The prologue and bison declarations: This section contains a list of the terminal symbols, the non-terminal symbols and the types of these symbols.</li>
+			<li>The rules section: This section contains a description of the actual phrase-structure rules that are used to parse the configuration commands. Each rule consists of a left-hand side (LHS), a right-hand side (RHS) and an optional action. As is standard with phrase-structure grammars, the LHS consists of a single non-terminal symbol. The RHS can contain both terminal and non-terminal symbols, while the optional action can consist of any arbitrary C code.</li>
+			<li>The epilogue: This section is left empty on purpose. It is traditionally used to code the support functions needed to build the ASTs Since, we have moved all the support functions to <b>ntp_config.c</b>, this section is left empty.</li> 
 		</ol>
 		<h4>Prologue and Bison Declarations</h4>
 		<p>All the terminal symbols (also known as tokens) have to be declared in the prologue section. Note that terminals and non-terminals may have values associated with them and these values have types. (More on this later). An unnamed union has to be declared with all the possible types at the start of the prologue section. For example, we declare the following union at the start of the <b>ntp_config.y</b> file:</p>
@@ -153,17 +154,17 @@
 		<p><b>ntp_config.c</b></p>
 		<p>This file contains the major chunk of the configuration code including all the support functions needed for building and traversing the ASTs. As such, most of the functions in this file can be divided into two groups:</p>
 		<ol>
-			<li>Functions that have a <tt>create_</tt> prefix. These functions are used to build a node of the AST. 
-			<li>Functions that have a <tt>config_</tt> prefix. These functions are used to traverse the AST and configure NTP according to the nodes present on the tree. 
+			<li>Functions that have a <tt>create_</tt> prefix. These functions are used to build a node of the AST.</li> 
+			<li>Functions that have a <tt>config_</tt> prefix. These functions are used to traverse the AST and configure NTP according to the nodes present on the tree.</li> 
 		</ol>
 		<h4>Guidelines for Adding Configuration Commands</h4>
 		<p>The following steps may be used to add a new configuration command to the NTP reference implementation:</p>
 		<ol>
-			<li>Write phrase-structure grammar rules for the syntax of the new command. Add these rules to the rules section of the <b>ntp_config.y</b> file. 
-			<li>Write the action to be performed on recognizing the rules. These actions will be used to build the AST.
-			<li>If new reserved words are needed, add these to the <tt>struct key_tok keyword_list[]</tt>structure in the <b>ntp_config.c </b>file. This will allow the scanner to recognize these reserved words and generate the desired tokens on recognizing them. 
-			<li>Specify the types of all the terminals and non-terminal symbols in the prologue section of the <b>ntp_config.c</b> file. 
-			<li>Write a function with a <tt>config_</tt> prefix that will   be executed for this new command. Make sure this function is called in the <tt>config_ntpd()</tt>function. 
+			<li>Write phrase-structure grammar rules for the syntax of the new command. Add these rules to the rules section of the <b>ntp_config.y</b> file. </li>
+			<li>Write the action to be performed on recognizing the rules. These actions will be used to build the AST.</li>
+			<li>If new reserved words are needed, add these to the <tt>struct key_tok keyword_list[]</tt>structure in the <b>ntp_config.c </b>file. This will allow the scanner to recognize these reserved words and generate the desired tokens on recognizing them.</li> 
+			<li>Specify the types of all the terminals and non-terminal symbols in the prologue section of the <b>ntp_config.c</b> file.</li> 
+			<li>Write a function with a <tt>config_</tt> prefix that will   be executed for this new command. Make sure this function is called in the <tt>config_ntpd()</tt>function.</li> 
 		</ol>
 		<hr>
 		<address><a href="mailto:skamboj at udel.edu">Sachin Kamboj</a></address>

==== html/ntpd.html ====
2008-08-30 23:18:19-04:00, stenn at whimsy.udel.edu +9 -9
  Documentation updates from Dave Mills

--- 1.45/html/ntpd.html	2008-08-17 06:57:11 -04:00
+++ 1.46/html/ntpd.html	2008-08-30 23:18:19 -04:00
@@ -19,15 +19,15 @@
 		<script type="text/javascript" language="javascript" src="scripts/command.txt"></script>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#synop">Synopsis</a>
-			<li class="inline"><a href="#descr">Description</a>
-			<li class="inline"><a href="#time">Setting the Time and Frequency</a>
-			<li class="inline"><a href="#modes">Operating Modes</a>
-			<li class="inline"><a href="#poll">Poll Interval Control</a>
-			<li class="inline"><a href="#leap">Leap Second Processing</a>
-			<li class="inline"><a href="#notes">Additional Features</a>
-			<li class="inline"><a href="#cmd">Command Line Options</a>
-			<li class="inline"><a href="#cfg">The Configuration File</a>
+			<li class="inline"><a href="#synop">Synopsis</a></li>
+			<li class="inline"><a href="#descr">Description</a></li>
+			<li class="inline"><a href="#time">Setting the Time and Frequency</a></li>
+			<li class="inline"><a href="#modes">Operating Modes</a></li>
+			<li class="inline"><a href="#poll">Poll Interval Control</a></li>
+			<li class="inline"><a href="#leap">Leap Second Processing</a></li>
+			<li class="inline"><a href="#notes">Additional Features</a></li>
+			<li class="inline"><a href="#cmd">Command Line Options</a></li>
+			<li class="inline"><a href="#cfg">The Configuration File</a></li>
 			<li class="inline"><a href="#files">Files</a>
 		</ul>
 		<hr>

==== html/ntpdsim_new.html ====
2008-08-30 23:18:20-04:00, stenn at whimsy.udel.edu +8 -1
  Documentation updates from Dave Mills

--- 1.3/html/ntpdsim_new.html	2008-05-12 01:36:31 -04:00
+++ 1.4/html/ntpdsim_new.html	2008-08-30 23:18:20 -04:00
@@ -25,7 +25,14 @@
 		</ul>
 		<h4 id="description">Description</h4>
 		<p>The ntpdsim program is used to simulate and study the behavior of an NTP daemon that derives its time from a number of different simulated time sources (servers). Each simulated server can be configured to have a different time offset, frequency offset, propagation delay, processing delay, network jitter and oscillator wander.</p>
-		<p>The ntpdsim program runs all the same selection, mitigation, and discipline algorithms as the actual ntpd daemon at the client. (It actually uses the same code). However, the input/output routines and servers are simulated. That is, instead of sending the client messages over the network to the actual servers, the client messages are intercepted by the ntpdsim program, which then generates the replies to those messages. The reply messages are carefully "inserted" into the input queue of the client at the right time according to the specified server properties (like propagation delay).</p>
+		<p>The ntpdsim program runs all the same selection, mitigation, and discipline
+			algorithms as the actual ntpd daemon at the client. (It actually
+			uses the same code). However, the input/output routines and servers are simulated.
+			That is, instead of sending the client messages over the network
+			to the actual servers, the client messages are intercepted by the ntpdsim
+			program, which then generates the replies to those messages. The reply messages
+			are carefully &quot;inserted&quot; into the input queue of the client at the right time
+			according to the specified server properties (like propagation delay).</p>
 		<p>Each simulated server runs according to a specified script that describes the server properties at a particular time. Each script consists of a series of consecutive acts. Each act runs for a particular duration and specifies the frequency offset, propagation delay, processing delay, network jitter and oscillator wander of the server for that duration. Once the duration of an act expires, the simulated server reconfigures itself according to the properties specified in the next act.</p>
 		<h4 id="configuration">Configuration</h4>
 		<p>The ntpdsim program is configured by providing a configuration file at startup. The crux of the simulator configuration is specified using a <tt>simulate</tt> command, the syntax of which is given below. Note that all time quantities are in seconds and all frequency quantities are in parts per million (PPM):</p>

==== html/parsenew.html ====
2008-08-30 23:18:21-04:00, stenn at whimsy.udel.edu +1 -3
  Documentation updates from Dave Mills

--- 1.10/html/parsenew.html	2005-09-15 02:22:35 -04:00
+++ 1.11/html/parsenew.html	2008-08-30 23:18:21 -04:00
@@ -185,9 +185,7 @@ struct clockformat
 		</ol>
 		<p>Well, this is very sketchy, i know. But I hope it helps a little bit. The best way is to look which clock comes closest to your and tweak that code.</p>
 		<p>Two sorts of clocks are used with parse. Clocks that automatically send their time code (once a second) do not need entries in the poll routines because they send the data all the time. The second sort are the clocks that need a command sent to them in order to reply with a time code (like the Trimble clock).</p>
-		<p>For questions: <a href="mailto:%20kardel <AT> acm.org">kardel 
-				<AT>
-				acm.org</a>.</p>
+		<p>For questions: <a href="mailto:%20kardel <AT> acm.org">kardel at acm.org</a>.</p>
 		<p>Please include an exact description on how your clock works. (initialisation, TTY modes, strings to be sent to it, responses received from the clock).</p>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>

==== html/pps.html ====
2008-08-30 23:18:22-04:00, stenn at whimsy.udel.edu +6 -4
  Documentation updates from Dave Mills

--- 1.19/html/pps.html	2008-01-26 03:11:59 -05:00
+++ 1.20/html/pps.html	2008-08-30 23:18:22 -04:00
@@ -18,10 +18,12 @@
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
 		<h4>Table of Contents</h4>
-			<li class="inline"><a href="#intro">Introduction</a>
-			<li class="inline"><a href="#gadget">Gadget Box</a>
-			<li class="inline"><a href="#opsys">Operating System Support</a>
-			<li class="inline"><a href="#use">Using the Pulse-per-Second (PPS) Signal</a>
+		<ul>
+			<li class="inline"><a href="#intro">Introduction</a></li>
+			<li class="inline"><a href="#gadget">Gadget Box</a></li>
+			<li class="inline"><a href="#opsys">Operating System Support</a></li>
+			<li class="inline"><a href="#use">Using the Pulse-per-Second (PPS) Signal</a></li>
+			</ul>
 		<hr>
 		<h4 id="intro">Introduction</h4>
 			<p>Most radio clocks are connected using a serial port operating at speeds of 9600 bps. The accuracy using typical timecode formats, where the on-time epoch is indicated by a designated ASCII character like carriage-return <tt>&lt;cr&gt;</tt>, is normally limited to a hundred microseconds. Using carefuly crafted averaging techniques, the NTP&nbsp;algorithms can whittle this down to a few tens of microseconds. However, some radios produce a PPS signal which can be used to improve the accuracy to few microseconds. This page describes the hardware and software necessar for NTP to use the PPS signal.</p>

==== html/prefer.html ====
2008-08-30 23:18:22-04:00, stenn at whimsy.udel.edu +14 -14
  Documentation updates from Dave Mills

--- 1.16/html/prefer.html	2008-01-26 03:12:00 -05:00
+++ 1.17/html/prefer.html	2008-08-30 23:18:22 -04:00
@@ -18,10 +18,10 @@
 		<script type="text/javascript" language="javascript" src="scripts/misc.txt"></script>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#intro">Introduction</a>
-			<li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a>
-			<li class="inline"><a href="#peer">Peer Classification</a>
-			<li class="inline"><a href="#miti">Mitigation Rules</a>
+			<li class="inline"><a href="#intro">Introduction</a></li>
+			<li class="inline"><a href="#prefer">The <tt>prefer</tt> Peer</a></li>
+			<li class="inline"><a href="#peer">Peer Classification</a></li>
+			<li class="inline"><a href="#miti">Mitigation Rules</a></li>
 		</ul>
 		<hr>
 		<h4 id="intro">Introduction</h4>
@@ -36,11 +36,11 @@
 		<h4 id="peer">Peer Classification</h4>
 		<p>In order to understand the effects of the various intricate schemes involved, it is necessary to understand some arcane details on how the algorithms decide on a synchronization source when more than one source is available. This is done on the basis of a set of explicit mitigation rules, which define special classes of remote serves and local radio clocks as a function of configuration declarations and clock driver type:</p>
 		<ol>
-			<li>The prefer peer is designated using the <tt>prefer</tt> keyword with the <tt>server</tt> or <tt>peer</tt> commands. All other things being equal, this peer will be selected for synchronization over all other survivors of the clock selection procedures.
-			<li>When a PPS signal is connected via the PPS Clock Discipline driver (type 22), this is called the <i>PPS peer</i>. This driver provides precision clock corrections only within one second, so is always operated in conjunction with another server or radio clock driver, which provides the seconds numbering. The PPS peer is active only under conditions explained below.
-			<li>When the Undisciplined Local Clock driver (type 1) is configured, this is called the <i>local clock peer</i>. This is used either as a backup reference source (stratum greater than zero), should all other synchronization sources fail, or as the primary reference source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lockclock</tt> scheme, or another synchronization protocol, such as the Digital Time Synchronization Service (DTSS).
-			<li>When a modem driver such as the Automated Computer Time Service driver (type 18) is configured, this is called the <i>modem peer</i>. This is used either as a backup reference source, should all other primary sources fail, or as the (only) primary reference source.
-			<li>Where support is available, the PPS signal may be processed directly by the kernel, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. This is called the <i>kernel discipline</i>. The PPS signal can discipline the kernel in both frequency and time. The frequency discipline is active as long as the PPS interface device and signal itself is operating correctly, as determined by the kernel algorithms. The time discipline is active only under conditions explained below.
+			<li>The prefer peer is designated using the <tt>prefer</tt> keyword with the <tt>server</tt> or <tt>peer</tt> commands. All other things being equal, this peer will be selected for synchronization over all other survivors of the clock selection procedures.</li>
+			<li>When a PPS signal is connected via the PPS Clock Discipline driver (type 22), this is called the <i>PPS peer</i>. This driver provides precision clock corrections only within one second, so is always operated in conjunction with another server or radio clock driver, which provides the seconds numbering. The PPS peer is active only under conditions explained below.</li>
+			<li>When the Undisciplined Local Clock driver (type 1) is configured, this is called the <i>local clock peer</i>. This is used either as a backup reference source (stratum greater than zero), should all other synchronization sources fail, or as the primary reference source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST <tt>lockclock</tt> scheme, or another synchronization protocol, such as the Digital Time Synchronization Service (DTSS).</li>
+			<li>When a modem driver such as the Automated Computer Time Service driver (type 18) is configured, this is called the <i>modem peer</i>. This is used either as a backup reference source, should all other primary sources fail, or as the (only) primary reference source.</li>
+			<li>Where support is available, the PPS signal may be processed directly by the kernel, as described in the <a href="kern.html">A Kernel Model for Precision Timekeeping</a> page. This is called the <i>kernel discipline</i>. The PPS signal can discipline the kernel in both frequency and time. The frequency discipline is active as long as the PPS interface device and signal itself is operating correctly, as determined by the kernel algorithms. The time discipline is active only under conditions explained below.</li>
 		</ol>
 		<p>Reference clock drivers operate in the manner described in the <a href="refclock.html">Reference Clock Drivers</a> page and its dependencies. The drivers are ordinarily operated at stratum zero, so that as the result of ordinary NTP operations, the server itself operates at stratum one, as required by the NTP specification. In some cases described below, the driver is intentionally operated at an elevated stratum, so that it will be selected only if no other survivor is present with a lower stratum. In the case of the PPS peer or kernel time discipline, these sources appear active only if the prefer peer has survived the intersection and clustering algorithms, as described below, and its clock offset relative to the current local clock is less than a specified value, currently 128 ms.</p>
 		<p>The modem clock drivers are a special case. Ordinarily, the update interval between modem calls to synchronize the system clock is many times longer than the interval between polls of either a remote server or local radio clock. In order to provide the best stability, the operation of the clock discipline algorithm changes gradually from a phase-lock mode at the shorter update intervals to a frequency-lock mode at the longer update intervals. If remote servers or local radio clocks together with a modem peer operate in the same client, the following things can happen.</p>
@@ -51,11 +51,11 @@
 		<p>The clustering algorithm repeatedly discards outlyers in order to reduce the residual jitter in the survivor population. As required by the NTP specification, these operations continue until either a specified minimum number of survivors remain or the minimum select dispersion of the population is greater than the maximum peer dispersion of any member. The mitigation rules require an additional terminating condition which stops these operations at the point where the prefer peer is about to be discarded.</p>
 		<p>The mitigation rules establish the choice of <i>system peer</i>, which determines the stratum, reference identifier and several other system variables which are visible to clients of the server. In addition, they establish which source or combination of sources control the local clock.</p>
 		<ol>
-			<li>If there is a prefer peer and it is the local-clock peer or the modem peer; or, if there is a prefer peer and the kernel time discipline is active, choose the prefer peer as the system peer and its offset as the system clock offset. If the prefer peer is the local-clock peer, an offset can be calculated by the driver to produce a frequency offset in order to correct for systematic frequency errors. In case a source other than NTP is controlling the system clock, corrections determined by NTP can be ignored by using the <tt>disable pll</tt> in the configuration file. If the prefer peer is the modem peer, it must be the primary source for the reasons noted above. If the kernel time discipline is active, the system clock offset is ignored and the corrections handled directly by the kernel.
-			<li>If the above is not the case and there is a PPS peer, then choose it as the system peer and its offset as the system clock offset.
-			<li>If the above is not the case and there is a prefer peer (not the local-clock or modem peer in this case), then choose it as the system peer and its offset as the system clock offset.
-			<li>If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to clockhopping, when switching the system peer would not materially improve the time accuracy.
-			<li>If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification.
+			<li>If there is a prefer peer and it is the local-clock peer or the modem peer; or, if there is a prefer peer and the kernel time discipline is active, choose the prefer peer as the system peer and its offset as the system clock offset. If the prefer peer is the local-clock peer, an offset can be calculated by the driver to produce a frequency offset in order to correct for systematic frequency errors. In case a source other than NTP is controlling the system clock, corrections determined by NTP can be ignored by using the <tt>disable pll</tt> in the configuration file. If the prefer peer is the modem peer, it must be the primary source for the reasons noted above. If the kernel time discipline is active, the system clock offset is ignored and the corrections handled directly by the kernel.</li>
+			<li>If the above is not the case and there is a PPS peer, then choose it as the system peer and its offset as the system clock offset.</li>
+			<li>If the above is not the case and there is a prefer peer (not the local-clock or modem peer in this case), then choose it as the system peer and its offset as the system clock offset.</li>
+			<li>If the above is not the case and the peer previously chosen as the system peer is in the surviving population, then choose it as the system peer and average its offset along with the other survivors to determine the system clock offset. This behavior is designed to avoid excess jitter due to clockhopping, when switching the system peer would not materially improve the time accuracy.</li>
+			<li>If the above is not the case, then choose the first candidate in the list of survivors ranked in order of synchronization distance and average its offset along with the other survivors to determine the system clock offset. This is the default case and the only case considered in the current NTP specification.</li>
 		</ol>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>

==== html/rate.html ====
2008-08-30 23:18:24-04:00, stenn at whimsy.udel.edu +14 -8
  Documentation updates from Dave Mills

--- 1.3/html/rate.html	2008-05-12 01:36:35 -04:00
+++ 1.4/html/rate.html	2008-08-30 23:18:24 -04:00
@@ -19,12 +19,12 @@
 		<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#intro">Introduction</a>
-			<li class="inline"><a href="#poll">Poll Rate Control</a>
-			<li class="inline"><a href="#burst">Burst Control</a>
-			<li class="inline"><a href="#mah">Average Headway Time</a>
-			<li class="inline"><a href="#mgt">Guard Time</a>
-			<li class="inline"><a href="#kiss">The Kiss-o'-Death Packet</a>
+			<li class="inline"><a href="#intro">Introduction</a></li>
+			<li class="inline"><a href="#poll">Poll Rate Control</a></li>
+			<li class="inline"><a href="#burst">Burst Control</a></li>
+			<li class="inline"><a href="#mah">Average Headway Time</a></li>
+			<li class="inline"><a href="#mgt">Guard Time</a></li>
+			<li class="inline"><a href="#kiss">The Kiss-o'-Death Packet</a></li>
 		</ul>
 		<hr>
 		<h4 id="intro">Introduction</h4>
@@ -32,7 +32,10 @@
 		<p>Some national time metrology laboratories, including NIST and USNO, use the <tt>ntpd</tt> reference implementation in their very busy public time servers. They operate multiple servers behind load-balancing devices to support aggregate rates up to several thousand packets per second. The servers need to defend themselves against all manner of broken implementations that can clog the server and and network infrastructure. On the other hand, friendly <tt>ntpd</tt> clients need to avoid configurations that can result in unfriendly rates.</p>
 		<p>There are several features in <tt>ntpd</tt> designed to defend the servers, clients and network against accidental or intentional flood attack. On the other hand these features are also used to insure <tt>ntpd</tt> is a good citizen, even if configured in unfriendly ways. The ground rules are:</p>
 		<ul>
-			<li>Send at the lowest rate consistent with the expected accuracy expectations.<li>Maintain strict minimum average headway and guard times, even if multiple burst options and/or the Autokey protocol are operating.<li>When the first packet of a burst is sent to a server, do not send further packets until the first packet has been received from the server.<li>Upon receiving a Kiss-o'-Death packet (see below), immediately reduce the sending rate.
+			<li>Send at the lowest rate consistent with the expected accuracy expectations.</li>
+			<li>Maintain strict minimum average headway and guard times, even if multiple burst options and/or the Autokey protocol are operating.</li>
+			<li>When the first packet of a burst is sent to a server, do not send further packets until the first packet has been received from the server.</li>
+			<li>Upon receiving a Kiss-o'-Death packet (see below), immediately reduce the sending rate.</li>
 		</ul>
 		<p>Rate management involves four algorithms to manage resources: (1) poll rate control, (2) burst control, (3) average headway time and (4) guard time. These are described in following sections.</p>
 		<h4 id="poll">Poll Rate Control</h4>
@@ -41,7 +44,10 @@
 		<p>The poll interval is proportional to the time constant of the feedback loop which disciplines the system clock. The optimum time constant depends on the network time jitter and the clock oscillator frequency wander. Errors due to jitter decrease as the time constant increases, while errors due to wander decrease as the time constant decreases. The two error characteristics intersect at a point called the Allan intercept, which represents the ideal time constant. With a compromise Allan intercept of 2000 s, the optimim poll interval is about 64 s, which corresponds to a poll exponent of 6.</p>
 		<p>There is normally no need to change the poll limits, as the poll interval is managed automatically as a function of prevailing jitter and wander. The most common exceptions are the following.</p>
 		<ul>
-			<li>With fast, lightly loaded LANs and modern processors, the nominal Allan intercept is about 500 s. In these cases the expected errors can be further reduced using a poll exponent of 4 (16 s). In the case of the pulse-per-second (PPS) driver, this is the recommended value. <li>With symmetric modes the most stable behavior results when both peers are configured in symmetric active mode with matching poll intervals of 6 (64 s).<li>The poll interval should not be modified for reference clocks, with the single exception the ACTS telephone modem driver. In this case the recommended minimum and maximum intervals are 12 (1.1 h) and 17 (36 h), respectively.</ul>
+			<li>With fast, lightly loaded LANs and modern processors, the nominal Allan intercept is about 500 s. In these cases the expected errors can be further reduced using a poll exponent of 4 (16 s). In the case of the pulse-per-second (PPS) driver, this is the recommended value.</li>
+			<li>With symmetric modes the most stable behavior results when both peers are configured in symmetric active mode with matching poll intervals of 6 (64 s).</li>
+			<li>The poll interval should not be modified for reference clocks, with the single exception the ACTS telephone modem driver. In this case the recommended minimum and maximum intervals are 12 (1.1 h) and 17 (36 h), respectively.</li>
+			</ul>
 		<h4 id="burst">Burst Control</h4>
 		<p>Occasionally it is necessary to send packets at intervals less than the poll interval. For instance, with the <tt>burst</tt> and <tt>iburst</tt> options of the <tt>server</tt> command, the poll algorithm sends a burst of several packets at 2-s intervals. The <tt>ntpd</tt> poll algorithm avoids sending needless packets if the server is not responding. The client begins a burst with a single packet. When the first packet is received from the server, the client continues with the remaining packets in the burst. If the first packet is not received within 64 s, it will be sent again for two additional retries before beginning backoff. The result is to minimize network load if the server is not responding.</p>
 		<p>For the <tt>iburst</tt> option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the <tt>burst</tt> option, the number of packets in the burst is determined by the difference between the poll interval and the minimum poll interval set by the <tt>minpoll</tt> option of the <a href="confopt.html#server"><tt>server</tt></a> command. For instance, with a poll exponent of 6 (64 s), only a single packet is sent for every poll, while the full number of eight packets is sent at poll intervals of 9 (512 s) or more.</p>

==== html/refclock.html ====
2008-08-30 23:18:24-04:00, stenn at whimsy.udel.edu +47 -47
  Documentation updates from Dave Mills

--- 1.33/html/refclock.html	2008-01-26 03:12:02 -05:00
+++ 1.34/html/refclock.html	2008-08-30 23:18:24 -04:00
@@ -19,9 +19,9 @@
 		<script type="text/javascript" language="javascript" src="scripts/audio.txt"></script>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#clock">Introduction</a>
-			<li class="inline"><a href="#cal">Driver Calibration</a>
-			<li class="inline"><a href="#list">Comprehensive List of Clock Drivers</a>
+			<li class="inline"><a href="#clock">Introduction</a></li>
+			<li class="inline"><a href="#cal">Driver Calibration</a></li>
+			<li class="inline"><a href="#list">Comprehensive List of Clock Drivers</a></li>
 		</ul>
 		<hr>
 		<h4 id="clock">Introduction</h4>
@@ -38,50 +38,50 @@
 		<h4 id="list">Comprehensive List of Clock Drivers</h4>
 		<p>Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, driver ID, device name and serial line speed. For those drivers without specific documentation, please contact the author listed in the <a href="copyright.html">Copyright Notice</a> page.</p>
 		<ul>
-			<li class="inline"><a href="drivers/driver1.html">Type 1</a> Undisciplined Local Clock (<tt>LOCAL</tt>)
-			<li class="inline"><a href="drivers/driver2.html">Type 2</a> Trak 8820 GPS Receiver (<tt>GPS_TRAK</tt>)
-			<li class="inline"><a href="drivers/driver3.html">Type 3</a> PSTI/Traconex 1020 WWV/WWVH Receiver (<tt>WWV_PST</tt>)
-			<li class="inline"><a href="drivers/driver4.html">Type 4</a> Spectracom WWVB/GPS Receivers (<tt>WWVB_SPEC</tt>)
-			<li class="inline"><a href="drivers/driver5.html">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers (<tt>TRUETIME</tt>)
-			<li class="inline"><a href="drivers/driver6.html">Type 6</a> IRIG Audio Decoder (<tt>IRIG_AUDIO</tt>)
-			<li class="inline"><a href="drivers/driver7.html">Type 7</a> Radio CHU Audio Demodulator/Decoder (<tt>CHU</tt>)
-			<li class="inline"><a href="drivers/driver8.html">Type 8</a> Generic Reference Driver (<tt>PARSE</tt>)
-			<li class="inline"><a href="drivers/driver9.html">Type 9</a> Magnavox MX4200 GPS Receiver (<tt>GPS_MX4200</tt>)
-			<li class="inline"><a href="drivers/driver10.html">Type 10</a> Austron 2200A/2201A GPS Receivers (<tt>GPS_AS2201</tt>)
-			<li class="inline"><a href="drivers/driver11.html">Type 11</a> Arbiter 1088A/B GPS Receiver (<tt>GPS_ARBITER</tt>)
-			<li class="inline"><a href="drivers/driver12.html">Type 12</a> KSI/Odetics TPRO/S IRIG Interface (<tt>IRIG_TPRO</tt>)
-			<li class="inline">Type 13 Leitch CSD 5300 Master Clock Controller (<tt>ATOM_LEITCH</tt>)
-			<li class="inline">Type 14 EES M201 MSF Receiver (<tt>MSF_EES</tt>)
-			<li class="inline">Type 15 reserved
-			<li class="inline"><a href="drivers/driver16.html">Type 16</a> Bancomm GPS/IRIG Receiver (<tt>GPS_BANCOMM</tt>)
-			<li class="inline">Type 17 Datum Precision Time System (<tt>GPS_DATUM</tt>)
-			<li class="inline"><a href="drivers/driver18.html">Type 18</a> NIST/USNO/PTB Modem Time Services (<tt>ACTS_MODEM</tt>)
-			<li class="inline"><a href="drivers/driver19.html">Type 19</a> Heath WWV/WWVH Receiver (<tt>WWV_HEATH</tt>)
-			<li class="inline"><a href="drivers/driver20.html">Type 20</a> Generic NMEA GPS Receiver (<tt>NMEA</tt>)
-			<li class="inline">Type 21 TrueTime GPS-VME Interface (<tt>GPS_VME</tt>)
-			<li class="inline"><a href="drivers/driver22.html">Type 22</a> PPS Clock Discipline (<tt>PPS</tt>)
-			<li class="inline">Type 23 reserved
-			<li class="inline">Type 24 reserved
-			<li class="inline">Type 25 reserved
-			<li class="inline"><a href="drivers/driver26.html">Type 26</a> Hewlett Packard 58503A GPS Receiver (<tt>GPS_HP</tt>)
-			<li class="inline"><a href="drivers/driver27.html">Type 27</a> Arcron MSF Receiver (<tt>MSF_ARCRON</tt>)
-			<li class="inline"><a href="drivers/driver28.html">Type 28</a> Shared Memory Driver (<tt>SHM</tt>)
-			<li class="inline"><a href="drivers/driver29.html">Type 29</a> Trimble Navigation Palisade GPS (<tt>GPS_PALISADE</tt>)
-			<li class="inline"><a href="drivers/driver30.html">Type 30</a> Motorola UT Oncore GPS <tt>GPS_ONCORE</tt>)
-			<li class="inline"><a href="drivers/driver31.html">Type 31</a> Rockwell Jupiter GPS (<tt>GPS_JUPITER</tt>)
-			<li class="inline"><a href="drivers/driver32.html">Type 32</a> Chrono-log K-series WWVB receiver (<tt>CHRONOLOG</tt>)
-			<li class="inline"><a href="drivers/driver33.html">Type 33</a> Dumb Clock (<tt>DUMBCLOCK</tt>)
-			<li class="inline"><a href="drivers/driver34.html">Type 34</a> Ultralink WWVB Receivers (<tt>ULINK</tt>)
-			<li class="inline"><a href="drivers/driver35.html">Type 35</a> Conrad Parallel Port Radio Clock (<tt>PCF</tt>)
-			<li class="inline"><a href="drivers/driver36.html">Type 36</a> Radio WWV/H Audio Demodulator/Decoder (<tt>WWV</tt>)
-			<li class="inline"><a href="drivers/driver37.html">Type 37</a> Forum Graphic GPS Dating station (<tt>FG</tt>)
-			<li class="inline"><a href="drivers/driver38.html">Type 38</a> hopf GPS/DCF77 6021/komp for Serial Line (<tt>HOPF_S</tt>)
-			<li class="inline"><a href="drivers/driver39.html">Type 39</a> hopf GPS/DCF77 6039 for PCI-Bus (<tt>HOPF_P</tt>)
-			<li class="inline"><a href="drivers/driver40.html">Type 40</a> JJY Receivers (<tt>JJY</tt>)
-			<li class="inline">Type 41 TrueTime 560 IRIG-B Decoder
-			<li class="inline"><a href="drivers/driver42.html">Type 42</a> Zyfer GPStarplus Receiver
-			<li class="inline"><a href="drivers/driver43.html">Type 43</a> RIPE NCC interface for Trimble Palisade
-			<li class="inline"><a href="drivers/driver44.html">Type 44</a> NeoClock4X - DCF77 / TDF serial line
+			<li class="inline"><a href="drivers/driver1.html">Type 1</a> Undisciplined Local Clock (<tt>LOCAL</tt>)</li>
+			<li class="inline"><a href="drivers/driver2.html">Type 2</a> Trak 8820 GPS Receiver (<tt>GPS_TRAK</tt>)</li>
+			<li class="inline"><a href="drivers/driver3.html">Type 3</a> PSTI/Traconex 1020 WWV/WWVH Receiver (<tt>WWV_PST</tt>)</li>
+			<li class="inline"><a href="drivers/driver4.html">Type 4</a> Spectracom WWVB/GPS Receivers (<tt>WWVB_SPEC</tt>)</li>
+			<li class="inline"><a href="drivers/driver5.html">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers (<tt>TRUETIME</tt>)</li>
+			<li class="inline"><a href="drivers/driver6.html">Type 6</a> IRIG Audio Decoder (<tt>IRIG_AUDIO</tt>)</li>
+			<li class="inline"><a href="drivers/driver7.html">Type 7</a> Radio CHU Audio Demodulator/Decoder (<tt>CHU</tt>)</li>
+			<li class="inline"><a href="drivers/driver8.html">Type 8</a> Generic Reference Driver (<tt>PARSE</tt>)</li>
+			<li class="inline"><a href="drivers/driver9.html">Type 9</a> Magnavox MX4200 GPS Receiver (<tt>GPS_MX4200</tt>)</li>
+			<li class="inline"><a href="drivers/driver10.html">Type 10</a> Austron 2200A/2201A GPS Receivers (<tt>GPS_AS2201</tt>)</li>
+			<li class="inline"><a href="drivers/driver11.html">Type 11</a> Arbiter 1088A/B GPS Receiver (<tt>GPS_ARBITER</tt>)</li>
+			<li class="inline"><a href="drivers/driver12.html">Type 12</a> KSI/Odetics TPRO/S IRIG Interface (<tt>IRIG_TPRO</tt>)</li>
+			<li class="inline">Type 13 Leitch CSD 5300 Master Clock Controller (<tt>ATOM_LEITCH</tt>)</li>
+			<li class="inline">Type 14 EES M201 MSF Receiver (<tt>MSF_EES</tt>)</li>
+			<li class="inline">Type 15 reserved</li>
+			<li class="inline"><a href="drivers/driver16.html">Type 16</a> Bancomm GPS/IRIG Receiver (<tt>GPS_BANCOMM</tt>)</li>
+			<li class="inline">Type 17 Datum Precision Time System (<tt>GPS_DATUM</tt>)</li>
+			<li class="inline"><a href="drivers/driver18.html">Type 18</a> NIST/USNO/PTB Modem Time Services (<tt>ACTS_MODEM</tt>)</li>
+			<li class="inline"><a href="drivers/driver19.html">Type 19</a> Heath WWV/WWVH Receiver (<tt>WWV_HEATH</tt>)</li>
+			<li class="inline"><a href="drivers/driver20.html">Type 20</a> Generic NMEA GPS Receiver (<tt>NMEA</tt>)</li>
+			<li class="inline">Type 21 TrueTime GPS-VME Interface (<tt>GPS_VME</tt>)</li>
+			<li class="inline"><a href="drivers/driver22.html">Type 22</a> PPS Clock Discipline (<tt>PPS</tt>)</li>
+			<li class="inline">Type 23 reserved</li>
+			<li class="inline">Type 24 reserved</li>
+			<li class="inline">Type 25 reserved</li>
+			<li class="inline"><a href="drivers/driver26.html">Type 26</a> Hewlett Packard 58503A GPS Receiver (<tt>GPS_HP</tt>)</li>
+			<li class="inline"><a href="drivers/driver27.html">Type 27</a> Arcron MSF Receiver (<tt>MSF_ARCRON</tt>)</li>
+			<li class="inline"><a href="drivers/driver28.html">Type 28</a> Shared Memory Driver (<tt>SHM</tt>)</li>
+			<li class="inline"><a href="drivers/driver29.html">Type 29</a> Trimble Navigation Palisade GPS (<tt>GPS_PALISADE</tt>)</li>
+			<li class="inline"><a href="drivers/driver30.html">Type 30</a> Motorola UT Oncore GPS <tt>GPS_ONCORE</tt>)</li>
+			<li class="inline"><a href="drivers/driver31.html">Type 31</a> Rockwell Jupiter GPS (<tt>GPS_JUPITER</tt>)</li>
+			<li class="inline"><a href="drivers/driver32.html">Type 32</a> Chrono-log K-series WWVB receiver (<tt>CHRONOLOG</tt>)</li>
+			<li class="inline"><a href="drivers/driver33.html">Type 33</a> Dumb Clock (<tt>DUMBCLOCK</tt>)</li>
+			<li class="inline"><a href="drivers/driver34.html">Type 34</a> Ultralink WWVB Receivers (<tt>ULINK</tt>)</li>
+			<li class="inline"><a href="drivers/driver35.html">Type 35</a> Conrad Parallel Port Radio Clock (<tt>PCF</tt>)</li>
+			<li class="inline"><a href="drivers/driver36.html">Type 36</a> Radio WWV/H Audio Demodulator/Decoder (<tt>WWV</tt>)</li>
+			<li class="inline"><a href="drivers/driver37.html">Type 37</a> Forum Graphic GPS Dating station (<tt>FG</tt>)</li>
+			<li class="inline"><a href="drivers/driver38.html">Type 38</a> hopf GPS/DCF77 6021/komp for Serial Line (<tt>HOPF_S</tt>)</li>
+			<li class="inline"><a href="drivers/driver39.html">Type 39</a> hopf GPS/DCF77 6039 for PCI-Bus (<tt>HOPF_P</tt>)</li>
+			<li class="inline"><a href="drivers/driver40.html">Type 40</a> JJY Receivers (<tt>JJY</tt>)</li>
+			<li class="inline">Type 41 TrueTime 560 IRIG-B Decoder</li>
+			<li class="inline"><a href="drivers/driver42.html">Type 42</a> Zyfer GPStarplus Receiver</li>
+			<li class="inline"><a href="drivers/driver43.html">Type 43</a> RIPE NCC interface for Trimble Palisade</li>
+			<li class="inline"><a href="drivers/driver44.html">Type 44</a> NeoClock4X - DCF77 / TDF serial line</li>
 		</ul>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>

==== html/release.html ====
2008-08-30 23:18:25-04:00, stenn at whimsy.udel.edu +27 -24
  Documentation updates from Dave Mills

--- 1.35/html/release.html	2008-05-12 01:36:36 -04:00
+++ 1.36/html/release.html	2008-08-30 23:18:25 -04:00
@@ -23,34 +23,37 @@
 		<p>This note summarizes the differences between this software release of NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called xntp3-5.x.x.</p>
 		<h4>New Features</h4>
 		<ol>
-			<li>Support for the IPv6 addressing family is included in this distribution. If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is generated in addition to the default support for the IPv4 address family.<li>Most calculations are now done using 64-bit floating double format, rather than 64-bit fixed point format. The motivation for this is to reduce size, improve speed and avoid messy bounds checking.<li>The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow increased in poll intervals to 36 hours with only moderate sacrifice in accuracy. 
-			<li>A new feature called &quot;huffpuff&quot; maximizes accuracy in cases of highly asymmetric network delays typical of ISDN and telephone modems.
-			<li>The clock selection algorithm has been redesigned to reduce &quot;clockhopping&quot; when the choice of servers changes frequently as the result of comparatively insignificant quality changes.
-			<li>This release includes support for the <a href="ftp://ftp.udel.edu/usa/ftp/pub/ntp/software/">nanokernel</a> precision time kernel modifications, which are now in stock FreeBSD and optional in Linux kernels. With this support the system clock can be disciplined to the order of one nanosecon. The older microtime kernel modifications in Digital/Compaq/HP Tru64, Digital Ultrix and Sun Microsystems SunOS and Solaris, continue to be supported. In either case the support eliminates sawtooth error, which can be in the hundreds of microseconds.
-			<li>This release includes support for Autokey public-key cryptography, which is the preferred scheme for authenticating servers to clients. Additional information about Autokey cryptography is on the <a href="authopt.html">Authentication Options</a> page and links from there. See also the new <tt>cryptostats</tt> monitoring statistics file in the <a href="monopt.html">Monitoring Options</a> page.
-			<li>The OpenSSL cryptographic library has replaced the library formerly available from RSA Laboratories. All cryptographic routines except a version of the MD5 message digest routine have been removed from the base distribution.<li>As the result of the above, the <tt>authstuff</tt> directory, intended as a development and testing aid for porting cryptographic routines to exotic architectures, has been removed. Testing and conformance validation tools are in the OpenSSL software distrbution.
-			<li>This release includes support for a discrete event simulator (DES), which allows the NTP&nbsp;algorithms to be tested in an embedded environment with systematic and pseudorandom network delay and oscillator wander distributions. This has been used to verify correct operation under conditions of extreme error and misconfiguration. See the <a href="ntpdsim.html"><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a> page.
-			<li>NTPv4 includes three new server discovery schemes, which in most applications can avoid per-host configuration altogether. Two of these are based on IP multicast technology, while the remaining one is based on crafted DNS lookups. See the <a href="manyopt.html">Automatic NTP Configuration Schemes</a> page for further information.
-			<li>This release includes comprehensive packet rate management tools to help reduce the level of spurious network traffic and protect the busiest servers from overload. See the <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a> page for further information.
-			<li>This release includes support for the orphan mode, which replaces the local clock driver for most configurations. Orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It can be used in isolated networks or in Internet subnets where the servers or Internet connection have failed. See the <a href="manyopt.html">Automatic NTP Configuration Options</a> page for further information.
-			
-			<li>There are two new burst mode features available where special conditions apply. One of these is enabled by the <tt>iburst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where it is important to set the clock quickly when an association is first mobilized. The other is enabled by the <tt>burst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where the network attachment requires an initial calling or training procedure. See the <a href="assoc.html">Association Management</a> page for further information.
-			
-			<li>The reference clock driver interface is smaller, more rational and more accurate. Support for pulse-per-second (PPS) signals has been extended to all drivers as an intrinsic function. Most of the drivers in NTPv3 have been converted to the NTPv4 interface and continue to operate as before. New drivers have been added for several GPS receivers now on the market for a total of 44 drivers. Audio drivers for the Canadian standard time and frequency station CHU, the US standard time and frequency stations WWV/H and for IRIG signals have been updated and capabilities added to allow direct connection of these signals to an audio port. See the <a href="audio.html">Reference Clock Audio Drivers</a> page for further information.
-			
-			<li>In all except a very few cases, all timing intervals are randomized, so that the tendency for NTPv3 to self-synchronize and bunch messages, especially with a large number of configured associations, is minimized.
-			<li>In NTPv3 a large number of weeds and useless code had grown over the years since the original NTP code was implemented 25 years ago. Using a powerful weedwacker, much of the shrubbery has been removed, with effect a substantial reduction in size of almost 40 percent.
-			<li>The entire distribution has been converted to gnu <tt>automake</tt>, which should greatly ease the task of porting to new and different programming environments, as well as reduce the incidence of bugs due to improper handling of idiosyncratic kernel functions. Version control is provided by Bitkeeper using an online repository at www.ntp.org. Trouble ticket reporting is provided using Bugzilla.
-			<li>Several new options have been added for the <tt>ntpd</tt> command line. For the inveterate knob twiddlers several of the more important performance variables can be changed to fit actual or perceived special conditions. In particular, the <tt>tos</tt> and <tt>tos</tt> commands can be used to adjust thresholds, throw switches and change limits.
-			<li>The <tt>ntpd</tt> daemon can be operated in a one-time mode similar to <tt>ntpdate</tt>, which program is headed for retirement. See the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page for the new features.
+			<li>Support for the IPv6 addressing family is included in this distribution. If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is generated in addition to the default support for the IPv4 address family.</li>
+			<li>Most calculations are now done using 64-bit floating double format, rather than 64-bit fixed point format. The motivation for this is to reduce size, improve speed and avoid messy bounds checking.</li>
+			<li>The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow increased in poll intervals to 36 hours with only moderate sacrifice in accuracy.</li>
+			<li>A new feature called &quot;huffpuff&quot; maximizes accuracy in cases of highly asymmetric network delays typical of ISDN and telephone modems.</li>
+			<li>The clock selection algorithm has been redesigned to reduce &quot;clockhopping&quot; when the choice of servers changes frequently as the result of comparatively insignificant quality changes.</li>
+			<li>This release includes support for the <a href="ftp://ftp.udel.edu/usa/ftp/pub/ntp/software/">nanokernel</a> precision time kernel modifications, which are now in stock FreeBSD and optional in Linux kernels. With this support the system clock can be disciplined to the order of one nanosecon. The older microtime kernel modifications in Digital/Compaq/HP Tru64, Digital Ultrix and Sun Microsystems SunOS and Solaris, continue to be supported. In either case the support eliminates sawtooth error, which can be in the hundreds of microseconds.</li>
+			<li>This release includes support for Autokey public-key cryptography, which is the preferred scheme for authenticating servers to clients. Additional information about Autokey cryptography is on the <a href="authopt.html">Authentication Options</a> page and links from there. See also the new <tt>cryptostats</tt> monitoring statistics file in the <a href="monopt.html">Monitoring Options</a> page.</li>
+			<li>The OpenSSL cryptographic library has replaced the library formerly available from RSA Laboratories. All cryptographic routines except a version of the MD5 message digest routine have been removed from the base distribution.</li>
+			<li>As the result of the above, the <tt>authstuff</tt> directory, intended as a development and testing aid for porting cryptographic routines to exotic architectures, has been removed. Testing and conformance validation tools are in the OpenSSL software distrbution.</li>
+			<li>This release includes support for a discrete event simulator (DES), which allows the NTP&nbsp;algorithms to be tested in an embedded environment with systematic and pseudorandom network delay and oscillator wander distributions. This has been used to verify correct operation under conditions of extreme error and misconfiguration. See the <a href="ntpdsim.html"><tt>ntpdsim</tt> - Network Time Protocol (NTP) simulator</a> page.</li>
+			<li>NTPv4 includes three new server discovery schemes, which in most applications can avoid per-host configuration altogether. Two of these are based on IP multicast technology, while the remaining one is based on crafted DNS lookups. See the <a href="manyopt.html">Automatic NTP Configuration Schemes</a> page for further information.</li>
+			<li>This release includes comprehensive packet rate management tools to help reduce the level of spurious network traffic and protect the busiest servers from overload. See the <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a> page for further information.</li>
+			<li>This release includes support for the orphan mode, which replaces the local clock driver for most configurations. Orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It can be used in isolated networks or in Internet subnets where the servers or Internet connection have failed. See the <a href="manyopt.html">Automatic NTP Configuration Options</a> page for further information.</li>
+			<li>There are two new burst mode features available where special conditions apply. One of these is enabled by the <tt>iburst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where it is important to set the clock quickly when an association is first mobilized. The other is enabled by the <tt>burst</tt> keyword in the <tt>server</tt> configuration command. It is intended for cases where the network attachment requires an initial calling or training procedure. See the <a href="assoc.html">Association Management</a> page for further information.</li>
+			<li>The reference clock driver interface is smaller, more rational and more accurate.</li>
+			<li>Support for pulse-per-second (PPS) signals has been extended to all drivers as an intrinsic function. Most of the drivers in NTPv3 have been converted to the NTPv4 interface and continue to operate as before. New drivers have been added for several GPS receivers now on the market for a total of 44 drivers. Audio drivers for the Canadian standard time and frequency station CHU, the US standard time and frequency stations WWV/H and for IRIG signals have been updated and capabilities added to allow direct connection of these signals to an audio port. See the <a href="audio.html">Reference Clock Audio Drivers</a> page for further information.</li>
+			<li>In all except a very few cases, all timing intervals are randomized, so that the tendency for NTPv3 to self-synchronize and bunch messages, especially with a large number of configured associations, is minimized.</li>
+			<li>In NTPv3 a large number of weeds and useless code had grown over the years since the original NTP code was implemented 25 years ago. Using a powerful weedwacker, much of the shrubbery has been removed, with effect a substantial reduction in size of almost 40 percent.</li>
+			<li>The entire distribution has been converted to gnu <tt>automake</tt>, which should greatly ease the task of porting to new and different programming environments, as well as reduce the incidence of bugs due to improper handling of idiosyncratic kernel functions. Version control is provided by Bitkeeper using an online repository at www.ntp.org. Trouble ticket reporting is provided using Bugzilla.</li>
+			<li>Several new options have been added for the <tt>ntpd</tt> command line. For the inveterate knob twiddlers several of the more important performance variables can be changed to fit actual or perceived special conditions. In particular, the <tt>tos</tt> and <tt>tos</tt> commands can be used to adjust thresholds, throw switches and change limits.</li>
+			<li>The <tt>ntpd</tt> daemon can be operated in a one-time mode similar to <tt>ntpdate</tt>, which program is headed for retirement. See the <a href="ntpd.html"><tt>ntpd</tt> - Network Time Protocol (NTP) daemon</a> page for the new features.</li>
 		</ol>
 		<h4>Nasty Surprises</h4>
 		<p>There are a few things different about this release that have changed since the latest NTP Version 3 release. Following are a few things to worry about:</p>
 		<ol>
-			<li>Some configuration commands have been removed, others added and some changed in minor ways. See the Commands and Options collection on the <a href="sitemap.html">Site Map</a> page.
-			<li>When both IPv4 and IPv6 address families are in use, the host's resolver library may not choose the intended address family if a server has an IPv4 and IPv6 address associated with the same DNS name. The solution is to use the IPv4 or IPv6 address directly in such cases or use another DNS name that resolves to the intended address family. Older versions of <tt>ntpdc</tt> will show only the IPv4 associations with the <tt>peers</tt> and some other commands. Older versions of <tt>ntpq</tt> will show 0.0.0.0 for IPv6 associations with the <tt>peers</tt> and some other commands.<li>There is a minor change to the reference ID field of the NTP packet header when operating with IPv6 associations. In IPv4 associations this field contains the 32-bit IPv4 address of the server, in order to detect and avoid loops. In IPv6 associations this field contains the first 32-bits of a MD5 hash formed from the IPv6 address. All programs in the distribution have been modified to work with 
 both address families.
-			<li>The <tt>tty_clk</tt> and <tt>ppsclock</tt> pulse-per-second (PPS) line discipline/streams modules are no longer supported. The PPS function is now handled by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver, which uses the new PPSAPI application program interface adopted by the IETF. Note that the <tt>pps</tt> configuration file command has been obsoleted by the driver. See the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.
-			<li>Support for the NTPv1 symmetric mode has been discontinued, since it hasn't worked for years. Support continues for the NTPv1 client mode, which is used by some SNTP clients.</ol>
+			<li>Some configuration commands have been removed, others added and some changed in minor ways. See the Commands and Options collection on the <a href="sitemap.html">Site Map</a> page.</li>
+			<li>When both IPv4 and IPv6 address families are in use, the host's resolver library may not choose the intended address family if a server has an IPv4 and IPv6 address associated with the same DNS name. The solution is to use the IPv4 or IPv6 address directly in such cases or use another DNS name that resolves to the intended address family. Older versions of <tt>ntpdc</tt> will show only the IPv4 associations with the <tt>peers</tt> and some other commands. Older versions of <tt>ntpq</tt> will show 0.0.0.0 for IPv6 associations with the <tt>peers</tt> and some other commands.</li>
+			<li>There is a minor change to the reference ID field of the NTP packet header when operating with IPv6 associations. In IPv4 associations this field contains the 32-bit IPv4 address of the server, in order to detect and avoid loops. In IPv6 associations this field contains the first 32-bits of a MD5 hash formed from the IPv6 address. All programs in the distribution have been modified to work with both address families.</li>
+			<li>The <tt>tty_clk</tt> and <tt>ppsclock</tt> pulse-per-second (PPS) line discipline/streams modules are no longer supported. The PPS function is now handled by the <a href="drivers/driver22.html">PPS Clock Discipline</a> driver, which uses the new PPSAPI application program interface adopted by the IETF. Note that the <tt>pps</tt> configuration file command has been obsoleted by the driver. See the <a href="pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.</li>
+			<li>Support for the NTPv1 symmetric mode has been discontinued, since it hasn't worked for years. Support continues for the NTPv1 client mode, which is used by some SNTP clients.</li>
+			</ol>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>

==== html/xleave.html ====
2008-08-30 23:18:27-04:00, stenn at whimsy.udel.edu +3 -2
  Documentation updates from Dave Mills

--- 1.2/html/xleave.html	2008-08-17 06:57:12 -04:00
+++ 1.3/html/xleave.html	2008-08-30 23:18:27 -04:00
@@ -30,8 +30,9 @@
 			Interleaved On-Wire Protocol</a> and the briefing <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">Interleaved
 			Synchronization Protocols for LANs and Space Data Links</a>.</p>
 		<hr>
-		<center>
-			<img src="pic/pogo1a.gif" alt="gif"></center>
+		<div align="center">
+			<img src="pic/pogo1a.gif" alt="gif">
+			</div>
 		<br>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>


More information about the bk-ntp-dev-send mailing list