Load newtrunk into ntp/trunk.

git-svn-id: svn://svn.debian.org/pkg-ntp/ntp/trunk@4 0070b5ef-2f16-0410-befa-9a02bd1d6ddb

5 files changed, 17 insertions, 14 deletions

diff --git a/html/clockopt.html b/html/clockopt.html
index af79b04..6156464 100644
--- a/html/clockopt.html
+++ b/html/clockopt.html
@@ -40,7 +40,7 @@
                 <dd>Specifies a mode number which is interpreted in a device-specific fashion. For instance, it selects a dialing protocol in the ACTS driver and a device subtype in the <tt>parse</tt> drivers.
                 <dt><tt>minpoll <i>int</i></tt>
                 <dt><tt>maxpoll <i>int</i></tt>
-                <dd>These options specify the minimum and maximum polling interval for reference clock messages, in seconds to the power of two. For most directly connected reference clocks, both <tt>minpoll</tt> and <tt>maxpoll</tt> default to 6 (64 s). For modem reference clocks, <tt>minpoll</tt> defaults to 10 (17.1 m) and <tt>maxpoll</tt> defaults to 14 (4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
+                <dd>These options specify the minimum and maximum polling interval for reference clock messages in seconds, interpreted as dual lgarithms (2 ^ x). For most directly connected reference clocks, both <tt>minpoll</tt> and <tt>maxpoll</tt> default to 6 (2^16 = 64 s). For modem reference clocks, <tt>minpoll</tt> defaults to 10 (2^10 = 1024 s = 17.1 m) and <tt>maxpoll</tt> defaults to 14 (2^14 = 16384 s = 4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
             </dl>
             <dt><tt>fudge 127.127.<i>t.u</i> [time1 <i>sec</i>] [time2 <i>sec</i>] [stratum <i>int</i>] [refid <i>string</i>] [mode <i>int</i>] [flag1 0|1] [flag2 0|1] [flag3 0|1] [flag4 0|1]</tt>
             <dd>This command can be used to configure reference clocks in special ways. It must immediately follow the <tt>server</tt> command which configures the driver. Note that the same capability is possible at run time using the <tt><a href="ntpdc.html">ntpdc</a></tt> program. The options are interpreted as follows:
@@ -64,4 +64,4 @@
         <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
     </body>
 
-</html>
\ No newline at end of file
+</html>
diff --git a/html/notes.html b/html/notes.html
index 24a2cf7..32947bd 100644
--- a/html/notes.html
+++ b/html/notes.html
@@ -24,7 +24,7 @@
         <p>The code is biased towards the needs of a busy time server with numerous, often hundreds, of clients and other servers. Tables are hashed to allow efficient handling of many associations, though at the expense of additional overhead when the number of associations is small. Many fancy features have been included to permit efficient management and monitoring of a busy primary server, features which are probably excess baggage for a high stratum client. In such cases, a stripped-down version of the protocol, the Simple Network Time Protocol (SNTP) can be used. SNTP and NTP servers and clients can interwork in most situations, as described in: Mills, D.L. Simple Network Time Protocol (SNTP). Network Working Group Report RFC-2030, University of Delaware, October 1996, 14 pp. <a href="http://www.eecis.udel.edu/%7emills/database/rfc2030.txt">(ASCII)</a>.</p>
         <p>The code was written with near demonic attention to details which can affect precision and as a consequence should be able to make good use of high performance, special purpose hardware such as precision oscillators and radio clocks. The present code supports a number of radio clocks, including those for the WWV, CHU, WWVB, MSF, DCF77, GOES and GPS radio and satellite time services and USNO, ACTS and PTB modem time services. It also supports the IRIG-B and IRIG-E signal format connected via an audio codec. The server methodically avoids the use of Unix-specific library routines where possible by implementing local versions, in order to aid in porting the code to perverse Unix and non-Unix platforms.</p>
         <p>While this implementation conforms in most respects to the NTP Version 3 specification RFC-1305, a number of improvements have been made which are described in the conformance statement in the <a href="http://www.eecis.udel.edu/%7emills/biblio.html">NTP Protocol Conformance Statement</a> page. It has been specifically tuned to achieve the highest accuracy possible on whatever hardware and operating-system platform is available. In general, its precision and stability are limited only by the characteristics of the onboard clock source used by the hardware and operating system, usually an uncompensated crystal oscillator. On modern RISC-based processors connected directly to radio clocks via serial-asynchronous interfaces, the accuracy is usually limited by the radio clock and interface to the order of a millisecond or less. The code includes special features to support a pulse-per-second (PPS) signal and/or an IRIG-B signal generated by some radio clocks. When used in conjunction with a suitable hardware level converter, the accuracy can be improved to a few tens of microseconds. Further improvement is possible using an outboard, stabilized frequency source, in which the accuracy and stability are limited only by the characteristics of that source.</p>
-        <p>The NTP Version 4 distribution includes, in addition to the daemon itself (<tt><a href="ntpd.html">ntpd</a></tt>), several utility programs, including two remote-monitoring programs (<a href="ntpq.html"><tt>ntpq</tt></a>, <tt><a href="ntpdc.html">ntpdc</a></tt>), a remote clock-setting program similar to the Unix rdate program (<tt>ntpdate</tt>), a traceback utility u seful to discover suitable synchronization sources (<tt>ntptrace</tt>), and various programs used to configure the local platform and calibrate the intrinsic errors. NTP has been ported to a large number of platforms, including most RISC and CISC workstations and mainframes manufactured today. Example configuration files for many models of these machines are included in the distribution. While in most cases the standard version of the implementation runs with no hardware or operating system modifications, not all features of the distribution are available on all platforms. For instance, a special feature allowing Sun workstations to achieve accuracies in the order of 100 microseconds requires some minor changes and additions to the kernel and input/output support.</p>
+        <p>The NTP Version 4 distribution includes, in addition to the daemon itself (<tt><a href="ntpd.html">ntpd</a></tt>), several utility programs, including two remote-monitoring programs (<a href="ntpq.html"><tt>ntpq</tt></a>, <tt><a href="ntpdc.html">ntpdc</a></tt>), a remote clock-setting program similar to the Unix rdate program (<tt>ntpdate</tt>), a traceback utility useful to discover suitable synchronization sources (<tt>ntptrace</tt>), and various programs used to configure the local platform and calibrate the intrinsic errors. NTP has been ported to a large number of platforms, including most RISC and CISC workstations and mainframes manufactured today. Example configuration files for many models of these machines are included in the distribution. While in most cases the standard version of the implementation runs with no hardware or operating system modifications, not all features of the distribution are available on all platforms. For instance, a special feature allowing Sun workstations to achieve accuracies in the order of 100 microseconds requires some minor changes and additions to the kernel and input/output support.</p>
         <p>There are, however, several drawbacks to all of this. <tt>ntpd</tt> is quite fat. This is rotten if your intended platform for the daemon is memory limited. <tt>ntpd</tt> uses <tt>SIGIO</tt> for all input, a facility which appears to not enjoy universal support and whose use seems to exercise the parts of your vendors' kernels which are most likely to have been done poorly. The code is unforgiving in the face of kernel problems which affect performance, and generally requires that you repair the problems in order to achieve acceptable performance. The code has a distinctly experimental flavour and contains features which could charitably be termed failed experiments, but which have not been completely hacked out. Much was learned from the addition of support for a variety of radio clocks, with the result that some radio clock drivers could use some rewriting.</p>
         <h4>How NTP Works</h4>
         <p>The approach used by NTP to achieve reliable time synchronization from a set of possibly unreliable remote time servers is somewhat different than other protocols. In particular, NTP does not attempt to synchronize clocks to each other. Rather, each server attempts to synchronize to Universal Coordinated Time (UTC) using the best available source and available transmission paths to that source. This is a fine point which is worth understanding. A group of NTP-synchronized clocks may be close to each other in time, but this is not a consequence of the clocks in the group having synchronized to each other, but rather because each clock has synchronized closely to UTC via the best source it has access to. As such, trying to synchronize a set of clocks to a set of servers whose time is not in mutual agreement may not result in any sort of useful synchronization of the clocks, even if you don't care about UTC. However, in networks isolated from UTC sources, provisions can made to nominate one of them as a phantom UTC source.</p>
@@ -39,7 +39,7 @@
         At startup time the <tt>ntpd</tt> daemon running on a host reads the initial configuration information from a file, usually <tt>/etc/ntp.conf</tt>, unless a different name has been specified at compile time. Putting something in this file which will enable the host to obtain time from somewhere else is usually the first big hurdle after installation of the software itself, which is described in the <a href="build/build.html">Building and Installing the Distribution</a> page. At its simplest, what you need to do in the configuration file is declare the servers that the daemon should poll for time synchronization. In principle, no such list is needed if some other time server operating in broadcast/multicast mode is available, which requires the client to operate in a broadcastclient mode.
         <p>In the case of a workstation operating in an enterprise network for a public or private organization, there is often an administrative department that coordinates network services, including NTP. Where available, the addresses of appropriate servers can be provided by that department. However, if this infrastructure is not available, it is necessary to explore some portion of the existing NTP subnet now running in the Internet. There are at present many thousands of time servers running NTP in the Internet, a significant number of which are willing to provide a public time- synchronization service. Some of these are listed in the list of public time servers, which can be accessed via the <a href="http://www.eecis.udel.edu/%7entp">NTP web page</a>. These data are updated on a regular basis using information provided voluntarily by various site administrators. There are other ways to explore the nearby subnet using the <tt><a href="ntptrace.html">ntptrace</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> programs.</p>
         <p>It is vital to carefully consider the issues of robustness and reliability when selecting the sources of synchronization. Normally, not less than three sources should be available, preferably selected to avoid common points of failure. It is usually better to choose sources which are likely to be &quot;close&quot; to you in terms of network topology, though you shouldn't worry overly about this if you are unable to determine who is close and who isn't. Normally, it is much more serious when a server becomes faulty and delivers incorrect time than when it simply stops operating, since an NTP-synchronized host normally can coast for hours or even days without its clock accumulating serious error approaching a second, for instance. Selecting at least three sources from different operating administrations, where possible, is the minimum recommended, although a lesser number could provide acceptable service with a degraded degree of robustness.</p>
-        <p>Normally, it is not considered good practice for a single workstation to request synchronization from a primary (stratum-1) time server. At present, these servers provide synchronization for hundreds of clients in many cases and could, along with the network access paths, become seriously overloaded if large numbers of workstation clients requested synchronization directly. Therefore, workstations located in sparsely populated administrative domains with no local synchronization infrastructure should request synchronization from nearby stratum-2 servers instead. In most cas es the keepers of those servers in the lists of public servers provide unrestricted access without prior permission; however, in all cases it is considered polite to notify the administrator listed in the file upon commencement of regular service. In all cases the access mode and notification requirements listed in the file must be respected. Under no conditions should servers not in these lists be used without prior permission, as to do so can create severe problems in the local infrastructure, especially in cases of dial-up access to the Internet.</p>
+        <p>Normally, it is not considered good practice for a single workstation to request synchronization from a primary (stratum-1) time server. At present, these servers provide synchronization for hundreds of clients in many cases and could, along with the network access paths, become seriously overloaded if large numbers of workstation clients requested synchronization directly. Therefore, workstations located in sparsely populated administrative domains with no local synchronization infrastructure should request synchronization from nearby stratum-2 servers instead. In most cases the keepers of those servers in the lists of public servers provide unrestricted access without prior permission; however, in all cases it is considered polite to notify the administrator listed in the file upon commencement of regular service. In all cases the access mode and notification requirements listed in the file must be respected. Under no conditions should servers not in these lists be used without prior permission, as to do so can create severe problems in the local infrastructure, especially in cases of dial-up access to the Internet.</p>
         <p>In the case of a gateway or file server providing service to a significant number of workstations or file servers in an enterprise network it is even more important to provide multiple, redundant sources of synchronization and multiple, diversity-routed, network access paths. The preferred configuration is at least three administratively coordinated time servers providing service throughout the administrative domain including campus networks and subnetworks. Each of these should obtain service from at least two different outside sources of synchronization, preferably via different gateways and access paths. These sources should all operate at the same stratum level, which is one less than the stratum level to be used by the local time servers themselves. In addition, each of these time servers should peer with all of the other time servers in the local administrative domain at the stratum level used by the local time servers, as well as at least one (different) outside source at this level. This configuration results in the use of six outside sources at a lower stratum level (toward the primary source of synchronization, usually a radio clock), plus three outside sources at the same stratum level, for a total of nine outside sources of synchronization. While this may seem excessive, the actual load on network resources is minimal, since the interval between polling messages exchanged between peers usually ratchets back to no more than one message every 17 minutes.</p>
         <p>The stratum level to be used by the local time servers is an engineering choice. As a matter of policy, and in order to reduce the load on the primary servers, it is desirable to use the highest stratum consistent with reliable, accurate time synchronization throughout the administrative domain. In the case of enterprise networks serving hundreds or thousands of client file servers and workstations, conventional practice is to obtain service from stratum-1 primary servers listed for public access. When choosing sources away from the primary sources, the particular synchronization path in use at any time can be verified using the <tt>ntptrace</tt> program included in this distribution. It is important to avoid loops and possible common points of failure when selecting these sources. Note that, while NTP detects and rejects loops involving neighboring servers, it does not detect loops involving intervening servers. In the unlikely case that all primary sources of synchronization are lost throughout the subnet, the remaining servers on that subnet can form temporary loops and, if the loss continues for an interval of many hours, the servers will drop off the subnet and free-run with respect to their internal (disciplined) timing sources. After some period with no outside timing source (currently one day), a host will declare itself unsynchronized and provide this information to local application programs.</p>
         <p>In many cases the purchase of one or more radio clocks is justified, in which cases good engineering practice is to use the configurations described above anyway and connect the radio clock to one of the local servers. This server is then encouraged to participate in a special primary-server subnetwork in which each radio-equipped server peers with several other similarly equipped servers. In this way the radio-equipped server may provide synchronization, as well as receive synchronization, should the local or remote radio clock(s) fail or become faulty. <tt>ntpd</tt> treats attached radio clock(s) in the same way as other servers and applies the same criteria and algorithms to the time indications, so can detect when the radio fails or becomes faulty and switch to alternate sources of synchronization. It is strongly advised, and in practice for most primary servers today, to employ the authentication or access-control features of the NTP specification in order to protect against hostile intruders and possible destabilization of the time service. Using this or similar strategies, the remaining hosts in the same administrative domain can be synchronized to the three (or more) selected time servers. Assuming these servers are synchronized directly to stratum-1 sources and operate normally as stratum-2, the next level away from the primary source of synchronization, for instance various campus file servers, will operate at stratum 3 and dependent workstations at stratum 4. Engineered correctly, such a subnet will survive all but the most exotic failures or even hostile penetrations of the various, distributed timekeeping resources.</p>
@@ -72,11 +72,11 @@
         <p>Note the inclusion of a <tt>driftfile</tt> declaration. One of the things the NTP daemon does when it is first started is to compute the error in the intrinsic frequency of the clock on the computer it is running on. It usually takes about a day or so after the daemon is started to compute a good estimate of this (and it needs a good estimate to synchronize closely to its server). Once the initial value is computed, it will change only by relatively small amounts during the course of continued operation. The <tt>driftfile</tt> declaration indicates to the daemon the name of a file where it may store the current value of the frequency error so that, if the daemon is stopped and restarted, it can reinitialize itself to the previous estimate and avoid the day's worth of time it will take to recompute the frequency estimate. Since this is a desirable feature, a <tt>driftfile</tt> declaration should always be included in the configuration file.</p>
         <p>An implication in the above is that, should <tt>ntpd</tt> be stopped for some reason, the local platform time will diverge from UTC by an amount that depends on the intrinsic error of the clock oscillator and the time since last synchronized. In view of the length of time necessary to refine the frequency estimate, every effort should be made to operate the daemon on a continuous basis and minimize the intervals when for some reason it is not running.</p>
         <h4>Configuring NTP with NetInfo</h4>
-        If NetInfo support is compiled into NTP, you can opt to configure ntp in your NetInfo domain. NTP will look int he NetInfo directory <tt>/locations/ntp</tt> for property/value pairs which are equivalent the the lines in the configuration file described above. Each configuration keyword may have a coresponding property in NetInfo. Each value for a given property is treated as arguments to that property, similar to a line in the configuration file.
+        If NetInfo support is compiled into NTP, you can opt to configure NTP in your NetInfo domain. NTP will look in the NetInfo directory <tt>/locations/ntp</tt> for property/value pairs which are equivalent to the lines in the configuration file described above. Each configuration keyword may have a corresponding property in NetInfo. Each value for a given property is treated as arguments to that property, similar to a line in the configuration file.
         <p>For example, the configuration shown in the configuration file above can be duplicated in NetInfo by adding a property &quot;<tt>server</tt>&quot; with values &quot;<tt>rackety.udel.edu</tt>&quot;, &quot;<tt>umd1.umd.edu</tt>&quot;, and &quot;<tt>lilben.tn.cornell.edu</tt>&quot;; and a property &quot;<tt>driftfile</tt>&quot; with the single value &quot;<tt>/etc/ntp.drift</tt>&quot;.</p>
         <p>Values may contain multiple tokens similar to the arguments available in the configuration file. For example, to use <tt>mimsy.mil</tt> as an NTP version 1 time server, you would add a value &quot;<tt>mimsy.mil version 1</tt>&quot; to the &quot;<tt>server</tt>&quot; property.</p>
         <h4>Ntp4 Versus Previous Versions</h4>
-        There are several items of note when dealing with a mixture of <tt>ntp4</tt> and previous distributions of NTP Version 2 (<tt>ntpd</tt>) and NTP Version 1 (<tt>ntp3.4</tt>). The <tt>ntp4</tt> implementation conforms to the NTP Version 3 specification RFC-1305 and, in addition, contains additional feaures documented in the <a href="release.html">Release Notes</a> page. As such, by default when no additional information is available concerning the preferences of the peer, <tt>ntpd</tt> claims to be version 4 in the packets that it sends from configured associations. The <tt>version</tt> subcommand of the <tt>server</tt>, <tt>peer</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> command can be used to change the default. In unconfigured (ephemeral) associaitons, the daemon always replies in the same version as the request.
+        There are several items of note when dealing with a mixture of <tt>ntp4</tt> and previous distributions of NTP Version 2 (<tt>ntpd</tt>) and NTP Version 1 (<tt>ntp3.4</tt>). The <tt>ntp4</tt> implementation conforms to the NTP Version 3 specification RFC-1305 and, in addition, contains additional features documented in the <a href="release.html">Release Notes</a> page. As such, by default when no additional information is available concerning the preferences of the peer, <tt>ntpd</tt> claims to be version 4 in the packets that it sends from configured associations. The <tt>version</tt> subcommand of the <tt>server</tt>, <tt>peer</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> command can be used to change the default. In unconfigured (ephemeral) associations, the daemon always replies in the same version as the request.
         <p>An NTP implementation conforming to a previous version specification ordinarily discards packets from a later version. However, in most respects documented in RFC-1305, The version 2 implementation is compatible with the version 3 algorithms and protocol. The version 1 implementation contains most of the version 2 algorithms, but without important features for clock selection and robustness. Nevertheless, in most respects the NTP versions are backwards compatible. The sticky part here is that, when a previous version implementation receives a packet claiming to be from a version 4 server, it discards it without further processing. Hence there is a danger that in some situations synchronization with previous versions will fail.</p>
         <p>The trouble occurs when an previous version is to be included in an <tt>ntpd</tt> configuration file. With no further indication, <tt>ntpd</tt> will send packets claiming to be version 4 when it polls. To get around this, <tt>ntpd</tt> allows a qualifier to be added to configuration entries to indicate which version to use when polling. Hence the entries</p>
         <pre>
@@ -156,13 +156,13 @@ key (6) for accessing server variables
 (Sun4c/50 IPX)
 </pre>
         There are a couple of previously unmentioned things in here. The <tt>keys</tt> line specifies the path to the keys file (see below and the <tt>ntpd</tt> document page for details of the file format). The <tt>trustedkey</tt> declaration identifies those keys that are known to be uncompromised; the remainder presumably represent the expired or possibly compromised keys. Both sets of keys must be declared by key identifier in the <tt>ntp.keys</tt> file described below. This provides a way to retire old keys while minimizing the frequency of delicate key-distribution procedures. The <tt>requestkey</tt> line establishes the key to be used for mode-6 control messages as specified in RFC-1305 and used by the <tt>ntpq</tt> utility program, while the <tt>controlkey</tt> line establishes the key to be used for mode-7 private control messages used by the <tt>ntpdc</tt> utility program. These keys are used to prevent unauthorized modification of daemon variables.
-        <p>Ordinarily, the authentication delay; that is, the processing time taken between the freezing of a transmit timestamp and the actual transmission of the packet when authentication is enabled (i.e. more or less the time it takes for the DES or MD5 routine to encrypt a single block) is computed automatically by the daemon. If necessary, the delay can be overriden by the <tt>authdelay</tt> line, which is used as a correction for the transmit timestamp.</p>
+        <p>Ordinarily, the authentication delay; that is, the processing time taken between the freezing of a transmit timestamp and the actual transmission of the packet when authentication is enabled (i.e. more or less the time it takes for the DES or MD5 routine to encrypt a single block) is computed automatically by the daemon. If necessary, the delay can be overridden by the <tt>authdelay</tt> line, which is used as a correction for the transmit timestamp.</p>
         Additional utility programs included in the <tt>./authstuff</tt> directory can be used to generate random keys, certify implementation correctness and display sample keys. As a general rule, keys should be chosen randomly, except possibly the request and control keys, which must be entered by the user as a password.
         <p>The <tt>ntp.keys</tt> file contains the list of keys and associated key IDs the server knows about (for obvious reasons this file is better left unreadable by anyone except root). The contents of this file might look like:</p>
         <pre>
      # ntp keys file (ntp.keys)
      1    N   
-29233E0461ECD6AE    # des key in NTP format
+29233E0461ECD6AE    # DES key in NTP format
      2    M   
 RIrop8KPPvQvYotM    # md5 key as an ASCII random string
      14   M   
@@ -170,7 +170,7 @@ sundial
 ;  # md5 key as an ASCII string
      15   A   
 sundial           
-;  # des key as an ASCII string
+;  # DES key as an ASCII string
 
      # the following 3 keys are identical
 
@@ -181,7 +181,7 @@ d3e54352e5548080
 a7cb86a4cba80101
 </pre>
         In the keys file the first token on each line indicates the key ID, the second token the format of the key and the third the key itself. There are four key formats. An <tt>A</tt> indicates a DES key written as a 1- to-8 character string in 7-bit ASCII representation, with each character standing for a key octet (like a Unix password). An <tt>S</tt> indicates a DES key written as a hex number in the DES standard format, with the low order bit (LSB) of each octet being the (odd) parity bit. An <tt>N</tt> indicates a DES key again written as a hex number, but in NTP standard format with the high order bit of each octet being the (odd) parity bit (confusing enough?). An <tt>M</tt> indicates an MD5 key written as a 1-to-31 character ASCII string in the <tt>A</tt> format. Note that, because of the simple tokenizing routine, the characters <tt>' ', '#', '\t', '\n'</tt> and <tt>'\0'</tt> can't be used in either a DES or MD5 ASCII key. Everything else is fair game, though. Key 0 (zero) is used for special purposes and should not appear in this file.
-        <p>The big trouble with the authentication facility is the keys file. It is a maintenance headache and a security problem. This should be fixed some day. Presumably, this whole bag of worms goes away if/when a generic security regime for the Internet is established. An alternative with NTP Version 4 is the autokey feature, which uses random session keys and public-key cruptography and avoids the key file entirely. While this feature is not completely finished yet, details can be found in the <a href="release.html">Release Notes</a> page.</p>
+        <p>The big trouble with the authentication facility is the keys file. It is a maintenance headache and a security problem. This should be fixed some day. Presumably, this whole bag of worms goes away if/when a generic security regime for the Internet is established. An alternative with NTP Version 4 is the autokey feature, which uses random session keys and public-key cryptography and avoids the key file entirely. While this feature is not completely finished yet, details can be found in the <a href="release.html">Release Notes</a> page.</p>
         <h4>Query Programs</h4>
         Three utility query programs are included with the distribution, <tt>ntpq</tt>, <tt>ntptrace</tt> and <tt>ntpdc</tt>. <tt>ntpq</tt> is a handy program which sends queries and receives responses using NTP standard mode-6 control messages. Since it uses the standard control protocol specified in RFC- 1305, it may be used with NTP Version 2 and Version 3 implementations for both Unix and Fuzzball, but not Version 1 implementations. It is most useful to query remote NTP implementations to assess timekeeping accuracy and expose bugs in configuration or operation.
         <p><tt>ntptrace</tt> can be used to display the current synchronization path from a selected host through possibly intervening servers to the primary source of synchronization, usually a radio clock. It works with both version 2 and version 3 servers, but not version 1.</p>
@@ -228,7 +228,7 @@ requests
         <h4>Dealing with Frequency Tolerance Violations (<tt>tickadj</tt> and Friends)</h4>
         The NTP Version 3 specification RFC-1305 calls for a maximum oscillator frequency tolerance of +-100 parts-per-million (PPM), which is representative of those components suitable for use in relatively inexpensive workstation platforms. For those platforms meeting this tolerance, NTP will automatically compensate for the frequency errors of the individual oscillator and no further adjustments are required, either to the configuration file or to various kernel variables. For the NTP Version 4 release, this tolerance has been increased to +-500 PPM.
         <p>However, in the case of certain notorious platforms, in particular Sun 4.1.1 systems, the performance can be improved by adjusting the values of certain kernel variables; in particular, <tt>tick</tt> and <tt>tickadj</tt>. The variable <tt>tick</tt> is the increment in microseconds added to the system time on each interval- timer interrupt, while the variable <tt>tickadj</tt> is used by the time adjustment code as a slew rate, in microseconds per tick. When the time is being adjusted via a call to the system routine <tt>adjtime()</tt>, the kernel increases or reduces tick by <tt>tickadj</tt> microseconds per tick until the specified adjustment has been completed. Unfortunately, in most Unix implementations the tick increment must be either zero or plus/minus exactly <tt>tickadj</tt> microseconds, meaning that adjustments are truncated to be an integral multiple of <tt>tickadj</tt> (this latter behaviour is a misfeature, and is the only reason the <tt>tickadj</tt> code needs to concern itself with the internal implementation of <tt>tickadj</tt> at all). In addition, the stock Unix implementation considers it an error to request another adjustment before a prior one has completed.</p>
-        <p>Thus, to make very sure it avoids problems related to the roundoff, the <tt>tickadj</tt> program can be used to adjust the values of <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all adjustments given to <tt>adjtime()</tt> are an even multiple of <tt>tickadj</tt> microseconds and computes the largest adjustment that can be completed in the adjustment interval (using both the value of <tt>tick</tt> and the value of <tt>tickadj</tt>) so it can avoid exceeding this limit. It is important to note that not all systems will allow inspection or modification of kernel variables other than at system build time. It is also important to know that, with the current NTP tolerances, it is rarely necessary to make these changes, but in many cases they will substantially improve the general accurace of the time service.</p>
+        <p>Thus, to make very sure it avoids problems related to the roundoff, the <tt>tickadj</tt> program can be used to adjust the values of <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all adjustments given to <tt>adjtime()</tt> are an even multiple of <tt>tickadj</tt> microseconds and computes the largest adjustment that can be completed in the adjustment interval (using both the value of <tt>tick</tt> and the value of <tt>tickadj</tt>) so it can avoid exceeding this limit. It is important to note that not all systems will allow inspection or modification of kernel variables other than at system build time. It is also important to know that, with the current NTP tolerances, it is rarely necessary to make these changes, but in many cases they will substantially improve the general accuracy of the time service.</p>
         <p>Unfortunately, the value of <tt>tickadj</tt> set by default is almost always too large for <tt>ntpd</tt>. NTP operates by continuously making small adjustments to the clock, usually at one-second intervals. If <tt>tickadj</tt> is set too large, the adjustments will disappear in the roundoff; while, if <tt>tickadj</tt> is too small, NTP will have difficulty if it needs to make an occasional large adjustment. While the daemon itself will read the kernel's values of these variables, it will not change the values, even if they are unsuitable. You must do this yourself before the daemon is started using the <tt>tickadj</tt> program included in the <tt>./util</tt> directory of the distribution. Note that the latter program will also compute an optimal value of <tt>tickadj</tt> for NTP use based on the kernel's value of <tt>tick</tt>.</p>
         <p>The <tt>tickadj</tt> program can reset several other kernel variables if asked. It can change the value of <tt>tick</tt> if asked. This is handy to compensate for kernel bugs which cause the clock to run with a very large frequency error, as with SunOS 4.1.1 systems. It can also be used to set the value of the kernel <tt>dosynctodr</tt> variable to zero. This variable controls whether to synchronize the system clock to the time-of-day clock, something you really don't want to be happen when <tt>ntpd</tt> is trying to keep it under control. In some systems, such as recent Sun Solaris kernels, the <tt>dosynctodr</tt> variable is the only one that can be changed by the <tt>tickadj</tt> program. In this and other modern kernels, it is not necessary to change the other variables in any case.</p>
         <p>We have a report that says starting with Solaris 2.6 we should leave <i>dosynctodr</i> alone.</p>
diff --git a/html/ntpd.html b/html/ntpd.html
index 94df907..7b756c3 100644
--- a/html/ntpd.html
+++ b/html/ntpd.html
@@ -51,7 +51,7 @@
         <p>In some cases it may not be practical for <tt>ntpd</tt> to run continuously. A common workaround has been to run the <tt>ntpdate</tt> program from a <tt>cron</tt> job at designated times. However, this program does not have the crafted signal processing, error checking and mitigation algorithms of <tt>ntpd</tt>. The <tt>-q</tt> option is intended for this purpose. Setting this option will cause <tt>ntpd</tt> to exit just after setting the clock for the first time. The procedure for initially setting the clock is the same as in continuous mode; most applications will probably want to specify the <tt>iburst</tt> keyword with the <tt>server</tt> configuration command. With this keyword a volley of messages are exchanged to groom the data and the clock is set in about 10 s. If nothing is heard after a couple of minutes, the daemon times out and exits. After a suitable period of mourning, the <tt>ntpdate</tt> program may be retired.</p>
         <p>When kernel support is available to discipline the clock frequency, which is the case for stock Solaris, Tru64, Linux and FreeBSD, a useful feature is available to discipline the clock frequency. First, <tt>ntpd</tt> is run in continuous mode with selected servers in order to measure and record the intrinsic clock frequency offset in the frequency file. It may take some hours for the frequency and offset to settle down. Then the <tt>ntpd</tt> is stopped and run in one-time mode as required. At each startup, the frequency is read from the file and initializes the kernel frequency.</p>
         <h4 id="poll">Poll Interval Control</h4>
-        <p>This version of NTP includes an intricate state machine to reduce the network load while maintaining a quality of synchronization consistent with the observed jitter and wander. There are a number of ways to tailor the operation in order enhance accuracy by reducing the interval or to reduce network overhead by increasing it. However, the user is advised to carefully consider the consequences of changing the poll adjustment range from the default minimum of 64 s to the default maximum of 1,024 s. The default minimum can be changed with the <tt>tinker minpoll</tt> command to a value not less than 16 s. This value is used for all configured associations, unless overriden by the <tt>minpoll</tt> option on the configuration command. Note that most device drivers will not operate properly if the poll interval is less than 64 s and that the broadcast server and manycast client associations will also use the default, unless overriden.</p>
+        <p>This version of NTP includes an intricate state machine to reduce the network load while maintaining a quality of synchronization consistent with the observed jitter and wander. There are a number of ways to tailor the operation in order enhance accuracy by reducing the interval or to reduce network overhead by increasing it. However, the user is advised to carefully consider the consequences of changing the poll adjustment range from the default minimum of 64 s to the default maximum of 1,024 s. The default minimum can be changed with the <tt>tinker minpoll</tt> command to a value not less than 16 s. This value is used for all configured associations, unless overridden by the <tt>minpoll</tt> option on the configuration command. Note that most device drivers will not operate properly if the poll interval is less than 64 s and that the broadcast server and manycast client associations will also use the default, unless overridden.</p>
         <p>In some cases involving dial up or toll services, it may be useful to increase the minimum interval to a few tens of minutes and maximum interval to a day or so. Under normal operation conditions, once the clock discipline loop has stabilized the interval will be increased in steps from the minimum to the maximum. However, this assumes the intrinsic clock frequency error is small enough for the discipline loop correct it. The capture range of the loop is 500 PPM at an interval of 64s decreasing by a factor of two for each doubling of interval. At a minimum of 1,024 s, for example, the capture range is only 31 PPM. If the intrinsic error is greater than this, the drift file <tt>ntp.drift</tt> will have to be specially tailored to reduce the residual error below this limit. Once this is done, the drift file is automatically updated once per hour and is available to initialize the frequency on subsequent daemon restarts.</p>
         <h4 id="huff">The huff-n'-puff Filter</h4>
         <p>In scenarios where a considerable amount of data are to be downloaded or uploaded over telephone modems, timekeeping quality can be seriously degraded. This occurs because the differential delays on the two directions of transmission can be quite large. In many cases the apparent time errors are so large as to exceed the step threshold and a step correction can occur during and after the data transfer is in progress.</p>
diff --git a/html/ntpdate.html b/html/ntpdate.html
index fe51195..632355d 100644
--- a/html/ntpdate.html
+++ b/html/ntpdate.html
@@ -58,6 +58,9 @@
             <dt><tt>-<i>v</i></tt>
             <dd>Be verbose. This option will cause <tt>ntpdate</tt>'s version identification string to be logged.
         </dl>
+        <h4>Diagnostics</h4>
+        <tt>ntpdate</tt>'s exit status is zero if it finds a server
+        and updates the clock, and nonzero otherwise.
         <h4>Files</h4>
         <tt>/etc/ntp.keys</tt> - encryption keys used by <tt>ntpdate</tt>.
         <h4>Bugs</h4>
diff --git a/html/ntpdc.html b/html/ntpdc.html
index 3eda964..22e4993 100644
--- a/html/ntpdc.html
+++ b/html/ntpdc.html
@@ -64,7 +64,7 @@
             <dd>Exit <tt>ntpdc</tt>.
             <dt><tt>passwd</tt>
             <dd>This command prompts you to type in a password (which will not be echoed) which will be used to authenticate configuration requests. The password must correspond to the key configured for use by the NTP server for this purpose if such requests are to be successful.
-            <dt><tt>timeout <i>millseconds</i></tt>
+            <dt><tt>timeout <i>milliseconds</i></tt>
             <dd>Specify a timeout period for responses to server queries. The default is about 8000 milliseconds. Note that since <tt>ntpdc</tt> retries each query once after a timeout, the total waiting time for a timeout will be twice the timeout value set.
         </dl>
         <h4>Control Message Commands</h4>
@@ -91,7 +91,7 @@
             <dt><tt>sysinfo</tt>
             <dd>Print a variety of system state variables, i.e., state related to the local server. All except the last four lines are described in the NTP Version 3 specification, RFC-1305.
             <p>The <tt>system flags</tt> show various system flags, some of which can be set and cleared by the <tt>enable</tt> and <tt>disable</tt> configuration commands, respectively. These are the <tt>auth</tt>, <tt>bclient</tt>, <tt>monitor</tt>, <tt>pll</tt>, <tt>pps</tt> and <tt>stats</tt> flags. See the <tt>ntpd</tt> documentation for the meaning of these flags. There are two additional flags which are read only, the <tt>kernel_pll</tt> and <tt>kernel_pps</tt>. These flags indicate the synchronization status when the precision time kernel modifications are in use. The <tt>kernel_pll</tt> indicates that the local clock is being disciplined by the kernel, while the kernel_pps indicates the kernel discipline is provided by the PPS signal.</p>
-            <p>The <tt>stability</tt> is the residual frequency error remaining afterthe system frequency correction is applied and is intended for maintenance and debugging. In most architectures, this value will initially decrease from as high as 500 ppm to a nominal value in the range .01 to 0.1 ppm. If it remains high for some time after starting the daemon, something may be wrong with the local clock, or the value of the kernel variable <tt>tick</tt> may be incorrect.</p>
+            <p>The <tt>stability</tt> is the residual frequency error remaining after the system frequency correction is applied and is intended for maintenance and debugging. In most architectures, this value will initially decrease from as high as 500 ppm to a nominal value in the range .01 to 0.1 ppm. If it remains high for some time after starting the daemon, something may be wrong with the local clock, or the value of the kernel variable <tt>tick</tt> may be incorrect.</p>
             <p>The <tt>broadcastdelay</tt> shows the default broadcast delay, as set by the <tt>broadcastdelay</tt> configuration command.</p>
             <p>The <tt>authdelay</tt> shows the default authentication delay, as set by the <tt>authdelay</tt> configuration command.</p>
             <dt><tt>sysstats</tt>