From: Harlan Stenn Date: Wed, 7 Jul 1999 06:02:36 +0000 (-0000) Subject: Many files: X-Git-Tag: NTP_4_0_94~28 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3bcd93cac5a3944c5f0d77dd4e38c2bd67bf48de;p=thirdparty%2Fntp.git Many files: Import new HTML pages from Dave Mills bk: 3782ed7cYU1Fl3d9brcVJQkipUNd7Q --- diff --git a/html/accopt.htm b/html/accopt.htm index 96022f990d..d64a0d11a0 100644 --- a/html/accopt.htm +++ b/html/accopt.htm @@ -1,142 +1,219 @@ - -Access Control Options -

-Access Control Options -

- -

Access Control Support

- -The ntpd daemon provides an access control mechanism based on a -restriction list. Each entry in the list includes a 32-bit IP address, -32-bit mask and a set of restriction flags. The list is sorted first by -address and then by mask. The source address of every incoming NTP -packet is matched with each entry of the list in order. The matching -operation consists of first computing the bitwise AND of the packet IP -address and mask, then the bitwise AND of the entry IP address and mask. -If the results of the two AND operations agree, the restriction flags of -the entry define the restrictions for the packet. In the case of -multiple matches, the last match found is used. This allows default -restrictions to be defined, then exceptions for networks, subnets and -individual hosts defined as needed. Additional information and examples -can be found in the Notes on Configuring NTP and -Setting up a NTP Subnet page. - -

Access Control Commands

+ + + + + Access Control Options + + + + +

+Access Control Options

+ +
+

+Access Control Support

+ntpd implements a general purpose address-and-mask based restriction +list. The list is sorted by address and by mask, and the list is searched +in this order for matches, with the last match found defining the restriction +flags associated with the incoming packets. The source address of incoming +packets is used for the match, with the 32-bit address being and'ed with +the mask associated with the restriction entry and then compared with the +entry's address (which has also been and'ed with the mask) to look for +a match. Additional information and examples can be found in the Notes +on Configuring NTP and Setting up a NTP Subnet page. + +

The restriction facility was implemented in conformance with the access +policies for the original NSFnet backbone time servers. While this facility +may be otherwise useful for keeping unwanted or broken remote time servers +from affecting your own, it should not be considered an alternative to +the standard NTP authentication facility. Source address based restrictions +are easily circumvented by a determined cracker. +

+Access Control Commands

- -
restrict numeric_address [mask numeric_mask] -[flag] +
+restrict numeric_address [mask numeric_mask] [flag] [...]
-
The numeric_address argument, expressed in -dotted-quad form, is the IP address of a network, subnet or individual -host. The mask argument, also expressed in dotted-quad -form, defaults to 255.255.255.255, so that a -numeric_address without mask is treated as the address -of an individual host. The special numeric_address -value specified as the string default is interpreted as address -0.0.0.0) and mask 255.255.255.255. Since the -restriction list entries are sorted by IP address and mask, this is -always the first entry in the list.
- -
The flag always restricts access, i.e., an entry -with no flags indicates that no restrictions are defined. The flags -are not orthogonal, in that more restrictive flags will often make less -restrictive ones redundant. The flags can generally be classed into two -categories, those which restrict time service and those which restrict -informational queries and attempts to do run-time reconfiguration of the -server. One or more of the following flags may be specified:
-
+
+The numeric_address argument, expressed in dotted-quad +form, is the address of an host or network. The mask argument, +also expressed in dotted-quad form, defaults to 255.255.255.255, +meaning that the numeric_address is treated as the address +of an individual host. A default entry (address 0.0.0.0, mask +0.0.0.0) is always included and, given the sort algorithm, is +always the first entry in the list. Note that, while numeric_address +is normally given in dotted-quad format, the text string default, +with no mask option, may be used to indicate the default entry.
+ +
+In the current implementation, flag always restricts access, +i.e., an entry with no flags indicates that free access to the server is +to be given. The flags are not orthogonal, in that more restrictive flags +will often make less restrictive ones redundant. The flags can generally +be classed into two catagories, those which restrict time service and those +which restrict informational queries and attempts to do run-time reconfiguration +of the server. One or more of the following flags may be specified:
+ +
+ 
-
ignore
-
Ignore all packets from hosts which match this entry. If this flag -is specified neither queries nor time server polls will be responded -to.
- -
noquery
-
Ignore all NTP mode 6 and 7 packets (i.e. information queries and -configuration requests) from the source. Time service is not -affected.
- -
nomodify
-
Ignore all NTP mode 6 and 7 packets which attempt to modify the -state of the server (i.e. run time reconfiguration). Queries which -return information are permitted.
- -
notrap
-
Decline to provide mode 6 control message trap service to matching -hosts. The trap service is a subsystem of the mode 6 control message -protocol which is intended for use by remote event logging -programs.
- -
lowpriotrap
-
Declare traps set by matching hosts to be low priority. The number -of traps a server can maintain is limited (the current limit is 3). -Traps are usually assigned on a first come, first served basis, with -later trap requestors being denied service. This flag modifies the -assignment algorithm by allowing low priority traps to be overridden by -later requests for normal priority +
+ignore
+ +
+Ignore all packets from hosts which match this entry. If this flag is specified +neither queries nor time server polls will be responded to.
+ +
+ 
+ +
+noquery
+ +
+Ignore all NTP mode 6 and 7 packets (i.e. information queries and configuration +requests) from the source. Time service is not affected.
+ +
+ 
+ +
+nomodify
+ +
+Ignore all NTP mode 6 and 7 packets which attempt to modify the state of +the server (i.e. run time reconfiguration). Queries which return information +are permitted.
+ +
+ 
+ +
+notrap
+ +
+Decline to provide mode 6 control message trap service to matching hosts. +The trap service is a subsystem of the mode 6 control message protocol +which is intended for use by remote event logging programs.
+ +
+ 
+ +
+lowpriotrap
+ +
+Declare traps set by matching hosts to be low priority. The number of traps +a server can maintain is limited (the current limit is 3). Traps are usually +assigned on a first come, first served basis, with later trap requestors +being denied service. This flag modifies the assignment algorithm by allowing +low priority traps to be overridden by later requests for normal priority traps.
-
noserve
-
Ignore NTP packets whose mode is other than 6 or 7. In effect, time -service is denied, though queries may still be permitted.
- -
nopeer
-
Provide stateless time service to polling hosts, but do not allocate -peer memory resources to these hosts even if they otherwise might be -considered useful as future synchronization partners.
- -
notrust
-
Treat these hosts normally in other respects, but never use them as -synchronization sources.
- -
limited
-
These hosts are subject to limitation of number of clients from the -same net. Net in this context refers to the IP notion of net (class A, -class B, class C, etc.). Only the first client_limit hosts that -have shown up at the server and that have been active during the last -client_limit_period seconds are accepted. Requests from other -clients from the same net are rejected. Only time request packets are -taken into account. Query packets sent by the ntpq and -ntpdc programs are not subject to these limits. A history of -clients is kept using the monitoring capability of ntpd. Thus, -monitoring is always active as long as there is a restriction entry with -the limited flag.
- -
ntpport
-
This is actually a match algorithm modifier, rather than a -restriction flag. Its presence causes the restriction entry to be -matched only if the source port in the packet is the standard NTP UDP -port (123). Both ntpport and non-ntpport may be -specified. The ntpport is considered more specific and is -sorted later in the list.
- -
Default restriction list entries, with the flags ignore, -ntpport, for each of the local host's interface addresses are -inserted into the table at startup to prevent the server from attempting -to synchronize to its own time. A default entry is also always present, -though if it is otherwise unconfigured; no flags are associated with the -default entry (i.e., everything besides your own NTP server is -unrestricted).
+
+ 
+ +
+noserve
+ +
+Ignore NTP packets whose mode is other than 6 or 7. In effect, time service +is denied, though queries may still be permitted.
+ +
+ 
+ +
+nopeer
+ +
+Provide stateless time service to polling hosts, but do not allocate peer +memory resources to these hosts even if they otherwise might be considered +useful as future synchronization partners.
+ +
+ 
+ +
+notrust
+ +
+Treat these hosts normally in other respects, but never use them as synchronization +sources.
+ +
+ 
+ +
+limited
+ +
+These hosts are subject to limitation of number of clients from the same +net. Net in this context refers to the IP notion of net (class A, class +B, class C, etc.). Only the first client_limit hosts that have +shown up at the server and that have been active during the last client_limit_period +seconds are accepted. Requests from other clients from the same net are +rejected. Only time request packets are taken into account. Query packets +sent by the ntpq and ntpdc programs are not subject to +these limits. A history of clients is kept using the monitoring capability +of ntpd. Thus, monitoring is always active as long as there is +a restriction entry with the limited flag.
+ +
+ 
+ +
+ntpport
+ +
+This is actually a match algorithm modifier, rather than a restriction +flag. Its presence causes the restriction entry to be matched only if the +source port in the packet is the standard NTP UDP port (123). Both ntpport +and non-ntpport may be specified. The ntpport is considered +more specific and is sorted later in the list.
+ +
+ 
-
-
clientlimit limit
-
Set the client_limit variable, which limits the number of -simultaneous access-controlled clients. The default value for this -variable is 3.
+
+Default restriction list entries, with the flags ignore, ntpport, +for each of the local host's interface addresses are inserted into the +table at startup to prevent the server from attempting to synchronize to +its own time. A default entry is also always present, though if it is otherwise +unconfigured; no flags are associated with the default entry (i.e., everything +besides your own NTP server is unrestricted).
+ +
+ 
-
clientperiod period
-
Set the client_limit_period variable, which specifies the -number of seconds after which a client is considered inactive and thus -no longer is counted for client limit restriction. The default value for -this variable is 3600 seconds.
+
+clientlimit limit
+
+Set the client_limit variable, which limits the number of simultaneous +access-controlled clients. The default value for this variable is 3.
+ +
+ 
+ +
+clientperiod period
+ +
+Set the client_limit_period variable, which specifies the number +of seconds after which a client is considered inactive and thus no longer +is counted for client limit restriction. The default value for this variable +is 3600 seconds.
-
David L. Mills <mills@udel.edu> -
+
+
+David L. Mills (mills@udel.edu)
+ + + diff --git a/html/assoc.htm b/html/assoc.htm index 4e762a3547..69cb7bc5b1 100644 --- a/html/assoc.htm +++ b/html/assoc.htm @@ -1,190 +1,170 @@ - -Association Management -

-Association Management -

- -

Association Modes

- + + + + + Release Notes + + + + +

+Association Management

+ +
+

+Association Modes

This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates -new features and refinements to the NTP Version 3 (NTPv3) algorithms. -However, it continues the tradition of retaining backwards compatibility -with older versions. The NTPv4 version has been under development for -quite a while and isn't finished yet. In fact, quite a number of NTPv4 -features have already been implemented in the current NTPv3, including a -number of new operating modes for automatic server discovery and -improved accuracy in occasionally-connected networks. Following is an -extended abstract describing the new features. - -

An ephemeral association of some mode is mobilized when a message -arrives from another client or server. For instance, a symmetric-passive -association is mobilized upon arrival of a message from a symmetric- -active peer. A client association is mobilized upon arrival of a -broadcast message from a multicast server or a server message from a -manycast server. Ephemeral associations are demobilized when either (a) -the server becomes unreachable or (b) an error occurs on initial contact -before the association is mobilized. - -

The one exception to (a) and (b) above is when autokey is in use and the initial -authentication check fails due to unknown key identifier or autokey -mismatch. This exception is necessary because the Unix kernel does not -bind the local address until the first packet is received. The result in -broadcast mode is a rather painful initial exchange, where -authentication fails until after the first round of messages. The result -in multicast mode is in general fatal, especially if multiple interfaces +new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, +it continues the tradition of retaining backwards compatibility with older +versions. The NTPv4 version has been under development for quite a while +and isn't finished yet. In fact, quite a number of NTPv4 features have +already been implemented in the current NTPv3, including a number of new +operating modes for automatic server discovery and improved accuracy in +occasionally-connected networks. Following is an extended abstract describing +the new features.. + +

An ephemeral association of some mode is mobilized when a message arrives +from another client or server. For instance, a symmetric-passive association +is mobilized upon arrival of a message from a symmetric- active peer. A +client association is mobilized upon arrival of a broadcast message from +a multicast server or a server message from a manycast server. Ephemeral +associations are demobilized when either (a) the server becomes unreachable +or (b) an error occurs on initial contact before the association is mobilized. + +

The one exception to (a) and (b) above is when +autokey is in use and the initial +authentication check fails due to unknown +key identifier or autokey mismatch. This exception is necessary because +the Unix kernel does not bind the local address until the first packet +is received. The result in broadcast mode is a rather painful initial exchange, +where authentication fails until after the first round of messages. The +result in multicast mode is in general fatal, especially if multiple interfaces are in use. As promiscuous modes such as multicast and manycast require -authentication for reliable and safe operation, autokey is in general -useless with these modes until and if the input/output machinery is -overhauled. +authentication for reliable and safe operation, autokey is in general useless +with these modes until and if the input/output machinery is overhauled.

Following is a summary of the protocol operations for each mode. -

- -
Peer Modes (Active and Passive)
- -
In these modes, two client/server peers agree to back each other up, -should the synchronization source for either peer fail. One or both -peers are configured in symmetric-active mode using the peer command. -Alternatively, one - the active peer - is configured in this mode and -the other, the passive peer, operates in symmetric-passive mode and -requires no prior configuration. Both association scenarios operate in -NTPv4 as in NTPv3; however, several bugs in the handling of keys and -recovery of resources when an active peer fails, have been corrected in -NTPv4. The original NTPv3 authentication scheme is applicable in this -mode, as well as the new NTPv4 autokey scheme.
- -
Client/Server Modes
- -
In these modes, a client sends a request to the server and expects a -reply at some future time. The client is configured in client mode using -the server (sic) command; the server requires no prior configuration. -The original NTPv3 authentication scheme is applicable in this mode, as -well as the new NTPv4 autokey scheme.
- -
Broadcast/Multicast Modes
- -
In these modes, the server generates messages at intervals specified +

Peer Modes (Active and Passive) +

    In these modes, two client/server peers agree to back each other up, +should the synchronization source for either peer fail. One or both peers +is configured in symmetric-active mode using the peer command. Alternatively, +one - the active peer - is configured in this mode and the other, the passive +peer, operates in symmetric-passive mode and requires no prior configuration. +Both association scenarios operate in NTPv4 as in NTPv3; however, several +bugs in the handling of keys and recovery of resources when an active peer +fails, have been corrected in NTPv4. The original NTPv3 authentication +scheme is applicable in this mode, as well as the new NTPv3 autokey scheme.
+Client/Server Modes +
    In these modes, a client sends a request to the server and expects +a reply at some future time. The client is configured in client mode using +the server (sic) command; the server requires no prior configuration. The +original NTPv3 authentication scheme is applicable in this mode, as well +as the new NTPv3 autokey scheme.
+Broadcast/Multicast Modes +
    In these modes, the server generates messages at intervals specified by the minpoll subcommand. When using IP multicast addresses, the scope of the multicast tree is specified by the ttl subcommand in hops. When using a local interface broadcast address, the scope is limited to the -attached subnet. The client responds to the first message received by -waiting an interval randomized over the minpoll interval, in order to -avoid implosions. Then, it polls the server in burst mode, in order to -accumulate data to reliably set the host clock. This normally results in -eight client/server cycles over a 32-s interval. When the next multicast -message is received, the client computes the offset between the system -clock just set and the apparent time of the multicast message in order -to correct the apparent time in future multicast messages.
- -
Manycast Mode
- -
In this mode, a configured client broadcasts a request message as in -client mode to a designated multicast group address. All servers -configured as manycast clients and in ttl range respond with a server -reply message. Each reply mobilizes a persistent client/server -association as in client mode. Then, the NTP intersection and clustering -algorithms act to discard all but the best of these associations, which -then continue as in client/server mode.
-
- -

Poll Interval Management

- -

A major goal in the system design is to minimize network overhead -without significant impairment in accuracy. Since each system clock -update requires an exchange of messages with each of possibly several -servers, the interval between these messages, the poll interval, must be -carefully and automatically managed over a prescribed range in response -to prevailing wander of the system clock oscillator and network jitter. -The limits to this range are set by the minpoll and -maxpoll variables described on the Configuration Options page. The default values -(usually 64 s and 1024 s) should be changed only in very special -circumstances and thorough understanding of the consequences. - -

Ordinarily, the daemon manages the poll interval automatically so -that, most of the time the interval hovers near the maximum. However, -under conditions of extreme network jitter or when the servers are -intermittently unreachable, the poll interval may be reduced, in the -extreme to the minimum. However, after some period when a server remains -unreachable, the poll interval is increased in steps to the maximum. -This protects the network against spurious traffic while continuing to -probe for server reachability. - -

Burst mode can be configured when the network attachment requires an -initial calling or training procedure and in cases where the first -message sent after a considerable interval is lost or the network has -moderate to high loss rate. This mode does produce additional network -overhead and can cause trouble if used indiscriminately. It should only -be used where the poll interval is expected to settle to values at or -above 1024 s. - -

Each poll initiates a burst of either two or eight request messages. -If the server is unreachable, 2 messages are sent; if reachable, 8 -messages are sent. If no valid reply is received, the client waits for -16 s before sending the next request. This is to allow time to complete -a dial-out modem or ISDN call. If a valid reply is received, the client -waits for 2 s before sending the next request. Reply messages update the -clock filter, but do not update the system clock until 2 s after the -last request is sent. - -

Error Checking

- -It is very important to avoid spurious mobilizations from possibly -broken or rogue servers; in particular, to avoid denial-of-service -attacks. In order to resist such attacks, arriving messages that might -mobilize ephemeral associations are carefully screened using a series of -eleven sanity checks. - +attached subnet. The client responds to the first message received by waiting +an interval randomized over the minpoll interval, in order to avoid implosions. +Then, it polls the server in burst mode, in order to accumulate data to +reliably set the host clock. This normally results in eight client/server +cycles over a 32-s interval. When the next multicast message is received, +the client computes the offset between the system clock just set and the +apparent time of the multicast message in order to correct the apparent +time in future multicast messages. +Manycast Mode + + +

+Burst Mode

+Burst mode can be configured when the network attachment requires an initial +calling or training procedure. Each poll initiates a burst of eight request +messages at intervals randomized over the range 3-5 s. The reply messages +update the clock filter, which then selects the best (most accurate) among +them. When the last reply in the burst is sent, the next reply updates +the client variables and system clock in the usual manner, as if only a +single request/reply cycle had occurred. This mode does produce additional +network overhead and can cause trouble if used indiscriminately. It should +only be used where the poll interval is expected to settle to values above +1024 s. +

+Revised Error Checking

+It is very important to avoid spurious mobilizations from possibly broken +or rogue servers; in particular, to avoid denial-of-service attacks. In +order to resist such attacks, arriving messages that might mobilize ephemeral +associations are carefully screened using a series of eleven sanity checks.
    - -
  1. Duplicate packet. This message is a duplicate of one previously -received.
    2. - -
  2. Bogus packet. This message did not result from a message previously -sent, or messages have been received out of order.
    3. - -
  3. Unsynchronized. The server has not yet stored the previous -timestamps.
    4. - -
  4. Invalid delay or dispersion. Either the delay or dispersion or both -computed from the message timestamps are above the normal range.
    5. - -
  5. Authentication failed. The sent MAC does not match the received MAC, -either due to the wrong key material or damaged message.
    6. - -
  6. Server unsynchronized. The server indicates unsynchronized in the -leap warning bits included in the packet.
    7. - -
  7. Server stratum check. The server is operating at a stratum above the -normal range.
    8. - -
  8. Delay/dispersion check. The related server packet data values are -above the normal range.
    9. - -
  9. Autokey failed. The hash of the current session key does not match -the most recent key identifiers used. (The hash is repeated four times, -in order to recover from lost packets whenever possible.)
    10. - -
  10. Access denied. The sender has been blocked by the access control -list.
    11. - -
  11. Key not found. The key identifier does not match any identifier in -the key list or the key has expired or been revoked.
    12. - +
  12. +Duplicate packet. This message is a duplicate of one previously received.
    13. + +
      +
  13. +Bogus packet. This message did not result from a message previously sent, +or messages have been received out of order.
    14. + +
      +
  14. +Unsynchronized. The server has not yet stored the previous timestamps.
    15. + +
      +
  15. +Invalid delay or dispersion. Either the delay or dispersion or both computed +from the message timestamps are above the normal range.
    16. + +
      +
  16. +Authentication failed. The sent MAC does not match the received MAC, either +due to the wrong key material or damaged message.
    17. + +
      +
  17. +Server unsynchronized. The server indicates unsynchronized in the leap +bits included in the packet.
    18. + +
      +
  18. +Server stratum check. The server is operating at a stratum above the normal +range.
    19. + +
      +
  19. +Delay/dispersion check. The related server packet data values are above +the normal range.
    20. + +
      +
  20. +Autokey failed. The hash of the current session key does not match the +most recent key identifiers used. (The hash is repeated four times, in +order to recover from lost packets whenever possible.)
    21. + +
      +
  21. +Access denied. The sender has been blocked by the access control list.
    22. + +
      +
  22. +Key not found. The key identifier does not match any identifier in the +key list or the key has expired or been revoked.
- Failure to pass tests 5-11 is sufficient evidence to discard the packet -without forming an association. However, failure to pass tests 1-4 is -not necessarily grounds to reject the packet, since subsequent packets -may be acceptable. In this case, the association is mobilized, but only -the packet timestamps are stored. For the moment, and until the -cryptographic signature algorithm is available, test 9 is temporarily -disabled. - +without forming an association. However, failure to pass tests 1-4 is not +necessarily grounds to reject the packet, since subsequent packets may +be acceptable. In this case, the association is mobilized, but only the +packet timestamps are stored. For the moment, and until the cryptographic +signature algorithm is available, test 9 is temporarily disabled.
-
David L. Mills <mills@udel.edu> -
+
+
+David L. Mills (mills@udel.edu)
+
  + + diff --git a/html/authopt.htm b/html/authopt.htm index 26f98823a1..6355e9fefe 100644 --- a/html/authopt.htm +++ b/html/authopt.htm @@ -1,143 +1,130 @@ - -Authentication Options -

-Authentication Options -

- -

Authentication Support

- + + + + + Authentication Options + + + + +

+Authentication Options

+ +
+

+Authentication Support

Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder intending accidentally -or on purpose to masquerade as that server. The NTPv3 specification -RFC-1305 defines a scheme which provides cryptographic authentication of -received NTP packets. Originally, this was done using the Data -Encryption Standard (DES) operating in Cipher Block Chaining (CBC) mode, -commonly called DES-CBC. Subsequently, this was augmented by the RSA -Message Digest 5 (MD5) using a private key, commonly called keyed-MD5. -Either algorithm computes a message digest, or one-way hash, which can -be used to verify the server has the correct private key and key -identifier. NTPv4 retains this scheme and, in addition, provides a new -autokey scheme based on reverse hashing and public key -cryptography. Authentication can be configured separately for each -association using the key or autokey subcommands on -the peer, server, broadcast and -manycastclient commands as described in the Configuration Options page. +or on purpose to masquerade as that server. The NTPv3 specification RFC-1305 +defines an scheme which provides cryptographic authentication of received +NTP packets. Originally, this was done using the Data Encryption Standard +(DES) operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. +Subsequently, this was augmented by the RSA Message Digest 5 (MD5) using +a private key, commonly called keyed-MD5. Either algorithm computes a message +digest, or one-way hash, which can be used to verify the server has the +correct private key and key identifier. NTPv4 retains this scheme and, +in addition, provides a new autokey scheme based on reverse hashing +and public key cryptography. Authentication can be configured separately +for each association using the key or autokey subcommands +on the peer, server, broadcast and manycastclient +commands as described in the  Configuration Options +page.

The authentication options specify the suite of keys, select the key for each configured association and manage the configuration operations, -as described below. The auth flag which controls these -functions can be set or reset by the enable and -disable configuration commands and also by remote configuration -commands sent by a ntpdc program running in another machine. If -this flag is set, persistent peer associations and remote configuration -commands are effective only if cryptographically authenticated. If this -flag is disabled, these operations are effective even if not -cryptographically authenticated. It should be understood that operating -in the latter mode invites a significant vulnerability where a rogue -hacker can seriously disrupt timekeeping operations. - -

The auth flag affects all authentication procedures -described below; however, it operates differently if cryptographic -support is compiled in the distribution. If this support is available -and the flag is enabled, then persistent associations are mobilized and -remote configuration commands are effective only if successfully -authenticated. If the support is unavailable and the flag is enabled, -then it is not possible under any conditions to mobilize persistent -associations or respond to remote or local configuration commands. The -auth flag normally defaults enabled if cryptographic support is -available and disabled otherwise. - -

Persistent associations are normally mobilized upon arrival of a -message from a server operating in symmetric active mode. The -peer configuration file command mobilizes such an association. -When a message arrives from the active server, the passive server -attempts to mobilize a symmetric passive association. Unless refused by -the passive server, either using access controls or authentication, this -could allow a rogue active server to control the passive server clock. -Using cryptographic authentication, such attacks can be deflected. - -

With the above vulnerabilities in mind, it is desirable to set the -auth flag in all cases. One aspect which is often confusing is -the name resolution process which maps server names in the configuration -file to IP addresses. In order to protect against bogus name server -messages, this process is authenticated using an internally generated -key which is normally invisible to the user. However, if cryptographic -support is unavailable and the auth flag is enabled, the name -resolution process will fail. This can be avoided either by specifying -IP addresses instead of host names, which is generally inadvisable, or -by leaving the flag disabled and enabling it once the name resolution -process is complete. - -

Private Key Scheme

- -The original RFC-1305 specification allows any one of possibly 65,536 -keys, each distinguished by a 32-bit key identifier, to authenticate an -association. The servers involved must agree on the key and key -identifier to authenticate their messages. Keys and related information -are specified in a key file, usually called ntp.keys, which -should be exchanged and stored using secure procedures beyond the scope -of the NTP protocol itself. Besides the keys used for ordinary NTP -associations, additional ones can be used as passwords for the ntpq and ntpdc +as described below. The auth flag which controls these functions +can be set or reset by the enable and disable configuration +commands and also by remote configuration commands sent by a ntpdc +program running in another machine. If this flag is set, persistent peer +associations and remote configuration commands are effective only if cryptographically +authenticated. If this flag is disabled, these operations are effective +even if not cryptographic authenticated. It should be understood that operating +in the latter mode invites a significant vulnerability where a rogue hacker +can seriously disrupt client operations. + +

The auth flag affects all authentication procedures described +below; however, it operates differently if cryptographic support is compiled +in the distribution. If this support is available and the flag is enabled, +then persistent associations are mobilized and remote configuration commands +are effective only if successfully authenticated. If the support is unavailable +and the flag is enabled, then it is not possible under any conditions to +mobilize persistent associations or respond to remote configuration commands. +The auth flag normally defaults to set if cryptographic support +is available and to reset otherwise. + +

With the above vulnerabilities in mind, it is desirable to set the auth +flag in all cases. One aspect which is often confusing is the name resolution +process which maps server names in the configuration file to IP addresses. +In order to protect against bogus name server messages, this process is +authenticated using an internally generated key which is normally invisible +to the user. However, if cryptographic support is unavailable and the auth +flag is enabled, the name resolution process will fail. This can be avoided +either by specifying IP addresses instead of host names, which is generally +inadvisable, or by leaving the flag disabled and enabling it once the name +resolution process is complete. +

+Private Key Scheme

+The original RFC-1305 specification allows any one of possibly 65,536 keys, +each distinguished a 32-bit key identifier, to authenticate an association. +The servers involved must agree on the key and key identifier to authenticate +their messages. Keys and related information are specified in a key file, +usually called ntp.keys, which should be exchanged and stored +using secure procedures beyond the scope of the NTP protocol itself. Besides +the keys used for ordinary NTP associations, additional ones can be used +as passwords for the ntpq and ntpdc utility programs. -

When ntpdis first started, it reads the key file and -installs the keys in the key cache. However, the keys must be activated -before they can be used with the trusted command. This allows, -for instance, the installation of possibly several batches of keys and -then activating or inactivating each batch remotely using -ntpdc. This also provides a revocation capability that can be -used if a key becomes compromised. The requestkey command -selects the key used as the password for the ntpdc utility, -while the controlkey command selects the key used as the -password for the ntpqutility. - -

Autokey Scheme

- +

When ntpd is first started, it reads the key file and installs +the keys in the key cache. However, the keys must be activated before they +can be used with the trusted command. This allows, for instance, +the installation of possibly several batches of keys and then activating +or inactivating each batch remotely using ntpdc. This also provides +a revocation capability that can be used if a key becomes compromised. +The requestkey command selects the key used as the password for +the ntpdc utility, while the controlkey command selects +the key used as the password for the the ntpq utility. +

+Autokey Scheme

The original NTPv3 authentication scheme described in RFC-1305 continues -to be supported. In NTPv4, an additional authentication scheme called -autokey is available. It operates much like the S/KEY scheme, in -that a session key list is constructed and the entries used in reverse -order. A description of the scheme, along with a comprehensive security -analysis, is contained in a technical report available from the IETF web -page www.ietf.org. - -

The autokey scheme is specifically designed for multicast modes, -where clients normally do not send messages to the server. In these -modes, the server uses the scheme to generate a key list by repeated -hashing of a secret value. The list is used in reverse order to generate -a unique session key for each message sent. The client regenerates the -session key and verifies that the hash matches the previous session key. Each -message contains the public values binding the session key to the secret -value, but these values need to be verified only when the server -generates a new key list or more than four server messages have been -lost. +to be supported. In NTPv4, an additional authentication scheme called autokey +is available. It operates much like the S-KEY scheme, in that a session +key list is constructed and the entries used in reverse order. A description +of the scheme, along with a comprehensive security analysis, is contained +in a technical report available from the IETF web page www.ietf.org +. + +

The autokey scheme is specifically designed for multicast modes, where +clients normally do not send messages to the server. In these modes, the +server uses the scheme to generate a key list by repeated hashing of a +secret value. The list is used in reverse order to generate a unique session +key for each message sent. The client regenerates the session key and verifies +the hash matches the previous session key. Each message contains the public +values binding the session key to the secret value, but these values need +to be verified only when the server generates a new key list or more than +four server messages have been lost.

The scheme is appropriate for client/server and symmetric-peer modes -as well. In these modes, the client generates a session key as in -multicast modes. The server regenerates the session key and uses it to -formulate a reply using its own public values. The client verifies that the -key identifier of the reply matches the request, verifies the public -values and validates the message. In peer mode, each peer independently -generates a key list and operates as in the multicast mode. +as well. In these modes, the client generates a session key as in multicast +modes. The server regenerates the session key and uses it to formulates +a reply using its own public values. The client verifies the key identifier +of the reply matches the request, verifies the public values and validates +the message. In peer mode, each peer independently generates a key list +and operates as in the multicast mode.

The autokey scheme requires no change to the NTP packet header format or message authentication code (MAC), which is appended to the header; however, if autokey is in use, an extensions field is inserted between the header and MAC. The extensions field contains a random public value which is updated at intervals specified by the revoke command, together -with related cryptographic values used in the signing algorithm. The -format of the extensions field is defined in Internet Draft -draft-ntp-auth-coexist-01.txt. The MAC itself is constructed in the same -way as NTPv3, but using the original NTP header and the extensions field -padded to a 64-bit boundary. Each new public value is encrypted by the -host private value. It is the intent of the design, not yet finalized, -that the public value, encrypted public value, public key and -certificate be embedded in the extensions field where the client can -decrypt as needed. However, the relatively expensive encryption -and decryption operations are necessary only when the public value is -changed. +with related cryptographic values used in the signing algorithm. The format +of the extensions field is defined in Internet Draft draft-NTP- auth-coexist-00.txt. +The MAC itself is constructed in the same way as NTPv3, but using the original +NTP header and the extensions field padded to a 64-bit boundary. Each new +public value is encrypted by the host private value. It is the intent of +the design, not yet finalized, that the public value, encrypted public +value, public key and certificate be embedded in the extensions field where +the client can decrypt as needed. However, the relatively expensive encryption +and decryption operations are necessary only when the public value is changed.

Note that both the original NTPv3 authentication scheme and the new NTPv4 autokey scheme operate separately for each configured association, @@ -146,124 +133,156 @@ same time. Since all keys, including session keys, occupy the same key cache, provisions have been made to avoid collisions, where some random roll happens to collide with another already generated. Since something like four billion different session key identifiers are available, the -chances are small that this might happen. If it happens during -generation, the generator terminates the current session key list. By -the time the next list is generated, the collided key will probably have -been expired or revoked. - -

While permanent keys have lifetimes that expire only when manually -revoked, random session keys have a lifetime specified at the time of -generation. When generating a key list for an association, the lifetime -of each key is set to expire one poll interval later than it is -scheduled to be used. The maximum lifetime of any key in the list is -specified by the autokey command. Lifetime enforcement is a -backup to the normal procedure that revokes the last-used key at the -time the next key on the key list is used. - -

Authentication Commands

+chances are small that this might happen. If it happens during generation, +the generator terminates the current session key list. By the time the +next list is generated, the collided key will probably have been expired +or revoked. + +

While permanent keys have lifetimes that expire only when manually revoked, +random session keys have a lifetime specified at the time of generation. +When generating a key list for an association, the lifetime of each key +is set to expire one poll interval later than it is scheduled to be used. +The maximum lifetime of any key in the list is specified by the autokey +command. Lifetime enforcement is a backup to the normal procedure that +revokes the last-used key at the time the next key on the key list is used. +

+Authentication Commands

- -
keys keyfile
-
Specifies the file name containing the encryption keys and key -identifiers used by ntpd, ntpq and ntpdc when -operating in authenticated mode. The format of this file is described -later in this document.
- -
trustedkey key [...]
-
Specifies the encryption key identifiers which are trusted for the -purposes of authenticating peers suitable for synchronization, as well -as keys used by the ntpq and ntpdc programs. The -authentication procedures require that both the local and remote servers -share the same key and key identifier for this purpose, although -different keys can be used with different servers. The -key arguments are 32-bit unsigned integers with values -less than 65,536. Note that NTP key 0 is used to indicate an invalid key -and/or key identifier, so should not be used for any other purpose.
- -
requestkey key
-
Specifies the key identifier to use with the ntpdc program, -which uses a proprietary protocol specific to this implementation of -ntpd. This program is useful to diagnose and repair problems -that affect ntpd operation. The key argument to -this command is a 32-bit key identifier for a previously defined trusted -key. If no requestkey command is included in the configuration -file, or if the keys don't match, any request to change a server -variable with be denied.
- -
controlkey key
-
Specifies the key identifier to use with the ntpq program, -which uses the standard protocol defined in RFC-1305. This program is -useful to diagnose and repair problems that affect ntpd +
+keys keyfile
+ +
+Specifies the file name containing the encryption keys and key identifiers +used by ntpd, ntpq and ntpdc when operating +in authenticated mode. The format of this file is described later in this +document.
+ +
+ 
+ +
+trustedkey key [...]
+ +
+Specifies the encryption key identifiers which are trusted for the purposes +of authenticating peers suitable for synchronization, as well as keys used +by the ntpq and ntpdc programs. The authentication procedures +require that both the local and remote servers share the same key and key +identifier for this purpose, although different keys can be used with different +servers. The key arguments are 32-bit unsigned integers +with values less than 65,536. Note that NTP key 0 is used to indicate an +invalid key and/or key identifier, so should not be used for any other +purpose.
+ +
+ 
+ +
+requestkey key
+ +
+Specifies the key identifier to use with the ntpdc program, which +uses a proprietary protocol specific to this implementation of ntpd. +This program is useful to diagnose and repair problems that affect ntpd operation. The key argument to this command is a 32-bit -key identifier for a trusted key in the key cache. If no controlkey +key identifier for a previously defined trusted key.  If no requestkey command is included in the configuration file, or if the keys don't match, any request to change a server variable with be denied.
-
+
+ 
-

Authentication Key File Format

+
+controlkey key
+
+Specifies the key identifier to use with the ntpq program, which +uses the standard protocol defined in RFC-1305. This program is useful +to diagnose and repair problems that affect ntpd operation. The +key argument to this command is a 32-bit key identifier +for a trusted key in the key cache. If no controlkey command is +included in the configuration file, or if the keys don't match, any request +to change a server variable with be denied.
+ + +

+Authentication Key File Format

In the case of DES, the keys are 56 bits long with, depending on type, a parity check on each byte. In the case of MD5, the keys are 64 bits (8 -bytes). ntpd reads its keys from a file specified using the --k command line option or the keys statement in the -configuration file. While key number 0 is fixed by the NTP standard (as -56 zero bits) and may not be changed, one or more of the keys numbered 1 -through 15 may be arbitrarily set in the keys file. +bytes). ntpd reads its keys from a file specified using the -k +command line option or the keys statement in the configuration +file. While key number 0 is fixed by the NTP standard (as 56 zero bits) +and may not be changed, one or more of the keys numbered 1 through 15 may +be arbitrarily set in the keys file.

The key file uses the same comment conventions as the configuration file. Key entries use a fixed format of the form

keyno type key -

where keyno is a positive integer, -type is a single character which defines the key format, -and key is the key itself. +

where keyno is a positive integer, type +is a single character which defines the key format, and key +is the key itself.

The key may be given in one of three different formats, controlled by -the type character. The three key types, and -corresponding formats, are listed following. - +the type character. The three key types, and corresponding +formats, are listed following.

- -
S
-
The key is a 64-bit hexadecimal number in the format specified in -the DES specification; that is, the high order seven bits of each octet -are used to form the 56-bit key while the low order bit of each octet is -given a value such that odd parity is maintained for the octet. Leading -zeroes must be specified (i.e., the key must be exactly 16 hex digits -long) and odd parity must be maintained. Hence a zero key, in standard -format, would be given as 0101010101010101.
- -
N
-
The key is a 64-bit hexadecimal number in the format specified in -the NTP standard. This is the same as the DES format, except the bits in -each octet have been rotated one bit right so that the parity bit is now -the high order bit of the octet. Leading zeroes must be specified and -odd parity must be maintained. A zero key in NTP format would be -specified as 8080808080808080.
- -
A
-
The key is a 1-to-8 character ASCII string. A key is formed from -this by using the low order 7 bits of each ASCII character in the -string, with zeroes added on the right when necessary to form a full -width 56-bit key, in the same way that encryption keys are formed from -Unix passwords.
- -
M
-
The key is a 1-to-8 character ASCII string, using the MD5 -authentication scheme. Note that both the keys and the authentication -schemes (DES or MD5) must be identical between a set of peers sharing -the same key number.
- +
+S
+ +
+The key is a 64-bit hexadecimal number in the format specified in the DES +specification; that is, the high order seven bits of each octet are used +to form the 56-bit key while the low order bit of each octet is given a +value such that odd parity is maintained for the octet. Leading zeroes +must be specified (i.e., the key must be exactly 16 hex digits long) and +odd parity must be maintained. Hence a zero key, in standard format, would +be given as 0101010101010101.
+ +
+ 
+ +
+N
+ +
+The key is a 64-bit hexadecimal number in the format specified in the NTP +standard. This is the same as the DES format, except the bits in each octet +have been rotated one bit right so that the parity bit is now the high +order bit of the octet. Leading zeroes must be specified and odd parity +must be maintained. A zero key in NTP format would be specified as 8080808080808080.
+ +
+ 
+ +
+A
+ +
+The key is a 1-to-8 character ASCII string. A key is formed from this by +using the low order 7 bits of each ASCII character in the string, with +zeroes added on the right when necessary to form a full width 56-bit key, +in the same way that encryption keys are formed from Unix passwords.
+ +
+ 
+ +
+M
+ +
+The key is a 1-to-8 character ASCII string, using the MD5 authentication +scheme. Note that both the keys and the authentication schemes (DES or +MD5) must be identical between a set of peers sharing the same key number.
- Note that the keys used by the ntpq and ntpdc programs are checked against passwords requested by the programs and entered by -hand, so it is generally appropriate to specify these keys in ASCII -format. +hand, so it is generally appropriate to specify these keys in ASCII format.  +
+
+David L. Mills (mills@udel.edu)
-
David L. Mills <mills@udel.edu> -
+ + diff --git a/html/biblio.htm b/html/biblio.htm index 799e343332..3396481beb 100644 --- a/html/biblio.htm +++ b/html/biblio.htm @@ -33,7 +33,7 @@ included in this document.

Note that network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP -community, see the David L. +community, see the David L. Mills web page.

The NTP architecture, protocol and algorithm models are described in @@ -43,9 +43,9 @@ Mills web page.

  • Mills, D.L. Internet time synchronization: the Network Time Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-1493. +HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf> PDF. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and Time in Distributed Systems. IEEE Computer Society Press, Los Alamitos, CA, 1994, 91-102. @@ -68,17 +68,17 @@ implementation defined in
  • Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: -PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps> +PostScript) | PDF, Body: -PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps> +PostScript) | PDF, Appendices: +HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf> PDF. @@ -92,160 +92,168 @@ issued include:
      -
    1. Support for precision-time kernel modifications, as described -in +

    2. Support for precision-time kernel modifications, as described +in
      3. -

      Mills, D.L. Unix kernel modifications for precision time +

      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: +HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf> PDF, Body: +HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf> PDF. Major revision and update of: Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. ASCII +HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII -

    3. Support for IP Multicasting, as described in +

    4. Support for IP Multicasting, as described in

      5. Mills, D.L, and A. Thyagarajan. Network time protocol version 4 proposed changes. Electrical Engineering Department Report 94-10-2, University of Delaware, October 1994, 32 pp. Abstract: +HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf> PDF, Body: +HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf> PDF -

    5. A new hybrid phase/frequency-lock clock discipline, which -replaces the RFC-1305 local clock algorithm, as described in +

    6. A new hybrid phase/frequency-lock clock discipline, which +replaces the RFC-1305 local clock algorithm, as described in

      7. Mills, D.L. Clock discipline algorithms for the Network Time Protocol Version 4. Electrical Engineering Report 97-3-3, University of Delaware, March 1997, 35 pp. Abstract: +HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps> PostScript | +HREF= +http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf> PDF, Body: +HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps> PostScript | +HREF= +http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf> PDF

      Mills, D.L. Improved algorithms for synchronizing computer network clocks. IEEE/ACM Trans. Networks 3, 3 (June 1995), 245-254. +HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf> PDF -

    7. Engineered refinements to radio clock drivers and interface code, -as described in: +

    8. Engineered refinements to radio clock drivers and interface code, +as describedin:

      9. Mills, D.L. Precision synchronization of computer network clocks. ACM Computer Communication Review 24, 2 (April 1994). 28-43. +HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf> PDF -

    9. Support for over two dozen reference clock drivers for all known +

    10. Support for over two dozen reference clock drivers for all known national and international radio, satellite and modem standard time services known at this time. See the Reference -Clock Drivers page. +Clock Drivers page.
      11. -
    11. A new security model and authentication scheme based on public- -key cryptography called autokey, as described in +

    12. A new security model and authentication scheme based on public- +key cryptography called autokey, as described in

      13. Mills, D.L., T.S. Glassey, and M.E. McNeil. Coexistence and interoperability of NTP authentication schemes. Internet Draft draft-mills-ntp-auth-coexist-00.txt, University of Delaware and Coastek InfoSys, Inc., November 1997, 8 pp. ASCII +HREF=http://www.eecis.udel.edu/~mills/memos/draft.txt>ASCII

      Mills, D.L. Authentication scheme for distributed, ubiquitous, real- time protocols. Proc. Advanced Telecommunications/Information Distribution Research Program (ATIRP) Conference (College Park MD, January 1997), 293-298. +HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps> PostScript | +HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf> PDF

      Mills, D.L. Proposed authentication enhancements for the Network Time Protocol version 4. Electrical Engineering Report 96-10-3, University of Delaware, October 1996, 36 pp. Abstract: +HREF= +http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps> PostScript | +HREF= +http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf> PDF, Body: +HREF= +http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps> PostScript | +HREF= +http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf> PDF -

    13. Support for the MD5 cryptographic hash algorithm, in addition to +

    14. Support for the MD5 cryptographic hash algorithm, in addition to the DES-CBC algorithm described in RFC-1305, as described in the ntpd - Network Time Protocol (NTP) daemon page.
      15. -
    15. The prefer-peer scheme, as described in the
    16. The prefer-peer scheme, as described in the Mitigation Rules and the prefer Keyword page.
      17. -
    17. Specification for the Simple Network Time Protocol (SNTP), as -described in +

    18. Specification for the Simple Network Time Protocol (SNTP), as +described in

      19. Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4, IPv6 and OSI. Network Working Group Report RFC-2030, University of Delaware, October 1996, 18 pp. +HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt> ASCII. Obsoletes RFC-1769 and RFC-1361. -

    19. Performance surveys for NTP Version 4 can be found in +

    20. Performance surveys for NTP Version 4 can be found in
      21. -

      Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet +

    21. Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet timekeeping around the globe. Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Long Beach CA, December 1997), 365-371. Paper: +href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps> PostScript | +href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf> PDF, Slides: +href= +http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm> HTML | +href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps> PostScript | +href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt> PowerPoint | -PDF +href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf> +PDF
      22. -
    22. Mills, D.L. The network computer as precision timekeeper. +

    23. Mills, D.L. The network computer as precision timekeeper. Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting (Reston VA, December 1996), 96-108. Paper: +href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps> PostScript | +href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf> PDF, Slides: +href= +http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm> HTML | +href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps> PostScript | +href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt> PowerPoint | -PDF +href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf> +PDF
    David L. Mills <mills@udel.edu> -
    +href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu> + diff --git a/html/build.htm b/html/build.htm index 859b2c12c4..c321bf35a8 100644 --- a/html/build.htm +++ b/html/build.htm @@ -11,26 +11,38 @@ Building and Installing the Distribution

    Building and Installing the Distribution

    -Note that the automatic build process inspects the machine environment -and tests for the presence of system header files and the contents of -these files to determine if certain features are available. When one or -more of these features are present, the code is compiled to use them; if -not, no special code is compiled. However, even if the code is compiled -to use these features, the code does a special test at run time to see -if one or more are actually present and avoids using them if not -present. In such cases a warning message is sent to the system log, but -the daemon should still work properly. - -

    Support for Cryptographic Authentication

    - -As required by the International Trade in Arms Regulations (ITAR), now -called the Defense Trade Regulations (DTR), certain cryptographic -products and media, including the Data Encryption Standard (DES), cannot -be exported without per-instance license. For this reason, the DES -encryption routine has been removed from the the current version, even -though it is used only to compute a message digest. Current DTR -regulations allow export of the the MD5 message digest routine, which is -in fact the preferred algorithm, and this is included in the current +As a practical matter, every computer architecture and operating system +version seems to be different than any other. The device drivers may be +different, the input/output system may bew idiosyncratic and the +libraries may have different semantics. It is not possible in a software +distribution such as this one to support every individual sysdtem with a +common set of binaries, even with the same system but different +versions. Therefore, it is necessary to configure each system +individually for each system and version, both at compile time and at +run time. In almost all cases, these procedures are completely automatic +and all the newbie user need do is type "make" and the autoconfigure +system does the rest. There are some exceptions, as noted below. + +

    The autoconfigure system inspects the hardware and software +environment and tests for the presence of system header files and the +contents of these files to determine if certain features are available. +When one or more of these features are present, the code is compiled to +use them; if not, no special code is compiled. However, even if the code +is compiled to use these features, the code does a special test at run +time to see if one or more are actually present and avoids using them if +not present. In such cases a warning message is sent to the system log, +but the daemon should still work properly. + +Some programs included in this distribution use cryptographic algorithms +to verify server authenticity and credentials. As required by the +International Trade in Arms Regulations (ITAR), now called the Defense +Trade Regulations (DTR), certain cryptographic products and media, +including the Data Encryption Standard (DES), cannot be exported without +per-instance license. For this reason, the DES encryption routine has +been removed from the the current version, even though it is used only +to compute a message digest. Current DTR regulations allow export of the +the MD5 message digest routine, which is in fact the preferred +algorithm, and this is included in the current version.

    The NTP authentication routines conform to the interface used by RSA @@ -118,8 +130,10 @@ useful to debug kernel time functions) is installed. to create a NTP configuration file ntp.conf and possibly a cryptographic key file ntp.keys. Directions for doing that are in the Notes on Configuring NTP and Setting up a NTP -Subnet. A tutorial on debugging technique is in NTP Debugging Technique. +Subnet. The behavior when the daemon starts for the first time can +be counterintuitive. To reduce the level of angst, see the Quick Start page. A tutorial on debugging technique +is in NTP Debugging Technique.

    If problems peculiar to the particular hardware and software environment (e.g. operating system -specific issues) are suspected, diff --git a/html/clockopt.htm b/html/clockopt.htm index cf4546d921..7c12a21fea 100644 --- a/html/clockopt.htm +++ b/html/clockopt.htm @@ -1,163 +1,236 @@ - -Reference Clock Options -

    -Reference Clock Options -

    - -

    Reference Clock Support

    - -The NTP Version 4 daemon supports many different radio, satellite and -modem reference clocks plus a special pseudo-clock used for backup or -when no other clock source is available. Detailed descriptions of -individual device drivers and options can be found in the Reference Clock Drivers page. Additional -information can be found in the pages referenced there, including the Debugging Hints for Reference Clock Drivers and How To Write a Reference Clock Driver pages. In -many drivers, support for a PPS signal is available as described in Pulse-per-second (PPS) Signal Interfacing page. Many -drivers support special line discipline/streams modules which can -significantly improve the accuracy using the driver. These are described -in the Line Disciplines and Streams Drivers -page. - -

    A reference clock will generally (though not always) be a radio -timecode receiver which is synchronized to a source of standard time -such as the services offered by the NRC in Canada and NIST and USNO in -the U.S. The interface between the computer and the timecode receiver is -device dependent, but is usually a serial port. A device driver specific -to each reference clock must be selected and compiled in the -distribution; however, most common radio, satellite and modem clocks are -included by default. Note that an attempt to configure a reference clock -when the driver has not been included or the hardware port has not been -appropriately configured results in a scalding remark to the system log -file, but is otherwise non hazardous. - -

    For the purposes of configuration, ntpd treats reference -clocks in a manner analogous to normal NTP peers as much as possible. -Reference clocks are identified by a syntactically correct but invalid -IP address, in order to distinguish them from normal NTP peers. -Reference clock addresses are of the form 127.127.t.u, -where t is an integer denoting the clock type and -u indicates the unit number. While it may seem overkill, -it is in fact sometimes useful to configure multiple reference clocks of -the same type, in which case the unit numbers must be unique. + + + + + Reference Clock Options + + + + +

    +Reference Clock Options

    + +
    +

    +Reference Clock Support

    +The NTP Version 4 daemon supports many different radio, satellite and modem +reference clocks plus a special pseudo-clock used for backup or when no +other clock source is available. Detailed descriptions of individual device +drivers and options can be found in the Reference +Clock Drivers page. Additional information can be found in the pages +referenced there, including the Debugging Hints for +Reference Clock Drivers and How To Write a Reference +Clock Driver pages. In many drivers, support for a PPS signal is available +as described in Pulse-per-second (PPS) Signal Interfacing +page. Many drivers support special line discipline/streams modules which +can significantly improve the accuracy using the driver. These are described +in the Line Disciplines and Streams Drivers page. + +

    A reference clock will generally (though not always) be a radio timecode +receiver which is synchronized to a source of standard time such as the +services offered by the NRC in Canada and NIST and USNO in the U.S. The +interface between the computer and the timecode receiver is device dependent, +but is usually a serial port. A device driver specific to each reference +clock must be selected and compiled in the distribution; however, most +common radio, satellite and modem clocks are included by default. Note +that an attempt to configure a reference clock when the driver has not +been included or the hardware port has not been appropriately configured +results in a scalding remark to the system log file, but is otherwise non +hazardous. + +

    For the purposes of configuration, ntpd treats reference clocks +in a manner analogous to normal NTP peers as much as possible. Reference +clocks are identified by a syntactically correct but invalid IP address, +in order to distinguish them from normal NTP peers. Reference clock addresses +are of the form 127.127.t.u, where t is +an integer denoting the clock type and u indicates the +unit number. While it may seem overkill, it is in fact sometimes useful +to configure multiple reference clocks of the same type, in which case +the unit numbers  must be unique.

    The server command is used to configure a reference clock, where the address argument in that command is the clock address. The key, version and ttl options are not used for reference clock support. The mode option is added -for reference clock support, as described below. The prefer -option can be useful to persuade the server to cherish a reference clock -with somewhat more enthusiasm than other reference clocks or peers. -Further information on this option can be found in the Mitigation Rules and the prefer Keyword -page. The minpoll and maxpoll options have meaning -only for selected clock drivers. See the individual clock driver -document pages for additional information. +for reference clock support, as described below. The prefer option +can be useful to persuade the server to cherish a reference clock with +somewhat more enthusiasm than other reference clocks or peers. Further +information on this option can be found in the Mitigation +Rules and the prefer Keyword page. The minpoll and +maxpoll options have meaning only for selected clock drivers. +See the individual clock driver document pages for additional information.

    The stratum number of a reference clock is by default zero. Since the -ntpd daemon adds one to the stratum of each peer, a primary -server ordinarily displays stratum one. In order to provide engineered -backups, it is often useful to specify the reference clock stratum as -greater than zero. The stratum option is used for this purpose. -Also, in cases involving both a reference clock and a pulse-per-second -(PPS) discipline signal, it is useful to specify the reference clock -identifier as other than the default, depending on the driver. The -refid option is used for this purpose. Except where noted, -these options apply to all clock drivers. - -

    Reference Clock Commands

    +ntpd daemon adds one to the stratum of each peer, a primary server +ordinarily displays stratum one. In order to provide engineered backups, +it is often useful to specify the reference clock stratum as greater than +zero. The stratum option is used for this purpose. Also, in cases +involving both a reference clock and a pulse-per-second (PPS) discipline +signal, it is useful to specify the reference clock identifier as other +than the default, depending on the driver. The refid option is +used for this purpose. Except where noted, these options apply to all clock +drivers. +

    +Reference Clock Commands

    +
    +server 127.127.t.u [prefer] [mode int] [minpoll int] +[maxpoll int]
    -
    server 127.127.t.u [prefer] [mode int] [minpoll -int] [maxpoll int]
    -
    This command can be used to configure reference clocks in special -ways. The options are interpreted as follows:
    - -
    prefer
    -
    Marks the reference clock as preferred. All other things being -equal, this host will be chosen for synchronization among a set of -correctly operating hosts. See the Mitigation Rules -and the prefer Keyword page for further information.
    - -
    mode int
    -
    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 parse drivers.
    - -
    minpoll int
    -
    maxpoll int
    -
    These options specify the minimum and maximum polling interval for -referenceclock messages, in seconds to the power of two. For most -directly connected reference clocks, both minpoll and -maxpoll default to 6 (64 s). For modem reference clocks, -minpoll defaults to 10 (17.1 m) and maxpoll defaults -to 14 (4.5 h). The allowable range is 4 (16 s) to 17 (36.4 h) -inclusive.
    - -
    fudge 127.127.t.u [time1 sec] [time2 sec] -[stratum int] [refid string] [mode int] [flag1 0|1] -[flag2 0|1] [flag3 0|1] [flag4 0|1]
    -
    This command can be used to configure reference clocks in special -ways. It must immediately follow the server command which -configures the driver. Note that the same capability is possible at run -time using the ntpdc program. The -options are interpreted as follows:
    - -
    time1 sec
    -
    Specifies a constant to be added to the time offset produced by the -driver, a fixed-point decimal number in seconds. This is used as a -calibration constant to adjust the nominal time offset of a particular -clock to agree with an external standard, such as a precision PPS -signal. It also provides a way to correct a systematic error or bias due -to serial port latencies, different cable lengths or receiver internal -delay. The specified offset is in addition to the propagation delay -provided by other means, such as internal DIP switches. Where a -calibration for an individual system and driver is available, an -approximate correction is noted in the driver documentation pages.
    - -
    time2 secs
    -
    Specifies a fixed-point decimal number in seconds, which is -interpreted in a driver-dependent way. See the descriptions of specific -drivers in the reference clock drivers -page.
    - -
    stratum int
    -
    Specifies the stratum number assigned to the driver, an integer -between 0 and 15. This number overrides the default stratum number -ordinarily assigned by the driver itself, usually zero.
    - -
    refid string
    -
    Specifies an ASCII string of from one to four characters which -defines the reference identifier used by the driver. This string -overrides the default identifier ordinarily assigned by the driver -itself.
    - -
    mode int
    -
    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 parse drivers.
    - -
    flag1 flag2 flag3 flag4
    -
    These four flags are used for customizing the clock driver. The -interpretation of these values, and whether they are used at all, is a -function of the particular clock driver. However, by convention -flag4 is used to enable recording verbose monitoring data to -the clockstats file configured with the filegen -command. Further information on the filegen command can be -found in the Monitoring Options page.
    - -
    pps device
    -
    Specifies the name of the serial port device to which the PPS signal -is connected. Note, this command replaces use of fudge flag3, -which was used for the same purpose in NTPv3. Note also that this -command should preceed the server and fudge command -for the same device.
    +
    +This command can be used to configure reference clocks in special ways. +The options are interpreted as follows:
    +
    + 
    + +
    +
    +prefer
    + +
    +Marks the reference clock as preferred. All other things being equal, this +host will be chosen for synchronization among a set of correctly operating +hosts. See the Mitigation Rules and the prefer +Keyword page for further information.
    + +
    + 
    + +
    +mode int
    + +
    +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 parse drivers.
    + +
    + 
    + +
    +minpoll int
    + +
    +maxpoll int
    + +
    +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 minpoll and maxpoll default to +6 (64 s). For modem reference clocks, minpoll defaults to 10 (17.1 +m) and maxpoll defaults to 14 (4.5 h). The allowable range is +4 (16 s) to 17 (36.4 h) inclusive.
    +
    +  +
    +fudge 127.127.t.u [time1 sec] [time2 sec] [stratum +int] [refid string] [mode int] [flag1 0|1] [flag2 +0|1] [flag3 0|1] [flag4 0|1]
    + +
    +This command can be used to configure reference clocks in special ways. +It must immediately follow the server command which configures +the driver. Note that the same capability is possible at run time using +the ntpdc program. The options are interpreted +as follows:
    + +
    + 
    + +
    +
    +time1 sec
    + +
    +Specifies a constant to be added to the time offset produced by the driver, +a fixed-point decimal number in seconds. This is used as a calibration +constant to adjust the nominal time offset of a particular clock to agree +with an external standard, such as a precision PPS signal. It also provides +a way to correct a systematic error or bias due to serial port latencies, +different cable lengths or receiver internal delay. The specified offset +is in addition to the propagation delay provided by other means, such as +internal DIPswitches. Where a calibration for an individual system and +driver is available, an approximate correction is noted in the driver documentation +pages.
    + +
    + 
    + +
    +time2 secs
    + +
    +Specifies a fixed-point decimal number in seconds, which is interpreted +in a driver-dependent way. See the descriptions of specific drivers in +the reference clock drivers page.
    + +
    + 
    + +
    +stratum int
    + +
    +Specifies the stratum number assigned to the driver, an integer between +0 and 15. This number overrides the default stratum number ordinarily assigned +by the driver itself, usually zero.
    + +
    + 
    + +
    +refid string
    + +
    +Specifies an ASCII string of from one to four characters which defines +the reference identifier used by the driver. This string overrides the +default identifier ordinarily assigned by the driver itself.
    + +
    + 
    + +
    +mode int
    + +
    +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 parse drivers.
    + +
    + 
    + +
    +flag1 flag2 flag3 flag4
    + +
    +These four flags are used for customizing the clock driver. The interpretation +of these values, and whether they are used at all, is a function of the +particular clock driver. However, by convention flag4 is used +to enable recording verbose monitoring data to the clockstats +file configured with the filegen command. Further information +on the filegen command can be found in the Monitoring +Options page.
    + +
    + 
    -
    David L. Mills <mills@udel.edu> -
    +
    +pps device
    + +
    +Specifies the name of the serial port device to which the PPS signal is +connected. Note, this command replaces use of fudge flag3, which +was used for the same purpose in NTPv3. Note also that this command should +preceed the server and fudge command for the same device.
    +
    + +
    +
    +David L. Mills (mills@udel.edu)
    + + + diff --git a/html/config.htm b/html/config.htm index 46737e9dfa..f8606f2fc8 100644 --- a/html/config.htm +++ b/html/config.htm @@ -22,110 +22,270 @@ options:

    Usage: configure [options] [host]
    Options: [defaults in brackets after descriptions] -

    -Configuration
-  --cache-file=FILE       cache test results in FILE
-  --help                  print this message
-  --no-create             do not create output files
-  --quiet, --silent       do not print `checking...' messages
-  --version               print the version of autoconf that created configure
-Directory and file names:
-  --prefix=PREFIX         install architecture-independent files in PREFIX
-                          [/usr/local]
-  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
-                          [same as prefix]
-  --bindir=DIR            user executables in DIR [EPREFIX/bin]
-  --sbindir=DIR           system admin executables in DIR [EPREFIX/sbin]
-  --libexecdir=DIR        program executables in DIR [EPREFIX/libexec]
-  --datadir=DIR           read-only architecture-independent data in DIR
-                          [PREFIX/share]
-  --sysconfdir=DIR        read-only single-machine data in DIR [PREFIX/etc]
-  --sharedstatedir=DIR    modifiable architecture-independent data in DIR
-                          [PREFIX/com]
-  --localstatedir=DIR     modifiable single-machine data in DIR [PREFIX/var]
-  --libdir=DIR            object code libraries in DIR [EPREFIX/lib]
-  --includedir=DIR        C header files in DIR [PREFIX/include]
-  --oldincludedir=DIR     C header files for non-gcc in DIR [/usr/include]
-  --infodir=DIR           info documentation in DIR [PREFIX/info]
-  --mandir=DIR            man documentation in DIR [PREFIX/man]
-  --srcdir=DIR            find the sources in DIR [configure dir or ..]
-  --program-prefix=PREFIX prepend PREFIX to installed program names
-  --program-suffix=SUFFIX append SUFFIX to installed program names
-  --program-transform-name=PROGRAM
-                          run sed PROGRAM on installed program names
-Host type:
-  --build=BUILD           configure for building on BUILD [BUILD=HOST]
-  --host=HOST             configure for HOST [guessed]
-  --target=TARGET         configure for TARGET [TARGET=HOST]
-Features and packages:
-  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
-  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
-  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
-  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
-  --x-includes=DIR        X include files are in DIR
-  --x-libraries=DIR       X library files are in DIR
---enable and --with options recognized:
-  --enable-debugging      + include debugging code
-  --enable-dst-minutes=60 + minutes per DST adjustment
-  --enable-md5            + include support for MD5 keys
-  --enable-des            s include support for DES keys
-  --enable-BANCOMM        - Datum/Bancomm bc635/VME interface
-  --enable-GPSVME         - TrueTime GPS receiver/VME interface
-  --enable-SHM            - SHM clock attached thru shared memory
-  --enable-ONCORE         + Motorola VP/UT Oncore GPS receiver
-  --enable-all-clocks     + include all suitable non-PARSE clocks:
-  --enable-ACTS           + ACTS modem service
-  --enable-ARBITER        + Arbiter 1088A/B GPS receiver
-  --enable-ARCRON-MSF     + Arcron MSF receiver
-  --enable-AS2201         + Austron 2200A/2201A GPS receiver
-  --enable-ATOM           + PPS interface
-  --enable-CHU            + CHU modem/decoder
-  --enable-AUDIO-CHU      s - CHU audio/decoder
-  --enable-DATUM          s Datum Programmable Time System
-  --enable-HEATH          s Heath GC-1000 WWV/WWVH receiver
-  --enable-HPGPS          + HP 58503A GPS receiver
-  --enable-IRIG           s Sun IRIG audio decoder
-  --enable-LEITCH         + Leitch CSD 5300 Master Clock System Driver
-  --enable-LOCAL-CLOCK    + local clock reference
-  --enable-MSFEES         + EES M201 MSF receiver
-  --enable-MX4200         s Magnavox MX4200 GPS receiver
-  --enable-NMEA           + NMEA GPS receiver
-  --enable-PALISADE       + Palisade clock
-  --enable-PST            + PST/Traconex 1020 WWV/WWVH receiver
-  --enable-JUPITER        s Rockwell Jupiter GPS receiver
-  --enable-PTBACTS        s PTB modem service
-  --enable-TPRO           s KSI/Odetics TPRO/S GPS receiver/IRIG interface
-  --enable-TRAK           + TRAK 8810 GPS receiver
-  --enable-CHRONOLOG      + Chrono-log K-series WWVB receiver
-  --enable-DUMBCLOCK      + Dumb generic hh:mm:ss local clock
-  --enable-TRUETIME       s Kinemetrics/TrueTime receivers
-  --enable-WWVB           + Spectracom 8170/Netclock/2 WWVB receiver
-  --enable-USNO           s USNO modem service
-  --enable-parse-clocks   - include all suitable PARSE clocks:
-  --enable-COMPUTIME      s Diem Computime Radio Clock
-  --enable-DCF7000        s ELV/DCF7000 clock
-  --enable-HOPF6021       s HOPF 6021 clock
-  --enable-MEINBERG       s Meinberg clocks
-  --enable-RAWDCF         s DCF77 raw time code
-  --enable-RCC8000        s RCC 8000 clock
-  --enable-SCHMID         s Schmid DCF77 clock
-  --enable-TRIMTAIP       s Trimble GPS receiver/TAIP protocol
-  --enable-TRIMTSIP       s Trimble GPS receiver/TSIP protocol
-  --enable-WHARTON        s WHARTON 400A Series clock
-  --enable-kmem           s read /dev/kmem for tick and/or tickadj
-  --enable-accurate-adjtime
-                          s the adjtime() call is accurate
-  --enable-tick=VALUE     s force a value for 'tick'
-  --enable-tickadj=VALUE  s force a value for 'tickadj'
-  --enable-udp-wildcard   s use UDP wildcard delivery
-  --enable-slew-always    s always slew the time
-  --enable-step-slew      s step and slew the time
-  --enable-ntpdate-step   s if ntpdate should step the time
-  --enable-hourly-todr-sync
-                          s if we should sync TODR hourly
-  --enable-kernel-fll-bug s if we should avoid a kernel FLL bug
-
    +
    Configuration
+
+  --cache-file=FILE      cache test
+results in FILE
+  --
+help           &n
+bsp;     print this message
+  --no-
+create           
+do not create output files
+  --quiet, --silent      do not print
+`checking...' messages
+  --
+version           
+;   print the version of autoconf that created
+            
+            
+configure
+Directory and file names
+
+  --prefix=PREFIX        install
+architecture-independent files in
+            
+            
+PREFIX [/usr/local]
+  --exec-prefix=EPREFIX  install architecture-dependent files
+in EPREFIX
+            
+            
+[same as prefix]
+  --
+bindir=DIR          
+user executables in DIR [EPREFIX/bin]
+  --
+sbindir=DIR          system
+admin executables in DIR [EPREFIX/sbin]
+  --libexecdir=DIR       program
+executables in DIR [EPREFIX/libexec]
+  --
+datadir=DIR          read-
+only architecture-independent data in DIR
+            
+            
+[PREFIX/share]
+  --sysconfdir=DIR       read-only
+single-machine data in DIR
+            
+            
+[PREFIX/etc]
+  --sharedstatedir=DIR   modifiable architecture-
+independent data in DIR
+            
+            
+[PREFIX/com]
+  --localstatedir=DIR    modifiable single-machine
+data in DIR
+            
+            
+[PREFIX/var]
+  --
+libdir=DIR          
+object code libraries in DIR [EPREFIX/lib]
+  --includedir=DIR       C header
+files in DIR [PREFIX/include]
+  --oldincludedir=DIR    C header files for non-gcc
+in DIR
+            
+            
+[/usr/include]
+  --
+infodir=DIR          info
+documentation in DIR [PREFIX/info]
+  --
+mandir=DIR          
+man documentation in DIR [PREFIX/man]
+  --
+srcdir=DIR          
+find the sources in DIR [configure dir or ..]
+  --program-prefix=PREFIX prepend PREFIX to installed program names
+  --program-suffix=SUFFIX append SUFFIX to installed program names
+  --program-transform-name=PROGRAM run sed PROGRAM on installed
+program
+            
+            
+names
+Host type
+
+  --
+build=BUILD         
+configure for building on BUILD [BUILD=HOST]
+  --
+host=HOST          &nb
+sp; configure for HOST [guessed]
+  --target=TARGET       
+configure for TARGET [TARGET=HOST]
    + +
    Features and packages
+
+  --disable-FEATURE      do not include
+FEATURE (same as --enable-
+            
+            
+FEATURE=no)
+  --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+  --with-PACKAGE[=ARG]   use PACKAGE [ARG=yes]
+  --without-PACKAGE      do not use
+PACKAGE (same as --with-PACKAGE=no)
+  --x-includes=DIR       X include
+files are in DIR
+  --x-libraries=DIR      X library files
+are in DIR
+
+--enable- and --disable- with options recognized
+
+    
+debugging          
+Include debugging code [enable]
+     gdt-
+surveying       Include GDT survey code
+[disable]
+    
+md5           &nb
+sp;     Include support for MD5 keys [enable]
+    
+des           &nb
+sp;     Include support for DES keys [enable]
+     all-
+clocks          Include
+drivers for all reference clocks
+            
+            
+[enable]
+
+  Radio Clocks (these are ordinarily enabled, if supported by the
+            
+            
+machine and operating system)
+
+    
+ACTS           &n
+bsp;    NIST dialup clock
+    
+ARBITER           
+;  Arbiter 1088A/B GPS receiver
+    
+AS2201           
+   Austron 2200A or 2201A GPS receiver
+    
+ATOM           &n
+bsp;    ATOM clock
+    
+BANCOMM           
+;  BANCOMM clock
+    
+CHU           &nb
+sp;     CHU clock
+    
+DATUM           &
+nbsp;   Datum Programmable Time System
+    
+DCF7000           
+;  ELV/DCF7000
+    
+GPSVME           
+   GPS-VME Clock
+    
+HEATH           &
+nbsp;   HeathKit GC-1000 Most Accurate Clock
+    
+HOPF6021          &nbs
+p; HOPF6021 Radio Clock support
+    
+HPGPS           &
+nbsp;   HP 58503A GPS Time & Frequency receiver
+    
+IRIG           &n
+bsp;    IRIG (Audio) Clock
+    
+LEITCH           
+   Leitch CSD 5300 Master Clock System Driver
+     LOCAL-
+CLOCK         Local Clock driver
+    
+MEINBERG          &nbs
+p; Meinberg clocks
+    
+MSFEES           
+   MSFEES clock
+    
+MOTO           &n
+bsp;    Motorola GPS clock
+    
+MX4200           
+   MX4200 clock
+    
+NMEA           &n
+bsp;    NMEA GPS clock
+    
+PARSE           &
+nbsp;   PARSE clock code
+    
+PST           &nb
+sp;     PST/Traconex 1020 WWV/H receiver
+    
+PTBACTS           
+;  PTB dialup clock support
+    
+RAWDCF           
+   use raw DCF77 time code
+    
+RCC8000           
+;  RCC8000 Radio Clock support
+    
+SCHMID           
+   SCHMID DCF77 clock support
+    
+TRAK           &n
+bsp;    TRAK 8810 GPS station clock
+    
+TPRO           &n
+bsp;    KSI/Odetics TPRO/S IRIG Interface
+    
+TRIMTAIP          &nbs
+p; Trimble GPS/TAIP Protocol
+    
+TRIMTSIP          &nbs
+p; Trimble GPS/TSIP Protocol
+    
+TRUETIME          &nbs
+p; Kinemetrics/TrueTime (generic) receiver
+    
+WWVB           &n
+bsp;    Spectracom 8170 or Netclock/2 WWVB receiver
+    
+USNO           &n
+bsp;    US Naval Observatory dialup clock
+  Miscellany
+
+     accurate-adjtime    The
+adjtime() call is accurate
+    
+kmem           &n
+bsp;    Read kmem
+    
+tick=VALUE          Force a
+value for 'tick'
+    
+tickadj=VALUE       Force a value for
+'tickadj'
+     udp-
+wildcard        Use UDP wildcard
+delivery
+     slew-
+always         Always slew the
+time
+     step-
+slew           Step
+and slew the time
+     ntpdate-
+step        If ntpdate should step
+the time
+     hourly-todr-sync    If we should
+sync TODR hourly
    David L. Mills <mills@udel.edu> -
    +href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu> + diff --git a/html/confopt.htm b/html/confopt.htm index 0b8c65e778..b57bd70274 100644 --- a/html/confopt.htm +++ b/html/confopt.htm @@ -1,8 +1,18 @@ - -Configuration Options -

    -Configuration Options -

    + + + + + + +Configuration Options + + + + +

    Configuration Options

    + +

    Configuration Support

    @@ -16,266 +26,315 @@ address of a local interface, (m) a multicast address (IP class D), or (r) a reference clock address (127.127.x.x). Note that, while autokey and burst modes are supported by these commands, their effect in some weird mode combinations can be meaningless -or even destructive. - -
    - -
    peer address [autokey | key -key] [burst] [version -version] [prefer] [minpoll -minpoll] [maxpoll -maxpoll]
    - -
    server address [autokey | key -key] [burst] [version -version] [prefer] [minpoll -minpoll] [maxpoll -maxpoll]
    - -
    broadcast address [autokey | key -key] [burst] [version -version] [minpoll -minpoll] [maxpoll -maxpoll] [ttl -ttl]
    - -
    manycastclient address [autokey | -keykey] [burst] [version -version] [minpoll minpoll -[maxpoll maxpoll] [ttl -ttl]
    - -
    These four commands specify the time server name or address to be -used and the mode in which to operate. The address -can be either a DNS name or a IP address in dotted-quad notation. -Additional information on association behavior can be found in the Association Management page.
    - -
    +or even destructive.

    - -
    server
    -
    For type s and r addresses, this operates as the NTPv3 server -command, which mobilizes a persistent client mode association. The -server command specifies that the local server is to operate in -client mode with the specified remote server. In this mode, the local -server can be synchronized to the remote server, but the remote server -can never be synchronized to the local server.
    - -
    peer
    -
    For type s addresses (only), this operates as the current peer -command, which mobilizes a persistent symmetric-active mode -association, except that additional modes are available. This command -should NOT be used for type b, m or r addresses. - -

    The peer command specifies that the local server is to -operate in symmetric active mode with the remote server. In this mode, -the local server can be synchronized to the remote server and, in -addition, the remote server can be synchronized by the local server. -This is useful in a network of servers where, depending on various -failure scenarios, either the local or remote server may be the better -source of time.

    - -
    broadcast
    -
    For type b and m addresses (only), this operates as the current -NTPv3 broadcast command, which mobilizes a persistent broadcast -mode association, except that additional modes are available. Multiple -commands can be used to specify multiple local broadcast interfaces -(subnets) and/or multiple multicast groups. Note that local broadcast -messages go only to the interface associated with the subnet specified, -but multicast messages go to all interfaces. In the current -implementation, the source address used for these messages is the Unix -host default address. - -

    In broadcast mode, the local server sends periodic broadcast -messages to a client population at the address -specified, which is usually the broadcast address on (one of) -the local network(s) or a multicast address assigned to NTP. The IANA -has assigned the multicast group address 224.0.1.1 exclusively to NTP, -but other nonconflicting addresses can be used to contain the messages -within administrative boundaries. Ordinarily, this specification -applies only to the local server operating as a sender; for operation as -a broadcast client, see the broadcastclient or -multicastclient commands below.

    - -
    manycastclient
    -
    For type m addresses (only), this mobilizes a manycast client-mode -association for the multicast address specified. In this case a specific -address must be supplied which matches the address used on the -manycastserver command for the designated manycast servers. The -NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, -unless specific means are taken to avoid spraying large areas of the -Internet with these messages and causing a possibly massive implosion of -replies at the sender.
    - -
    The manycastclient command specifies that the local server is to -operate in client mode with the remote servers that are discovered as the -result of broadcast/multicast messages. The client broadcasts a request -message to the group address associated with the specified -address and specifically enabled servers respond to -these messages. The client selects the servers providing the best time -and continues as with the server command. The remaining servers -are discarded as if never heard.
    - -
    - -
    Options
    - -
    - -
    autokey
    -
    All packets sent to the address are to include authentication fields -encrypted using the autokey scheme.
    - -
    burst
    -
    At each poll interval, send a burst of eight packets spaced, instead -of the usual one.
    - -
    key key
    -
    All packets sent to the address are to include authentication fields -encrypted using the specified key identifier, which is an -unsigned 32-bit integer less than 65536. The default is to include no -encryption field.
    - -
    version version
    -
    Specifies the version number to be used for outgoing NTP packets. -Versions 1-4 are the choices, with version 4 the default.
    - -
    prefer
    -
    Marks the server as preferred. All other things being equal, this -host will be chosen for synchronization among a set of correctly -operating hosts. See the Mitigation Rules and the -prefer Keyword page for further information.
    - -
    ttl ttl
    -
    This option is used only with broadcast mode. It specifies the time- -to-live ttl to use on multicast packets. Selection of -the proper value, which defaults to 127, is something of a black art and -must be coordinated with the network administrator.
    - -
    minpoll minpoll
    -
    maxpoll maxpoll
    -
    These options specify the minimum and maximum polling intervals for -NTP messages, in seconds to the power of two. The default range is 6 (64 -s) to 10 (1,024 s).The allowable range is 4 (16 s) to 17 (36.4 h) -inclusive.
    - -
    - -
    broadcastclient
    -
    This command directs the local server to listen for and respond to -broadcast messages received on any local interface. Upon hearing a -broadcast message for the first time, the local server measures the -nominal network delay using a brief client/server exchange with the -remote server, then enters the broadcastclient mode, in which it listens -for and synchronizes to succeeding broadcast messages. Note that, in -order to avoid accidental or malicious disruption in this mode, both the -local and remote servers should operate using authentication and the -same trusted key and key identifier.
    - -
    multicastclient [address] -[...]
    -
    This command directs the local server to listen for multicast -messages at the group address(es) of the global network. The default -address is that assigned by the Numbers Czar to NTP (224.0.1.1). This -command operates in the same way as the broadcastclient -command, but uses IP multicasting. Support for this command requires a - multicast kernel.
    - -
    driftfile driftfile
    -
    This command specifies the name of the file used to record the -frequency offset of the local clock oscillator. If the file exists, it -is read at startup in order to set the initial frequency offset and then -updated once per hour with the current frequency offset computed by the -daemon. If the file does not exist or this command is not given, the -initial frequency offset is assumed zero. In this case, it may take some -hours for the frequency to stabilize and the residual timing errors to -subside. - -

    The file format consists of a single line containing a single -floating point number, which records the frequency offset measured in -parts-per-million (PPM). The file is updated by first writing the -current drift value into a temporary file and then renaming this file to -replace the old version. This implies that ntpd must have - write permission for the directory the drift file is located in, and -that file system links, symbolic or otherwise, should be avoided.

    - -
    manycastserver address[...]
    -
    This command directs the local server to listen for and respond to -broadcast messages received on any local interface, and in addition -enables the server to respond to client mode messages to the multicast -group address(es) (type m) specified. At least one address is required, -but the NTP multicast address 224.0.1.1 assigned by the IANA should NOT -be used, unless specific means are taken to limit the span of the reply -and avoid a possibly massive implosion at the original sender.
    - -
    revoke [logsec]
    -
    Specifies the interval between recomputations of the private value -used with the autokey feature, which ordinarily requires an expensive -public-key computation. The default value is 12 (65,536 s or about 18 -hours). For poll intervals above the specified interval, a new private -value will be recomputed for every message sent.
    - -
    autokey [logsec]
    -
    Specifies the interval between regenerations of the session key list -used with the autokey feature. Note that the size of the key list for -each association depends on this interval and the current poll interval. -The default value is 12 (4096 s or about 1.1 hours). For poll intervals -above the specified interval, a session key list with a single entry -will be regenerated for every message sent.
    - -
    enable [auth | bclient | kernel | monitor | ntp | -stats]
    -
    disable [auth | bclient | kernel | monitor | ntp | -stats]
    -
    Provides a way to enable or disable various server options. Flags -not mentioned are unaffected. Note that all of these flags can be -controlled remotely using the ntpdc -utility program.
    - -
    - -
    auth
    -
    Enables the server to synchronize with unconfigured peers only if -the peer has been correctly authenticated using a trusted key and -key identifier. The default for this flag is enable.
    - -
    bclient
    -
    When enabled, this is identical to the broadcastclient -command. The default for this flag is disable.
    - -
    kernel
    -
    Enables the precision-time kernel support for the -ntp_adjtime() system call, if implemented. Ordinarily, support -for this routine is detected automatically when the NTP daemon is -compiled, so it is not necessary for the user to worry about this flag. -It flag is provided primarily so that this support can be disabled -during kernel development.
    - -
    monitor
    -
    Enables the monitoring facility. See the ntpdc program and -the monlist command for further information. The default for -this flag is enable.
    - -
    ntp
    -
    Enables the server to adjust its local clock by means of NTP. If -disabled, the local clock free-runs at its intrinsic time and frequency -offset. This flag is useful in case the local clock is controlled by -some other device or protocol and NTP is used only to provide -synchronization to other clients. In this case, the local clock driver -can be used to provide this function and also certain time variables for -error estimates and leap-indicators. See the Reference Clock Drivers page for further -information. The default for this flag is enable.
    - -
    stats
    -
    Enables the statistics facility. See the Monitoring Options page for further information. -The default for this flag is enable.
    - -
    - -
    David L. Mills <mills@udel.edu> -
    +
    peer address [autokey | key key] + [burst] [version version] + [prefer] [minpoll minpoll] + [maxpoll maxpoll]
    +
     
    +
    server address [autokey | + key key] [burst] [version version] + [prefer] [minpoll minpoll] + [maxpoll maxpoll]
    +
     
    +
    broadcast address [autokey | + key key] [burst] [version version] + [minpoll minpoll] [maxpoll + maxpoll] [ttl ttl]
    +
     
    +
    manycastclient address + [autokey | key key] [burst] + [version version] [minpoll minpoll + [maxpoll maxpoll] + [ttl ttl]
    +
     
    +
    These four commands specify the time server name or + address to be used and the mode in which to operate. The address + can be either a DNS name or a IP address in + dotted-quad notation. Additional information on + association behavior can be found in the Association Management page.
    +
     
    +
    +
    server
    +
    For type s and r addresses, this operates as the + NTPv3 server command, which mobilizes a + persistent client mode association. The server + command specifies that the local server is to + operate in client mode with the specified remote + server. In this mode, the local server can be + synchronized to the remote server, but the remote + server can never be synchronized to the local + server.
    +
     
    +
    peer
    +
    For type s addresses (only), this operates as the + current peer command, which mobilizes a + persistent symmetric-active mode association, + except that additional modes are available. This + command should NOT be used for type b, m or r + addresses.
    +
     
    +
    The peer command specifies that the + local server is to operate in symmetric active + mode with the remote server. In this mode, the + local server can be synchronized to the remote + server and, in addition, the remote server can be + synchronized by the local server. This is useful + in a network of servers where, depending on + various failure scenarios, either the local or + remote server may be the better source of time.
    +
     
    +
    broadcast
    +
    For type b and m addresses (only), this is + operates as the current NTPv3 broadcast command, + which mobilizes a persistent broadcast mode + association, except that additional modes are + available. Multiple commands can be used to + specify multiple local broadcast interfaces + (subnets) and/or multiple multicast groups. Note + that local broadcast messages go only to the + interface associated with the subnet specified, + but multicast messages go to all interfaces. In + the current implementation, the source address + used for these messages is the Unix host default + address.
    +
     
    +
    In broadcast mode, the local server sends + periodic broadcast messages to a client + population at the address specified, + which is usually the broadcast address on (one + of) the local network(s) or a multicast address + assigned to NTP. The IANA has assigned the + multicast group address 224.0.1.1 exclusively to + NTP, but other nonconflicting addresses can be + used to contain the messages within + administrative boundaries.. Ordinarily, this + specification applies only to the local server + operating as a sender; for operation as a + broadcast client, see the broadcastclient + or multicastclient commands below.
    +
     
    +
    manycastclient
    +
    For type m addresses (only), this mobilizes a + manycast client-mode association for the + multicast address specified. In this case a + specific address must be supplied which matches + the address used on the manycastserver command + for the designated manycast servers. The NTP + multicast address 224.0.1.1 assigned by the IANA + should NOT be used, unless specific means are + taken to avoid spraying large areas of the + Internet with these messages and causing a + possibly massive implosion of replies at the + sender.
    +
     
    +
    The manycast command specifies that the + local server is to operate in client mode with + the remote server that are discovered as the + result of broadcast/multicast messages. The + client broadcasts a request message to the group + address associated with the specified address + and specifically enabled servers respond + to these messages. The client selects the servers + providing the best time and continues as with the + server command. The remaining servers + are discarded as if never heard.
    +
     
    +
    +
    +
    Options
    +
     
    +
    +
    autokey
    +
    All packets sent to the address are to include + authentication fields encrypted using the autokey + scheme.
    +
     
    +
    burst
    +
    At each poll interval, send a burst of eight + packets spaced, instead of the usual one.
    +
     
    +
    key key
    +
    All packets sent to the address are to include + authentication fields encrypted using the + specified key identifier, which is an + unsigned 32-bit integer less than 65536. The + default is to include no encryption field.
    +
     
    +
    version version
    +
    Specifies the version number to be used for + outgoing NTP packets. Versions 1-4 are the + choices, with version 4 the default.
    +
     
    +
    prefer
    +
    Marks the server as preferred. All other things + being equal, this host will be chosen for + synchronization among a set of correctly + operating hosts. See the Mitigation + Rules and the prefer Keyword page + for further information.
    +
     
    +
    ttl ttl
    +
    This option is used only with broadcast mode. It + specifies the time-to-live ttl to + use on multicast packets. Selection of the proper + value, which defaults to 127, is something of a + black art and must be coordinated with the + network administrator.
    +
     
    +
    minpoll minpoll
    +
    maxpoll maxpoll
    +
    These options specify the minimum and maximum + polling intervals for NTP messages, in seconds to + the power of two. The default range is 6 (64 s) + to 10 (1,024 s).The allowable range is 4 (16 s) + to 17 (36.4 h) inclusive.
    +
     
    +
    +
    +
    broadcastclient
    +
    This command directs the local server to listen for and + respond to broadcast messages received on any local + interface. Upon hearing a broadcast message for the first + time, the local server measures the nominal network delay + using a brief client/server exchange with the remote + server, then enters the broadcastclient mode, in which it + listens for and synchronizes to succeeding broadcast + messages. Note that, in order to avoid accidental or + malicious disruption in this mode, both the local and + remote servers should operate using authentication and + the same trusted key and key identifier.
    +
     
    +
    multicastclient [address] + [...]
    +
    This command directs the local server to listen for + multicast messages at the group address(es) of the global + network. The default address is that assigned by the + Numbers Czar to NTP (224.0.1.1). This command operates in + the same way as the broadcastclient command, but + uses IP multicasting. Support for this command requires a + multicast kernel.
    +
     
    +
    driftfile driftfile
    +
    This command specifies the name of the file used to + record the frequency offset of the local clock + oscillator. If the file exists, it is read at startup in + order to set the initial frequency offset and then + updated once per hour with the current frequency offset + computed by the daemon. If the file does not exist or + this command is not given, the initial frequency offset + is assumed zero. In this case, it may take some hours for + the frequency to stabilize and the residual timing errors + to subside.
    +
     
    +
    The file format consists of a single line containing a + single floating point number, which records the frequency + offset measured in parts-per-million (PPM). The file is + updated by first writing the current drift value into a + temporary file and then renaming this file to replace the + old version. This implies that ntpd must have + write permission for the directory the drift file is + located in, and that file system links, symbolic or + otherwise, should be avoided.
    +
     
    +
    manycastserver address [...]
    +
    This command directs the local server to listen for and + respond to broadcast messages received on any local + interface, and in addition enables the server to respond + to client mode messages to the multicast group + address(es) (type m) specified. At least one address is + required, but The NTP multicast address 224.0.1.1 + assigned by the IANA should NOT be used, unless specific + means are taken to limit the span of the reply and avoid + a possibly massive implosion at the original sender.
    +
     
    +
    revoke [logsec]
    +
    Specifies the interval between recomputations of the + private value used with the autokey feature, which + ordinarily requires an expensive public- key computation. + The default value is 12 (65,536 s or about 18 hours). For + poll intervals above the specified interval, a new + private value will be recomputed for every message sent.
    +
     
    +
    autokey [logsec]
    +
    Specifies the interval between regenerations of the + session key list used with the autokey feature. Note that + the size of the key list for each association depends on + this interval and the current poll interval. The default + value is 12 (4096 s or about 1.1 hours). For poll + intervals above the specified interval, a session key + list with a single entry will be regenerated for every + message sent.
    +
     
    +
    enable [auth | bclient | kernel | monitor | ntp | + stats]
    +
    disable [auth | bclient | kernel | monitor | ntp | + stats]
    +
    Provides a way to enable or disable various server + options. Flags not mentioned are unaffected. Note that + all of these flags can be controlled remotely using the ntpdc utility program.
    +
     
    +
    +
    auth
    +
    Enables the server to synchronize with + unconfigured peers only if the peer has been + correctly authenticated using a trusted key and + key identifier. The default for this flag is + enable.
    +
     
    +
    bclient
    +
    When enabled, this is identical to the broadcastclient + command. The default for this flag is disable.
    +
     
    +
    kernel
    +
    Enables the precision-time kernel support for the + ntp_adjtime() system call, if + implemented. Ordinarily, support for this routine + is detected automatically when the NTP daemon is + compiled, so it is not necessary for the user to + worry about this flag. It flag is provided + primarily so that this support can be disabled + during kernel development.
    +
     
    +
    monitor
    +
    Enables the monitoring facility. See the ntpdc + program and the monlist command or + further information. The default for this flag is + enable.
    +
     
    +
    ntp
    +
    Enables the server to adjust its local clock by + means of NTP. If disabled, the local clock + free-runs at its intrinsic time and frequency + offset. This flag is useful in case the local + clock is controlled by some other device or + protocol and NTP is used only to provide + synchronization to other clients. In this case, + the local clock driver can be used to provide + this function and also certain time variables for + error estimates and leap-indicators. See the Reference Clock Drivers page + for further information. The default for this + flag is enable.
    +
     
    +
    stats
    +
    Enables the statistics facility. See the Monitoring Options page for + further information. The default for this flag is + enable.
    +
     
    +
    +
    + + +
    + +
    + David L. Mills (mills@udel.edu) +
    + + diff --git a/html/copyright.htm b/html/copyright.htm index a3e968fc65..c5863c8873 100644 --- a/html/copyright.htm +++ b/html/copyright.htm @@ -11,24 +11,22 @@ me," says Dolly sheepishly

    The following copyright notice applies to all files collectively called the Network Time Protocol Version 4 Distribution. Unless specifically declared otherwise in an individual file, this notice applies as if the text was explicitly included in the file.
    -

    -/***********************************************************************
- *                                                                     *
- * Copyright (c) David L. Mills 1992-1998                              *
- *                                                                     *
- * Permission to use, copy, modify, and distribute this software and   *
- * its documentation for any purpose and without fee is hereby         *
- * granted, provided that the above copyright notice appears in all    *
- * copies and that both the copyright notice and this permission       *
- * notice appear in supporting documentation, and that the name        *
- * University of Delaware not be used in advertising or publicity      *
- * pertaining to distribution of the software without specific,        *
- * written prior permission. The University of Delaware makes no       *
- * representations about the suitability this software for any         *
- * purpose. It is provided "as is" without express or implied          *
- * warranty.                                                           *
- **********************************************************************/
-
    +
    /***********************************************************************
+ *                                                                     *
+ * Copyright (c) David L. Mills 1992-1998                              *
+ *                                                                     *
+ * Permission to use, copy, modify, and distribute this software and   *
+ * its documentation for any purpose and without fee is hereby         *
+ * granted, provided that the above copyright notice appears in all    *
+ * copies and that both the copyright notice and this permission       *
+ * notice appear in supporting documentation, and that the name        *
+ * University of Delaware not be used in advertising or publicity      *
+ * pertaining to distribution of the software without specific,        *
+ * written prior permission. The University of Delaware makes no       *
+ * representations about the suitability this software for any         *
+ * purpose. It is provided "as is" without express or implied          *
+ * warranty.                                                           *
+ **********************************************************************/
    The following individuals contributed in part to the Network Time Protocol Distribution Version 4 and are acknowledged as authors of this work. @@ -54,6 +52,10 @@ MSF clock driver, Trimble PARSE support
    • Steve Clift <clift@ml.csiro.au> OMEGA clock driver +
  • +Casey Crellin <casey@csc.co.za> +vxWorks (Tornado) port and help with target configuration
    • +
  • Casey Crellin <casey@csc.co.za> VxWorks (Tornado) port and help with target configuration
    • @@ -184,20 +186,10 @@ TRAK clock driver GPS driver, generic TrueTime clock driver
  • -Ulrich Windl -<Ulrich.Windl@rz.uni-regensburg.de> -
      -
    • Corrected and validated HTML documents according to the official -HTML DTDs from IETF and W3C -
    • Contributed several fixes for better Linux support -
    • Implemented PPS code for the -Linux kernel, including the ``nanokernel'' -
    -
    • - +Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> +corrected and validated HTML documents according to the HTML DTD
    David L. Mills <mills@udel.edu> -
    +href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu> + diff --git a/html/debug.htm b/html/debug.htm index 4aee941c74..bf16049795 100644 --- a/html/debug.htm +++ b/html/debug.htm @@ -42,31 +42,30 @@ useful for debugging. In general, interpretation of this output requires reference to the sources. However, a single -d does produce only mildly cryptic output and can be very useful in finding problems with configuration and network troubles. With a little experience, the -volume of output can be reduced by piping the output to grep and -specifying a keyword, such as receive or clock of the -trace you want to see. +volume of output can be reduced by piping the output to grep +and specifying the keyword of the trace you want to see.

    Some problems are immediately apparent when the daemon first starts -running. The most common of these are the lack of ntp (UDP port 123) -in the host /etc/services file. Note that NTP always uses UDP -and never uses TCP. Other problems are apparent in the system log file. -The log file should show the startup banner, some cryptic initialization -data, and the computed precision value. The next most common problem is +running. The most common of these are the lack of a ntp (UDP port 123) +in the host /etc/services file. Note that NTP does not use TCP +in any form. Other problems are apparent in the system log file. The log +file should show the startup banner, some cryptic initialization data, +and the computed precision value. The next most common problem is incorrect DNS names. Check that each DNS name used in the configuration file responds to the Unix ping command.

    When first started, the daemon normally polls the servers listed in the configuration file at 64-second intervals. In order to allow a sufficient number of samples for the NTP algorithms to reliably -discriminate between correctly operating servers (truechimers) and -possible intruders (falsetickers), at least four valid messages from at -least one server is required before the daemon can set the local clock. -However, if the current local time is more than 1000 seconds in error -from the server time, the daemon will not set the local clock; instead, -it will plant a message in the system log and shut down. It is necessary -to set the local clock to within 1000 seconds first, either from the -time-of-year (TOY) chip, the ntpdate -program or manually by eyeball and wristwatch. +discriminate between correctly operating servers and possible intruders, +at least four valid messages from at least one server is required before +the daemon can set the local clock. However, if the current local time +is greater than 1000 seconds in error from the server time, the daemon +will not set the local clock; instead, it will plant a message in the +system log and shut down. It is necessary to set the local clock to +within 1000 seconds first, either by a time-of-year hardware clock, by +first using the ntpdate program or +manually be eyeball and wristwatch.

    After starting the daemon, run the ntpq program using the -n switch, which will avoid possible distractions due to name @@ -75,8 +74,7 @@ showing the status of configured peers and possibly other clients poking the daemon. After operating for a few minutes, the display should be something like: -

    -ntpq>pe
+
    ntpq>pe
 remote      refid       st t when poll reach   delay  offset   disp
 ===================================================================
 +128.4.2.6  132.249.16.1 2 u  131  256   373    9.89   16.28  23.25
@@ -114,23 +112,21 @@ documentation for the meaning of these symbols.
 following procedure. First, use the as command to display an
 index of association identifiers, such as
 
-
    -ntpq>as
+
    ntpq>as
 ind assID status conf reach auth condition last_event cnt
 =========================================================
  1  11670   7414   no   yes   ok candidate  reachable   1
  2  11673   7614   no   yes   ok sys.peer   reachable   1
  3  11833   7314   no   yes   ok outlyer    reachable   1
  4  11868   7414   no   yes   ok candidate  reachable   1
-
    
+ 
    
 
-Each line in this billboard is associated with the corresponding line of
+Each line in this billboard is associated with the corresponding line
 the pe billboard above. Next, use the rv command and
 the respective identifier to display a detailed synopsis of the selected
 peer, such as
 
-
    -ntpq>rv 11670
+
    ntpq>rv 11670
 status=7414 reach, auth, sel_sync, 1 event, event_reach
 srcadr=128.4.2.6, srcport=123, dstadr=128.4.2.7, dstport=123, keyid=1,
 stratum=2, precision=-10, rootdelay=362.00, rootdispersion=21.99,
@@ -147,7 +143,7 @@ filtoffset= 13.24 16.28 -49.19 16.04 16.83 16.49 16.95 -39.43,
 filterror=  16.27 20.17  27.98 31.89 35.80 39.70 43.61  47.52
 
    
 
-A detailed explanation of the fields in this billboard is beyond the
+A detailed explanation of the fields in this billboard are beyond the
 scope of this discussion; however, most variables defined in the
 specification RFC-1305 can be found. The most useful portion for
 debugging is the last three lines, which give the roundtrip delay, clock
@@ -164,8 +160,7 @@ exists.
 
    Finally, the state of the local clock can be determined using the
 rv command (without the argument), such as
 
-
    -ntpq>rv
+
    ntpq>rv
 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg
 system="UNIX", leap=00, stratum=2, rootdelay=280.62,
 rootdispersion=45.26, peer=11673, refid=128.4.1.20,
@@ -181,129 +176,48 @@ RFC-1305.
 
 
    When nothing seems to happen in the pe billboard after some
 minutes, there may be a network problem. The most common network problem
-is an access controlled router on the path to the selected peer. Few
-public NTP time server selectively restricts access, although this may
-change in future; however, many private network servers do. It also may
-be the case that the server is down or running in unsynchronized mode
-due to a local problem. Use the ntpq program and hosts
-command program to spy on the server variables in the same way you can
-spy on your own.
+is an access controlled router on the path to the selected peer. No
+known public NTP time server selectively restricts access at this time,
+although this may change in future; however, many private networks do.
+It also may be the case that the server is down or running in
+unsynchronized mode due to a local problem. Use the ntpq
+program to spy on its own variables in the same way you can spy on your
+own.
 
 
    Once the daemon has set the local clock, it will continuously track
 the discrepancy between local time and NTP time and adjust the local
 clock accordingly. There are two components of this adjustment, time and
 frequency. These adjustments are automatically determined by the clock
-discipline algorithm. The behavior of this algorithm is carefully
-controlled to minimize residual errors due to network jitter and
-frequency variations of the local clock hardware oscillator due to
-temperature changes. However, when started for the first time, the
-algorithm may take many hours to converge to the intrinsic frequency
-of the host machine.
-
    It has sometimes been the experience that the local clock oscillator
-frequency error is too large for the NTP discipline algorithm, which
-cannot correct frequency errors larger than 500 parts-per-million (PPM)
-or 43 seconds per day. There are two possibilities that may result in
-this problem. First, the hardware TOY clock chip must be disabled
-when using NTP, since it can destabilize the discipline process. This
-is usually done using the tickadj
-program and the -s command line argument, but other means may
-be necessary. For instance, in the Sun Solaris kernel, this can be done
-using a command in the /etc/system system startup file.
-
-
    Normally, the NTP daemon amortizes time adjustments at a rate of
-500 PPM until the remaining adjustment is completely amortized. The
-adjustment process is updated with a new time correction each second.
-This process, or slew, operates continuously as long as the adjustment
-does not exceed 128 milliseconds, which for most Internet paths is a
-rare event. If an adjustment does exceed this value, perhaps due to an
-occasional network delay spike, the correction is simply discarded;
-however, if outlyer values persist in subsequent updates for an interval
-of 900 seconds, the local clock is stepped to the new value. This
-behavior is designed to resist errors due to severely congested network
-paths, as well as errors due to confused radio clocks upon the epoch of
-a leap second.
-
-
    Network Problems
    
-
-
    Most problems observed with NTP over the years has been some kind of
-network problem. Frequently, the problem turns out to be a filter in the
-firewall between a public server and a client on a private network. In
-other cases the problem is due simply to the fact a designated server is
-unreachable or itself unsynchronized. The Unix ping program can
-be used to verify server reachability and the traceroute
-utility to explore the path between the remote server and local client.
-The techniques used are common to other network services and considered
-beyond the scope of the discussion here.
-
-
    Sometimes such things as access control and authentication can get in
-the way of successful synchronization. The -d command line
-debug flag is a useful diagnostic in such cases. One or more debug flags
-and the Unix grep filter can be used to identify and resolve
-intractable cases. For this purpose, the lavish commentary sprinkled in
-the ntp_proto.c source file may be helpful in resolving the
-cause. In particular, the various header and data sanity checks can be
-determined for each arriving message.
-
-
    The Unix tcpdump program is useful to discover rogue packets
-and to calibrate the traffic between a client and its server or peer.
-The ntptrace program is useful to discover the synchronization
-path to the primary server, which can be useful should loops develop. If
-kernel support is available, the ntptime program can be used to
-display and alter the kernel state variables. The status bits reveal the
-current state; see the /usr/include/sys/timex.h header file for
-interpretation. Typical performance expectations are jitter less than 5
-microseconds and stability less than .05 PPM.
-
-
    With Extreme Prejudice
    
+discipline algorithm, which functions as a hybrid phase/frequency
+feedback loop. The behavior of this algorithm is carefully controlled to
+minimize residual errors due to network jitter and frequency variations
+of the local clock hardware oscillator that normally occur in practice.
+However, when started for the first time, the algorithm may take some
+time to converge on the intrinsic frequency error of the host machine.
 
 
    It has sometimes been the experience that the local clock oscillator
 frequency error is too large for the NTP discipline algorithm, which can
-correct frequency errors as large as 500 parts-per-million (PPM) or 43
-seconds per day. There are two possibilities that may result in this
-behavior. First, the hardware time-of-year (TOY) clock chip must be
-disabled when using NTP, since this can destabilize the discipline
-process. If this is not done, the time can be jerked from under NTP,
-with result excessive jitter and instability. The TOY chip can be
-disabled in many systems using the tickadj program and the -s command
-line argument, but other means may be necessary. For instance, in the
-Sun Solaris kernel, this is done using a command in the
-/etc/system system startup file.
-
-
    Second, the local intrinsic clock frequency error may exceed the 500
-PPM limit. If this occurs, the apparent clock offset will grow until
-reaching 128 ms; then, after the 900-second timeout, the clock will be
-stepped to the apparent time. If the -x option is used to
-always slew the clock, the offset will grow continuously. Eventually,
-the offset will reach 1000 seconds and the daemon will fall on its sword
-and terminate with an uncivil message to the system log.
-
-
    The tickadj program can be used to force the clock frequency
-error to a low value which the NTP daemon can handle. This is done by
-changing the value of the tick kernel variable which defines
-the number of microseconds added to the clock at each timer interrupt.
-The best way to determine if this is the cause is to start the daemon
-with a configuration file listing a known good server and including the
-line disable ntp. For this purpose, the drift file
-/etc/ntp.drift should be temporarily removed or renamed. If
-kernel support is available and enabled, previous debugging may have
-left nonsense in the kernel variables. The ntptime program can
-be used to set the frequency variable to zero, or the system can be
-rebooted with the same effect.
-
-
    Once the daemon has started, the ntpq program can be used to
-inspect the clock filter values, which show the roundtrip delay, offset
-and dispersion. By inspecting successive offsets in the eight-sample
-clock filter window and finding the interval between updates, the
-intrinsic clock frequency can be calculated. If this exceeds 500 PPM,
-the daemon cannot correct the frequency and a correction to the
-tick kernel variable is required. For 100-Hz kernels, which
-represent the majority of systems, this value is normally 10000, which
-results in ten milliseconds clock increment for each timer interrupt.
-Changing this value in unit increments results in frequency changes in
-100 PPM increments. The intrinsic offset calculated previously, the
-correct value of tick can be determined to the nearest 100-PPM
-value.
+correct frequency errors as large as 43 seconds per day. There are two
+possibilities that may result in this problem. First, the hardware time-
+of-year clock chip must be disabled when using NTP, since this can
+destabilize the discipline process. This is usually done using the
+tickadj program and the -s
+command line argument, but other means may be necessary. For instance,
+in the Sun Solaris kernel, this can be done using a command in the
+system startup file.
+
+
    Normally, the daemon will adjust the local clock in small steps in
+such a way that system and user programs are unaware of its operation.
+The adjustment process operates continuously as long as the apparent
+clock error exceeds 128 milliseconds, which for most Internet paths is a
+quite rare event. If the event is simply an outlyer due to an occasional
+network delay spike, the correction is simply discarded; however, if the
+apparent time error persists for an interval of about 20 minutes, the
+local clock is stepped to the new value (as an option, the daemon can be
+compiled to slew at an accelerated rate to the new value, rather than be
+stepped). This behavior is designed to resist errors due to severely
+congested network paths, as well as errors due to confused radio clocks
+upon the epoch of a leap second.
 
 
    Debugging Checklist
    
 
@@ -313,28 +227,29 @@ not result in correct synchronization, verify the following:
 
 
      
 
-
    1. Verify the /etc/services file host machine is configured
-to accept UDP packets on the NTP port 123. NTP is specifically designed
-to use UDP and does not respond to TCP.
      2. 
+
    2. Verify the /etc/services file host machine is configured
+to
+accept UDP packets on the NTP port 123. NTP is specifically designed to
+use UDP and does not respond to TCP.
      3. 
 
-
    3. Check the system log for ntpd messages about
-configuration errors, name-lookup failures or initialization
-problems.
      4. 
+
    4. Check the system log for ntpd messages about
+configuration
+errors, name-lookup failures or initialization problems.
      5. 
 
-
    5. Using the ntpdc program and iostats command,
+
    6. Using the ntpdc program and iostats command,
 verify that the received packets and packets sent counters are
-incrementing. If the packets sent counter does not increment and the
+incrementing. If the packets send counter does not increment and the
 configuration file includes designated servers, something may be wrong
 in the network configuration of the ntpd host. If this counter does
 increment and packets are actually being sent to the network, but the
 received packets counter does not increment, something may be wrong in
 the network or the server may not be responding.
      7. 
 
-
    7. If both the packets sent counter and received packets counter do
+
    8. If both the packets sent counter and received packets counter do
 increment, but the rec timestamp in the pe billboard
 shows far from the current date, received packets are probably being
 discarded for some reason. There is a handy, undocumented state variable
-flash visible in the pe billboard. The value is in hex
+flash visible in the pebillboard. The value is in hex
 and normally has the value zero (OK). However, if something is wrong,
 the bits of this variable, reading from the right, correspond to the
 sanity checks listed in Section 3.4.3 of the NTP specification RFC-1305. A bit other than zero indicates the associated sanity
 check failed.
      9. 
 
-
    9. If the org, rec and xmt timestamps in the
+
    10. If the org, rec and xmt timestamps in the
 pe billboard appear current, but the local clock is not set, as
 indicated by a stratum number less than 16 in the rv command
 without arguments, verify that valid clock offset, roundtrip delay and
@@ -351,7 +266,7 @@ be less than 1000 seconds, the roundtrip delay less than one second and
 the dispersion less than one second.
      11. 
 
 
-
    11. While the algorithm can tolerate a relatively large frequency
+
    12. While the algorithm can tolerate a relatively large frequency
 error (up to 500 parts per million or 43 seconds per day), various
 configuration errors (and in some cases kernel bugs) can exceed this
 tolerance, leading to erratic behavior. This can result in frequent loss
@@ -369,5 +284,5 @@ command line argument.
      13. 
 
    
 
 
     David L. Mills <mills@udel.edu>
-
    
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/driver1.htm b/html/driver1.htm
index 423c352e4a..1f88e7de01 100644
--- a/html/driver1.htm
+++ b/html/driver1.htm
@@ -1,140 +1,157 @@
-
-Undisciplined Local Clock
-
    
-Undisciplined Local Clock
-
    
-
-
    Synopsis
    
-
+
+
+   
+   
+   Undisciplined Local Clock
+
+
+
+
+
    
+Undisciplined Local Clock
    
+
+
    
+
    
+Synopsis
    
 Address: 127.127.1.u
 
    Reference ID: LCL
 
    Driver ID: LOCAL
-
-
    Description
    
-
+
    
+Description
    
 This driver is intended for use in an isolated network where no external
 source of synchronization such as a radio clock or modem is available.
-It allows a designated time server to act as a primary or backup server
-to provide synchronization to other clients on the network. Pick a
-machine that has a good clock oscillator (Digital machines are good, Sun
-machines are not) and configure it with this driver. Set the clock using
-the best means available, like eyeball-and-wristwatch. Then, point all
-the other machines at this one or use broadcast (not multicast) mode to
-distribute time.
+It allows a designated time server to act as a primary server to provide
+synchronization to other clients on the network. Pick a machine that has
+a good clock oscillator (Digital machines are good, Sun machines are not)
+and configure it with this driver. Set the clock using the best means available,
+like eyeball-and-wristwatch. Then, point all the other machines at this
+one or use broadcast (not multicast) mode to distribute time.
 
 
    Another application for this driver is if a particular server clock
-is to be used as the clock of last resort when all other normal
-synchronization sources have gone away. This is especially useful if
-that server has an ovenized oscillator. For this you would configure
-this driver at a stratum greater than any other likely sources of time
-(say 3 or 4) to prevent the server taking over when legitimate sources
-are still available.
-
-
    A third application for this driver is when an external discipline
-source is available, such as the NIST lockclock program, which
-synchronizes the local clock via a telephone modem and the NIST
-Automated Computer Time Service (ACTS), or the Digital Time
-Synchronization Service (DTSS), which runs on DCE machines. In this case
-the stratum should be set at zero, indicating a bona fide stratum-1
-source. In the case of DTSS, the local clock can have a rather large
-jitter, depending on the interval between corrections and the intrinsic
-frequency error of the clock oscillator. In extreme cases, this can
-cause clients to exceed the 128-ms slew window and drop off the NTP
-subnet.
+is to be used as the clock of last resort when all other normal synchronization
+sources have gone away. This is especially useful if that server has an
+ovenized oscillator. For this you would configure this driver at a stratum
+greater than any other likely sources of time (say 3 or 4) to prevent the
+server taking over when legitimate sources are still available.
+
+
    A third application for this driver is when an external discipline source
+is available, such as the NIST lockclock program, which synchronizes
+the local clock via a telephone modem and the NIST Automated Computer Time
+Service (ACTS), or the Digital Time Synchronization Service (DTSS), which
+runs on DCE machines. In this case the stratum should be set at zero, indicating
+a bona fide stratum-1 source. In the case of DTSS, the local clock can
+have a rather large jitter, depending on the interval between corrections
+and the intrinsic frequency error of the clock oscillator. In extreme cases,
+this can cause clients to exceed the 128-ms slew window and drop off the
+NTP subnet.
 
 
    In the case where a NTP time server is synchronized to some device or
-protocol external to the NTP daemon itself, a means must be available to
-pass such things as error and health values to the NTP daemon for
-dissemination to its clients. If this is not done, there is a very real
-danger that the device or protocol could fail and with no means to tell
-NTP clients of the mishap. When ordinary Unix system calls like
-adjtime() are used to discipline the kernel clock, there is no
-obvious way this can be done without modifying the code for each case.
-However, when kernel support for the ntp_adjtime() system call
-is available, that routine can be used for the same purpose as the
-adjtime() system call and in addition provided with the
-estimated error, maximum error, and leap-indicator values. This is the
-preferred way to synchronize the kernel clock and pass information to
-the NTP clients.
-
-
    The means currently available in the latest version of the local
-clock driver and kernel support implement a simple protocol used by the
-daemon and external device driver to relinquish control by the device
-driver when the external device becomes unreachable or inoperable and to
-regain control when it resumes normal operation. The device driver
-communicates with the daemon via bits in the status word managed by the
-ntp_adjtime() system call. Details of the protocol are
-described in the source code for the local clock driver.
+protocol that is not external to the NTP daemon itself, some means should
+be provided to pass such things as error and health values to the NTP daemon
+for dissemination to its clients. If this is not done, there is a very
+real danger that the device or protocol could fail and with no means to
+tell NTP clients of the mishap. When ordinary Unix system calls like adjtime()
+are used to discipline the kernel clock, there is no obvious way this can
+be done without modifying the code for each case. However, when a modified
+kernel with the ntp_adjtime() system call  is available,
+that routine can be used for the same purpose as the adjtime()
+routine and in addition provided with the estimated error, maximum error,
+and leap-indicator values. This is the preferred way to synchronize the
+kernel clock and pass information to the NTP clients.
 
 
    In the default mode the behavior of the clock selection algorithm is
 modified when this driver is in use. The algorithm is designed so that
 this driver will never be selected unless no other discipline source is
-available. This can be overridden with the prefer keyword of
-the server configuration command, in which case only this
-driver will be selected for synchronization and all other discipline
-sources will be ignored. This behavior is intended for use when an
-external discipline source controls the system clock. See the Mitigation Rules and the prefer Keyword
-page for a detailed description of the exact behavior.
-
-
    The stratum for this driver is set at 3 by default, but can be
-changed by the fudge configuration command and/or the
-ntpdc utility. The reference ID is LCL by default, but
-can be changed using the same mechanisms. *NEVER* configure this
-driver to operate at a stratum which might possibly disrupt a client
-with access to a bona fide primary server, unless the local clock
-oscillator is reliably disciplined by another source. *NEVER
-NEVER* configure a server which might devolve to an undisciplined
-local clock to use multicast mode.
+available. This can be overridden with the prefer keyword of the
+server configuration command, in which case only this driver will
+be selected for synchronization and all other discipline sources will be
+ignored. This behavior is intended for use when an external discipline
+source controls the system clock. See the Mitigation
+Rules and the prefer Keyword page for a detailed description
+of the exact behavior.
+
+
    The stratum for this driver is set at 3 by default, but can be changed
+by the fudge configuration command and/or the ntpdc utility.
+The reference ID is LCL by default, but can be changed using the
+same mechanisms. *NEVER* configure this driver to operate at a stratum
+which might possibly disrupt a client with access to a bona fide primary
+server, unless the local clock oscillator is reliably disciplined by another
+source. *NEVER NEVER* configure a server which might devolve to
+an undisciplined local clock to use multicast mode.
 
 
    This driver provides a mechanism to trim the local clock in both time
-and frequency, as well as a way to manipulate the leap bits. The
-fudge time1 parameter adjusts the time (in seconds) and the
-fudge time2 parameter adjusts the frequency (in parts per
-million). Both parameters are additive and operate only once; that is,
-each command (as from ntpdc) adds signed increments in time or
-frequency to the system clock nominal time and frequency.
+and frequency, as well as a way to manipulate the leap bits. The fudge
+time1 parameter adjusts the time (in seconds) and the fudge time2
+parameter adjusts the frequency (in parts per million). Both parameters
+are additive and operate only once; that is, each command (as from ntpdc)
+adds signed increments in time or frequency to the nominal local clock
+time and frequency.
+
    
+Monitor Data
    
+No filegen clockstats monitor data are produced by this driver.
+
    
+Fudge Factors
    
 
-
    Monitor Data
    
+
    
+
    
+time1 time
    
 
-No filegen clockstats monitor data are produced by this driver.
+
    
+Specifies the time offset calibration factor, in seconds and fraction,
+with default 0.0.
    
 
-
    Fudge Factors
    
+
    
+time2 time
    
 
-
    
+
    
+Specifies the frequency offset calibration factor, in parts per million,
+with default 0.0.
    
+
+
    
+stratum number
    
+
+
    
+Specifies the driver stratum, in decimal from 0 to 15, with default 3.
    
+
+
    
+refid string
    
 
-
    time1 time
    
-
    Specifies the time offset calibration factor, in seconds and
-fraction, with default 0.0.
    
+
    
+Specifies the driver reference identifier, an ASCII string from one to
+four characters, with default LCL.
    
 
-
    time2 time
    
-
    Specifies the frequency offset calibration factor, in parts per
-million, with default 0.0.
    
+
    
+flag1 0 | 1
    
 
-
    stratum number
    
-
    Specifies the driver stratum, in decimal from 0 to 15, with default
-3.
    
+
    
+Not used by this driver.
    
 
-
    refid string
    
-
    Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default LCL.
    
+
    
+flag2 0 | 1
    
 
-
    flag1 0 | 1
    
-
    Not used by this driver.
    
+
    
+Not used by this driver.
    
 
-
    flag2 0 | 1
    
-
    Not used by this driver.
    
+
    
+flag3 0 | 1
    
 
-
    flag3 0 | 1
    
-
    Not used by this driver.
    
+
    
+Not used by this driver.
    
+
+
    
+flag4 0 | 1
    
+
+
    
+Not used by this driver.
    
 
-
    flag4 0 | 1
    
-
    Not used by this driver.
 
 
    Additional Information
 
 
    Reference Clock Drivers
    
 
-
     David L. Mills <mills@udel.edu>
-
    
+
    
+
    
+David L. Mills (mills@udel.edu)
    
+
+
+
diff --git a/html/driver10.htm b/html/driver10.htm
index 32c7ae1ed8..bdf314ae46 100644
--- a/html/driver10.htm
+++ b/html/driver10.htm
@@ -105,7 +105,7 @@ Enable verbose clockstats recording if set.
 
    
 Additional Information
 
-
    Reference Clock Drivers
+
    Reference Clock Drivers 
 
    
 
    
 David L. Mills (mills@udel.edu)
    
diff --git a/html/driver11.htm b/html/driver11.htm
index 07b35184dd..6e5dd7a3f1 100644
--- a/html/driver11.htm
+++ b/html/driver11.htm
@@ -35,8 +35,7 @@ sequence B5, which initiates a line in the following format to
 be repeated once per second until turned off by the B0 command.
 
 
    Format B5 (24 ASCII printing characters):
-
    -<cr><lf>i yy ddd hh:mm:ss.000bbb
+
    <cr><lf>i yy ddd hh:mm:ss.000bbb
 
 on-time = <cr>
 i = synchronization flag (' ' = locked, '?' = unlocked)
@@ -44,8 +43,7 @@ yy = year of century
 ddd = day of year
 hh:mm:ss = hours, minutes, seconds
 .000 = fraction of second (not used)
-bbb = tailing spaces for fill
-
    
+bbb = tailing spaces for fill
    
 The alarm condition is indicated by a '?' at i, which indicates the receiver
 is not synchronized. In normal operation, a line consisting of the timecode
 followed by the time quality character (TQ) followed by the receiver status
@@ -54,30 +52,26 @@ string (SR) is written to the clockstats file.
 
    The time quality character is encoded in IEEE P1344 standard:
 
 
    Format TQ (IEEE P1344 estimated worst-case time quality)
-
    -0       clock locked, maximum accuracy
-F       clock failure, time not reliable
-4       clock unlocked, accuracy < 1 us
-5       clock unlocked, accuracy < 10 us
-6       clock unlocked, accuracy < 100 us
-7       clock unlocked, accuracy < 1 ms
-8       clock unlocked, accuracy < 10 ms
-9       clock unlocked, accuracy < 100 ms
-A       clock unlocked, accuracy < 1 s
-B       clock unlocked, accuracy < 10 s
-
    
+
    0       clock locked, maximum accuracy
+F       clock failure, time not reliable
+4       clock unlocked, accuracy < 1 us
+5       clock unlocked, accuracy < 10 us
+6       clock unlocked, accuracy < 100 us
+7       clock unlocked, accuracy < 1 ms
+8       clock unlocked, accuracy < 10 ms
+9       clock unlocked, accuracy < 100 ms
+A       clock unlocked, accuracy < 1 s
+B       clock unlocked, accuracy < 10 s
    
 The status string is encoded as follows:
 
 
    Format SR (25 ASCII printing characters)
-
    -V=vv S=ss T=t P=pdop E=ee
+
    V=vv S=ss T=t P=pdop E=ee
 
 vv = satellites visible
 ss = relative signal strength
 t = satellites tracked
 pdop = position dilution of precision (meters)
-ee = hardware errors
-
    
+ee = hardware errors
    
 A three-stage median filter is used to reduce jitter and provide a dispersion
 measure. The driver makes no attempt to correct for the intrinsic jitter
 of the radio itself.
@@ -147,7 +141,7 @@ Enable verbose clockstats recording if set.
 
 Additional Information
 
-
    Reference Clock Drivers
+
    Reference Clock Drivers 
 
    
 
    
 David L. Mills (mills@udel.edu)
    
diff --git a/html/driver12.htm b/html/driver12.htm
index e0ca980f06..57dbb71912 100644
--- a/html/driver12.htm
+++ b/html/driver12.htm
@@ -89,7 +89,7 @@ Not used by this driver.
 
 Additional Information
 
-
    Reference Clock Drivers
+
    Reference Clock Drivers 
 
    
 
    
 David L. Mills (mills@udel.edu)
    
diff --git a/html/driver18.htm b/html/driver18.htm
index 7cff8aad6c..5410d98076 100644
--- a/html/driver18.htm
+++ b/html/driver18.htm
@@ -90,8 +90,7 @@ tt = DST indicator (see driver listing)
 l = leap-second warning (see driver listing)
 uuu = DUT1 correction (see driver listing)
 mmmmm = modem calibration (see driver listing)
-on-time = '*'
-
    
+on-time = '*'
    
 The timecode message is transmitted continuously after a signon banner,
 which this driver ignores. The driver also ignores all but the yy-mm-dd,
 hh:mm:ss and on-time character '*' fields, although it checks the format
@@ -153,20 +152,17 @@ disables automatic call attempts.
 
    Manual call attempts can be made at any time by setting fudge flag1
 using ntpdc. For example, the ntpdc command
 
    -fudge 127.127.18.1 flags 1
-
    
+fudge 127.127.18.1 flags 1
    
 will ask for a key identifier and password and, if authenticated by the
 server, will set flag1. There may be a short delay until the expiration
 of the current poll timeout.
 
 
    The flag1 can be set from a cron job in the following way. Construct
 a file with contents
-
    -keyid 11
+
    keyid 11
 passwd dialup
 fudge 127.127.18.1 flags 1
-quit
-
    
+quit
    
 Then, run the following program at specified times as required.
 
    /usr/local/bin/ntpdc <file
    
 
@@ -230,7 +226,7 @@ Not used by this driver.
 
 Additional Information
 
-
    Reference Clock Drivers
+
    Reference Clock Drivers 
 
    
 
    
 David L. Mills (mills@udel.edu)
    
diff --git a/html/driver19.htm b/html/driver19.htm
index a0d194e486..a5cd5e0da8 100644
--- a/html/driver19.htm
+++ b/html/driver19.htm
@@ -48,13 +48,11 @@ interface, although other interfaces may work as well.
 
 
    The clock message consists of 23 ASCII printing characters in the following
 format:
-
    -hh:mm:ss.f     dd/mm/yr<cr>
+
    hh:mm:ss.f     dd/mm/yr<cr>
 
 hh:mm:ss.f = hours, minutes, seconds
 f = deciseconds ('?' when out of spec)
-dd/mm/yr = day, month, year
-
    
+dd/mm/yr = day, month, year
    
 The alarm condition is indicated by '?', rather than a digit, at A. Note
 that 0?:??:??.? is displayed before synchronization is first established
 and hh:mm:ss.? once synchronization is established and then lost again
@@ -117,7 +115,7 @@ Not used by this driver
 
 Additional Information
 
-
    Reference Clock Drivers
+
    Reference Clock Drivers 
 
    
 
    
 David L. Mills (mills@udel.edu)
    
diff --git a/html/driver2.htm b/html/driver2.htm
index 80b3aa7fef..885a1b2021 100644
--- a/html/driver2.htm
+++ b/html/driver2.htm
@@ -40,20 +40,18 @@ The timecode format includes neither the year nor leap-second warning.
 
    In operation, this driver sends a RQTS\r request to the radio
 at initialization in order to put it in continuous time output mode. The
 radio then sends the following message once each second:
-
    -*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
+
    *RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
 
 on-time = '*'
 ddd = day of year
 hh:mm:ss = hours, minutes, seconds
 q = quality indicator (phase error), 0-6:
-     0 > 20 us
-     6 > 10 us
-     5 > 1 us
-     4 > 100 ns
-     3 > 10 ns
-     2 < 10 ns
-
    
+     0 > 20 us
+     6 > 10 us
+     5 > 1 us
+     4 > 100 ns
+     3 > 10 ns
+     2 < 10 ns
    
 The alarm condition is indicated by 0 at Q, which means
 the radio has a phase error greater than 20 us relative to the broadcast
 time. The absence of year, DST and leap-second warning in this format is
@@ -124,7 +122,8 @@ Not used by this driver.
 flag4 0 | 1
 
 
    
-Not used by this driver.
+Not used by this driver.
    
+
 
 
    Additional Information
 
diff --git a/html/driver20.htm b/html/driver20.htm
index 99f1890d36..e6a4bd2a83 100644
--- a/html/driver20.htm
+++ b/html/driver20.htm
@@ -31,23 +31,21 @@ actual accuracy is limited by the precision of the timecode and the latencies
 of the serial interface and operating system.
 
 
    The $GPRMC message that the GPS transmits look like this:
-
    -$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC<cr><lf>
-
-  POS_UTC  - UTC of position. Hours, minutes and seconds. (hhmmss)
-  POS_STAT - Position status. (A = Data valid, V = Data invalid)
-  LAT      - Latitude (llll.ll)
-  LAT_REF  - Latitude direction. (N = North, S = South)
-  LON      - Longitude (yyyyy.yy)
-  LON_REF  - Longitude direction (E = East, W = West)
-  SPD      - Speed over ground. (knots) (x.x)
-  HDG      - Heading/track made good (degrees True) (x.x)
-  DATE     - Date (ddmmyy)
-  MAG_VAR  - Magnetic variation (degrees) (x.x)
-  MAG_REF  - Magnetic variation (E = East, W = West)
-  CC       - Checksum (optional)
-  <cr><lf> - Sentence terminator.
-
    
+
    $GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC<cr><lf>
+
+  POS_UTC  - UTC of position. Hours, minutes and seconds. (hhmmss)
+  POS_STAT - Position status. (A = Data valid, V = Data invalid)
+  LAT      - Latitude (llll.ll)
+  LAT_REF  - Latitude direction. (N = North, S = South)
+  LON      - Longitude (yyyyy.yy)
+  LON_REF  - Longitude direction (E = East, W = West)
+  SPD      - Speed over ground. (knots) (x.x)
+  HDG      - Heading/track made good (degrees True) (x.x)
+  DATE     - Date (ddmmyy)
+  MAG_VAR  - Magnetic variation (degrees) (x.x)
+  MAG_REF  - Magnetic variation (E = East, W = West)
+  CC       - Checksum (optional)
+  <cr><lf> - Sentence terminator.
    
 The driver will send a $PMOTG,RMC,0000*1D<cr><lf> message
 each time a $GPRMC string is needed. This is not needed on most
 GPS receivers because they automatically send the $GPRMC string
@@ -118,7 +116,8 @@ Not used by this driver.
 flag4 0 | 1
 
 
    
-Not used by this driver.
+Not used by this driver.
    
+
 
 
    Additional Information
 
diff --git a/html/driver22.htm b/html/driver22.htm
index 50d40e9544..313d2b8232 100644
--- a/html/driver22.htm
+++ b/html/driver22.htm
@@ -114,7 +114,8 @@ Not used by this driver.
 flag4 0 | 1
 
 
    
-Not used by this driver.
+Not used by this driver.
    
+
 
 
    Additional Information
 
diff --git a/html/driver23.htm b/html/driver23.htm
index 330a1c108f..6633999eca 100644
--- a/html/driver23.htm
+++ b/html/driver23.htm
@@ -78,7 +78,7 @@ Not used by this drivert.
 
 Additional Information
 
-
    Reference Clock Drivers
+
    Reference Clock Drivers 
 
    
 
    
 David L. Mills (mills@udel.edu)
    
diff --git a/html/driver27.htm b/html/driver27.htm
index adac8d071f..686e985b1b 100644
--- a/html/driver27.htm
+++ b/html/driver27.htm
@@ -145,8 +145,9 @@ The commands and their responses are:
 
 
    
 Request for signal quality. Answer only valid during (late part of) resync
-to MSF signal. The response consists of two characters as follows:
+to MSF signal. The response consists of two characters as follows:
    
 
+
      
 
      
 
      
 bit 7
      
@@ -238,6 +239,7 @@ in the range 0--2 no successful reception is to be expected. The reported
 value drops to zero when not resyncing, ie when first returned byte is
 not `3'.
 
      
+
    
 
 
    
 h CR
    
@@ -258,7 +260,7 @@ once per hour to minimise clock wander.
 Request timestamp. Start bit of first byte of response is on-time, so may
 be delayed up to 1 second. Note that when the BST mode is in effect the
 time is GMT/UTC +0100, ie an hour ahead of UTC to reflect local time in
-the UK. The response data is as follows:
+the UK. The response data is as follows:
 
 
      
 
    1. 
@@ -302,7 +304,7 @@ year tens (years range from 00 to 99)
      2. 
 year units
 
 
    2. 
-BST/UTC status
+BST/UTC status
      3. 
 
 
      
 
      
@@ -355,9 +357,9 @@ bit 0
      
 
      
 
 
    3. 
-clock status
+clock status
      4. 
 
-
      
+
       
 
      
 bit 7
      
 
@@ -417,8 +419,7 @@ decides to move us to +0100/+0200 time as opposed to the current +0000/+0100
 time, it is not clear what effect that will have on the time broadcast
 by MSF, and therefore on this driver's usefulness.
      
 A typical ntp.conf configuration file for this driver might be:
-
      -# hostname(n) means we expect (n) to be the stratum at which hostname runs.
+
      # hostname(n) means we expect (n) to be the stratum at which hostname runs.
 
 #------------------------------------------------------------------------------
 # SYNCHRONISATION PARTNERS
@@ -440,20 +441,19 @@ driftfile /var/tmp/ntp.drift
 # RESTRICTIONS
 # ============
 
-# By default, don't trust and don't allow modifications.  Ignore in fact.
+# By default, don't trust and don't allow modifications.  Ignore in fact.
 restrict default ignore notrust nomodify
 
 # Allow others in our subnet to check us out...
 restrict 11.22.33.0 mask 255.255.255.0 nomodify notrust
 
-# Trust our peers for time.  Don't trust others in case they are insane.
+# Trust our peers for time.  Don't trust others in case they are insane.
 restrict 127.127.27.0 nomodify
 restrict 11.22.33.4 nomodify
 restrict 11.22.33.9 nomodify
 
 # Allow anything from the local host.
-restrict 127.0.0.1
-
      
+restrict 127.0.0.1
      
 There are a few #defines in the code that you might wish to play
 with:
 
      
@@ -477,16 +477,17 @@ When defined, the code uses its own median-filter code rather than that
 available in ntp_refclock.c since the latter seems to have a minor
 bug, at least in version 3-5.90. If this bug goes away this flag should
 be turned off to avoid duplication of code. (The bug, if that's what it
-is, causes the last raw offset to be used rather than the median offset.)
+is, causes the last raw offset to be used rather than the median offset.)
+
 
 
      Without this defined (and without ARCRON_MULTIPLE_SAMPLES below)
 a typical set of offsets reported and used to drive the clock-filter algorithm
 is (oldest last):
-
      filtoffset=  -4.32  -34.82   -0.78    0.89    2.76    4.58   -3.92   -2.17
      
+
      filtoffset=  -4.32  -34.82   -0.78    0.89    2.76    4.58   -3.92   -2.17
      
 Look at that spike!
 
 
      With this defined a typical set of offsets is:
-
      filtoffset=  -7.06   -7.06   -2.91   -2.91   -2.91   -1.27   -9.54   -6.70
      
+
      filtoffset=  -7.06   -7.06   -2.91   -2.91   -2.91   -1.27   -9.54   -6.70
      
 with the repeated values being some evidence of outlyers being discarded.
 
      
 ARCRON_MULTIPLE_SAMPLES
      
@@ -546,16 +547,14 @@ the system log at level LOG_NOTICE; note that each resync drains
 the unit's batteries, so the syslog entry seems justified.
 
 
      Syslog entries are of the form:
-
      -May 10 10:15:24 oolong ntpd[615]: ARCRON: unit 0: sending resync command
+
      May 10 10:15:24 oolong ntpd[615]: ARCRON: unit 0: sending resync command
 May 10 10:17:32 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock
 May 10 11:13:01 oolong ntpd[615]: ARCRON: unit 0: sending resync command
 May 10 11:14:06 oolong ntpd[615]: ARCRON: sync finished, signal quality -1: UNKNOWN, will use clock anyway
 May 10 11:41:49 oolong ntpd[615]: ARCRON: unit 0: sending resync command
 May 10 11:43:57 oolong ntpd[615]: ARCRON: sync finished, signal quality 5: OK, will use clock
 May 10 12:39:26 oolong ntpd[615]: ARCRON: unit 0: sending resync command
-May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, will use clock
-
      
+May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, will use clock
      
 
 
      
 Fudge Factors
      
@@ -626,7 +625,7 @@ Additional Information
 Reference Clock Drivers
 
 
      ARC Rugby MSF Receiver
-page
+page 
 
      
 
      
 Damon Hart-Davis (d@hd.org)
      
diff --git a/html/driver28.htm b/html/driver28.htm
index 3917ec2141..787ccb4178 100644
--- a/html/driver28.htm
+++ b/html/driver28.htm
@@ -24,29 +24,27 @@ and 1, and world access for unit 2 and 3
 
      
 Structure of shared memory-segment
      
 
-
      -struct shmTime {
-  int    mode; /* 0 - if valid set
-                *       use values, 
-                *       clear valid
-                * 1 - if valid set 
-                *       if count before and after read of 
-                *       values is equal,
-                *         use values 
-                *       clear valid
-                */
-  int    count;
-  time_t clockTimeStampSec;      /* external clock */
-  int    clockTimeStampUSec;     /* external clock */
-  time_t receiveTimeStampSec;    /* internal clock, when external value was received */
-  int    receiveTimeStampUSec;   /* internal clock, when external value was received */
-  int    leap;
-  int    precision;
-  int    nsamples;
-  int    valid;
-  int    dummy[10]; 
-};
-
      
+
      struct shmTime {
+  int    mode; /* 0 - if valid set
+                *       use values, 
+                *       clear valid
+                * 1 - if valid set 
+                *       if count before and after read of 
+                *       values is equal,
+                *         use values 
+                *       clear valid
+                */
+  int    count;
+  time_t clockTimeStampSec;      /* external clock */
+  int    clockTimeStampUSec;     /* external clock */
+  time_t receiveTimeStampSec;    /* internal clock, when external value was received */
+  int    receiveTimeStampUSec;   /* internal clock, when external value was received */
+  int    leap;
+  int    precision;
+  int    nsamples;
+  int    valid;
+  int    dummy[10]; 
+};
      
 
 
      
 Operation mode=0
      
@@ -124,7 +122,8 @@ Not used by this driver.
 flag4 0 | 1
 
 
      
-Not used by this driver.
+Not used by this driver.
      
+
 
 
      Additional Information
 
diff --git a/html/driver3.htm b/html/driver3.htm
index a9494dd76e..47511d85b9 100644
--- a/html/driver3.htm
+++ b/html/driver3.htm
@@ -36,8 +36,7 @@ fudge time1 parameter can be used for vernier corrections.
 
      Using the poll sequence QTQDQM, the response timecode is in
 three sections totalling 50 ASCII printing characters, as concatenated
 by the driver, in the following format:
-
      -ahh:mm:ss.fffs<cr> yy/dd/mm/ddd<cr>
+
      ahh:mm:ss.fffs<cr> yy/dd/mm/ddd<cr>
 frdzycchhSSFTttttuuxx<cr>
 
 on-time = first <cr>
@@ -58,8 +57,7 @@ F = current receive frequency (4 = 15 MHz)
 T = transmitter (C = WWV, H = WWVH)
 tttt = time since last update (0000 = minutes)
 uu = flush character (03 = ^c)
-xx = 94 (unknown)
-
      
+xx = 94 (unknown)
      
 The alarm condition is indicated by other than 8 at a,
 which occurs during initial synchronization and when received signal is
 lost for an extended period; unlock condition is indicated by other than
@@ -124,7 +122,7 @@ Not used by this driver.
 
      
 Additional Information
 
-
      Reference Clock Drivers
+
      Reference Clock Drivers 
 
      
 
      
 David L. Mills (mills@udel.edu)
      
diff --git a/html/driver30.htm b/html/driver30.htm
index d4266e406d..8d547b180c 100644
--- a/html/driver30.htm
+++ b/html/driver30.htm
@@ -1,116 +1,153 @@
-
-
-Motorola Oncore GPS Receiver
-
      
-Motorola Oncore GPS receiver
-
      
-
-
      Synopsis
      
+
+
+
+   
+   
+   Motorola Oncore GPS Receiver
+
+
+
+
+
      
+Motorola Oncore GPS receiver
      
+
+
      
+
      
+Synopsis
      
 
 Address: 127.127.30.0
 
      Reference ID: GPS
 
      Driver ID: ONCORE
-
      Serial Port: /dev/oncore.serial.u; 9600 baud,
-8-bits, no parity
-
      PPS Port: /dev/oncore.pps.u;
-PPS_CAPTUREASSERT required,
-PPS_OFFSETASSERT supported.
-
-
      Description
      
-
+
      Serial Port: /dev/cuaa0; 9600 baud, 8-bits, no parity
+
      PPS Port: /dev/xpps0; PPS_CAPTUREASSERT
+required, PPS_OFFSETASSERT supported.
+
      
+Description
      
 This driver supports various models of the Motorola Oncore GPS receivers.
-as long as they support the Motorola Binary Protocol.
      The two
-most interesting version of the Oncore are the "UT+" and the
-"Remote" which is a prepackaged "UT+". The evaluation kit can
-also be recommended, it interfaces to a PC straightaway, using the
+HREF="http://www.mot.com/AECS/PNSB/products">Motorola Oncore GPS
+receivers. as long as they support the Motorola Binary
+Protocol.
+
+
      The two most interesting version of the Oncore are the "UT+" 
+and the "Remote" which is a prepackaged "UT+".  The evaluation kit
+can also be recommended, it interfaces to a PC straightaway, using the
 parallel port for PPS input (supported under FreeBSD), and packs the
 receiver in a nice and sturdy box.
-
-
      
-
+
       
+
      
+
 
+
 
-
-
-
-
+
 
+
+
+
+
      
 
      
 
 
      
 
 
      UT+ oncore
      Evaluation kit
      Oncore Remote
      
+
      UT+ oncore
      
+      		
+
      Evaluation kit
      
+      		
+
      Oncore Remote
      
+
      
 
      
 
-
      The driver requires a standard PPS interface for the
-pulse-per-second output from the receiver. The serial data stream alone
+
      The driver requires a standard PPS interface for the pulse-
+per-second output from the receiver.  The serial data stream alone
 does not provide precision time stamps (0-50msec variance, according to
 the manual), whereas the PPS output is precise down to 50 nsec (1 sigma)
-for the UT models.
-
-
      The driver will use the "position hold" mode if available, with
-either the receivers built-in site-survey or a similar algorithm
-implemented in this driver.
-
-
      Please check the source file for more info on configuration of this
-driver.
-
-
      Monitor Data
      
-
-The driver is quite chatty on stdout if ntpd is run with debugging.
+for the UT models. 
      The driver will use the "position hold" mode if
+available, with either the receivers built-in site-survey or a similar
+algorithm implemented in this driver.
+
      
+Monitor Data
      
+The driver is quite chatty on stdout if ntpd is run with
+debugging. 
 A manual will be required though.
-
-
      Fudge Factors
      
+
      
+Fudge Factors
      
 
 
      
+
      
+time1 time
      
 
-
      time1 time
      
-
      Specifies the time offset calibration factor, in seconds and
-fraction, with default 0.0.
      
+
      
+Specifies the time offset calibration factor, in seconds and fraction,
+with default 0.0.
      
 
-
      time2 time
      
-
      Not used by this driver.
      
+
      
+time2 time
      
 
-
      stratum number
      
-
      Specifies the driver stratum, in decimal from 0 to 15, with default
-0.
      
+
      
+Not used by this driver.
      
 
-
      refid string
      
-
      Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default GPS.
      
+
      
+stratum number
      
 
-
      flag1 0 | 1
      
-
      Not used by this driver.
      
+
      
+Specifies the driver stratum, in decimal from 0 to 15, with default
+0.
      
 
-
      flag2 0 | 1
      
-
      Assume GPS receiver is on a mobile platform if set.
      
+
      
+refid string
      
 
-
      flag3 0 | 1
      
-
      Not used by this driver.
      
+
      
+Specifies the driver reference identifier, an ASCII string from one to
+four characters, with default GPS.
      
 
-
      flag4 0 | 1
      
-
      Not used by this driver.
      
+
      
+flag1 0 | 1
      
 
-
      
+
      
+Not used by this driver.
      
 
-Additional Information
+
      
+flag2 0 | 1
      
 
-
      The driver has been developed under FreeBSD, and may still be pretty
-FreeBSD centric. Patches are most welcome.
+
      
+Assume GPS receiver is on a mobile platform if set.
      
 
-
      Performance
+
      
+flag3 0 | 1
      
 
-
      Really good. With the UT+, the generated PPS pulse is referenced
-to UTC(GPS) with better than 50 nsec (1 sigma) accuracy.
-
      Actual measurements can be found here: Oncore UT+ performance
-measurements
+
      
+Not used by this driver.
      
 
-
      The limiting factor will be the timebase of the computer and the
-precision with which you can timestamp the rising flank of the PPS
-signal.
+
      
+flag4 0 | 1
      
 
-
      Poul-Henning Kamp (phk@FreeBSD.org)
      
+
      
+Not used by this driver.
      
+
      
+Additional Information
+
      The driver has been developed under FreeBSD, and may still be pretty
+FreeBSD centric.  Patches are most welcome.
+
      Performance
+
      Really good.  With the UT+, the generated PPS pulse is
+referenced
+to UTC(GPS) with better than 50 nsec (1 sigma) accuracy.  The
+limiting factor will be the timebase of the computer and the precision
+with which you can timestamp the rising flank of the
+PPS signal. 
+Using FreeBSD,  a FPGA based Timecounter/PPS interface
+and
+an ovenized quartz oscillator, that performance has been reproduced.
+ For
+more details on this aspect:  Sub-Microsecond
+timekeeping under FreeBSD
+
      
+
      
+Poul-Henning Kamp (phk@FreeBSD.org)
      
+
+
 
diff --git a/html/driver4.htm b/html/driver4.htm
index 7d22907c76..460ab3e99e 100644
--- a/html/driver4.htm
+++ b/html/driver4.htm
@@ -38,28 +38,24 @@ is available with both the Netclock/2 and 8170, and format 2, which is
 available only with the Netclock/2 and specially modified 8170.
 
 
      Format 0 (22 ASCII printing characters):
-
      -<cr><lf>i  ddd hh:mm:ss  TZ=zz<cr><lf>
+
      <cr><lf>i  ddd hh:mm:ss  TZ=zz<cr><lf>
 
 on-time = first <cr>
 i = synchronization flag (' ' = in synch, '?' = out synch)
-hh:mm:ss = hours, minutes, seconds
-
      
+hh:mm:ss = hours, minutes, seconds
      
 The alarm condition is indicated by other than ' ' at i, which
 occurs during initial synchronization and when received signal is lost
 for about ten hours.
 
 
      Format 2 (24 ASCII printing characters):
-
      -<cr><lf>iqyy ddd hh:mm:ss.fff ld
+
      <cr><lf>iqyy ddd hh:mm:ss.fff ld
 
 on-time = <cr>
 i = synchronization flag (' ' = in synch, '?' = out synch)
 q = quality indicator (' ' = locked, 'A'...'D' = unlocked)
 yy = year (as broadcast)
 ddd = day of year
-hh:mm:ss.fff = hours, minutes, seconds, milliseconds
-
      
+hh:mm:ss.fff = hours, minutes, seconds, milliseconds
      
 The alarm condition is indicated by other than ' ' at i, which
 occurs during initial synchronization and when received signal is lost
 for about ten hours. The unlock condition is indicated by other than '
@@ -143,7 +139,7 @@ Enable verbose clockstats recording if set.
 
 Additional Information
 
-
      Reference Clock Drivers
+
      Reference Clock Drivers 
 
      
 
      
 David L. Mills (mills@udel.edu)
      
diff --git a/html/driver5.htm b/html/driver5.htm
index 41b6682275..edbd045829 100644
--- a/html/driver5.htm
+++ b/html/driver5.htm
@@ -29,8 +29,7 @@ others in the same model family that use the same timecode formats.
 
 
      Most of this code is originally from refclock_wwvb.c with thanks. It
 has been so mangled that wwvb is not a recognizable ancestor.
-
      -Timcode format: ADDD:HH:MM:SSQCL
+
      Timcode format: ADDD:HH:MM:SSQCL
 
 A - control A (this is stripped before we see it)
 Q - Quality indication (see below)
@@ -39,26 +38,25 @@ L - Line feed
 
 Quality codes indicate possible error of
 
-        468-DC GOES Receiver:
-        GPS-TM/TMD Receiver:
-                ? +/- 500 milliseconds  # +/- 50 milliseconds
-                * +/- 5 milliseconds    . +/- 1 millisecond
-                space less than 1 millisecond
+        468-DC GOES Receiver:
+        GPS-TM/TMD Receiver:
+                ? +/- 500 milliseconds  # +/- 50 milliseconds
+                * +/- 5 milliseconds    . +/- 1 millisecond
+                space less than 1 millisecond
 
-        OM-DC OMEGA Receiver:
+        OM-DC OMEGA Receiver:
 
-                > +/- 5 seconds
+                > +/- 5 seconds
 
-                ? +/- 500 milliseconds  # +/- 50 milliseconds
-                * +/- 5 milliseconds    . +/- 1 millisecond
+                ? +/- 500 milliseconds  # +/- 50 milliseconds
+                * +/- 5 milliseconds    . +/- 1 millisecond
 
-                A-H less than 1 millisecond. Character indicates which
+                A-H less than 1 millisecond. Character indicates which
 station
-                is being received as follows: A = Norway, B = Liberia,
-                C = Hawaii, D = North Dakota, E = La Reunion, F =
+                is being received as follows: A = Norway, B = Liberia,
+                C = Hawaii, D = North Dakota, E = La Reunion, F =
 Argentina,
-                G = Australia, H = Japan.
-
      
+                G = Australia, H = Japan.
      
 The carriage return start bit begins on 0 seconds and extends to 1 bit
 time.
 
@@ -152,7 +150,7 @@ Not used by this driver.
 
 Additional Information
 
-
      Reference Clock Drivers
+
      Reference Clock Drivers 
 
      
 
      
 David L. Mills (mills@udel.edu)
      
diff --git a/html/driver6.htm b/html/driver6.htm
index 66b6b304fa..a728a542ad 100644
--- a/html/driver6.htm
+++ b/html/driver6.htm
@@ -1,244 +1,253 @@
-
-IRIG Audio Decoder II for Sun SPARCstation
-
      
-IRIG Audio Decoder II for Sun SPARCstation
-
      
-
-
      Synopsis
      
-
+
+
+   
+   
+   IRIG Audio Decoder II for Sun SPARCstation
+
+
+
+
+
      
+IRIG Audio Decoder
      
+
+
      
+
      
+Synopsis
      
 Address: 127.127.6.u
 
      Reference ID: IRIG
 
      Driver ID: IRIG_AUDIO
 
      Audio Device: /dev/audio and /dev/audioctl
 
 
      Note: This driver supersedes an older one of the same name, address
-and ID which required replacing the original kernel audio driver with
-another which works only on older Sun SPARCstation systems. The new
-driver described here uses the stock kernel audio driver and works in
-SunOS 4.1.3 and Solaris 2.6 versions and probably all versions in
-between. The new driver requires no modification of the operating
-system. While it is generic and likely portable to other systems, it is
-somewhat slower than the original, since the extensive signal
-conditioning, filtering and decoding is done in user space, not kernel
-space.
-
-
      Description
      
-
-This driver supports the Inter-Range Instrumentation Group (IRIG)
-standard time distribution signal using the audio codec native to the
-Sun SPARCstation. This signal is generated by several radio clocks,
-including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom
-and TrueTime, among others, although it is often an add-on option. The
-signal is connected via an optional attenuator box and cable to either
-the microphone or line-in ports on a Sun SPARCstation
-/dev/audio audio codec device. The driver receives, demodulates
-and decodes the IRIG-B and IRIG-E signal formats using internal filters
-designed to reduce the effects of noise and interfering signals.
-
-
      The IRIG signal format uses an amplitude-modulated carrier with
-pulse-width modulated data bits. For IRIG-B, the carrier frequency is
-1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequency is 100
-Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy,
-generally within a few tens of microseconds relative to IRIG time, it
-can also generate a significant load on the processor with older
-workstations. Generally, the accuracy with IRIG-E is about ten times
-worse than IRIG-B, but the processor load is ten times less.
+and ID which required replacing the original kernel audio driver with another
+which works only on older Sun SPARCstation systems. The new driver described
+here uses the stock kernel audio driver and works in SunOS 4.1.3 and Solaris
+2.6 versions and probably all versions in between. The new driver requires
+no modification of the operating system. While it is generic and likely
+portable to other systems, it is somewhat slower than the original, since
+the extensive signal conditioning, filtering and decoding is done in user
+space, not kernel space.
+
      
+Description
      
+This driver supports the Inter-Range Instrumentation Group (IRIG) standard
+time distribution signal using the audio codec native to the Sun SPARCstation.
+This signal is generated by several radio clocks, including those made
+by Arbiter, Austron, Bancomm, Odetics, Spectracom and TrueTime, among others,
+although it is often an add-on option. The signal is connected via an optional
+attenuator box and cable to either the microphone or line-in ports on a
+Sun SPARCstation /dev/audio audio codec device. The driver receives,
+demodulates and decodes the IRIG-B and IRIG-E signal formats using internal
+filters designed to reduce the effects of noise and interfering signals.
+
+
      The IRIG signal format uses an amplitude-modulated carrier with pulse-width
+modulated data bits. For IRIG-B, the carrier frequency is 1000 Hz and bit
+rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 Hz and bit rate
+10 b/s. While IRIG-B provides the best accuracy, generally within a few
+tens of microseconds relative to IRIG time, it can also generate a significant
+load on the processor with older workstations. Generally, the accuracy
+with IRIG-E is about ten times worse than IRIG-B, but the processor load
+is ten times less.
 
 
      The program processes 8000-Hz mu-law companded samples using separate
 signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector
-and automatic threshold corrector. Cycle crossings relative to the
-corrected slice level determine the width of each pulse and its value -
-zero, one or position identifier. The data encode 20 BCD digits which
-determine the second, minute, hour and day of the year and sometimes the
-year and synchronization condition. The comb filter exponentially
-averages the corresponding samples of successive baud intervals in order
-to reliably identify the reference carrier cycle. A type-II phase-lock
-loop (PLL) performs additional integration and interpolation to
-accurately determine the zero crossing of that cycle, which determines
-the reference timestamp. A pulse-width discriminator demodulates the
-data pulses, which are then encoded as the BCD digits of the timecode.
+and automatic threshold corrector. Cycle crossings relative to the corrected
+slice level determine the width of each pulse and its value - zero, one
+or position identifier. The data encode 20 BCD digits which determine the
+second, minute, hour and day of the year and sometimes the year and synchronization
+condition. The comb filter exponentially averages the corresponding samples
+of successive baud intervals in order to reliably identify the reference
+carrier cycle. A type-II phase-lock loop (PLL) performs additional integration
+and interpolation to accurately determine the zero crossing of that cycle,
+which determines the reference timestamp. A pulse-width discriminator demodulates
+the data pulses, which are then encoded as the BCD digits of the timecode.
 The timecode and reference timestamp are updated once each second with
-IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved
-for later processing. At poll intervals of 64 s, the saved samples are
-processed by a trimmed-mean filter and used to update the system clock.
+IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved for
+later processing. At poll intervals of 64 s, the saved samples are processed
+by a trimmed-mean filter and used to update the system clock.
 
 
      Infinite impulse response (IIR) filters are used with both IRIG-B and
-IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a 130-
-Hz lowpass filter for IRIG-E. These are intended for use with noisy
-signals, such as might be received over a telephone line or radio
-circuit, or when interfering signals may be present in the audio
-passband. The driver determines which IRIG format is in use by sampling
-the amplitude of each filter output and selecting the one with maximum
-signal. An automatic gain control feature provides protection against
-overdriven or underdriven input signal amplitudes. It is designed to
-maintain adequate demodulator signal amplitude while avoiding occasional
-noise spikes. In order to assure reliable capture, the decompanded input
-signal amplitude must be greater than 100 units and the codec sample
-frequency error less than 250 PPM (.025 percent).
-
-
      The program performs a number of error checks to protect against
-overdriven or underdriven input signal levels, incorrect signal format
-or improper hardware configuration. Specifically, if any of the
-following errors occur for a timecode, the data are rejected.
-Specifically, if any of the following errors occur for a time
-measurement, the data are rejected.
-
+IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a 130-Hz
+lowpass filter for IRIG-E. These are intended for use with noisy signals,
+such as might be received over a telephone line or radio circuit, or when
+interfering signals may be present in the audio passband. The driver determines
+which IRIG format is in use by sampling the amplitude of each filter output
+and selecting the one with maximum signal. An automatic gain control feature
+provides protection against overdriven or underdriven input signal amplitudes.
+It is designed to maintain adequate demodulator signal amplitude while
+avoiding occasional noise spikes. In order to assure reliable capture,
+the decompanded input signal amplitude must be greater than 100 units and
+the codec sample frequency error less than 250 PPM (.025 percent).
+
+
      The program performs a number of error checks to protect against overdriven
+or underdriven input signal levels, incorrect signal format or improper
+hardware configuration. Specifically, if any of the following errors occur
+for a timecode, the data are rejected. Secifically, if any of the following
+errors occur for a time measurement, the data are rejected.
 
        
-
-
      1. The peak carrier amplitude is less than 100 units. This usually
-means dead IRIG signal source, broken cable or wrong input port.
        2. 
-
-
      2. The frequency error is greater than +-250 PPM (.025 percent). This
-usually means broken codec hardware or wrong codec configuration.
        3. 
-
-
      3. The modulation index is less than 0.5. This usually means overdriven
-IRIG signal or wrong IRIG format.
        4. 
-
-
      4. A frame synchronization error has occurred. This usually means wrong
-IRIG signal format or the IRIG signal source has lost synchronization
-(signature control).
        5. 
-
-
      5. A data decoding error has occurred. This usually means wrong IRIG
-signal format.
        6. 
-
-
      6. The current second of the day is not exactly one greater than the
-previous one. This usually means a very noisy IRIG signal or
-insufficient CPU resources.
        7. 
-
-
      7. An audio codec error (overrun) occurred. This usually means
-insufficient CPU resources, as sometimes happens with Sun SPARC IPCs
-when doing something useful.
        8. 
-
+
      8. 
+The peak carrier amplitude is less than 100 units. This usually means dead
+IRIG signal source, broken cable or wrong input port.
        9. 
+
+
         
+
      9. 
+The frequency error is greater than +-250 PPM (.025 percent). This usually
+means broken codec hardware or wrong codec configuration.
        10. 
+
+
         
+
      10. 
+The modulation index is less than 0.5. This usually means overdriven IRIG
+signal or wrong IRIG format.
        11. 
+
+
         
+
      11. 
+A frame synchronization error has occured. This usually means wrong IRIG
+signal format or the IRIG signal source has lost synchronization (signature
+control).
        12. 
+
+
         
+
      12. 
+A data decoding error has occured. This usually means wrong IRIG signal
+format.
        13. 
+
+
         
+
      13. 
+The current second of the day is not exactly one greater than the previous
+one. This usually means a very noisy IRIG signal or insufficient CPU resources.
        14. 
+
+
         
+
      14. 
+An audio codec error (overrun) occured. This usually means insufficient
+CPU resources, as sometimes happens with Sun SPARC IPCs when doing something
+useful.
        15. 
 
      
-
-Note that additional checks are done elsewhere in the reference clock
-interface routines.
-
-
      Unlike other drivers, which can have multiple instantiations, this
-one supports only one. It does not seem likely that more than one audio
-codec would be useful in a single machine. More than one would probably
-chew up too much CPU time anyway.
-
-
      IRIG-B Timecode Format
      
-
-The 100 elements of the IRIG timecode are numbered from 0 through 99.
-Position identifiers occur at elements 0, 9, 19 and every ten thereafter
-to 99. The control function (CF) elements begin at element 50 (CF 1) and
-extend to element 78 (CF 27). The straight-binary-seconds (SBS) field,
-which encodes the seconds of the UTC day, begins at element 80 (CF 28)
-and extends to element 97 (CF 44). The encoding of elements 50 (CF 1)
-through 78 (CF 27) is device dependent. This driver presently decodes
-the CF elements, but does nothing with them.
-
-
      Where feasible, the IRIG signal source should be operated with
-signature control so that, if the signal is lost or mutilated, the
-source produces an unmodulated signal, rather than possibly random
-digits. The driver will automatically reject the data and declare itself
-unsynchronized in this case. Some devices, in particular Spectracom
-radio/satellite clocks, provide additional year and status indication in
-the format:
-
-
      -     Element  
-CF        Function
-     -------------------------------------
-     55       
-6         time sync status
-     60-63     10-
-13     BCD year units
-     65-68     15-
-18     BCD year tens
-
      
-
+Note that additional checks are done elsewhere in the reference clock interface
+routines.
+
+
      Unlike other drivers, which can have multiple instantiations, this one
+supports only one. It does not seem likely that more than one audio codec
+would be useful in a single machine. More than one would probably chew
+up too much CPU time anyway.
+
      
+IRIG-B Timecode Format
      
+The 100 elements of the IRIG timecode are numbered from 0 through 99. Position
+identifiers occur at elements 0, 9, 19 and every ten thereafter to 99.
+The control function (CF) elements begin at element 50 (CF 1) and extend
+to element 78 (CF 27). The straight-binary-seconds (SBS) field, which encodes
+the seconds of the UTC day, begins at element 80 (CF 28) and extends to
+element 97 (CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27)
+is device dependent. This driver presently decodes the CF elements, but
+does nothing with them.
+
+
      Where feasible, the IRIG signal source should be operated with signature
+control so that, if the signal is lost or mutilated, the source produces
+an unmodulated signal, rather than possibly random digits. The driver will
+automatically reject the data and declare itself unsynchronized in this
+case. Some devices, in particular Spectracom radio/satellite clocks, provide
+additional year and status indication in the format:
+
           Element   CF        Function
+     -------------------------------------
+     55        6         time sync status
+     60-63     10-13     BCD year units
+     65-68     15-18     BCD year tens
      
 Other devices set these elements to zero.
-
-
      Performance
      
-
+
      
+Performance
      
 The mu-law companded data format allows considerable latitude in signal
 levels; however, an automatic gain control (AGC) function is implemented
-to further compensate for varying input signal levels and to avoid
-signal distortion. For proper operation, the IRIG signal source should
-be configured for analog signal levels, NOT digital TTL levels.
-
-
      The accuracy of the system clock synchronized to the IRIG-B source
-with this driver and the ntpd daemon is 10-20 microseconds with
-a Sun UltraSPARC II and maybe twice that with a Sun SPARC IPC. The
-processor resources consumed by the daemon can be significant, ranging
-from about 1.2 percent on the faster UltraSPARC II to 38 percent on the
-slower SPARC IPC. However, the overall timing accuracy is limited by the
-resolution and stability of the CPU clock oscillator and the interval
-between clock corrections, which is 64 s with this driver. This
-performance, while probably the best that can be achieved by the daemon
-itself, can be improved with assist from the PPS discipline as described
-elsewhere in the documentation.
-
-
      Monitor Data
      
-
+to further compensate for varying input signal levels and to avoid signal
+distortion. For proper operation, the IRIG signal source should be configured
+for analog signal levels, NOT digital TTL levels.
+
+
      The accuracy of the system clock synchronized to the IRIG-B source with
+this driver and the ntpd daemon is 10-20 microseconds with a Sun
+UltraSPARC II and maybe twice that with a Sun SPARC IPC. The processor
+resources consumed by the daemon can be significant, ranging from about
+1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC
+IPC. However, the overall timing accuracy is limited by the resolution
+and stability of the CPU clock oscillator and the interval between clock
+corrections, which is 64 s with this driver. This performance, while probably
+the best that can be achieved by the daemon itself, can be improved with
+assist from the PPS discipline as described elsewhere in the documentation.
+
      
+Monitor Data
      
 The timecode format used for debugging and data recording includes data
-helpful in diagnosing problems with the IRIG signal and codec
-connections. With debugging enabled (-d -d -d on the ntpd command line),
-the driver produces one line for each timecode in the following format:
-
+helpful in diagnosing problems with the IRIG signal and codec connections.
+With debugging enabled (-d -d -d on the ntpd command line), the driver
+produces one line for each timecode in the following format:
 
      00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 3094572411.00027
      
-
-The first field contains the error flags in hex, where the hex bits are
-interpreted as below. This is followed by the IRIG status indicator,
-year of century, day of year and time of day. The status indicator and
-year are not produced by some IRIG devices. Following these fields are
-the signal amplitude (0-8100), codec gain (0-255), field phase (0-79),
-time constant (2-20), modulation index (0-1), carrier phase error (0+-
-0.5) and carrier frequency error (PPM). The last field is the on-time
-timestamp in NTP format. The fraction part is a good indicator of how
-well the driver is doing. With an UltrSPARC 30, this is normally within
-a few tens of microseconds relative to the IRIG-B signal and within a
-few hundred microseconds with IRIG-E.
-
-
      Fudge Factors
      
+The first field containes the error flags in hex, where the hex bits are
+interpreted as below. This is followed by the IRIG status indicator, year
+of century, day of year and time of day. The status indicator and year
+are not produced by some IRIG devices. Following these fields are the signal
+amplitude (0-8100), codec gain (0-255), field phase (0-79), time constant
+(2-20), modulation index (0-1), carrier phase error (0+-0.5) and carrier
+frequency error (PPM). The last field is the on-time timestamp in NTP format.
+The fraction part is a good indicator of how well the driver is doing.
+With an UltrSPARC 30, this is normally within a few tens of microseconds
+relative to the IRIG-B signal and within a few hundred microseconds with
+IRIG-E.
+
      
+Fudge Factors
      
 
 
      
+
      
+time1 time
      
 
-
      time1 time
      
-
-
      Specifies the time offset calibration factor, in seconds and
-fraction, with default 0.0.
      
-
-
      time2 time
      
+
      
+Specifies the time offset calibration factor, in seconds and fraction,
+with default 0.0.
      
 
-
      Not used by this driver.
      
+
      
+time2 time
      
 
-
      stratum number
      
+
      
+Not used by this driver.
      
 
-
      Specifies the driver stratum, in decimal from 0 to 15, with default
-0.
      
+
      
+stratum number
      
 
-
      refid string
      
+
      
+Specifies the driver stratum, in decimal from 0 to 15, with default 0.
      
 
-
      Specifies the driver reference identifier, an ASCII string from one
-to four characters, with default IRIG.
      
+
      
+refid string
      
 
-
      flag1 0 | 1
      
+
      
+Specifies the driver reference identifier, an ASCII string from one to
+four characters, with default IRIG.
      
 
-
      Not used by this driver.
      
+
      
+flag1 0 | 1
      
 
-
      flag2 0 | 1
      
+
      
+Not used by this driver.
      
 
-
      Specifies the microphone port if set to zero or the line-in port if
-set to one. It does not seem useful to specify the compact disc player
-port.
      
+
      
+flag2 0 | 1
      
 
-
      flag3 0 | 1
      
+
      
+Specifies the microphone port if set to zero or the line-in port if set
+to one. It does not seem useful to specify the compact disc player port.
      
 
-
      Enables audio monitoring of the input signal. For this purpose, the
-speaker volume must be set before the driver is started.
      
+
      
+flag3 0 | 1
      
 
-
      flag4 0 | 1
      
+
      
+Enables audio monitoring of the input signal. For this purpose, the speaker
+volume must be set before the driver is started.
      
 
-
      Enable verbose clockstats recording if set.
      
+
      
+flag4 0 | 1
      
 
+
      
+Enable verbose clockstats recording if set.
      
 
      
-
 Additional Information
 
-
      Reference Clock Drivers
      
-David L. Mills (mills@udel.edu)
-
      
+
      Reference Clock Drivers 
+
      
+
      
+David L. Mills (mills@udel.edu)
      
+
+
+
diff --git a/html/driver7.htm b/html/driver7.htm
index 1d377e6440..0394fbfb32 100644
--- a/html/driver7.htm
+++ b/html/driver7.htm
@@ -61,7 +61,7 @@ polarity.
 
      Format A bursts are sent at seconds 32 through 39 of the minute in hex
 digits
 
-
          6dddhhmmss6dddhhmmss
+
          6dddhhmmss6dddhhmmss
 
 
      The first ten digits encode a frame marker (6) followed by
 the day (ddd), hour (hh in UTC), minute (mm)
@@ -72,7 +72,7 @@ are then repeated with the same polarity.
 
 
      Format B bursts are sent at second 31 of the minute in hex digits
 
-
          xdyyyyttaaxdyyyyttaa
+
          xdyyyyttaaxdyyyyttaa
 
 
      The first ten digits encode a code (x described below) followed
 by the DUT1 (d in deciseconds), Gregorian year (yyyy),
@@ -81,11 +81,11 @@ peculiar to Canada. These digits are then repeated with inverted polarity.
 
 
      The x is coded
 
-
      1    Sign of DUT (0 = +)
-
      2    Leap second warning. One second will be added.
-
      4    Leap second warning. One second will be subtracted.
+
      1    Sign of DUT (0 = +)
+
      2    Leap second warning. One second will be added.
+
      4    Leap second warning. One second will be subtracted.
 This is not likely to happen in our universe.
-
      8    Even parity bit for this nibble.
+
      8    Even parity bit for this nibble.
 
 
      By design, the last stop bit of the last character in the burst coincides
 with 0.5 second. Since characters have 11 bits and are transmitted at 300
@@ -102,7 +102,7 @@ With debugging enabled (-d -d -d on the ntpd command
 line), the driver produces one line for each burst in two formats corresponding
 to format A and B. Following is format A:
 
-
          n b f s m code
+
          n b f s m code
 
 
      where n is the number of characters in the burst (0-11), b
 the burst distance (0-40), f the field alignment (-1, 0,
@@ -110,7 +110,7 @@ to format A and B. Following is format A:
 number (2-9) and code the burst characters as received. Note that
 the hex digits in each character are reversed, so the burst
 
-
          10 38 0 16 9 06851292930685129293
+
          10 38 0 16 9 06851292930685129293
 
 
      is interpreted as containing 11 characters with burst distance 38, field
 alignment 0, synchronization distance 16 and burst number 9. The nibble-swapped
@@ -123,7 +123,7 @@ results in a signal level near 1000.
 
 
      Following is format B:
 
-
          n b s code
+
          n b s code
 
 
      where n is the number of characters in the burst (0-11), b
 the burst distance (0-40), s the synchronization distance
@@ -131,7 +131,7 @@ results in a signal level near 1000.
 hex digits in each character are reversed and the last ten digits inverted,
 so the burst
 
-
          11 40 1091891300ef6e76ecff
+
          11 40 1091891300ef6e76ecff
 
 
      is interpreted as containing 11 characters with burst distance 40. The
 nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI - UTC
@@ -141,7 +141,7 @@ nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI - UTC
 to the clockstats file and debug score after the last burst received in
 the minute. The format is
 
-
          qq yyyy ddd hh:mm:ss nn dd tt
+
          qq yyyy ddd hh:mm:ss nn dd tt
 
 
      where qq are the error flags, as described below, yyyy
 is the year, ddd the day, hh:mm:ss the time of day,
@@ -218,7 +218,7 @@ Enable verbose clockstats recording if set.
 
 Additional Information
 
-
      Reference Clock Drivers
+
      Reference Clock Drivers 
 
      
 
      
 David L. Mills (mills@udel.edu)
      
diff --git a/html/driver8.htm b/html/driver8.htm
index b54a703d55..890b6c5e97 100644
--- a/html/driver8.htm
+++ b/html/driver8.htm
@@ -27,7 +27,8 @@ machines.
 
      The actual receiver status is mapped into various synchronization
 states generally used by receivers. The STREAMS module is configured to
 interpret the time codes of DCF C51, PZF535, PZF509, GPS166, Trimble SV6
-GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see list below).
+GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see list
+below).
 
 
      The reference clock support in ntp contains the necessary
 configuration tables for those receivers. In addition to supporting
@@ -74,37 +75,26 @@ listed in refclock_status. Additional feature flags of the receiver are
 optionally listed in parentheses. The actual time code is listed in
 timecode.
 A qualification of the decoded time code format is following in
-refclock_format.
-The last piece of information is the overall running time and the
-accumulated
-times for the clock event states in refclock_states. When PPS
-information
-is present additional variable are available. refclock_ppstime lists
-then
-the PPS timestamp and refclock_ppsskew lists the difference between
-RS232
+refclock_format. The last piece of information is the overall running
+time and the accumulated times for the clock event states in
+refclock_states. When PPS information is present additional variable are
+available. refclock_ppstime lists then the PPS timestamp and
+refclock_ppsskew lists the difference between RS232
 derived timestamp and the PPS timestamp.
 
 
      Currently, fourteen clock types (devices /dev/refclock-0 -
-/dev/refclock-3)
-are supported by the PARSE driver.
+/dev/refclock-3) are supported by the PARSE driver.
 
      A note on the implementations:
-
      • These implementations where mainly done WITHOUT actual
-access to the hardware. Thus not all implementations provide full
-support.
-The development was done with the help of many souls who had the
-hardware
-and where so kind to borrow me their time an patience during the
-development
-and debugging cycle. Thus for continued support and quality direct
-access
-to the receivers is a big help. Nevertheless i am not prepared to buy
-these
-reference clocks - donations to me
+
        • These implementations where mainly done WITHOUT
+actual access to the hardware. Thus not all implementations provide full
+support. The development was done with the help of many souls who had
+the hardware and where so kind to borrow me their time an patience
+during the development and debugging cycle. Thus for continued support
+and quality direct access to the receivers is a big help. Nevertheless i
+am not prepared to buy these reference clocks - donations to me
 (kardel@acm.org) are welcome as
-long
-as they work within Europe 8-).
+long as they work within Europe 8-).
 
 
          Verified implementations are:
 
            
@@ -112,14 +102,11 @@ as they work within Europe 8-).
 RAWDCF variants
 
 
            These variants are tested for the decoding with my own homegrown
-receivers.
-Interfacing with specific commercial products may involve some fiddeling
-with cables. Especially commericial RAWDCF receivers have a seemingly
-unlimited
-number of ways to draw power from the RS232 port and to encode the DCF77
-datastream. You are mainly on your own here unless i have a sample of
-the
-receiver.
+receivers. Interfacing with specific commercial products may involve
+some fiddeling with cables. Especially commericial RAWDCF receivers have
+a seemingly unlimited number of ways to draw power from the RS232 port
+and to encode the DCF77 datastream. You are mainly on your own here
+unless i have a sample of the receiver.
 
          • 
 Meinberg  clocks
 
@@ -127,16 +114,15 @@ receiver.
 and i have access to one of these clocks.
          
 
        
 The pictures below refer to the respective clock and where taken from
-the
-vendors web pages. They are linked to the respective vendors.
+the vendors web pages. They are linked to the respective vendors.
 
          
 
        • 
 server 127.127.8.0-3 mode 0
 
 
          Meinberg PZF535/PZF509
-receiver (FM demodulation/TCXO / 50us)
-
           
+HREF="http://www.meinberg.de/english/pzf509.htm">PZF509 receiver (FM
+demodulation/TCXO / 50us)
+
          
 
        • 
 server 127.127.8.0-3 mode 1
 
@@ -146,7 +132,7 @@ receiver (FM demodulation/OCXO / 50us)
 
          BILD PZF509
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 2
 
@@ -155,32 +141,32 @@ ALIGN=TEXTTOP>
 (AM demodulation / 4ms)
 
          BILD C51
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 3
 
 
          ELV DCF7000 (sloppy AM
 demodulation
 / 50ms)
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 4
 
 
          Walter Schmid DCF receiver Kit (AM demodulation /
 1ms)
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 5
 
 
          RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module /
 5ms)
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 6
 
 
          RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module
 / 5ms)
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 7
 
@@ -190,21 +176,21 @@ receiver (GPS / <<1us)
 
          BILD GPS167
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 8
 
          IGEL clock
 
          
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 9
 
 
          Trimble SVeeSix
 GPS receiverTAIP protocol (GPS / <<1us)
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 10
 
@@ -218,14 +204,14 @@ ALIGN=TEXTTOP>
 
          Lassen-SK8
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 11
 
 
          Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master
 Clock
 support 
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 12
 
@@ -235,12 +221,12 @@ HREF="http://www.hopf-time.com/kart6021.htm">Funkuhr
 
          DCF77-Interface Board
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 13
 
 
          Diem's Computime Radio Clock
-
           
+
          
 
        • 
 server 127.127.8.0-3 mode 14
 
@@ -249,7 +235,8 @@ ALIGN=TEXTTOP>
 
        • 
 server 127.127.8.0-3 mode 15
 
-
          WHARTON 400A Series Clocks with a 404.2 Serial Interface
+
          WHARTON 400A Series Clocks with a 404.2 Serial
+Interface
 
        
 
        
 Actual data formats and set-up requirements of the various clocks can be
@@ -262,133 +249,95 @@ a summary of the accumulated times for the clock states is listed via
 syslog.
 
 
        PPS support is only available when the receiver is completely
-synchronized.
-The receiver is believed to deliver correct time for an additional
-period
-of time after losing synchronizations, unless a disruption in time code
-transmission is detected (possible power loss). The trust period is
-dependent
-on the receiver oscillator and thus a function of clock type. This is
-one
-of the parameters in the clockinfo field of the reference clock
-implementation.
-This parameter cannot be configured by ntpdc.
+synchronized. The receiver is believed to deliver correct time for an
+additional period of time after losing synchronizations, unless a
+disruption in time code transmission is detected (possible power loss).
+The trust period is dependent on the receiver oscillator and thus a
+function of clock type. This is one of the parameters in the clockinfo
+field of the reference clock implementation. This parameter cannot be
+configured by ntpdc.
 
 
        In addition to the PPS loopfilter control a true PPS hardware signal
 can be applied on Sun Sparc stations via the CPU serial ports on the CD
 pin. This signal is automatically detected and will be used for offset
 calculation. The input signal must be the time mark for the following
-time
-code. (The edge sensitivity can be selected - look into the appropriate
-kernel/parsestreams.c for details). Meinberg receivers can be connected
-by feeding the PPS pulse of the receiver via a 1488 level converter to
-Pin 8 (CD) of a Sun serial zs-port. To select PPS support the STREAMS
-driver
-for PARSE must be loaded and the mode parameter ist the mode value of
-above
-plus 128. If 128 is not added to the mode value PPS will be detected to
-be available but it will not be used. For PPS to be used you MUST add
-128
-to the mode parameter.
+time code. (The edge sensitivity can be selected - look into the
+appropriate kernel/parsestreams.c for details). Meinberg receivers can
+be connected by feeding the PPS pulse of the receiver via a 1488 level
+converter to Pin 8 (CD) of a Sun serial zs-port. To select PPS support
+the STREAMS driver for PARSE must be loaded and the mode parameter ist
+the mode value of above plus 128. If 128 is not added to the mode value
+PPS will be detected to be available but it will not be used. For PPS to
+be used you MUST add 128 to the mode parameter.
 
 
        For the Meinberg GPS166/GPS167 receiver is also a special firmware
-release
-available (Uni-Erlangen). This release should be used for proper
+release available (Uni-Erlangen). This release should be used for proper
 operation.
 
 
        The raw DCF77 pulses can be fed via a level converter directly into
 Pin 3 (Rx) of the Sun. The telegrams will be decoded an used for
-synchronization.
-AM DCF77 receivers are running as low as $25. The accuracy is dependent
-on the receiver and is somewhere between 2ms (expensive) to 10ms
-(cheap).
-Upon bad signal reception of DCF77 synchronizations will cease as no
-backup
-oscillator is available as usually found in other reference clock
-receivers.
-So it is important to have a good place for the DCF77 antenna. For
-transmitter
-shutdowns you are out of luck unless you have other NTP servers with
-alternate
-time sources available.
-
        
-Monitor Data
        
-clock states statistics are written hourly the the syslog service.
-Online
-information can be found by examining the clock variable via the ntpq cv
-command.
-
        
-Fudge Factors
        
+synchronization. AM DCF77 receivers are running as low as $25. The
+accuracy is dependent on the receiver and is somewhere between 2ms
+(expensive) to 10ms (cheap). Upon bad signal reception of DCF77
+synchronizations will cease as no backup oscillator is available as
+usually found in other reference clock receivers. So it is important to
+have a good place for the DCF77 antenna. For transmitter shutdowns you
+are out of luck unless you have other NTP servers with alternate time
+sources available.
 
-
        
-
        
-time1 time
        
+
        Monitor Data
        
 
-
        
-Specifies the time offset calibration factor, in seconds and fraction,
-with default depending on clock type.
        
+Clock states statistics are written hourly the the syslog service.
+Online information can be found by examining the clock variable via the
+ntpq cv command.
 
-
        
-time2 time
        
-
        
-Specifies the offset if the PPS signal to the actual time. (PPS fine
-tuning).
        
-
-
        
-stratum number
        
-
-
        
-Specifies the driver stratum, in decimal from 0 to 15, with default
-0.
        
+
        Fudge Factors
        
 
-
        
-refid string
        
+
        
 
-
        
-Specifies the driver reference identifier, an ASCII string from one to
-four characters, with default according to current clock type.
        
+
        time1 time
        
+
        Specifies the time offset calibration factor, in seconds and
+fraction, with default depending on clock type.
        
 
-
        
-flag1 0 | 1
        
+
        time2 time
        
+
        Specifies the offset if the PPS signal to the actual time. (PPS fine
+tuning).
        
 
-
        
-Not used by this driver.
        
+
        stratum number
        
+
        Specifies the driver stratum, in decimal from 0 to 15, with default
+0.
        
 
-
        
-flag2 0 | 1
        
+
        refid string
        
+
        Specifies the driver reference identifier, an ASCII string from one
+to four characters, with default according to current clock type.
        
 
-
        
-Not used by this driver.
        
+
        flag1 0 | 1
        
+
        Not used by this driver.
        
 
-
        
-flag3 0 | 1
        
+
        flag2 0 | 1
        
+
        Not used by this driver.
        
 
-
        
-delete next leap second instead of adding it.
        
+
        flag3 0 | 1
        
+
        delete next leap second instead of adding it.
        
 
 
        
 flag4 0 | 1
        
+
        Delete next leap second instead of adding it - flag will be re-
+defined soon - so don't use it. Statistics are provided by more common
+means (syslog, clock variable via ntpq)
        
 
-
        
-Delete next leap second instead of adding it - flag will be re-defined
-soon - so don't use it. Statistics are provided by more common means
-(syslog,
-clock variable via ntpq)
        
 
        
 
-
        
-Making your own PARSE clocks
        
-The pare clock mechanismis deviated from the way other ntp reference
-clocks
-work. For a short description how to build parse reference clocks see making
-PARSE clocks
+
        Making your own PARSE clocks
        
+
+The parse clock mechanismis deviated from the way other ntp reference
+clocks work. For a short description how to build parse reference clocks
+see making PARSE clocks
 
 
        Additional Information
 
-
        Reference Clock Drivers 
+
        Reference Clock Drivers
 
 
         David L. Mills <mills@udel.edu>
 
        
-
diff --git a/html/driver9.htm b/html/driver9.htm
index 9436aabbab..b7426383ea 100644
--- a/html/driver9.htm
+++ b/html/driver9.htm
@@ -20,30 +20,15 @@ Address: 127.127.9.u
 
        Features: ppsclock (required)
 
        
 Description
        
-This driver supports the Magnavox MX4200 Navigation Receiver adapted to
-precision timing applications. It requires the ppsclock line
-discipline or streams module described in the Line
-Disciplines and Streams Modules page. It also requires a gadget box and 1-PPS level converter, such as
-described in the Pulse-per-second (PPS) Signal
-Interfacing page.
+This driver supports the Magnavox MX 4200 Navigation Receiver adapted to
+precision timing applications. It requires the ppsclock line discipline
+or streams module described in the Line Disciplines
+and Streams Modules page. It also requires a gadget box and 1-PPS level
+converter, such as described in the Pulse-per-second
+(PPS) Signal Interfacing page.
 
 
        This driver supports all compatible receivers such as the 6-channel
-MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.
-
-
        
-
-Leica MX9400N Navigator
-Leica Geosystems acquired
-the Magnavox commercial GPS technology business in February of 1994.
-They now market and support former Magnavox GPS products such as the
-MX4200 and its successors.
        
-
-
        
-Leica MX9400N Navigator.
-
-
        
-
+MX 4200, MX 4200D, and the 12-channel MX 9212, MX 9012R, MX 9112.
 
        
 Operating Modes
        
 This driver supports two modes of operation, static and mobile, controlled
@@ -55,7 +40,9 @@ is in a fixed location. The receiver is initially placed in a "Static,
 for a fixed station. A DOP-weighted running average position is calculated
 from this data. After 24 hours, the receiver is placed into a "Known Position"
 mode, initialized with the calculated position, and then solves only for
-time.
+time. The position averaging algorithm does not take into account boundary
+conditions, so this mode of operation very near the international date
+line or the poles is not recommended.
 
 
        In mobile mode, the driver assumes the GPS antenna is mounted on a moving
 platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic,
@@ -64,10 +51,7 @@ position averaging is performed.
 
        
 Monitor Data
        
 The driver writes each timecode as received to the clockstats
-file.  Documentation for the NMEA-0183 proprietary
-sentences produced by the MX4200 can be found in
-MX4200 Receiver Data Format.
-
+file.
 
        
 Fudge Factors
        
 
@@ -124,7 +108,7 @@ Not used by this driver.
 
        
 Additional Information
 
-
        Reference Clock Drivers
+
        Reference Clock Drivers 
 
        
 
        
 David L. Mills (mills@udel.edu)
        
diff --git a/html/exec.htm b/html/exec.htm
index 68eaf936e8..756d987cdc 100644
--- a/html/exec.htm
+++ b/html/exec.htm
@@ -108,7 +108,7 @@ expressed
 
 
        T(t) = T(t0) +
 R(t - t0) + 1/2 D(t -
-t0)2,
        
+T0)2,
 
 
        where t is the current time, T is the time offset at
 the last measurement update t0, R is the
@@ -236,49 +236,48 @@ thousands of minutes for modem paths.
 
 
          
 
-
        1. Cristian, F. Probabilistic clock synchronization. In Distributed
+
        2. Cristian, F. Probabilistic clock synchronization. In Distributed
 Computing 3, Springer Verlag, 1989, 146-158.
          3. 
 
-
        3. Digital Time Service Functional Specification Version T.1.0.5.
-Digital Equipment Corporation, 1989.
          4. 
+
        4. Digital Time Service Functional Specification Version T.1.0.5.
+DigitalEquipment Corporation, 1989.
          5. 
 
-
        5. Gusella, R., and S. Zatti. TEMPO - A network time controller for
+
        6. Gusella, R., and S. Zatti. TEMPO - A network time controller for
 a distributed Berkeley UNIX system. IEEE Distributed Processing
 Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in:
 Proc. Summer 1984 USENIX (Salt Lake City, June 1984).
          7. 
 
-
        7. Kopetz, H., and W. Ochsenreiter. Clock synchronization in
+
        8. Kopetz, H., and W. Ochsenreiter. Clock synchronization in
 distributed real-time systems. IEEE Trans. Computers C-36, 8 (August
 1987), 933-939.
          9. 
 
-
        9. Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
+
        10. Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the
 presence of faults. JACM 32, 1 (January 1985), 52-78.
          11. 
 
-
        11. Marzullo, K., and S. Owicki. Maintaining the time in a
+
        12. Marzullo, K., and S. Owicki. Maintaining the time in a
 distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-
 54.
          13. 
 
-
        13. Mills, D.L. Internet time synchronization: the Network Time
+
        14. Mills, D.L. Internet time synchronization: the Network Time
 Protocol. IEEE Trans. Communications COM-39, 10 (October 1991), 1482-
 1493. Also in: Yang, Z., and T.A. Marsland (Eds.). Global States and
 Time in Distributed Systems, IEEE Press, Los Alamitos, CA, 91-102.
          15. 
-
-
        15. Mills, D.L. Modelling and analysis of computer network clocks.
+
        16. Mills, D.L. Modelling and analysis of computer network clocks.
 Electrical Engineering Department Report 92-5-2, University of Delaware,
 May 1992, 29 pp.
          17. 
 
-
        17. NIST Time and Frequency Dissemination Services. NBS Special
-Publication 432 (Revised 1990), National Institute of Science and
+
        18. NIST Time and Frequency Dissemination Services. NBS Special
+Publication432 (Revised 1990), National Institute of Science and
 Technology, U.S. Department of Commerce, 1990.
          19. 
 
-
        19. Schneider, F.B. A paradigm for reliable clock synchronization.
+
        20. Schneider, F.B. A paradigm for reliable clock synchronization.
 Department of Computer Science Technical Report TR 86-735, Cornell
 University, February 1986.
          21. 
 
-
        21. Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM
+
        22. Srikanth, T.K., and S. Toueg. Optimal clock synchronization. JACM
 34, 3 (July 1987), 626-645.
          23. 
 
-
        23. Stein, S.R. Frequency and time - their measurement and
+
        24. Stein, S.R. Frequency and time - their measurement and
 characterization (Chapter 12). In: E.A. Gerber and A. Ballato (Eds.).
 Precision Frequency Control, Vol. 2, Academic Press, New York 1985, 191-
 232, 399-416. Also in: Sullivan, D.B., D.W. Allan, D.A. Howe and F.L.
@@ -289,5 +288,5 @@ Government Printing Office (January, 1990), TN61-TN119.
          25. 
 
        
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/gadget.htm b/html/gadget.htm
index 9485fb9291..80274535ec 100644
--- a/html/gadget.htm
+++ b/html/gadget.htm
@@ -107,5 +107,5 @@ PCB, also from Omation.
 
        sst0126.lpr - pcb silkscreen mask (side 1)
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/hints.htm b/html/hints.htm
index f381966725..066b4dba89 100644
--- a/html/hints.htm
+++ b/html/hints.htm
@@ -5,7 +5,7 @@ Hints and Kinks
 
        
 
 
        This is an index for a set of troubleshooting notes contained in
-individual text files in the ./html/hints directory. They were
+individual text files in the ./hints directory. They were
 supplied by various volunteers in the form of mail messages, patches or
 just plain word of mouth. Each note applies to a specific computer and
 operating system and gives information found useful in setting up the
@@ -19,8 +19,8 @@ the computer manufacturer (and model numbers where appropriate),
 operating system (specific version(s) where appropriate), problem
 description, problem solution and submitter's name and electric address.
 If the submitter is willing to continue debate on the problem, please so
-advise. Bash here for a directory listing.
+advise. Bash here for a directory listing.
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/hints/solaris.html b/html/hints/solaris.html
index 4cda3796c1..8595fbfc3e 100644
--- a/html/hints/solaris.html
+++ b/html/hints/solaris.html
@@ -33,7 +33,7 @@ set dosynctodr = 0
 
        
 Instead of the tick kernel variable, which many operating
 systems use to control microseconds added to the system time every
-clock tick (cf. Dealing
+clock tick (c.f. Dealing
 with Frequency Tolerance Violations), Solaris has the variables
 nsec_per_tick and usec_per_tick.
 
        
@@ -61,8 +61,8 @@ HREF="solaris.xtra.S99ntpd">this one, installed in
 
        Solaris 2.6
        
 
        
 Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this
-support in such a fashion that using it is worse than not. This is  Sun Bug ID 4095849, and it is not yet
+support in such a fashion that using it worse than not. This is  SUN Bug ID 4095849, and it is not yet
 fixed as of June 1998.
 
        
 
        Solaris 2.5 and 2.5.1
        
@@ -70,7 +70,7 @@ fixed as of June 1998.
 On UltraSPARC systems, calculation of cpu_tick_freq is broken
 such that values that are off by significant amounts may be used
 instead. This unfortunately means that ntpd may have severe problems
-keeping synchronization. This is  Sun Bug ID
+keeping synchronization. This is  SUN Bug ID
 4023118. Bryan Cantrill  of Sun
 posted patchfreq, a workaround script,
 to comp.protocols.time.ntp in March of 1997.
@@ -122,12 +122,12 @@ The first sleep insures the adjtime has completed for the first ntpdate.
 The second ntpdate will use adjtime to set the time of day since the
 clock should be within 2 seconds of the correct time.
 
        
-The second tickadj sets the tick adjust system value to 200 microseconds.
+The second tickadj set the tick adjust system value to 5 microseconds.
 
        
 The second sleeps insure that adjtime will complete before starting 
-xntpd.
+the next xntpd.
 
        
-I tried running with a tickadj of 5 microseconds without much success.
+I tried running with a tickadj of 5 microseconds with out much success.
 200 microseconds seems to work well.  
 
        
 
        
diff --git a/html/howto.htm b/html/howto.htm
index 824ce843d3..2415482b60 100644
--- a/html/howto.htm
+++ b/html/howto.htm
@@ -267,5 +267,5 @@ values from the interface structure that can be displayed using
 
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/index.htm b/html/index.htm
index ec804eb53d..a676c871e8 100644
--- a/html/index.htm
+++ b/html/index.htm
@@ -34,7 +34,7 @@ HREF=biblio.htm>Protocol Conformance Statement page. Discussion on
 year-2000 issues can be found in the Year 2000
 Conformance Statement page. Background information, bibliography and
 briefing slides suitable for presentations can be found in the  Network Time
+HREF=http://www.eecis.udel.edu/~mills/ntp.htm> Network Time
 Synchronization Project page.
 
 
        Building and Installing NTP
        
@@ -91,15 +91,15 @@ at stratum one and provide synchronization to secondary servers
 operating at stratum two and so on to higher strata. In this hierarchy,
 clients are simply servers that have no dependents.
 
-
        The NTP subnet in early 1999 includes 79 public primary (stratum 1)
+
        The NTP subnet in early 1998 includes 70 public primary (stratum 1)
 servers synchronized directly to UTC by radio, satellite or modem and
-located in every continent of the globe except Antarctica (soon).
+located in every continent of the globe, except Antarctica (soon).
 Normally, client workstations and servers with a relatively small number
-of clients do not synchronize to primary servers. There are over 100
-public secondary (stratum 2) servers synchronized to the primary servers
-and providing synchronization to a total in excess of 100,000 clients
-and servers in the Internet. The current lists are maintained in the Information on Time
+of clients do not synchronize to primary servers. There are 106 public
+secondary (stratum 2) servers synchronized to the primary servers and
+providing synchronization to a total in excess of 100,000 clients and
+servers in the Internet. The current lists are maintained in the Information on Time
 and Frequency Services page, which is updated frequently. There are
 numerous private primary and secondary servers not normally available to
 the public as well. You are strongly discouraged from using these
@@ -107,81 +107,9 @@ servers, since they sometimes hide in little ghettos behind dinky links
 to the outside world and your traffic can bring up expensive ISDN lines,
 causing much grief and frustration.
 
-
        In some cases where a network is isolated from the Internet and no
-external synchronization source is available, one of the network hosts
-can be designated as the primary server and the others operate as
-clients. In these cases the network hosts will be synchronized, but not
-necessarily to standard civil time. Even if an external synchronization
-source is available, a host can be designated as backup server in the
-event the external source becomes unreachable or inoperable. A host
-operating as the primary or backup server is configured with the Undisciplined Local Clock driver. The configuration
-options provide for a stratum number to be assigned to the server,
-usually one for a primary server and three or more for a backup server.
-
-
        Performance Expectations
        
-
-
        In the majority of cases, the NTP subnet can keep the clock within a
-few milliseconds on LANs and a few tens of milliseconds on WANs.
-However, in some cases with network jitter of several hundred
-milliseconds or more, the clock discipline loop may not be able to
-converge to a stable frequency. In such cases, a large fraction of the
-time sample corrections are greater than the 128-ms step threshold and
-valid updates which can discipline the clock frequency are sparse. In
-these cases, the burst keyword should be used with the
-corresponding server line in the configuration file. This
-causes eight volleys in each measurement round, following which the best
-candidate is determined and used to discipline the clock. See the Configuration Options page for further information.
-
-
        When multiple servers are configured, the NTP algorithms operate to
-determine the best combination providing the highest accuracy.
-However, there may be small systematic differences in the apparent time
-of each server due to the different network paths involved. In practice,
-this can lead to occasional clockhopping between servers and
-result in increased jitter as seen by the clock discipline algorithm.
-Usually, a favored server can be selected so that, under most
-circumstances, only that server is used and the others disregarded. The
-favored server is identified by the prefer keyword in the
-corresponding server or peer line in the configuration
-file. See the Mitigation Rules and the
-prefer Keyword page for further information.
-
-
        In general, as the poll interval increases, so does the expected
-error. When the highest accuracy is required, the poll interval should
-be clamped at a low value using the maxpoll keyword in the
-corresponding server or peer line in the configuration
-file. A typical argument value is 6, which results in a poll interval of
-64 seconds. This should be done only sparingly, since it results in an
-increased load on the network. Where means are available, steps should
-be taken to minimize the ambient temperature variations, since the clock
-frequency is temperature dependent.
-
-
        For the best accuracy, latencies in the hardware and software should
-by minimized wherever possible. Consider using the tty_clk line
-discipline, if available. Where available, interrupt-driven I/O is
-preferred over polled I/O. When means are available, the scheduling
-priority can be raised to avoid preempting the NTP daemon by other
-processes. This can be done using the -P option on the
-ntpd command line. However, this can lead to trouble should the
-daemon stumble on an endless program loop. While this is a "cannot
-happen" event, the possibility of this kind of bug should be considered
-in the overall robustness model for the client or server. See the ntpd - Network Time Protocol (NTP) daemon
-page for further information.
-
-
        The very best accuracy can be achieved only by using an external
-discipline signal, such as a pulse-per-second (PPS) or Inter-Range
-Instrumentation Group (IRIG) signal. This requires external connection
-via a serial port or audio codec. See the Reference
-Clock Drivers page for further information and links to device
-drivers. Using the PPS signal and kernel support, for example,
-accuracies of a few microseconds can be achieved with modern workstation
-hardware.
-
 
        Resolving Problems
        
 
-Like other things on the Internet, the NTP synchronization subnets tend to be
+Like other things Internet, the NTP synchronization subnets tend to be
 large and devilishly intricate, with many opportunities for
 misconfiguration and network problems. The NTP engineering model is
 specifically designed to help isolate and repair such problems using an
@@ -202,7 +130,8 @@ operating systems easier. Additional information on reference clock
 driver construction and debugging can be found in the Reference Clock Drivers page. Further
 information on NTP in the Internet can be found in the NTP web page.
+HREF=http://www.eecis.udel.edu/~ntp>NTP
+web page.
 
 
        Program Manual Pages
        
 
@@ -229,7 +158,7 @@ variables
        • 
 
 
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/kern.htm b/html/kern.htm
index 5c193c6bf4..b1ee383d7e 100644
--- a/html/kern.htm
+++ b/html/kern.htm
@@ -19,43 +19,33 @@ over one day.
 
        The hybrid PLL/FLL has been implemented in the Unix kernels for
 several workstations, including those made by Sun Microsystems, Digital
 and Hewlett Packard. Currently, the modifications are in licensed
-kernels beginning with Digital Unix 4.0 and Sun Solaris 2.6. Since these
-specific implementations involve modifications to licensed code, they
-cannot be provided directly. Inquiries should be directed to the
-manufacturer's representatives. In addition to the licensed kernels, the
-hybrid PLL/FLL has been implemented in the nonlicensed kernels for Linux
-and FreeBSD. The current engineering model for these implementations,
-including a simulator with code segments almost identical to the
-implementations, but not involving licensed code, is available via the
-web at nanokernel.tar.Z or
-by anonymous FTP from ftp.udel.edu in the pub/ntp directory.
-The current version has an ultimate resolution of one nanosecond, while
-previous versions are limited to one microsecond.
+kernels for Digital Unix 4.0 and Sun Solaris 2.6. Since these specific
+implementations involve modifications to licensed code, they cannot be
+provided directly. Inquiries should be directed to the manufacturer's
+representatives. In addition to the licensed kernels, the hybrid PLL/FLL
+has been implemented in the nonlicensed kernels for Linux and FreeBSD.
+The engineering model for these implementations, including a simulator
+with code segments almost identical to the implementations, but not
+involving licensed code, is available via the web at kernel.tar.Z or by
+anonymous FTP from ftp.udel.edu in the pub/ntp directory.
 
 
        The model changes the way the system clock is adjusted in time and
 frequency, as well as provides mechanisms to discipline its time and
-frequency to an external precision timing source, such as a
-pulse-per-second (PPS) signal. The model incorporates a generic
-system-call interface for use with the Network Time Protocol (NTP) or similar
-time synchronization protocol. The NTP software daemons for Version 3
-xntpd and Version 4 ntpd operate with this model to
-provide synchronization limited in principle only by the accuracy and
+frequency to an external precision timing source, such as a pulse-per-
+second (PPS) signal. The model incorporates a generic system-call
+interface for use with the Network Time Protocol (NTP) or similar time
+synchronization protocol. The NTP software daemons for Version 3
+xntpd and Version 4  ntpd operate with this model
+to provide synchronization limited in principle only by the accuracy and
 stability of the external timing source. There are two new system calls
 defined in the model, ntp_gettime(), which returns a structure
 including the current time, estimated error and maximum error, and
 ntp_adjtime(), which provides a means to adjust kernel
 variables, including the current time and frequency offsets. Further
 information on the calling sequences and variable definitions are in the
-/usr/include/sys/timex.h file.
-
-
        If the /usr/include/sys/timex.h file is present when the
-distribution is built, code to use the hybrid PLL/FLL features is
-automatically generated. If necessary, these features can be disabled
-using the disable kernel configuration command. In this case,
-operation reverts to the standard NTP clock discipline algorithms
-included in the daemon.
+/usr/include/sys/timex.h file. 
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/kernpps.htm b/html/kernpps.htm
index 6b9fa708f8..fe003f78d1 100644
--- a/html/kernpps.htm
+++ b/html/kernpps.htm
@@ -22,5 +22,5 @@ lead, which can be driven by an external source via a level
 converter/pulse generator.
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/measure.htm b/html/measure.htm
index 282ebda0e7..a06261dd0e 100644
--- a/html/measure.htm
+++ b/html/measure.htm
@@ -46,5 +46,5 @@ issues in performing experiments of this type and summarizes various
 techniques found useful in practice.
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/miscopt.htm b/html/miscopt.htm
index f8f80db0b7..af5ee3cdf1 100644
--- a/html/miscopt.htm
+++ b/html/miscopt.htm
@@ -26,7 +26,7 @@ Ethernet), a number between 0.003 and 0.007 seconds is appropriate. The
 default when this command is not used is 0.004 seconds.
 
 
        
- 
        
+ 
 
 
        
 trap host_address [port port_number] [interface interface_address]
        
@@ -46,7 +46,7 @@ their own trap dynamically, configuring a trap receiver will ensure that
 no messages are lost when the server is started.
 
 
        
- 
        
+ 
 
 
        
 setvar variable [default]
        
@@ -67,7 +67,7 @@ and the clock_var_list holds the names of the reference clock
 variables.
 
 
        
- 
        
+ 
 
 
        
 logfile logfile
        
@@ -77,7 +77,7 @@ This command specifies the location of an alternate log file to be used
 instead of the default system syslog facility.
 
 
        
- 
        
+ 
 
 
        
 logconfig configkeyword
        
@@ -88,7 +88,7 @@ This command controls the amount and type of output written to the system
 default, all output is turned on. All configkeyword keywords
 can be prefixed with =, + and -, where =
 sets the syslogmask, + adds and - removes messages.
-syslog messages can be controlled in four classes (clock, peer,
+syslog messages can be controlled in four classes (, peer,
 sys and sync). Within these classes four types of messages
 can be controlled.
 
@@ -96,10 +96,10 @@ can be controlled.
 Informational messages (info) control configuration information.
 Event messages (events) control logging of events (reachability,
 synchronization, alarm conditions). Statistical output is controlled with
-the statistics keyword. The final message group is the status
+the statistics keyword. The final message group is the status
 messages. This describes mainly the synchronizations status. Configuration
 keywords are formed by concatenating the message class with the event class.
-The all prefix can be used instead of a message class. A message
+The allprefix can be used instead of a message class. A message
 class may also be followed by the all keyword to enable/disable
 all messages of the respective message class.
 
@@ -107,7 +107,7 @@ all messages of the respective message class.
 Thus, a minimal log configuration could look like this:
 
 
        
-logconfig =syncstatus +sysevents
        
+logconfig = syncstatus +sysevents
 
 
        
 This would just list the synchronizations state of ntpd and the
@@ -115,7 +115,7 @@ major system events. For a simple reference server, the following minimum
 message configuration could be useful:
        
 
 
        
-logconfig =syncall +clockall
        
+logconfig = syncall +clockall
 
 
        
 This configuration will list all clock information and synchronization
@@ -126,7 +126,7 @@ so on is suppressed.
        
 
        
 Variables
        
 Most variables used by the NTP protocol can be examined with the ntpdc
-(mode 7 messages) and the ntpq (mode 6 messages) programs. Currently, very
+(mode 7 messages) and the ntpq (mode 6 messages). Currently, very
 few variables can be modified via mode 6 messages. These variables are
 either created with the setvar directive or the leap warning bits.
 The leap warning bits can be set in the leapwarning variable up
@@ -154,6 +154,9 @@ Leap information from the synchronizations source is ignored (thus LEAP_NOWA
 is passed on).
 
 
-
         David L. Mills <mills@udel.edu>
-
        
+
        
+
        
+David L. Mills (mills@udel.edu)
        
+
+
+
diff --git a/html/monopt.htm b/html/monopt.htm
index b0f1b71f75..99c1f2d250 100644
--- a/html/monopt.htm
+++ b/html/monopt.htm
@@ -17,7 +17,7 @@ Monitoring Support
 continuous, long term recording of server and client timekeeping performance.
 See the statistics command below for a listing and example of
 each type of statistics currently supported. Statistic files are managed
-using file generation sets and scripts in the ./scripts directory of this
+using file generation sets and scripts in the ./scripts directory of this
 distribution. Using these facilities and Unix cron jobs, the data
 can be automatically summarized and archived for retrospective analysis.
 
        
@@ -31,13 +31,17 @@ Monitoring Commands
        
 Enables writing of statistics records. Currently, three kinds of name
 statistics are supported.
 
+
        
+ 
        
+
+
        
 
        
 loopstats
        
 
 
        
 Enables recording of loop filter statistics information. Each update of
 the local clock outputs a line of the following form to the file generation
-set named loopstats:
+set named loopstats:
        
 
 
        50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 6
        
 
@@ -47,6 +51,9 @@ and fraction past UTC midnight). The next five fields show time offset
 (seconds), frequency offset (parts per million - PPM), RMS jitter (seconds),
 Allan deviation (PPM) and clock discipline time constant.
 
+
        
+ 
        
+
 
        
 peerstats
        
 
@@ -54,7 +61,7 @@ Allan deviation (PPM) and clock discipline time constant.
 Enables recording of peer statistics information. This includes statistics
 records of all peers of a NTP server and of special signals, where present
 and configured. Each valid update appends a line of the following form
-to the current element of a file generation set named peerstats:
+to the current element of a file generation set named peerstats:
 
 
        48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142
        
 
@@ -66,13 +73,16 @@ in hex in the format described in Appendix A of the NTP specification RFC
 1305. The final three fields show the offset, delay and RMS jitter, all
 in seconds.
 
+
        
+ 
        
+
 
        
 clockstats
        
 
 
        
 Enables recording of clock driver statistics information. Each update received
 from a clock driver appends a line of the following form to the file generation
-set named clockstats:
+set named clockstats:
        
 
 
        49213 525.624 127.127.4.1 93 226 00:08:29.606 D
        
 
@@ -84,6 +94,9 @@ from the clock in decoded ASCII format, where meaningful. In some clock
 drivers a good deal of additional information can be gathered and displayed
 as well. See information specific to each clock for further details.
 
+
        
+ 
        
+
 
        
 rawstats
        
 
@@ -94,12 +107,15 @@ where present and configured. Each NTP message received from a peer or
 clock driver appends a line of the following form to the file generation
 set named rawstats:
 
+
        
+ 
        
+
 
        
 50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031
 02453332.540806000 3102453332.541458000
        
 
 
        
- 
        
+ 
 
 
        
 The first two fields show the date (Modified Julian Day) and time (seconds
@@ -108,6 +124,10 @@ address in dotted-quad notation, The final four fields show the originate,
 receive, transmit and final NTP timestamps in order. The timestamp values
 are as received and before processing by the various data smoothing and
 mitigation algorithms.
        
+
        
+
+
        
+ 
        
 
 
        
 statsdir directory_path
        
@@ -119,14 +139,14 @@ filename prefix to be modified for file generation sets, which is useful
 for handling statistics logs.
 
 
        
- 
        
+ 
 
 
        
 filegen name [file filename] [type typename] [link
 | nolink] [enable | disable]
        
 
 
        
- 
        
+ 
 
 
        
 Configures setting of generation file set name. Generation file
@@ -141,12 +161,16 @@ without the risk of disturbing the operation of ntpd. (Most important:
 they can be removed to free space for new data produced.)
        
 
 
        
- 
        
+ 
 
 
        
 Note that this command can be sent from the ntpdc program running
 at a remote location.
        
 
+
        
+ 
        
+
+
        
 
        
 name
        
 
@@ -155,11 +179,21 @@ This is the type of the statistics records, as shown in the statististics
 
 
        
-file filename
+ 
        
+
        
+
+
        
+file filename
        
 
-
        This is the file name for the statistics records. Filenames of set members
+
        
+
        
+This is the file name for the statistics records. Filenames of set members
 are built from three elements:
        
 
+
        
+ 
        
+
+
        
 
        
 prefix
        
 
@@ -171,6 +205,9 @@ file generation sets via other commands. For example, the prefix used with
 loopstats and peerstats generation can be configured
 using the statsdir option explained above.
        
 
+
        
+ 
        
+
 
        
 filename
        
 
@@ -181,25 +218,42 @@ argument to the filegen statement. No .. elements are
 allowed in this component to prevent filenames referring to parts outside
 the filesystem hierarchy denoted by prefix.
 
+
        
+ 
        
+
 
        
 suffix
        
 
 
        
 This part is reflects individual elements of a file set. It is generated
 according to the type of a file set.
        
+
+
+
        
+ 
        
+
 
-
        type typename
        
+
        
+type typename
        
 
+
        
 
        
 A file generation set is characterized by its type. The following types
 are supported:
        
 
+
        
+ 
        
+
+
        
 
        
 none
        
 
 
        
 The file set is actually a single plain file.
        
 
+
        
+ 
        
+
 
        
 pid
        
 
@@ -212,6 +266,9 @@ appending a . (dot) to concatenated prefix and filename
 strings, and appending the decimal representation of the process ID of
 the ntpd server process.
 
+
        
+ 
        
+
 
        
 day
        
 
@@ -224,6 +281,9 @@ month number. DD is a two digit day number. Thus, all information
 written at 10 December 1992 would end up in a file named prefix
 filename.19921210.
 
+
        
+ 
        
+
 
        
 week
        
 
@@ -235,6 +295,9 @@ suffix to the file set filename base: A dot, a 4-digit year number, the
 letter W, and a 2-digit week number. For example, information
 from January, 10th 1992 would end up in a file with suffix .1992W1.
 
+
        
+ 
        
+
 
        
 month
        
 
@@ -242,6 +305,9 @@ from January, 10th 1992 would end up in a file with suffix .1992W1.
 
+
        
+ 
        
+
 
        
 year
        
 
@@ -249,6 +315,9 @@ consists of a dot, a 4-digit year number, and a 2-digit month.
 One generation file element is generated per year. The filename suffix
 consists of a dot and a 4 digit year number.
 
+
        
+ 
        
+
 
        
 age
        
 
@@ -258,11 +327,17 @@ set every 24 hours of server operation. The filename suffix consists of
 a dot, the letter a, and an 8-digit number. This number is taken
 to be the number of seconds the server is running at the start of the corresponding
 24-hour period. Information is only written to a file generation by specifying
-enable; output is prevented by specifying disable.
+enabl; output is prevented by specifying disable.
+
+
        
+ 
        
+
        
+
        
 
 
        
-link | nolink
+link | nolink
        
 
+
        
 
        
 It is convenient to be able to access the current element of a file generation
 set by a fixed name. This feature is enabled by specifying link
@@ -275,12 +350,21 @@ is greater than one, the file is unlinked. This allows the current file
 to be accessed by a constant name.
        
 
 
        
-enable | disable
+ 
        
+
        
+
+
        
+enable | disable
        
 
+
        
 
        
 Enables or disables the recording function.
        
 
        
+
+
+
        
+
        
+David L. Mills (mills@udel.edu)
        
 
-
         David L. Mills <mills@udel.edu>
-
        
+
+
diff --git a/html/notes.htm b/html/notes.htm
index 0d1ca6f7dd..42a1fc4cbe 100644
--- a/html/notes.htm
+++ b/html/notes.htm
@@ -1,7 +1,8 @@
 
-Notes on Configuring NTP and Setting up a NTP Subnet
-
-
        Notes on Configuring NTP and Setting up a NTP Subnet
        
+Notes on Configuring NTP and Setting up a NTP Subnet
+
        
+Notes on Configuring NTP and Setting up a NTP Subnet
        
+
 
 
 From NBS Special Publication 432 (out of print)
@@ -10,7 +11,7 @@ From NBS Special Publication 432 (out of print)
 
        Introduction
        
 
 This document is a collection of notes concerning the use of ntpd and
-related programs, and on coping with the Network Time Protocol (NTP) in
+relatedprograms, and on coping with the Network Time Protocol (NTP) in
 general. It is a major rewrite and update of an earlier document written
 by Dennis Ferguson of the University of Toronto and includes many
 changes and additions resulting from the NTP Version 3 specification and
@@ -23,24 +24,24 @@ for new configurations.
 
 
-Additional features are described for NTP
+Additional features have are described for NTP
 Version 4. It also retains compatibility with both NTP Version 2, as
 defined in RFC-1119, and NTP Version 1, as defined in RFC-1059, although
 this compatibility is sometimes strained and only semiautomatic. In
@@ -51,7 +52,7 @@ arithmetic internally. ntpd fully implements NTP Versions 2 and
 3 authentication and in addition Version 4 autokey. It supports the NTP
 mode-6 control message facility along with a private mode-7 control-
 message facility used to remotely reconfigure the system and monitor a
-considerable amount of internal detail. As extension to the
+considerable amount of internal detail. As extensions to the
 specification, a flexible address-and-mask restriction facility has been
 included.
 
@@ -107,7 +108,7 @@ itself (ntpd), several utility programs,
 including two remote-monitoring programs (
 ntpq, ntpdc), a remote
 clock-setting program similar to the Unix rdate program
-(ntpdate), a traceback utility useful to discover suitable
+(ntpdate), a traceback utility u seful to discover suitable
 synchronization sources (ntptrace), 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
@@ -154,7 +155,7 @@ 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 be made to nominate one of them as a phantom UTC source.
+provisions can made to nominate one of them as a phantom UTC source.
 
 
        NTP operates on the premise that there is one true standard time, and
 that if several servers which claim synchronization to standard time
@@ -228,7 +229,8 @@ willing
 to supply time to the remote server if need be. This mode is appropriate
 in configurations involving a number of redundant time servers
 interconnected
-via diverse network paths, which is presently the case for most stratum-1
+via diverse network paths, which is presently the case for most stratum-
+1
 and stratum-2 servers on the Internet today. Configuring an association
 in client mode (usually indicated by a server declaration in
 the
@@ -268,7 +270,7 @@ clients and servers operate in either client/server or symmetric modes.
 Symmetric modes are most often used between two or more servers
 operating
 as a mutually redundant group. In these modes, the servers in the group
-arrange the synchronization paths for maximum performance,
+members arrange the synchronization paths for maximum performance,
 depending
 on network jitter and propagation delay. If one or more of the group
 members
@@ -512,6 +514,7 @@ of failure, but does not eliminate them in cases where the usual chain
 of associations to the primary sources of synchronization are disrupted
 due to failures.
 
+
         
 
      • 
 Don't configure peer associations with higher stratum servers. Let the
 higher strata configure lower stratum servers, but not the reverse. This
@@ -520,7 +523,7 @@ usually
 much greater configuration churn in the high stratum clients such as
 personal
 workstations.
        • 
-
+
         
 
      • 
 Don't synchronize more than one time server in a particular
 administrative
@@ -541,16 +544,14 @@ conventions.
 A working configuration file might look like (in this and other
 examples,
 do not copy this directly):
-
        -     # peer configuration for host whimsy
-     # (expected to operate at stratum 2)
+
             # peer configuration for host whimsy
+     # (expected to operate at stratum 2)
 
-     server rackety.udel.edu
-     server umd1.umd.edu
-     server lilben.tn.cornell.edu
+     server rackety.udel.edu
+     server umd1.umd.edu
+     server lilben.tn.cornell.edu
 
-     driftfile /etc/ntp.drift
-
        
+     driftfile /etc/ntp.drift
        
 (Note the use of host names, although host addresses in dotted-quad
 notation
 can also be used. It is always preferable to use names rather than
@@ -657,13 +658,13 @@ of the server, peer, broadcast and
 manycastclient
 command can be used to change the default. In unconfigured
 (ephemeral)
-associations, the daemon always replies in the same version as the
+associaitons, the daemon always replies in the same version as the
 request.
 
 
        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
+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
@@ -684,12 +685,12 @@ will send packets claiming to be version 4 when it polls. To get around
 this, ntpd allows a qualifier to be added to configuration
 entries
 to indicate which version to use when polling. Hence the entries
-
        -     # specify NTP version 1
+
             # specify NTP version 1
 
-     server mimsy.mil version 1     # server running ntpd version 1
-     server apple.com version 2     # server running ntpd version 2
-
        
+     server mimsy.mil version
+1     # server running ntpd version 1
+     server apple.com version
+2     # server running ntpd version 2
        
 will cause version 1 packets to be sent to the host mimsy.mil and
 version
 2 packets to be sent to apple.com. If you are testing ntpd
@@ -718,10 +719,8 @@ from each packet which is received by the server. This feature is
 normally
 enabled, but can be disabled if desired using the configuration file
 entry:
-
        -     # disable monitoring feature
-     disable monitor
-
        
+
             # disable monitoring feature
+     disable monitor
        
 The recorded information can be displayed using the ntpdc query
 program, described briefly below.
 
        
@@ -739,7 +738,8 @@ set of flags. On receipt of a packet, the source address of the packet
 is compared to each entry in the list, with a match being posted when
 the
 following is true:
-
             (source_addr & mask) == (address & mask)
        
+
             (source_addr & mask) == (address &
+mask)
        
 A particular source address may match several list entries. In this case
 the entry with the most one bits in the mask is chosen. The flags
 associated
@@ -769,22 +769,22 @@ ever synchronizes to one of a pair of off-campus servers or, failing
 that,
 a time source on net 128.100. The following entries in the configuration
 file would implement this policy:
-
        -     # by default, don't trust and don't allow modifications
+
             # by default, don't trust and don't allow
+modifications
 
-     restrict default notrust nomodify
+     restrict default notrust nomodify
 
-     # these guys are trusted for time, but no modifications allowed
+     # these guys are trusted for time, but no
+modifications allowed
 
-     restrict 128.100.0.0 mask 255.255.0.0 nomodify
-     restrict 128.8.10.1 nomodify
-     restrict 192.35.82.50 nomodify
+     restrict 128.100.0.0 mask 255.255.0.0 nomodify
+     restrict 128.8.10.1 nomodify
+     restrict 192.35.82.50 nomodify
 
-     # the local addresses are unrestricted
+     # the local addresses are unrestricted
 
-     restrict 128.100.100.7
-     restrict 127.0.0.1
-
        
+     restrict 128.100.100.7
+     restrict 127.0.0.1
        
 The first entry is the default entry, which all hosts match and hence
 which
 provides the default set of flags. The next three entries indicate that
@@ -828,7 +828,7 @@ latter presently is free from such restrictions. For this reason, the
 DES
 algorithm is not included in the current distribution. Directions for
 obtaining
-it in other countries are in the Building and
+it in other countries is in the Building and
 Installing
 the Distribution page. With either algorithm the receiving peer
 recomputes
@@ -861,22 +861,31 @@ key ID to be used to authenticate each configured peer association.
 Hence,
 for a server running in authenticated mode, the configuration file might
 look similar to the following:
-
        -     # peer configuration for 128.100.100.7
-     # (expected to operate at stratum 2)
-     # fully authenticated this time
-
-     peer 128.100.49.105 key 22 # suzuki.ccie.utoronto.ca
-     peer 128.8.10.1 key 4    # umd1.umd.edu
-     peer 192.35.82.50 key 6  # lilben.tn.cornell.edu
-
-     keys /usr/local/etc/ntp.keys  # path for key file
-     trustedkey 1 2 14 15     # define trusted keys
-     requestkey 15            # key (7) for accessing server variables
-     controlkey 15            # key (6) for accessing server variables
-
-     authdelay 0.000094       # authentication delay (Sun4c/50 IPX)
-
        
+
             # peer configuration for 128.100.100.7
+     # (expected to operate at stratum 2)
+     # fully authenticated this time
+
+     peer 128.100.49.105 key 22 #
+suzuki.ccie.utoronto.ca
+     peer 128.8.10.1 key 4    #
+umd1.umd.edu
+     peer 192.35.82.50 key 6  #
+lilben.tn.cornell.edu
+
+     keys /usr/local/etc/ntp.keys  # path for
+key file
+     trustedkey 1 2 14 15     #
+define trusted keys
+     requestkey
+15            #
+key (7) for accessing server variables
+     controlkey
+15            #
+key (6) for accessing server variables
+
+     authdelay
+0.000094       # authentication delay
+(Sun4c/50 IPX)
        
 There are a couple of previously unmentioned things in here. The
 keys
 line specifies the path to the keys file (see below and the
@@ -901,7 +910,7 @@ used by the ntpdc utility program. These keys are used to
 prevent
 unauthorized modification of daemon variables.
 
-
        Ordinarily, the authentication delay, that is, the processing time
+
        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
@@ -915,14 +924,12 @@ HREF="authspeed.htm">authspeed
 program included in the distribution. The usage is illustrated by
 the
 following:
-
        -     # for DES keys
+
             # for DES keys
 
-     authspeed -n 30000 auth.samplekeys
-     # for MD5 keys
+     authspeed -n 30000 auth.samplekeys
+     # for MD5 keys
 
-     authspeed -mn 30000 auth.samplekeys
-
        
+     authspeed -mn 30000 auth.samplekeys
        
 Additional utility programs included in the ./authstuff
 directory
 can be used to generate random keys, certify implementation correctness
@@ -935,23 +942,29 @@ the user as a password.
 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:
-
        -     # ntp keys file (ntp.keys)
-     1    N   29233E0461ECD6AE    # des key in NTP format
-     2    M   RIrop8KPPvQvYotM    # md5 key as an ASCII random string
-     14   M   sundial             # md5 key as an ASCII string
-     15   A   sundial             # des key as an ASCII string
-
-     # the following 3 keys are identical
-
-     10   A    SeCReT
-     10   N    d3e54352e5548080
-     10   S    a7cb86a4cba80101
-
        
+
             # ntp keys file (ntp.keys)
+     1    N   
+29233E0461ECD6AE    # des key in NTP format
+     2    M   
+RIrop8KPPvQvYotM    # md5 key as an ASCII random string
+     14   M   
+sundial           
+;  # md5 key as an ASCII string
+     15   A   
+sundial           
+;  # des key as an ASCII string
+
+     # the following 3 keys are identical
+
+     10   A    SeCReT
+     10   N   
+d3e54352e5548080
+     10   S   
+a7cb86a4cba80101
        
 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 A indicates a DES key written as a
-1-to-8
+are four key formats. An A 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 S indicates a DES
@@ -988,7 +1001,8 @@ Three utility query programs are included with the distribution,
 ntptrace and ntpdc. ntpq 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,
+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
@@ -1045,17 +1059,25 @@ support for the latter. The leap bits that can be set in the
 variable (up to one month ahead) and in the leap_indication
 variable
 have a slightly different encoding than the usual interpretation:
-
               
-Value           Action
-
-00              The daemon passes the leap bits of its
-                synchronisation source (usual mode of operation)
-
-01/10           A leap second is added/deleted
-  
-11              Leap information from the synchronization source
-                is ignored (thus LEAP_NOWARNING is passed on)
-
        
+
               
+Value           Action
+
+        
+00           &nbs
+p; The daemon passes the leap bits of its
+            
+           
+synchronisation source (usual mode of operation)
+
+        01/10   A leap
+second is added/deleted
+
+        
+11           &nbs
+p; Leap information from the synchronization source
+            
+            is
+ignored (thus LEAP_NOWARNING is passed on)
        
 Mode-6 and mode-7 messages which would modify the configuration of the
 server are required to be authenticated using standard NTP
 authentication.
@@ -1067,12 +1089,12 @@ for authenticating reconfiguration commands. Hence the following
 fragment
 might be added to a configuration file to enable the mode-6 (ntpq) and
 mode-7 (ntpdc) facilities in the daemon:
-
        -     # specify mode-6 and mode-7 trusted keys
+
             # specify mode-6 and mode-7 trusted keys
 
-     requestkey 65535    # for mode-7 requests
-     controlkey 65534    # for mode-6 requests
-
        
+     requestkey 65535    # for mode-7
+requests
+     controlkey 65534    # for mode-6
+requests
        
 If the requestkey and/or the controlkey configuration
 declarations are omitted from the configuration file, the corresponding
 run-time reconfiguration facility is disabled.
@@ -1207,7 +1229,7 @@ to set the value of the kernel dosynctodr 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 happen when ntpd
+clock, something you really don't want to be happen when ntpd
 is trying to keep it under control. In some systems, such as recent Sun
 Solaris kernels, the dosynctodr variable is the only one that
 can be changed by the tickadj program. In this and other modern
@@ -1231,7 +1253,7 @@ more.
 Multiply the time change over the day by 0.116 and add or subtract the
 result to tick, depending on whether the CPU is fast or slow. An example
 call to tickadj useful on SunOS 4.1.1 is:
-
             tickadj -t 9999 -a 5 -s
        
+
             tickadj -t 9999 -a 5 -s
        
 which sets tick 100 PPM fast, tickadj to 5 microseconds and
 turns
 off the clock/calendar chip fiddle. This line can be added to the
@@ -1280,11 +1302,10 @@ convenient
 to elect one of the servers at each stratum level as the preferred one
 using the keyword prefer on the configuration declaration for
 the selected server:
-
        -     # preferred server declaration
+
             # preferred server declaration
 
-     peer rackety.udel.edu prefer   # preferred server
-
        
+     peer rackety.udel.edu prefer   
+# preferred server
        
 The preferred server will always be included in the surviving
 population,
 regardless of its characteristics and as long as it survives preliminary
@@ -1316,7 +1337,7 @@ these bits are propagated throughout the subnet depending on these
 servers
 by the NTP protocol itself and automatically implemented by
 ntpd
-and the time-conversion routines of each host. The implementation is
+and the time- conversion routines of each host. The implementation is
 independent
 of the idiosyncrasies of the particular radio clock, which vary widely
 among the various devices, as long as the idiosyncratic behavior does
@@ -1332,7 +1353,8 @@ second is scrupulously correct, stock Unix systems are mostly inept in
 responding to the available information. This caveat goes also for the
 maximum-error and statistical-error bounds carefully calculated for all
 clients and servers, which could be very useful for application programs
-needing to calibrate the delays and offsets to achieve a near-simultaneous
+needing to calibrate the delays and offsets to achieve a near-
+simultaneous
 commit procedure, for example. While this information is maintained in
 the ntpd data structures, there is at present no way for
 application
@@ -1364,7 +1386,7 @@ normal
 peer, should this stretch of imagination ever be useful. As a concession
 to the need to sometimes transmit additional information to clock
 drivers,
-an additional configuration command is available: the fudge
+an additional configuration file is available: the fudge
 statement.
 This enables one to specify the values of two time quantities, two
 integral
@@ -1379,12 +1401,10 @@ an imprecise system clock and with the driver set to disbelieve the
 radio
 clock once it has gone 30 minutes without an update, one might use the
 following configuration file entries:
-
        -     # radio clock fudge fiddles
-     server 127.127.3.1
-     fudge 127.127.3.1 time1 0.0075 time2 0.0265
-     fudge 127.127.3.1 value2 30 flag1 1
-
        
+
             # radio clock fudge fiddles
+     server 127.127.3.1
+     fudge 127.127.3.1 time1 0.0075 time2 0.0265
+     fudge 127.127.3.1 value2 30 flag1 1
        
 Additional information on the interpretation of these data with respect
 to various radio clock drivers is given in the Reference
@@ -1441,7 +1461,7 @@ used to substantially improve the (disciplined) clock oscillator jitter
 and wander characteristics by at least an order of magnitude. Using
 these
 features it is possible to achieve accuracies in the order of a few tens
-of microseconds with a fast RISC-based platform.
+of microseconds with a fast RISC- based platform.
 
 
        There are three ways to implement PPS support, depending on the radio
 clock model, platform model and serial line interface. These are
@@ -1480,8 +1500,9 @@ clock.
 
        
 Parting Shots
        
 There are several undocumented programs which can be useful in unusual
-cases. They can be found in the ./clockstuff
-directory of the distribution. One of these is the propdelay
+cases. They can be found in the ./clockstuff and
+./authstuff
+directories of the distribution. One of these is the propdelay
 program, which can compute high frequency radio propagation delays
 between
 any two points whose latitude and longitude are known. The program
@@ -1494,8 +1515,8 @@ based on the great circle distance. Other programs of interest include
 clktest, which allows one to exercise the generic clock line
 discipline,
 and chutest, which runs the basic reduction algorithms used by
-the daemon on data received from a serial port. 
+the daemon on data received from a serial port. 
 
 
         David L. Mills <mills@udel.edu>
-
        
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/ntpd.htm b/html/ntpd.htm
index 7d8078f2f6..f4ff585b94 100644
--- a/html/ntpd.htm
+++ b/html/ntpd.htm
@@ -1,179 +1,247 @@
-
-ntpd</tt> - Network Time Protocol (NTP) daemon
-
        
-ntpd - Network Time Protocol (NTP) daemon
-
        
+
+
+   
+   
+   ntpd - Network Time Protocol (NTP) daemon
+
+
+
+
+
        
+ntpd - Network Time Protocol (NTP) daemon
        
+
+
        
+
        
+Synopsis
        
+ntpd [ -aAbdm ] [ -c conffile ] [ -f driftfile ] [ -k
+keyfile ] [ -l logfile ] [ -p pidfile ] [ -r broadcastdelay
+] [ -s statsdir ] [ -t key ] [ -v variable ] [ -V
+variable ]
+
        
+Description
        
+ntpd is an operating system daemon which sets and maintains the
+system time-of-day in synchronism with Internet standard time servers.
+ntpd is a complete implementation of the Network Time Protocol
+(NTP) version 4, but also retains compatibility with version 3, as defined
+by RFC-1305, and version 1 and 2, as defined by RFC-1059 and RFC-1119,
+respectively. ntpd does most computations in 64-bit floating point
+arithmetic and does relatively clumsy 64-bit fixed point operations only
+when necessary to preserve the unltimate precision, about 232 picoseconds.
+While the ultimate precision, is not achievable with ordinary workstations
+and networks of today, it may be required with future nanosecond CPU clocks
+and gigabit LANs.
 
-
        Synopsis
        
+
        The daemon can operate in any of several modes, including symmetric
+active/passive, client/server broadcast/multicast and manycast. A broadcast/multicast
+or manycast client can discover remote servers, compute server-client propagation
+delay correction factors and configure itself automatically. This makes
+it possible to deploy a fleet of workstations without specifying configuration
+details specific to the local environment.
 
-ntpd [ -aAbdgmnx ] [ -c conffile ] [ -D level ]
-[ -f driftfile ] [ -k keyfile ] [ -l logfile ]
-[ -p pidfile ] [ -P priority ] [ -r broadcastdelay ]
-[ -s statsdir ] [ -t key ] [ -v variable ]
-[ -V variable ]
+
        Ordinarily, ntpd reads the ntp.conf configuration
+file at startup time in order to determine the synchronization sources
+and operating modes. It is also possible to specify a working, although
+limited, configuration entirely on the command line, obviating the need
+for a configuration file. This may be particularly appropriate when the
+local host is to be configured as a broadcast/multicast client or manycast
+client, with all peers being determined by listening to broadcasts at run
+time.
 
-
        Description
        
+
        Various internal ntpd variables can be displayed and configuration
+options altered while the daemon is running using the ntpq
+and ntpdc utility programs.
 
-ntpd is an operating system daemon which sets and maintains the
-system time-of-day in synchronism with Internet standard time servers.
-ntpd is a complete implementation of the Network Time Protocol
-(NTP) version 4, but also retains compatibility with version 3, as
-defined by RFC-1305, and version 1 and 2, as defined by RFC-1059 and
-RFC-1119, respectively. ntpd does most computations in 64-bit
-floating point arithmetic and does relatively clumsy 64-bit fixed point
-operations only when necessary to preserve the ultimate precision,
-about 232 picoseconds. While the ultimate precision, is not achievable
-with ordinary workstations and networks of today, it may be required
-with future nanosecond CPU clocks and gigabit LANs.
-
-
        The daemon can operate in any of several modes, including symmetric
-active/passive, client/server, broadcast/multicast and manycast. A
-broadcast/multicast or manycast client can discover remote servers,
-compute server-client propagation delay correction factors and configure
-itself automatically. This makes it possible to deploy a fleet of
-workstations without specifying configuration details specific to the
-local environment.
-
-
        Ordinarily, ntpd reads the command line options and
-ntp.conf configuration file at startup time in order to
-determine the synchronization sources and operating modes. It is also
-possible to specify a working, although limited, configuration entirely
-on the command line, obviating the need for a configuration file. This
-may be particularly appropriate when the local host is to be configured
-as a broadcast/multicast client or manycast client, with all peers being
-determined by listening to broadcasts at run time.
-
-
        Note that the -x command line option disables clock
-stepping, in which case all adjustments are always slewed, no matter
-what the correction value is. Since the slew rate is intentionally
-small, as required by correctness principles, this may delay convergence
-of the clock discipline 2000 seconds for each second of correction.
-During this interval the clock cannot be considered correct and can
-easily destabilize dependent clients. Thus, this option should be used
-only sparingly.
-
-
        Various internal ntpd variables can be displayed and
-configuration options altered while the daemon is running using the
-ntpq and ntpdc utility programs.
-
-
        When ntpd starts it looks at the value of umask,
-and if it's zero ntpd will set the umask to
-022.
-
-
        Command Line Options
        
-
-
        
-
        -a
        
-
        Enable authentication mode (default).
        
-
-
        -A
        
-
        Disable authentication mode.
        
-
-
        -b
        
-
        Synchronize using NTP broadcast messages.
        
-
        -c conffile
        
-
        Specify the name and path of the configuration file.
        
-
-
        -d
        
-
        Increase debugging level. This flag may occur multiple times, with
-the debug level increasing by one with each occurance.
        
-
-
        -D level
        
-
        Specify debugging level.
        
-
-
        -f driftfile
        
-
        Specify the name and path of the drift file.
        
-
-
        -g
        
-
        Allow time corrections greater than the panic maximum (default 1000
-seconds).
        
-
-
        -k keyfile
        
-
        Specify the name and path of the file containing the NTP
-authentication keys.
        
-
-
        -l logfile
        
-
        Specify the name and path of the log file. The default is the system
-log facility.
        
-
-
        -m
        
-
        Synchronize using NTP multicast messages on the IP multicast group
-address 224.0.1.1 (requires multicast kernel).
        
-
-
        -n
        
-
        Do not fork resolver process (for system debugging).
        
-
-
        -p pidfile
        
-
        Specify the name and path to record the daemon's process ID.
        
-
-
        -P priority
        
-
        Specify scheduling priority (requires kernel support).
        
-
-
        -r broadcastdelay
        
-
        Specify the default propagation delay from the broadcast/multicast
-server and this client. This is necessary only if the delay cannot be
-computed automatically by the protocol.
        
-
-
        -s statsdir
        
-
        Specify the directory path for files created by the statistics
-facility.
        
-
-
        -t key
        
-
        Add a key number to the trusted key list.
        
-
-
        -v variable
        
-
        Add a system variable.
        
-
-
        -V variable
        
-
        Add a system variable listed by default.
        
-
-
        -x
        
-
        Disable step time corrections; use only slew corrections (maximum
-500 PPM slew rate).
        
-
-
        
-
-
        The Configuration File
        
-
-The ntpd configuration file is read at initial startup in order
-to specify the synchronization sources, modes and other related
-information. Usually, it is installed in the /etc directory,
-but could be installed elsewhere (see the -c conffile
-command line option). The file format is similar to other Unix
-configuration files - comments begin with a # character and
-extend to the end of the line; blank lines are ignored. Configuration
-commands consist of an initial keyword followed by a list of arguments,
-some of which may be optional, separated by whitespace. Commands may not
-be continued over multiple lines. Arguments may be host names, host
-addresses written in numeric, dotted-quad form, integers, floating point
-numbers (when specifying times in seconds) and text strings. Optional
-arguments are delimited by [ ] in the following descriptions,
-while alternatives are separated by |. The notation [ ...
-] means an optional, indefinite repetition of the last item before
-the [ ... ].
-
-
        See the following pages for configuration and control options. While
-there is a rich set of options available, the only required option is
-one or more server, peer, broadcast or
-manycastclient commands described in the Configuration Options
-page. The Notes on Configuring NTP and Setting up a
-NTP Subnet page contains an extended
-discussion of these options.
+
        When ntpd starts it looks at the value of umask, and
+if it's zero ntpd will set the umask to 022.
+
        
+Command Line Options
        
+
+
        
+
        
+-a
        
+
+
        
+Enable authentication mode (default).
        
+
+
        
+
        
+
+
        
+-A
        
+
+
        
+Disable authentication mode.
        
+
+
        
+
        
+
+
        
+-b
        
+
+
        
+Synchronize using NTP broadcast messages.
        
+
+
        
+
        
+
+
        
+-c conffile
        
+
+
        
+Specify the name and path of the configuration file.
        
+
+
        
+
        
+
+
        
+-d
        
+
+
        
+Specify debugging mode. This flag may occur multiple times, with each occurrence
+indicating greater detail of display.
        
+
+
        
+
        
+
+
        
+-f driftfile
        
+
+
        
+Specify the name and path of the drift file.
        
+
+
        
+
        
+
+
        
+-k keyfile
        
+
+
        
+Specify the name and path of the file containing the NTP authentication
+keys.
        
+
+
        
+
        
 
-
        Configuration Options
-
        Authentication Options
-
        Monitoring Options
-
        Access Control Options
-
        Reference Clock Options
-
        Miscellaneous Options
+
        
+-l logfile
        
 
-
        Files
        
+
        
+Specify the name and path of the log file. The default is the system log
+facility.
        
 
-/etc/ntp.conf - the default name of the configuration file
-
        /etc/ntp.drift - the default name of the drift file
-
        /etc/ntp.keys - the default name of the key file
+
        
+
        
+
+
        
+-m
        
+
+
        
+Synchronize using NTP multicast messages on the IP multicast group address
+224.0.1.1 (requires multicast kernel).
        
+
+
        
+
        
+
+
        
+-p pidfile
        
+
+
        
+Specify the name and path to record the daemon's process ID.
        
+
+
        
+
        
+
+
        
+-r broadcastdelay
        
+
+
        
+Specify the default propagation delay from the broadcast/multicast server
+and this computer. This is necessary only if the delay cannot be computed
+automatically by the protocol.
        
+
+
        
+
        
+
+
        
+-s statsdir
        
+
+
        
+Specify the directory path for files created by the statistics facility.
        
+
+
        
+
        
+
+
        
+-t key
        
+
+
        
+Add a key number to the trusted key list.
        
+
+
        
+
        
+
+
        
+-v variable
        
+
+
        
+Add a system variable.
        
+
+
        
+
        
+
+
        
+-V variable
        
+
+
        
+Add a system variable listed by default.
        
+
        
+
+
        
+The Configuration File
        
+The ntpd configuration file is read at initial startup in order
+to specify the synchronization sources, modes and other related information.
+Usually, it is installed in the /etc directory, but could be installed
+elsewhere (see the -c conffile command line option). The
+file format is similar to other Unix configuration files - comments begin
+with a # character and extend to the end of the line; blank lines
+are ignored. Configuration commands consist of an initial keyword followed
+by a list of arguments, some of which may be optional, separated by whitespace.
+Commands may not be continued over multiple lines. Arguments may be host
+names, host addresses written in numeric, dotted-quad form, integers, floating
+point numbers (when specifying times in seconds) and text strings. Optional
+arguments are delimited by [ ] in the following descriptions,
+while alternatives are separated by |. The notation [ ...
+] means an optional, indefinite repetition of the last item before
+the [ ... ].
+
+
        See the following pages for configuration and control options. While
+there is a rich set of options available, the only required option is one
+or more server, peer, broadcast or manycastclient
+commands described in the Configuration Options page. The Notes
+on Configuring NTP and Setting up a NTP Subnet page contains an extended
+discussion of these options.
 
-
         David L. Mills <mills@udel.edu>
-
        
+
        Configuration Options
+
        Authentication Options
+
        Monitoring Options
+
        Access Control Options
+
        Reference Clock Options
+
        Miscellaneous Options
+
        
+Files
        
+/etc/ntp.conf - the default name of the configuration file
+
        /etc/ntp.drift - the default name of the drift file
+
        /etc/ntp.keys - the default name of the key file
+
        
+Bugs
        
+ntpd has gotten rather fat. While not huge, it has gotten larger
+than might be desireable for an elevated-priority daemon running on a workstation,
+particularly since many of the fancy features which consume the space were
+designed more with a busy primary server, rather than a high stratum workstation,
+in mind. 
+
        
+
        
+David L. Mills (mills@udel.edu)
        
+
+
+
diff --git a/html/ntpdate.htm b/html/ntpdate.htm
index ed737c8717..2a68ee2f12 100644
--- a/html/ntpdate.htm
+++ b/html/ntpdate.htm
@@ -60,7 +60,7 @@ Command Line Options
 
 
        
 Enable the authentication function and specify the key identifier to be
-used for authentication as the argument key. The
+used for authentication as the argument keyntpdate. The
 keys and key identifiers must match in both the client and server key files.
 The default is to disable the authentication function.
        
 
@@ -69,11 +69,11 @@ The default is to disable the authentication function.
 
 
        
 Force the time to always be slewed using the adjtime() system call, even
-if the measured offset is greater than +-500 ms. The default is to step
-the time using settimeofday() if the offset is greater than +-500 ms. Note
-that, if the offset is much greater than +-500 ms in this case, that it
+if the measured offset is greater than +-128 ms. The default is to step
+the time using settimeofday() if the offset is greater than +-128 ms. Note
+that, if the offset is much greater than +-128 ms in this case, that it
 can take a long time (hours) to slew the clock to the correct value. During
-this time, the host should not be used to synchronize clients.
        
+this time. the host should not be used to synchronize clients.
 
 
        
 -b
        
@@ -114,7 +114,7 @@ described in ntpd.
 
 
        
 Specify the NTP version for outgoint packets as the integer version,
-which can be 1, 2, 3 or 4. The default is 4. This allows ntpdate to
+which can be 1 or 2. The default is 3. This allows ntpdate to
 be used with older NTP versions.
        
 
 
        
@@ -171,8 +171,10 @@ Bugs
 The slew adjustment is actually 50% larger than the measured offset, since
 this (it is argued) will tend to keep a badly drifting clock more accurate.
 This is probably not a good idea and may cause a troubling hunt for some
-values of the kernel variables tick and tickadj. 
+values of the kernel variables tick and tickadj. 
+
        
+
        
+David L. Mills (mills@udel.edu)
        
 
-
         David L. Mills <mills@udel.edu>
-
        
+
+
diff --git a/html/ntpdc.htm b/html/ntpdc.htm
index d4b4dc0f7b..52d1fdfe25 100644
--- a/html/ntpdc.htm
+++ b/html/ntpdc.htm
@@ -24,7 +24,7 @@ interface. In addition, nearly all the configuration options which can
 be specified at start up using ntpd's configuration file may also be specified
 at run time using ntpdc.
 
-
        If one or more request options are included on the command line when
+
        If one or more request options is included on the command line when
 ntpdc is executed, each of the requests will be sent to the NTP
 servers running on each of the hosts given as command line arguments, or
 on localhost by default. If no request options are given, ntpdc
@@ -34,14 +34,14 @@ again defaulting to localhost when no other host is specified. ntpdc
 will prompt for commands if the standard input is a terminal device.
 
 
        ntpdc uses NTP mode 7 packets to communicate with the NTP server,
-and hence can be used to query any compatible server on the network which
+and hence can be used to query any compatable server on the network which
 permits it. Note that since NTP is a UDP protocol this communication will
 be somewhat unreliable, especially over large distances in terms of network
 topology. ntpdc makes no attempt to retransmit requests, and will
 time requests out if the remote host is not heard from within a suitable
 timeout time.
 
-
        The operation of ntpdc is specific to the particular implementation
+
        The operation of ntpdc are specific to the particular implementation
 of the ntpd daemon and can be expected to work only with this
 and maybe some previous versions of the daemon. Requests from a remote
 ntpdc program which affect the state of the local server must
@@ -60,7 +60,7 @@ format commands from the standard input.
 
        
 The following argument is interpreted as an interactive format command
 and is added to the list of commands to be executed on the specified host(s).
-Multiple -c options may be given.
        
+Multiple -c options may be given.
 
 
        
 -i
        
@@ -95,7 +95,7 @@ state. This is equivalent to -c peers.
 
 
        
 Print a list of the peers known to the server as well as a summary of their
-state, but in a slightly different format than the -p switch. This is equivalent
+state, but in a slightly different format than the -p switch. This is equivalent
 to -c dmpeers.
        
 
 
@@ -105,7 +105,7 @@ Interactive format commands consist of a keyword followed by zero to four
 arguments. Only enough characters of the full keyword to uniquely identify
 the command need be typed. The output of a command is normally sent to
 the standard output, but optionally the output of individual commands may
-be sent to a file by appending a >, followed by a file name,
+be sent to a file by appending a <, followed by a file name,
 to the command line.
 
 
        A number of interactive format commands are executed entirely within
@@ -115,12 +115,12 @@ being sent to a server. These are described following.
 
        
 ? [ command_keyword ]
        
 
-
        help [ command_keyword ]
        
+
        helpl [ command_keyword ]
 
        
 A ? by itself will print a list of all the command keywords known
-to this incarnation of ntpdc. A ? followed by a command
-keyword will print function and usage information about the command. This
-command is probably a better source of information about ntpdc
+to this incarnation of ntpq. A ? followed by a command
+keyword will print funcation and usage information about the command. This
+command is probably a better source of information about ntpq
 than this manual page.
        
 
 
        
@@ -213,7 +213,8 @@ operating in. A + denotes symmetric active, a - indicates
 symmetric passive, a = means the remote server is being polled
 in client mode, a ^ indicates that the server is broadcasting
 to this address, a ~ denotes that the remote peer is sending broadcasts
-and a * marks the peer the server is currently synchronizing to.
+and a * marks the peer the server is currently synchonizing to.
+
 
 
        The contents of the host field may be one of four forms. It may be a
 host name, an IP address, a reference clock implementation name with its
@@ -236,7 +237,7 @@ is currently synchronizing with.
 
 
        
 Shows a detailed display of the current peer variables for one or more
-peers. Most of these values are described in the NTP Version 3 specification.
        
+peers. Most of these values are described in the NTP Version 2 specification.
 
 
        
 pstats peer_address [...]
        
@@ -282,8 +283,9 @@ as the default.
 
        
 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.
+3 specification, RFC-1305.
        
 
+
        
 
        
 The system flags show various system flags, some of which can
 be set and cleared by the enable and disable configuration
@@ -312,6 +314,7 @@ the broadcastdelay configuration command.
        
 
        
 The authdelay shows the default authentication delay, as set by
 the authdelay configuration command.
        
+
        
 
 
        
 sysstats
        
@@ -366,7 +369,7 @@ Runtime Configuration Requests
 All requests which cause state changes in the server are authenticated
 by the server using a configured NTP key (the facility can also be disabled
 by the server by not configuring a key). The key number and the corresponding
-key must also be made known to ntpdc. This can be done using the keyid
+key must also be made known to xtnpdc. This can be done using the keyid
 and passwd commands, the latter of which will prompt at the terminal for
 a password to use as the encryption key. You will also be prompted automatically
 for both the key number and password the first time a command which would
@@ -404,7 +407,7 @@ to conform to the new configuration, as appropriate. If the optional keyidversion#
-can be 1, 2, 3 or 4 and defaults to 3. The prefer keyword indicates
+can be 1, 2 or 3 and defaults to 3. The prefer keyword indicates
 a preferred peer (and thus will be used primarily for clock synchronisation
 if possible). The preferred peer also determines the validity of the PPS
 signal - if the preferred peer is suitable for synchronisation so is the
@@ -445,15 +448,18 @@ mode if the remote peer is willing to continue on in this fashion.
 This command provides a way to set certain data for a reference clock.
 See the source listing for further information.
 
-
        enable [ flag ] [ ... ]
        
-
        disable [ flag ] [ ... ]
        
+
        
+enable [ flag ] [ ... ]
        
+
+
        disable [ flag ] [ ... ]
 
        
 These commands operate in the same way as the enable and disable
 configuration file commands of ntpd. Following is a description
 of the flags. Note that only the auth, bclient, monitor,
 pll, pps and stats flags can be set by ntpdc;
-the kernel_sync and pps_sync flags are read-only.
        
+the pll_kernel and pps_kernel flags are read-only.
 
+
        
 
        
 auth
        
 
@@ -474,8 +480,8 @@ The default for this flag is disable.
 monitor
 
 
        
-Enables the monitoring facility. See the
-monlist command for further information. The default for this flag
+Enables the monitoring facility. See the ntpdc program and the
+monlist command or further information. The default for this flag
 is enable.
        
 
 
        
@@ -523,6 +529,7 @@ When the precision time kernel modifications are installed and a pulse-per-secon
 (PPS) signal is available, this indicates the PPS signal controls the clock
 discipline; otherwise, the daemon or kernel controls the clock discipline,
 as indicated by the pll_kernel flag.
+
        
 
 
        
 restrict address mask flag [ flag ]
        
@@ -604,8 +611,10 @@ Bugs
 boring and could only be loved by its implementer. The program was designed
 so that new (and temporary) features were easy to hack in, at great expense
 to the program's ease of use. Despite this, the program is occasionally
-useful.
+useful. 
+
        
+
        
+David L. Mills (mills@udel.edu)
        
 
-
         David L. Mills <mills@udel.edu>
-
        
+
+
diff --git a/html/ntpq.htm b/html/ntpq.htm
index 42d85dc96a..930886736d 100644
--- a/html/ntpq.htm
+++ b/html/ntpq.htm
@@ -8,7 +8,7 @@
 
 
 
        
-ntpq - standard NTP query program
        
+pq - standard NTP query program
 
 
        
 
        
@@ -24,7 +24,7 @@ can be assembled, with raw and pretty-printed output options being available.
 ntpq can also obtain and print a list of peers in a common format
 by sending multiple queries to the server.
 
-
        If one or more request options are included on the command line when
+
        If one or more request options is included on the command line when
 ntpq is executed, each of the requests will be sent to the NTP
 servers running on each of the hosts given as command line arguments, or
 on localhost by default. If no request options are given, ntpq
@@ -34,7 +34,7 @@ again defaulting to localhost when no other host is specified. ntpq
 will prompt for commands if the standard input is a terminal device.
 
 
        ntpq uses NTP mode 6 packets to communicate with the NTP server,
-and hence can be used to query any compatible server on the network which
+and hence can be used to query any compatable server on the network which
 permits it. Note that since NTP is a UDP protocol this communication will
 be somewhat unreliable, especially over large distances in terms of network
 topology. ntpq makes one attempt to retransmit requests, and will
@@ -42,7 +42,7 @@ time requests out if the remote host is not heard from within a suitable
 timeout time.
 
 
        Command line options are described following. Specifying a command line
-option other than -i or -n will cause the specified query (queries) to
+option other than -i or -n will cause the specified query (queries) to
 be sent to the indicated host(s) immediately. Otherwise, ntpq
 will attempt to read interactive format commands from the standard input.
 
        
@@ -52,7 +52,7 @@ will attempt to read interactive format commands from the standard input.
 
        
 The following argument is interpreted as an interactive format command
 and is added to the list of commands to be executed on the specified host(s).
-Multiple -c options may be given.
        
+Multiple -c options may be given.
 
 
        
 -i
        
@@ -82,47 +82,59 @@ Interactive format commands consist of a keyword followed by zero to four
 arguments. Only enough characters of the full keyword to uniquely identify
 the command need be typed. The output of a command is normally sent to
 the standard output, but optionally the output of individual commands may
-be sent to a file by appending a ">", followed by a file name, to the
+be sent to a file by appending a "<", followed by a file name, to the
 command line. A number of interactive format commands are executed entirely
 within the ntpq program itself and do not result in NTP mode 6
 requests being sent to a server. These are described following.
 
        
-
        ? [command_keyword]
        
-
        help [ command_keyword ]
        
+
        
+? [command_keyword]
        
+
+
        helpl [ command_keyword ]
 
        
 A "?" by itself will print a list of all the command keywords
 known to this incarnation of ntpq. A "?" followed by
-a command keyword will print function and usage information about the
+a command keyword will print funcation and usage information about the
 command. This command is probably a better source of information about
 ntpq than this manual page.
        
 
-
        addvars variable_name [ = value] [...]
        
-
        rmvars variable_name [...]
        
-
        clearvars
        
+
        
+ 
        
+
+
        
+addvars variable_name [ = value] [...]
        
 
+
        rmvars variable_name [...]
+
        clearvars
 
        
 The data carried by NTP mode 6 messages consists of a list of items of
 the form variable_name = value, where the "
 = value" is ignored, and can be omitted, in requests to the
 server to read variables. ntpq maintains an internal list in which
 data to be included in control messages can be assembled, and sent using
-the readlist and writelist commands described below. The addvars command
+the readlist and writelist commands described below. The addvars command
 allows variables and their optional values to be added to the list. If
 more than one variable is to be added, the list should be comma-separated
-and not contain white space. The rmvars command can be used to remove individual
-variables from the list, while the clearvars command removes all variables
+and not contain white space. The rmvars command can be used to remove individual
+variables from the list, while the clearlist command removes all variables
 from the list.
        
 
+
        
+ 
        
+
 
        
 authenticate yes | no
        
 
 
        
 Normally ntpq does not authenticate requests unless they are write
-requests. The command authenticate yes causes ntpq to send authentication
+requests. The command authenticate yes causes ntpq to send authentication
 with all requests it makes. Authenticated requests causes some servers
 to handle requests slightly differently, and can occasionally melt the
 CPU in fuzzballs if you turn authentication on before doing a peer display.
        
 
+
        
+ 
        
+
 
        
 cooked
        
 
@@ -132,6 +144,9 @@ are recognized by the server will have their values reformatted for human
 consumption. Variables which ntpq thinks should have a decodeable
 value but didn't are marked with a trailing "?".
 
+
        
+ 
        
+
 
        
 debug more | less | off
        
 
@@ -139,7 +154,7 @@ value but didn't are marked with a trailing "?".
 Turns internal query program debugging on and off.
 
 
        
- 
        
+ 
 
 
        
 delay milliseconds
        
@@ -152,7 +167,7 @@ clocks are unsynchronized. Actually the server does not now require timestamps
 in authenticated requests, so this command may be obsolete.
 
 
        
- 
        
+ 
 
 
        
 host hostname
        
@@ -162,7 +177,7 @@ Set the host to which future queries will be sent. Hostname may be either
 a host name or a numeric address.
 
 
        
- 
        
+ 
 
 
        
 hostnames [yes | no]
        
@@ -174,7 +189,7 @@ default is "yes", unless modified using the command line -n
 switch.
 
 
        
- 
        
+ 
 
 
        
 keyid keyid
        
@@ -185,7 +200,7 @@ configuration requests. This must correspond to a key number the server
 has been configured to use for this purpose.
 
 
        
- 
        
+ 
 
 
        
 ntpversion 1 | 2 | 3 | 4
        
@@ -197,7 +212,7 @@ exist in NTP version 1. There appear to be no servers left which demand
 version 1.
 
 
        
- 
        
+ 
 
 
        
 quit
        
@@ -206,7 +221,7 @@ version 1.
 Exit ntpq.
 
 
        
- 
        
+ 
 
 
        
 passwd
        
@@ -218,18 +233,18 @@ must correspond to the key configured for use by the NTP server for this
 purpose if such requests are to be successful.
 
 
        
- 
        
+ 
 
 
        
 raw
        
 
 
        
-Causes all output from query commands to be printed as received from the remote
-server. The only formating/interpretation done on the data is to transform
+Causes all output from query commands is printed as received from the remote
+server. The only formating/intepretation done on the data is to transform
 nonascii data into a printable (but barely understandable) form.
        
 
 
        
- 
        
+ 
 
 
        
 timeout millseconds
        
@@ -266,7 +281,7 @@ for in-spec peers of the server being queried. The list is printed in columns.
 The first of these is an index numbering the associations from 1 for internal
 use, the second the actual association identifier returned by the server
 and the third the status word for the peer. This is followed by a number
-of columns containing data decoded from the status word. See the peers command
+of columns containing data decoded from the status word See the peers command
 for a decode of the condition field. Note that the data returned
 by the "associations" command is cached internally in ntpq.
 The index is then of use when dealing with stupid servers which use association
@@ -275,7 +290,7 @@ commands which require an association identifier as an argument, the form
 and index may be used as an alternative.
 
 
        
- 
        
+ 
 
 
        
 clockvar [assocID] [variable_name [ = value [...]
@@ -297,7 +312,7 @@ show the variables of a particular clock. Omitting the variable list will
 cause the server to return a default variable display.
 
 
        
- 
        
+ 
 
 
        
 lassocations
        
@@ -311,7 +326,7 @@ associations are normally omitted from the display when the "associations""lassociations".
 
 
        
- 
        
+ 
 
 
        
 lpassociations
        
@@ -322,40 +337,44 @@ from the internally cached list of associations. This command differs from
 "passociations" only when dealing with fuzzballs.
 
 
        
- 
        
+ 
 
 
        
 lpeers
        
 
 
        
-Like peers, except a summary of all associations for which the server
+Like R peers, except a summary of all associations for which the server
 is maintaining state is printed. This can produce a much longer list of
 peers from fuzzball servers.
        
 
 
        
- 
        
+ 
+
+
        
+mreadlist assocID assocID
        
 
-
        mreadlist assocID assocID
        
-
        mrl assocID assocID
        
+
        mrl assocID assocID
 
        
 Like the readlist command, except the query is done for each of
 a range of (nonzero) association IDs. This range is determined from the
 association list cached by the most recent associations command.
        
 
 
        
- 
        
+ 
 
-
        mreadvar assocID assocID
-[ variable_name [ = value [ ... ]
        
-
        mrv assocID assocID
-[ variable_name [ = value [ ... ]
        
+
        
+mreadvar assocID assocID [ variable_name [ = value
+[ ... ]
        
+
+
        mrv assocID assocID [ variable_name [ = value
+[ ... ]
 
        
 Like the readvar command, except the query is done for each of
 a range of (nonzero) association IDs. This range is determined from the
 association list cached by the most recent associations command.
        
 
 
        
- 
        
+ 
 
 
        
 opeers
        
@@ -365,7 +384,7 @@ An old form of the peers command with the reference ID replaced
 by the local interface address.
 
 
        
- 
        
+ 
 
 
        
 passociations
        
@@ -377,7 +396,7 @@ except that it displays the internally stored data rather than making a
 new query.
 
 
        
- 
        
+ 
 
 
        
 peers
        
@@ -391,149 +410,254 @@ the last packet was received, the polling interval, in seconds, the reachability
 register, in octal, and the current estimated delay, offset and dispersion
 of the peer, all in milliseconds.
 
+
        
+ 
        
+
 
        
 The character in the left margin indicates the fate of this peer in the
-clock selection process. Following is a list of these characters, the pigeon
+clock selection process. Folowing is a list of these characters, the pidgeon
 used in the rv command, and a short explanation of the condition
 revealed.
        
 
+
        
+ 
        
+
 
        
 space reject
        
 
+
        
 
        
 The peer is discarded as unreachable, synchronized to this server (synch
 loop) or outrageous synchronization distance.
        
 
 
        
-x     falsetick
        
+ 
+
        
 
+
        
+x     falsetick
        
+
+
        
 
        
 The peer is discarded by the intersection algorithm as a falseticker.
        
 
 
        
-.     excess
        
+ 
+
        
 
+
        
+.     excess
        
+
+
        
 
        
 The peer is discarded as not among the first ten peers sorted by synchronization
 distance and so is probably a poor candidate for further consideration.
        
 
 
        
--     outlyer
        
+ 
+
        
+
+
        
+-     outlyer
        
 
+
        
 
        
 The peer is discarded by the clustering algorithm as an outlyer.
        
 
 
        
-+     candidat
        
+ 
+
        
+
+
        
++     candidat
        
 
+
        
 
        
 The peer is a survivor and a candidate for the combining algorithm.
        
 
 
        
-#     selected
        
+ 
+
        
 
+
        
+#     selected
        
+
+
        
 
        
 The peer is a survivor, but not among the first six peers sorted by synchronization
 distance. If the assocation is ephemeral, it may be demobilized to conserve
 resources.
        
 
 
        
-*     sys.peer
        
+ 
+
        
 
+
        
+*     sys.peer
        
+
+
        
 
        
 The peer has been declared the system peer and lends its variables to the
 system variables.
        
+
        
 
-
        
-o     pps.peer
        
+
        
+ 
        
 
+
        
+o     pps.peer
        
+
+
        
 
        
 The peer has been declared the system peer and lends its variables to the
 system variables. However, the actual system synchronization is derived
 from a pulse-per-second (PPS) signal, either indirectly via the PPS reference
 clock driver or directly via kernel interface.
        
 
+
        
+ 
        
+
        
+
 
        
 The flash variable is not defined in the NTP specification, but
 is included as a valuable debugging aid. It displays the results of the
 packet sanity checks defined in the NTP specification TEST1 through
-TEST10. The bits for each test read in increasing sequency from
+TEST9. The bits for each test read in increasing sequency from
 the least significant bit and are defined as follows.
        
 
+
        
+ 
        
+
 
        
 The following TEST1 through TEST4 enumerate procedure
 errors. The packet timestamps may or may not be believed, but the remaining
-header data are ignored.
+header data are ignored.
        
 
 
        
-
        
+
        
+ 
        
+
        
+
+
        
 TEST1
        
 
+
        
 
        
 Duplicate packet. A copy from somewhere.
        
+
        
 
-
        
-TEST2
        
+
        
+
        
+ 
        
+
        
 
+
        
+TEST2
        
+
+
        
 
        
 Bogus packet. It is not a reply to a message previously sent. This can
 happen when the NTP daemon is restarted and before a peer notices.
        
 
-
        
-TEST3
        
+
        
+ 
        
+
        
 
+
        
+TEST3
        
+
+
        
 
        
 Unsynchronized. One or more timestamp fields are missing. This normally
 happens when the first packet from a peer is received.
        
 
-
        
-TEST4
        
+
        
+ 
        
+
        
+
+
        
+TEST4
        
 
+
        
 
        
 Either peer delay or peer dispersion is greater than one second. Ya gotta
 be kidding.
        
+
+
        
+ 
        
 
        
 
 
        
-The following TEST5 through TEST10 enumerate errors
-in the packet header. The packet is discarded without inspecting its contents.
+The following TEST5 through TEST10 ennumerate errors
+in the packet header. The packet is discarded without inspecting its contents.
        
 
 
        
-
        
-TEST5
        
+
        
+ 
        
+
        
 
+
        
+TEST5
        
+
+
        
 
        
 Cryptographic authentication fails. See the Authentication
 Options page.
        
 
-
        
-TEST6
        
+
        
+ 
        
+
        
 
+
        
+TEST6
        
+
+
        
 
        
 Peer is unsynchronized. Wind up its clock first.
        
 
-
        
-TEST7
        
+
        
+ 
        
+
        
 
+
        
+TEST7
        
+
+
        
 
        
 Peer stratum is greater than 15. The peer is probably unsynchronized.
        
 
-
        
-TEST8
        
+
        
+ 
        
+
        
 
+
        
+TEST8
        
+
+
        
 
        
 Either root delay or root dispersion is greater than one second. Too far
 from home.
        
+
        
 
-
        
-TEST9
        
+
        
+
        
+ 
        
+
        
+
+
        
+TEST9
        
 
+
        
 
        
 Peer cryptographic authentication fails. Either the key identifier or key
 is wrong or somebody trashed our packet.
        
 
-
        
-TEST10
        
+
        
+ 
        
+
        
+
+
        
+TEST10
        
 
 
        
 
        
@@ -541,7 +665,7 @@ Access is denied. See the Access Control Options
 page.
        
 
 
        
- 
        
+ 
 
        
 
 
        
@@ -551,10 +675,15 @@ page.
 Sends a read status request to the server for the given association. The
 names and values of the peer variables returned will be printed. Note that
 the status word from the header is displayed preceding the variables, both
-in hexidecimal and in pigeon English.
+in hexidecimal and in pidgeon English.
+
+
        
+ 
        
+
+
        
+readlist [ assocID ]
        
 
-
        readlist [ assocID ]
        
-
        rl [ assocID ]
        
+
        rl [ assocID ]
 
        
 Requests that the values of the variables in the internal variable list
 be returned by the server. If the association ID is omitted or is 0 the
@@ -563,11 +692,15 @@ as peer variables. If the internal variable list is empty a request is
 sent without data, which should induce the remote server to return a default
 display.
        
 
+
        
+ 
        
 
-
        readvar assocID variable_name [ = value ] [ ...
-]
        
-
        rv assocID [ variable_name [ = value ] [ ...
+
        
+readvar assocID variable_name [ = value ] [ ...
 ]
        
+
+
        rv assocID [ variable_name [ = value ] [ ...
+]
 
        
 Requests that the values of the specified variables be returned by the
 server by sending a read variables request. If the association ID is omitted
@@ -576,6 +709,9 @@ are peer variables and the values returned will be those of the corresponding
 peer. Omitting the variable list will send a request with no data which
 should induce the server to return a default display.
        
 
+
        
+ 
        
+
 
        
 writevar assocID variable_name [ = value [ ...
 ]
        
@@ -584,6 +720,9 @@ should induce the server to return a default display.
 Like the readvar request, except the specified variables are written instead
 of read.
 
+
        
+ 
        
+
 
        
 writelist [ assocID ]
        
 
@@ -592,17 +731,17 @@ Like the readlist request, except the internal list variables are written
 instead of read.
 
        
 
-
        Bugs
        
-
+
        
+Bugs
        
 The peers command is non-atomic and may occasionally result in spurious
 error messages about invalid associations occurring and terminating the
 command. The timeout time is a fixed constant, which means you wait a long
 time for timeouts since it assumes sort of a worst case. The program should
 improve the timeout estimate as it sends queries to a particular host,
-but doesn't. 
+but doesn't. 
 
        
-
-
         David L. Mills <mills@udel.edu>
-
        
-
-
+
        
+David L. Mills (mills@udel.edu)
        
+
+
+
diff --git a/html/ntptime.htm b/html/ntptime.htm
index d2cbeb2968..3cc454487d 100644
--- a/html/ntptime.htm
+++ b/html/ntptime.htm
@@ -13,7 +13,7 @@
 
        
 
        
 Synopsis
        
-ntptime [ -chlr ] [ -e est_error ] [ -f frequency ] [
+ntptime [ -chr ] [ -e est_error ] [ -f frequency ] [
 -m max_error ] [ -o offset ] [ -s status ] [ -t time_constant
 ]
 
        
@@ -61,7 +61,7 @@ Specify the leap bits as a code from 0 to 3.
 -m max_error
 
 
        
-Specify maximum possible error, in microseconds.
        
+Display help information.
 
 
        
 -o offset
        
@@ -88,6 +88,9 @@ Specify clock status. Better know what you are doing.
 Specify time constant, an integer in the range 0-4.
 
        
 
-
         David L. Mills <mills@udel.edu>
-
        
+
        
+
        
+David L. Mills (mills@udel.edu)
        
+
+
+
diff --git a/html/ntptrace.htm b/html/ntptrace.htm
index db03eb18ae..675c347a56 100644
--- a/html/ntptrace.htm
+++ b/html/ntptrace.htm
@@ -22,12 +22,11 @@ Description
        
 server gets its time from, and follows the chain of NTP servers back to
 their master time source. If given no arguments, it starts with localhost.
 Here is an example of the output from ntptrace:
-
        -% ntptrace
+
        % ntptrace
 localhost: stratum 4, offset 0.0019529, synch distance 0.144135
 server2ozo.com: stratum 2, offset 0.0124263, synch distance 0.115784
-usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid 'WWVB'
-
        
+usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid
+'WWVB'
        
 On each line, the fields are (left to right): the host name, the host stratum,
 the time offset between that host and the local host (as measured by ntptrace;
 this is why it is not always zero for "localhost"), the host synchronization
@@ -74,8 +73,10 @@ Prints verbose information about the NTP servers.
 
 
        
 Bugs
        
-This program makes no attempt to improve accuracy by doing multiple samples.
+This program makes no attempt to improve accuracy by doing multiple samples. 
+
        
+
        
+David L. Mills (mills@udel.edu)
        
 
-
         David L. Mills <mills@udel.edu>
-
        
+
+
diff --git a/html/patches.htm b/html/patches.htm
index 01843459b3..154d4b8a53 100644
--- a/html/patches.htm
+++ b/html/patches.htm
@@ -15,34 +15,34 @@ changes to the distribution be submitted in the following form.
 
 
          
 
-
        1. Please submit patches to David L.
+
        2. Please submit patches to David L.
 Mills <mills@udel.edu> in the form of either unified-diffs
 (diff -u) or context-diffs (diff -c).
          3. 
 
-
        3. Please include the output from
+
        4. Please include the output from
 config.guess in the description of your patch.  If
 config.guess does not produce any output for your machine,
 please fix that, too!
          5. 
 
-
        5. Please base the patch on the root directory of the distribution.
+
        6. Please base the patch on the root directory of the distribution.
 The preferred procedure here is to copy your patch to the root directory
 and mumble
          7. 
 
 
          patch -p <your_patch>
 
-
        7. Please avoid patching the RCS subdirectories; better yet, clean
+
        8. Please avoid patching the RCS subdirectories; better yet, clean
 them out before submitting patches.
          9. 
 
-
        9. If you have whole new files, as well as patches, wrap the files
+
        10. If you have whole new files, as well as patches, wrap the files
 and patches in a shell script. If you need to compress it, use either
-GNU gzip or the stock Unix compress utility.
          11. 
+GNU zip or the stock Unix compress utility.
 
-
        11. Don't forget the documentation that may be affected by the patch.
+
        12. Don't forget the documentation that may be affected by the patch.
 Send us patches for the ./html files as well. See the A Beginner's Guide to HTML page for a
 tutorial.
          13. 
 
-
        13. We would be glad to include your name, electric address and
+
        14. We would be glad to include your name, electric address and
 descriptive phrase in the Copyright page,
 if you wish.
          15. 
 
@@ -51,13 +51,12 @@ if you wish.
 
          Prior to ntp3-5.83 (releases up to and including ntp3.5f) a
 complete patch history back to the dark ages was kept in the
 ./patches directory, which might have been helpful to see
-if the same problem occurred in another port, etc.  Patches were saved
-in
+if the same problem occured in another port, etc.  Patches were saved in
 that directory with file name in the form patch.nnn,
 where nnn was approaching 200. All patches in that directory have
 been made; so, if yours was there, it was in the distribution.
 
-
          Since we have been getting multiple patches for some bugs, plus many
+
          Since we have been getting multple patches for some bugs, plus many
 changes are implemented locally, no two maintainers here use the same
 tools, and since we're not using any bug-tracking software or even
 source code control, there is currently no tracking of specific changes.
@@ -67,5 +66,5 @@ run a diff against them.
 
          Thanks for your contribution and happy chime.
 
 
           David L. Mills <mills@udel.edu>
-
          
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/porting.htm b/html/porting.htm
index 02005cb2f6..d541d4e1da 100644
--- a/html/porting.htm
+++ b/html/porting.htm
@@ -4,8 +4,8 @@ Porting Hints
 Porting Hints
 
          
 
-
          NOTE: The following procedures have been replaced by GNU Automake and
-Autoconf. This page is to be updated in the next release.
+
          NOTE: The following procedures have been replaced by GNU automake and
+autoconfigure. This page is to be updated in the next release.
 
 
          Porting to a new machine or operating system ordinarily requires
 updating the ./machines directory and the
@@ -74,5 +74,5 @@ should be updated, including the advice herein.
 
          Good luck.
 
 
           David L. Mills <mills@udel.edu>
-
          
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/pps.htm b/html/pps.htm
index 06810a5228..e29479e169 100644
--- a/html/pps.htm
+++ b/html/pps.htm
@@ -4,8 +4,8 @@ Pulse-per-second (PPS) Signal Interfacing
 Pulse-per-second (PPS) Signal Interfacing
 
          
 
-
          Some radio clocks and related timekeeping gear have a 
-pulse-per-second (PPS) signal that can be used to discipline the local clock
+
          Some radio clocks and related timekeeping gear have a pulse-per-
+second (PPS) signal that can be used to discipline the local clock
 oscillator to a high degree of precision, typically to the order less
 than 20 ms in time and 0.01 PPM in frequency.
 The PPS signal can be connected in either of two ways: via the data
@@ -35,7 +35,7 @@ driver without using the PPS driver.
 
 
          The tty_clk module is included in the NTP software
 distribution, while the 
+HREF=http://www.eecis.udel.edu/~mills/ntp/ntp/ppsclock.tar.Z>
 ppsclock module can be obtained via the web at that link or by
 anonymous FTP from ftp.udel.edu in the pub/ntp directory. Both
 the tty_clk and ppsclock modules are described in the
@@ -45,7 +45,7 @@ Directions for building the modules themselves are in the
 ntpd to operate with these modules is described in Building and Installing the Distribution page.
 
-
          The PPS driver operates in conjunction with another reference
+
          The PPS driver is operates in conjunction with another reference
 clock driver that produces the PPS pulse, as described in the Mitigation Rules and the prefer Keyword
 page. One of the drivers described in the /usr/include/sys/timex.h
 header file. The presence of these kernel provisions is automatically
 detected and supporting code compiled.
 
-
          Some configurations may have multiple radio clocks, each with PPS
-outputs, as well as kernel provisions for the PPS signal. In order to
+
          In some configurations may have multiple radio clocks, each with PPS
+outputs, as well as a kernel provisions for the PPS signal. In order to
 provide the highest degree of redundancy and survivability, the kernel
 PPS discipline, tty_clk module, ppsclock module and
 kernel modifications may all be in use at the same time, each backing up
@@ -75,5 +75,5 @@ the other. The sometimes complicated mitigation rules are described in
 the Mitigation Rules and the prefer Keyword page.
 
 
           David L. Mills <mills@udel.edu>
-
          
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/prefer.htm b/html/prefer.htm
index ed7c7172af..edb51520dc 100644
--- a/html/prefer.htm
+++ b/html/prefer.htm
@@ -1,338 +1,332 @@
-
-Mitigation Rules and the ``prefer'' Keyword
-
          
+
+
+   
+   
+   Mitigation Rules and the ``prefer'' Keyword
+
+
+
+
+
          
 Mitigation Rules and the prefer Keyword
          
-
          
-
-
          Introduction
          
-
-The mechanics of the NTP algorithms which select the best data sample
-from each available peer and the best subset of the peer population have
-been finely crafted to resist network jitter, faults in the network or
-peer operations, and to deliver the best possible accuracy. Most of the
-time these algorithms do a good job without requiring explicit manual
-tailoring of the configuration file. However, there are times when the
-accuracy can be improved by some careful tailoring. The following
-sections explain how to do this using explicit configuration items and
-special signals, when available, that are generated by some radio
-clocks.
-
-
          In order to provide robust backup sources, primary (stratum-1)
-servers are usually operated in a diversity configuration, in which the
-server operates with a number of remote peers in addition to one or more
-radio or modem clocks operating as local peers. In these configurations
-the suite of algorithms used in NTP to refine the data from each peer
-separately and to select and weight the data from a number of peers are
-used with the entire ensemble of remote peers and local peers. As the
-result of these algorithms, a set of survivors are identified
-which can presumably provide the most reliable and accurate time.
-Ordinarily, the individual clock offsets of the survivors are combined
-on a weighted average basis to produce an offset used to control the
-system clock.
 
-
          However, because of small but significant systematic time offsets
-between the survivors, it is in general not possible to achieve the
-lowest jitter and highest stability in these configurations. This
-happens because the selection algorithm tends to clockhop between
-survivors of substantially the same quality, but showing small
-systematic offsets between them. In addition, there are a number of
-configurations involving pulse-per-second (PPS) signals, modem backup
-services and other special cases, so that a set of mitigation rules
-becomes necessary to select a single peer from among the survivors.
-These rules are based on a set of special characteristics of the various
-peers and reference clock drivers specified in the configuration file.
-
-
          The prefer Peer
          
-
-The mitigation rules are designed to provide an intelligent selection
-between various peers of substantially the same statistical quality.
-They are designed to provide the best quality time without compromising
-the normal operation of the NTP algorithms. The mitigation scheme in its
-present form is not an integral component of the NTP Version 3
-specification RFC-1305. but is to be included in the version 4
-specification when it is published. The scheme is based on the concept
-of prefer peer, which is specified by including the
-prefer keyword with the associated server or
-peer command in the configuration file. This keyword can be
-used with any peer or server, but is most commonly used with a radio
-clock. While the scheme does not forbid it, it does not seem useful to
-designate more than one peer as preferred, since the additional
-complexities to mitigate among them do not seem justified from on-air
-experience.
-
-
          The prefer scheme works on the set of peers that have survived the
-sanity checks and intersection algorithms of the clock selection
-procedures. Ordinarily, the members of this set can be considered
-truechimers and any one of them could in principle provide
-correct time; however, due to various error contributions, not all can
-provide the most accurate and stable time. The job of the clustering
-algorithm, which is invoked at this point, is to select the best subset
-of the survivors providing the least variance in the combined ensemble
-average, compared to the variance in each member of the subset
-separately. The detailed operation of the clustering algorithm, which is
-given in the specification, is not important here, other than to point
-out it operates in rounds, where a survivor, presumably the worst of the
-lot, is discarded in each round until one of several termination
+
          
+
          
+Introduction
          
+The mechanics of the NTP algorithms which select the best data sample from
+each available peer and the best subset of the peer population have been
+finely crafted to resist network jitter, faults in the network or peer
+operations, and to deliver the best possible accuracy. Most of the time
+these algorithms do a good job without requiring explicit manual tailoring
+of the configuration file. However, there are times when the accuracy can
+be improved by some careful tailoring. The following sections explain how
+to do this using explicit configuration items and special signals, when
+available, that are generated by some radio clocks.
+
+
          In order to provide robust backup sources, primary (stratum-1) servers
+are usually operated in a diversity configuration, in which the server
+operates with a number of remote peers in addition to one or more radio
+or modem clocks operating as local peers. In these configurations the suite
+of algorithms used in NTP to refine the data from each peer separately
+and to select and weight the data from a number of peers are used with
+the entire ensemble of remote peers and local peers. As the result of these
+algorithms, a set of survivors are identified which can presumably
+provide the most reliable and accurate time. Ordinarily, the individual
+clock offsets of the survivors are combined on a weighted average basis
+to produce an offset used to control the system clock.
+
+
          However, because of small but significant systematic time offsets between
+the survivors, it is in general not possible to achieve the lowest jitter
+and highest stability in these configurations. This happens because the
+selection algorithm tends to clockhop between survivors of substantially
+the same quality, but showing small systematic offsets between them. In
+addition, there are a number of configurations involving pulse-per-second
+(PPS) signals, modem backup services and other special cases, so that a
+set of mitigation rules becomes necessary to select a single peer from
+among the survivors. These rules are based on a set of special characteristics
+of the various peers and reference clock drivers specified in the configuration
+file.
+
          
+The prefer Peer
          
+The mitigation rules are designed to provide an intelligent selection between
+various peers of substantially the same statistical quality. They is designed
+to provide the best quality time without compromising the normal operation
+of the NTP algorithms. The mitigation scheme in its present form is not
+an integral component of the NTP Version 3 specification RFC- 1305. but
+is to be included in the version 4 specification when it is published.
+The scheme is based on the concept of prefer peer, which is specified
+by including the prefer keyword with the associated server
+or peer command in the configuration file. This keyword can be
+used with any peer or server, but is most commonly used with a radio clock.
+While the scheme does not forbid it, it does not seem useful to designate
+more than one peer as preferred, since the additional complexities to mitigate
+among them do not seem justified from on-air experience.
+
+
          The prefer scheme works on the set of peers that have survived the sanity
+checks and intersection algorithms of the clock selection procedures. Ordinarily,
+the members of this set can be considered truechimers and any one
+of them could in principle provide correct time; however, due to various
+error contributions, not all can provide the most accurate and stable time.
+The job of the clustering algorithm, which is invoked at this point, is
+to select the best subset of the survivors providing the least variance
+in the combined ensemble average, compared to the variance in each member
+of the subset separately. The detailed operation of the clustering algorithm,
+which is given in the specification, is not important here, other than
+to point out it operates in rounds, where a survivor, presumably the worst
+of the lot, is discarded in each round until one of several termination
 conditions is met.
 
 
          In the prefer scheme the clustering algorithm is modified so that the
 prefer peer is never discarded; on the contrary, its potential removal
 becomes a termination condition. If the original algorithm were about to
-toss out the prefer peer, the algorithm terminates right there. The
-prefer peer can still be discarded by the sanity checks and intersection
-algorithms, of course, but it will always survive the clustering
-algorithm. If it does not survive or for some reason it fails to provide
-updates, it will eventually become unreachable and the clock selection
-will remitigate to select the next best source.
+toss out the prefer peer, the algorithm terminates right there. The prefer
+peer can still be discarded by the sanity checks and intersection algorithms,
+of course, but it will always survive the clustering algorithm. If it does
+not survive or for some reason it fails to provide updates, it will eventually
+become unreachable and the clock selection will remitigate to select the
+next best source.
 
 
          Along with this behavior, the clock selection procedures are modified
-so that the combining algorithm is not used when a prefer peer is
-present. Instead, the offset of the prefer peer is used exclusively as
-the synchronization source. In the usual case involving a radio clock
-and a flock of remote stratum-1 peers, and with the radio clock
-designated a prefer peer, the result is that the high quality radio time
-disciplines the server clock as long as the radio itself remains
-operational and with valid time, as determined from the remote peers,
-sanity checks and intersection algorithm.
-
-
          Peer Classification
          
-
-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 and local peers as a
-function of configuration declarations and reference clock driver type:
-
+so that the combining algorithm is not used when a prefer peer is present.
+Instead, the offset of the prefer peer is used exclusively as the synchronization
+source. In the usual case involving a radio clock and a flock of remote
+stratum-1 peers, and with the radio clock designated a prefer peer, the
+result is that the high quality radio time disciplines the server clock
+as long as the radio itself remains operational and with valid time, as
+determined from the remote peers, sanity checks and intersection algorithm.
+
          
+Peer Classification
          
+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 and local peers as a function of configuration
+declarations and reference clock driver type:
 
            
-
-
          1.  The prefer peer is designated using the prefer keyword
-with the server or peer commands. All other things
-being equal, this peer will be selected for synchronization over all
-other survivors of the clock selection procedures.
            2. 
-
-
          2. When a PPS signal is connected via the PPS Clock Discipline
-driver (type 22), this is called the PPS peer. This driver
-provides precision clock corrections only within one second, so is
-always operated in conjunction with another peer or reference clock
-driver, which provides the seconds numbering. The PPS peer is active
-only under conditions explained below.
            3. 
-
-
          3. When the Undisciplined Local Clock driver (type 1) is configured,
-this is called the local clock peer. 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 lockclock
-scheme, or another synchronization protocol, such as the Digital Time
-Synchronization Service (DTSS).
            4. 
-
-
          4. When a modem driver such as the Automated Computer Time Service
-driver (type 18) is configured, this is called the modem peer.
-This is used either as a backup reference source, should all other
-primary sources fail, or as the (only) primary reference source.
            5. 
-
-
          5. Where support is available, the PPS signal may be processed
-directly by the kernel, as described in the A Kernel
-Model for Precision Timekeeping page. This is called the kernel
-discipline. 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.
            6. 
-
+
          6. 
+The prefer peer is designated using the prefer keyword with the
+server or peer commands. All other things being equal,
+this peer will be selected for synchronization over all other survivors
+of the clock selection procedures.
            7. 
+
+
             
+
          7. 
+When a PPS signal is connected via the PPS Clock Discipline driver (type
+22), this is called the PPS peer. This driver provides precision
+clock corrections only within one second, so is always operated in conjunction
+with another peer or reference clock driver, which provides the seconds
+numbering. The PPS peer is active only under conditions explained below.
            8. 
+
+
             
+
          8. 
+When the Undisciplined Local Clock driver (type 1) is configured, this
+is called the local clock peer. 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 lockclock scheme, or another synchronization
+protocol, such as the Digital Time Synchronization Service (DTSS).
            9. 
+
+
             
+
          9. 
+When a modem driver such as the Automated Computer Time Service driver
+(type 18) is configured, this is called the modem peer. This is
+used either as a backup reference source, should all other primary sources
+fail, or as the (only) primary reference source.
            10. 
+
+
             
+
          10. 
+Where support is available, the PPS signal may be processed directly by
+the kernel, as described in the A Kernel Model for Precision
+Timekeeping page. This is called the kernel discipline. 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.
            11. 
 
          
-
-
          Reference clock drivers operate in the manner described in the Reference Clock Drivers 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
+Reference clock drivers operate in the manner described in the Reference
+Clock Drivers 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.
 
-
          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 the remote or
-local peers. 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 both remote or local peers together with a modem
-peer are operated in the same configuration, what can happen is that
-first the clock selection algorithm can select one or more remote/local
-peers and the clock discipline algorithm will optimize for the shorter
-update intervals. Then, the selection algorithm can select the modem
-peer, which requires a much different optimization. The intent in the
-design is to allow the modem peer to control the system clock either
-when no other source is available or, if the modem peer happens to be
-marked as prefer, then it always controls the clock, as long as it
+
          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 the remote or local peers. 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 both
+remote or local peers together with a modem peer are operated in the same
+configuration, what can happen is that first the clock selection algorithm
+can select one or more remote/local peers and the clock discipline algorithm
+will optimize for the shorter update intervals. Then, the selection algorithm
+can select the modem peer, which requires a much different optimization.
+The intent in the design is to allow the modem peer to control the system
+clock either when no other source is available or, if the modem peer happens
+to be marked as prefer, then it always controls the clock, as long as it
 passes the sanity checks and intersection algorithm. There still is room
 for suboptimal operation in this scheme, since a noise spike can still
 cause a clockhop either way. Nevertheless, the optimization function is
 slow to adapt, so that a clockhop or two does not cause much harm.
 
 
          The local clock driver is another special case. Normally, this driver
-is eligible for selection only if no other source is available. When
-selected, vernier adjustments introduced via the configuration file or
-remotely using the ntpdc program can be
-used to trim the local clock frequency and time. However, if the local
-clock driver is designated the prefer peer, this driver is always
-selected and all other sources are ignored. This behavior is intended
-for use when the kernel time is controlled by some means external to
-NTP, such as the NIST lockclock algorithm or another time
-synchronization protocol such as DTSS. In this case the only way to
-disable the local clock driver is to mark it unsynchronized using the
-leap indicator bits. In the case of modified kernels with the
-ntp_adjtime() system call, this can be done automatically if
-the external synchronization protocol uses it to discipline the kernel
+is eligible for selection only if no other source is available. When selected,
+vernier adjustments introduced via the configuration file or remotely using
+the ntpdc program can be used to trim
+the local clock frequency and time. However, if the local clock driver
+is designated the prefer peer, this driver is always selected and all other
+sources are ignored. This behavior is intended for use when the kernel
+time is controlled by some means external to NTP, such as the NIST lockclock
+algorithm or  another time synchronization protocol such as DTSS.
+In this case the only way to disable the local clock driver is to mark
+it unsynchronized using the leap indicator bits. In the case of modified
+kernels with the ntp_adjtime() system call, this can be done automatically
+if the external synchronization protocol uses it to discipline the kernel
 time.
-
-
          Mitigation Rules
          
-
+
          
+Mitigation Rules
          
 The mitigation rules apply in the intersection and clustering algorithms
-described in the NTP specification. The intersection algorithm first
-scans all peers with a persistent association and includes only those
-that satisfy specified sanity checks. In addition to the checks required
-by the specification, the mitigation rules require either the local-
-clock peer or modem peer to be included only if marked as the prefer
-peer. The intersection algorithm operates on the included population to
-select only those peers believed to represent the correct time. If one
-or more peers survive the operation, processing continues in the
-clustering algorithm. Otherwise, if there is a modem peer, it is
-declared the only survivor; otherwise, if there is a local-clock peer,
-it is declared the only survivor. Processing then continues in the
-clustering algorithm.
-
-
          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.
-
-
          The mitigation rules establish the choice of system peer,
-which determine the stratum, reference identifier and several other
-system variables which are visible to clients of the local server. In
-addition, they establish which source or combination of sources control
-the local clock.
-
+described in the NTP specification. The intersection algorithm first scans
+all peers with a persistent association and includes only those that satisfy
+specified sanity checks. In addition to the checks required by the specification,
+the mitigation rules require either the local-clock peer or modem peer
+to be included only if marked as the prefer peer. The intersection algorithm
+operates on the included population to select only those peers believed
+to represent the correct time. If one or more peers survive the operation,
+processing continues in the clustering algorithm. Otherwise, if there is
+a modem peer, it is declared the only survivor; otherwise, if there is
+a local-clock peer, it is declared the only survivor. Processing then continues
+in the clustering algorithm.
+
+
          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.
+
+
          The mitigation rules establish the choice of system peer, which
+determine the stratum, reference identifier and several other system variables
+which are visible to clients of the local server. In addition, they establish
+which source or combination of sources control the local clock.
 
            
-
-
          1. 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 disable pll 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.
            2. 
-
-
          2. 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.
            3. 
-
-
          3. 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.
            4. 
-
-
          4. 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.
            5. 
-
-
          5. 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.
            6. 
+
          6. 
+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 disable pll 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.
            7. 
+
+
          7. 
+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.
            8. 
+
+
          8. 
+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.
            9. 
+
+
          9. 
+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.
            10. 
+
+
          10. 
+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.
            11. 
 
          
 
-
          Using the Pulse-per-Second (PPS) Signal
          
+
          
+Using the Pulse-per-Second (PPS) Signal
          
 Most radio clocks are connected using a serial port operating at speeds
-of 9600 bps or higher. The accuracy using typical timecode formats,
-where the on-time epoch is indicated by a designated ASCII character,
-like carriage-return <cr>, is limited to a millisecond at
-best and a few milliseconds in typical cases. However, some radios
-produce a PPS signal which can be used to improve the accuracy with
-typical workstation servers to the order of a few tens of microseconds.
-The details of how this can be accomplished are discussed in the Pulse-per-second (PPS) Signal Interfacing page. The
-following paragraphs discuss how the PPS signal is affected by the
-mitigation rules.
-
-
          First, it should be pointed out that the PPS signal is inherently
-ambiguous, in that it provides a precise seconds epoch, but does not
-provide a way to number the seconds. In principle and most commonly,
-another source of synchronization, either the timecode from an
-associated radio clock, or even one or more remote NTP servers, is
-available to perform that function. In all cases, a specific, configured
-peer or server must be designated as associated with the PPS signal.
-This is done using the prefer keyword as described previously.
-The PPS signal can be associated in this way with any peer, but is most
-commonly used with the radio clock generating the PPS signal.
+of 9600 bps or higher. The accuracy using typical timecode formats, where
+the on-time epoch is indicated by a designated ASCII character, like carriage-return
+<cr>, is limited to a millisecond at best and a few milliseconds
+in typical cases. However, some radios produce a PPS signal which can be
+used to improve the accuracy with typical workstation servers to the order
+of a few tens of microseconds. The details of how this can be accomplished
+are discussed in the Pulse-per-second (PPS) Signal Interfacing
+page. The following paragraphs discuss how the PPS signal is affected by
+the mitigation rules.
+
+
          First, it should be pointed out that the PPS signal is inherently ambiguous,
+in that it provides a precise seconds epoch, but does not provide a way
+to number the seconds. In principle and most commonly, another source of
+synchronization, either the timecode from an associated radio clock, or
+even one or more remote NTP servers, is available to perform that function.
+In all cases, a specific, configured peer or server must be designated
+as associated with the PPS signal. This is done using the prefer
+keyword as described previously. The PPS signal can be associated in this
+way with any peer, but is most commonly used with the radio clock generating
+the PPS signal.
 
 
          The PPS signal can be used in two ways to discipline the local clock,
-one using a special PPS driver described in the PPS Clock Discipline page, the other using PPS
-signal support in the kernel, as described in the A
-Kernel Model for Precision Timekeeping page. In either case, the
-signal must be present and within nominal jitter and wander error
-tolerances. In addition, the associated prefer peer must have survived
-the sanity checks and intersection algorithms and the dispersion settled
-below 1 s. This insures that the radio clock hardware is operating
+one using a special PPS driver described in the PPS
+Clock Discipline page, the other using PPS signal support in the kernel,
+as described in the A Kernel Model for Precision Timekeeping
+page. In either case, the signal must be present and within nominal jitter
+and wander error tolerances. In addition, the associated prefer peer must
+have survived the sanity checks and intersection algorithms and the dispersion
+settled below 1 s. This insures that the radio clock hardware is operating
 correctly and that, presumably, the PPS signal is operating correctly as
 well. Second, the absolute offset of the local clock from that peer must
 be less than 128 ms, or well within the 0.5-s unambiguous range of the
-PPS signal itself. In the case of the PPS driver, the time offsets
-generated from the PPS signal are propagated via the clock filter to the
-clock selection procedures just like any other peer. Should these pass
-the sanity checks and intersection algorithms, they will show up along
-with the offsets of the prefer peer itself. Note that, unlike the prefer
-peer, the PPS peer samples are not protected from discard by the
-clustering algorithm. These complicated procedures insure that the PPS
-offsets developed in this way are the most accurate, reliable available
-for synchronization.
+PPS signal itself. In the case of the PPS driver, the time offsets generated
+from the PPS signal are propagated via the clock filter to the clock selection
+procedures just like any other peer. Should these pass the sanity checks
+and intersection algorithms, they will show up along with the offsets of
+the prefer peer itself. Note that, unlike the prefer peer, the PPS peer
+samples are not protected from discard by the clustering algorithm. These
+complicated procedures insure that the PPS offsets developed in this way
+are the most accurate, reliable available for synchronization.
 
 
          The PPS peer remains active as long as it survives the intersection
-algorithm and the prefer peer is reachable; however, like any other
-clock driver, it runs a reachability algorithm on the PPS signal itself.
-If for some reason the signal fails or displays gross errors, the PPS
-peer will either become unreachable or stray out of the survivor
-population. In this case the clock selection remitigates as described
-above.
+algorithm and the prefer peer is reachable; however, like any other clock
+driver, it runs a reachability algorithm on the PPS signal itself. If for
+some reason the signal fails or displays gross errors, the PPS peer will
+either become unreachable or stray out of the survivor population. In this
+case the clock selection remitigates as described above.
 
 
          When kernel support for the PPS signal is available, the PPS signal
 is interfaced to the kernel serial driver code via a modem control lead.
-As the PPS signal is derived from external equipment, cables, etc.,
-which sometimes fail, a good deal of error checking is done in the
-kernel to detect signal failure and excessive noise. The way in which
-the mitigation rules affect the kernel discipline is as follows.
-
-
          The autoconfigure process normally detects the presence of the kernel
-support and compiles the required interface code. In order to operate,
-the PPS signal must be present and within nominal jitter and wander
-error tolerances. In the NTP daemon, the PPS discipline is active only
-when the prefer peer is among the survivors of the clustering algorithm,
-and its absolute offset is within 128 ms, as in the PPS driver. Under
-these conditions the kernel disregards updates produced by the NTP
-daemon and uses its internal PPS source instead. The kernel maintains a
-watchdog timer for the PPS signal; if the signal has not been heard or
-is out of tolerance for more than some interval, currently two minutes,
-the kernel discipline is declared inoperable and operation continues as
-if it were not present.
+As the PPS signal is derived from external equipment, cables, etc., which
+sometimes fail, a good deal of error checking is done in the kernel to
+detect signal failure and excessive noise. The way in which the mitigation
+rules affect the kernel discipline is as follows.
+
+
          In order to operate, the kernel support must be enabled by the enable
+pll command in the configuration file and the signal must be present
+and within nominal jitter and wander error tolerances. In the NTP daemon,
+the PPS discipline is active only when the prefer peer is among the survivors
+of the clustering algorithm, and its absolute offset is within 128 ms,
+as in the PPS driver. Under these conditions the kernel disregards updates
+produced by the NTP daemon and uses its internal PPS source instead. The
+kernel maintains a watchdog timer for the PPS signal; if the signal has
+not been heard or is out of tolerance for more than some interval, currently
+two minutes, the kernel discipline is declared inoperable and operation
+continues as if it were not present. 
+
          
+
          
+David L. Mills (mills@udel.edu)
          
 
-
           David L. Mills <mills@udel.edu>
-
          
+
+
diff --git a/html/quick.htm b/html/quick.htm
index c12dd05c2a..5ce009924a 100644
--- a/html/quick.htm
+++ b/html/quick.htm
@@ -19,10 +19,81 @@ was widely copied and used for testing purpose throughout much of the
 
 
          Introduction
          
 
-
          [under construction]
+
          This page describes what to expect when the NTP daemon ntpd
+is started for the first time. The discussion presumes the programs in
+this distribution have been compiled and installed as described in the
+Building and Installing the Distribution page.
 
-
           David L. Mills <mills@udel.edu>
-
          
+
          When the daemon is started, whether for the first or subsequent
+times, a number of roundtrip samples are required to accumulate reliable
+measurements of network path delay and clock offset relative to the
+server. Normally, this takes about four minutes, after which the local
+clock is synchronized to the server. The daemon behavior at startup
+depends on whether a drift file ntp.drift exists. This file
+contains the latest estimate of local clock frequency error. When the
+daemon is started for the first time, it is created after about one hour
+of operation and updated once each hour after that. When the daemon is
+started and the file does not exist, the daemon enters a special mode
+designed to quickly adapt to the particular system clock oscillator time
+and frequency error. This takes approximately 15 minutes, after which
+the time and frequency are set to nominal values and the daemon enters
+normal mode, where the time and frequency are continuously tracked
+relative to the server.
+
+
          As a practical matter, once the local clock has been set, it very
+rarely strays more than 128 ms relative to the server, even under
+extreme cases of network path congestion and jitter. Sometimes, in
+particular when the daemon is first started, the relative clock offset
+exceeds 128 ms. In such cases the normal behavior of the daemon is to
+set the clock directly, rather than rely on gradual corrections. This
+may cause the clock to be set backwards, if the local clock time is more
+than 128 s in the future relative to the server. In some applications,
+this behavior may be unacceptable. If the -x option is included
+on the command line that starts the daemon, the clock will never be
+stepped and only slew corrections will be used.
+
+
          The issues should be carefully explored before deciding to use the
+-x option. The maximum slew rate possible is limited to 500
+parts-per-million (PPM) as a consequence of the correctness principles
+on which the NTP protocol and algorithm design are based. As a result,
+the local clock can take a long time to converge to an acceptable
+offset, about 2000 s for each second the clock is outside the acceptable
+range. During this interval the local clock will not be consistent with
+any other network clock and the system cannot be used for distributed
+applications that require correctly synchronized network time.
 
+
          There may be an occasional outlyer, where an individual measurement
+exceeds 128 ms. When the frequency of occurrence of these outlyers is
+low, the measurement is discarded and operation continues with the next
+one. However, if the outlyers persist for an interval longer than about
+15 minutes, the next value is believed and the clock stepped or slewed
+as determined by the -x option. The usual reason for this
+behavior is when a leap second has occurred, but the reference clock
+receiver has not synchronized to it. When leap second support is
+implemented in the kernel, the kernel implements it as directed by the
+NTP daemon. If this happens and the reference clock source
+resynchronizes correctly within 15 minutes, the transient misbehavior of
+the source is transparent.
+
+
          It has been observed that, as the result of extreme network
+congestion, the roundtrip delays can exceed three seconds and the
+synchronization distance, which is equal to one-half the roundtrip delay
+plus the error budget terms, can become very large. When the
+synchronization distance exceeds one second, the offset measurement is
+discarded. If this condition persists for several poll intervals, the
+server may be declared unreachable. Sometimes the large jitter results
+in  large frequency errors which result in straying outside the
+acceptable offset range and an eventual step or slew time correction. If
+following such a correction the frequency error is so large that the
+first sample is outside the acceptable range, the daemon enters the same
+state as when the ntp.drift file is not present. The intent of
+this behavior is to quickly correct the frequency and restore operation
+to the normal tracking mode. In the most extreme cases
+(time.ien.it comes to mind), there may be occasional step/slew
+corrections and subsequent frequency corrections. It helps in these
+cases to use burst mode when configuring the server.
+
+
           David L. Mills <mills@udel.edu>
+
          
 
diff --git a/html/rdebug.htm b/html/rdebug.htm
index 21eeeb452d..472b09f67e 100644
--- a/html/rdebug.htm
+++ b/html/rdebug.htm
@@ -12,7 +12,7 @@ machine elsewhere in the network. The server is compiled, installed and
 started using the command-line switches described in the  ntpd  page. The first thing to look for
 are error messages on the system log. If none occur, the daemon has
-started, opened the devices specified and is waiting for peers and radios
+started, opened the devices specified and waiting for peers and radios
 to come up.
 
 
          The next step is to be sure the RS232 messages, if used, are getting
@@ -54,8 +54,8 @@ implementation bug shows up.
 
 
          Most drivers write a message to the clockstats file as
 each timecode or surrogate is received from the radio clock. By
-convention, this is the last ASCII timecode (or ASCII gloss of a
-binary-coded one) received from the radio clock. This file is managed by the
+convention, this is the last ASCII timecode (or ASCII gloss of a binary-
+coded one) received from the radio clock. This file is managed by the
 filegen facility described in the ntpd page
 and requires specific commands in the configuration file. This forms a
 highly useful record to discover anomalies during regular operation of
@@ -64,6 +64,4 @@ directory can be run from a cron job to collect and
 summarize these data on a daily or weekly basis. The summary files have
 proven invaluable to detect infrequent misbehavior due to clock
 implementation bugs in some radios.
-
           David L. Mills <mills@udel.edu>
-
          
+
          David L. Mills (mills@udel.edu)
          
diff --git a/html/refclock.htm b/html/refclock.htm
index 723eef3704..f3462103e1 100644
--- a/html/refclock.htm
+++ b/html/refclock.htm
@@ -26,7 +26,7 @@ included in the default configuration of the NTP daemon for Unix
 ntpd. Individual clocks can be activated by configuration file
 commands, specifically the server and fudge commands
 described in the ntpd program manual
-page. The following discussion presents information on how to select
+page. The following discussion presents Information on how to select
 and configure the device drivers in a running Unix system.
 
 
          Radio and modem clocks by convention have addresses in the form
@@ -99,13 +99,10 @@ Receiver
 (MSF_ARCRON)
 
          Type 28 Shared memory driver
 (SHM)
-
          Type 29 Trimble Navigation Palisade GPS
-(GPS_PALISADE)
-
          Type 30 Motorola UT Oncore GPS
+
          Type 29 Trimble Navigation Palisade GPS (GPS_PALISADE)
+
          Type 30 Motorola UT Oncore GPS
 (GPS_ONCORE)
 
          Type 31 Rockwell Jupiter GPS (GPS_JUPITER)
-
          Type 32 Chrono-log K-series WWVB receiver (CHRONOLOG)
-
          Type 33 Dumb localtime clock (DUMBCLOCK)
 
 
          * All TrueTime receivers are now supported by one driver, type 5.
 Types
@@ -120,8 +117,9 @@ Keyword
 
          Line Disciplines and Streams Drivers
 
          Pulse-per-second (PPS) Signal Interfacing
 
          How To Write a Reference Clock Driver
-
          The Network Time Protocol (NTP) Distribution
+
          The Network Time Protocol (NTP)
+Distribution  
 
 
           David L. Mills <mills@udel.edu>
-
          
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/release.htm b/html/release.htm
index 4643e53c6b..5bf6acab2f 100644
--- a/html/release.htm
+++ b/html/release.htm
@@ -15,21 +15,21 @@ new features and refinements to the NTP Version 3 (NTPv3) algorithms.
 However, it continues the tradition of retaining backwards compatibility
 with older versions. The NTPv4 version has been under development for
 quite a while and isn't finished yet. In fact, quite a number of NTPv4
-features were implemented and tested in the later releases of NTPv3. The
-primary purpose of this release is to verify new features as they are
-implemented work correctly in the various architectures, operating
-systems and hardware complement that can't be verified here. Of
-particular interest are Windows NT, VMS and various reference clock
-drivers. As always, corrections and bugfixes are warmly received,
-especially in the form of context diffs.
+features have already been implemented in the current NTPv3. The primary
+purpose of this release is to verify the remaining new code compiles and
+runs in the various architectures, operating systems and hardware
+complement that can't be verified here. Of particular interest are
+Windows NT, VMS and various reference clock drivers. As always,
+corrections and bugfixes are warmly received, especially in the form of
+context diffs.
 
 
          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
+NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called
+xntp3-5.x.x
 
 
            
 
-
          1. Most of the extensive calculations are now done using 64-bit
+
          2. Most of the extensive calculations are now done using 64-bit
 floating-point format, rather than 64-bit fixed-point format. The
 motivation for this is to reduce size, improve speed and avoid messy
 bounds checking. Workstations of today are much faster than when the
@@ -41,7 +41,7 @@ process raw timestamps all produce fixed-point differences before
 converting to double. The differences are ordinarily quite small
 so can be expressed without loss of accuracy in double format.
            3. 
 
-
          3. The clock discipline algorithm has been redesigned to improve
+
          4. The clock discipline algorithm has been redesigned to improve
 accuracy, reduce the impact of network jitter and allow an increase in
 poll intervals to well over one day with only moderate sacrifice in
 accuracy. The NTPv4 design allows servers to increase the poll intervals
@@ -50,43 +50,40 @@ in such cases was clamped to the minimum, usually 64 s. For those
 servers with hundreds of clients, the new design can dramatically reduce
 the network load.
            5. 
 
-
          5. A burst-mode feature is available which results in good accuracy
-with intermittent connections typical of PPP and ISDN services. When
-enabled, at each poll interval the server sends multiple messages and
-processes the replies in a batch. Outlyers and lost messages due to
-initial dial-up delay, ARP cache refresh, etc., are avoided and the
-server synchronizes with its peer generally usually within 30 s. See the
-Association Management page for further
-information.
            6. 
-
-
          6. In addition to the NTPv3 authentication scheme, which uses
-private-key cryptography, a new NTPv4 autokey authentication scheme is
-available. Autokey uses public-key technology and avoids the need to
-distribute keys by separate means. The design is such that full accuracy
-is available without degradation due to processing demands of the
-public-key routines. It can be used in any of the NTP association modes,
-but is most useful in broadcast/multicast modes. See the Authentication Options page for further
-information.
            7. 
-
-
          7. NTPv4 includes two new association modes which in most
+
          8. A burst-mode feature is available which
+results in good accuracy with intermittent connections typical of PPP
+and ISDN services. When enabled, at each poll interval the server sends
+eight messages over the next 30-s interval and processes them in a
+batch. Outlyers due to initial dial-up delays, etc., are avoided and the
+server synchronizes with its peer generally within 30 s.
            9. 
+
+
          9. In addition to the NTPv3 authentication scheme, which uses
+private-key cryptography, a new NTPv4 autokey
+authentication scheme is available. Autokey uses public-key
+technology and avoids the need to distribute keys by separate means. The
+design is such that full accuracy is available without degradation due
+to processing demands of the public-key routines. It can be used in any
+of the NTP association modes, but is most useful in broadcast/multicast
+modes.
            10. 
+
+
          10. NTPv4 includes two new association modes which in most
 applications can avoid per-host configuration altogether. Both of these
 are based on multicast technology. They provide for automatic discovery
-and configuration of servers and clients. In multicast mode, a server
-sends a message at fixed intervals using specified multicast addresses,
-while clients listen on these addresses. Upon receiving the message, a
-client exchanges several messages with the server in order to calibrate
-the multicast propagation delay between the client and server. In
-manycast mode, a client sends a message and expects one or more servers
-to reply. Using engineered algorithms, the client selects an appropriate
-subset of servers from the messages received and continues in ordinary
+and configuration of servers and clients. In multicast
+mode, a server sends a message at fixed intervals using specified
+multicast addresses, while clients listen on these addresses. Upon
+receiving the message, a client exchanges several messages with the
+server in order to calibrate the multicast propagation delay between the
+client and server. In manycast mode, a client
+sends a message and expects one or more servers to reply. Using
+engineered algorithms, the client selects an appropriate subset of
+servers from the messages received and continues in ordinary
 client/server operation with them. The manycast scheme can provide
 somewhat better accuracy than the multicast scheme at the price of
-additional network overhead. See the Association
-Management page for further information.
            11. 
+additional network overhead.
 
-
          11. The reference clock driver interface is smaller, more rational
-and more accurate. Support for pulse-per-second (PPS) signals has been
+
          12. The reference clock driver interface is smaller, more rational
+and moreaccurate. 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 this interface, but some, including the
 PARSE subinterface, have yet to be overhauled. New drivers have been
@@ -96,18 +93,18 @@ signals have been updated and capabilites added to allow direct
 connection of these signals to the Sun audio port
 /dev/audio.
            13. 
 
-
          13. In all except a very few cases, all timing intervals are
+
          14. In all except a very few cases, all timing intervals are
 randomized, so that the tendency for NTPv3 to bunch messages, especially
 with a large number of configured associations, is minimized.
            15. 
 
-
          15. In NTPv3 a large number of weeds and useless code had grown over
+
          16. In NTPv3 a large number of weeds and useless code had grown over
 the years since the original NTPv1 code was implemented almost ten years
 ago. Using a powerful weedwacker, much of the shrubbery has been
 removed, with effect a substantial reduction in size of almost 40
 percent.
            17. 
 
-
          17. The entire distribution has been converted to GNU Automake,
-which should greatly ease the task of porting to new and
+
          18. The entire distribution has been converted to gnu
+automake, 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.
            19. 
 
          
@@ -115,47 +112,36 @@ bugs due to improper handling of idiosyncratic kernel functions.
 
          Nasty Surprises
          
 
 There are a few things different about this release that have changed
-since the latest NTPv3 release. Following are a few things to worry
-about:
+since the latest NTP Version 3 release. Following are a few things to
+worry about:
 
 
            
 
-
          1. As required by Defense Trade Regulations (DTR), the cryptographic
-routine supporting the Data Encryption Standard (DES) has been removed
-from the distribtution. These routines are readily available in most
-countries from RSA Laboratories. Directions for their use are in the 
          2. As required by Defense Trade Regulations (DTR), the cryptographic
+routines supporting the Data Encryption Standard (DES) and Message
+Digest 5 (MD5) have been removed from the export version of the
+distribtution. These routines are readily available in most countries
+from RSA Laboratories. Directions for their use are in the Building and Installing the Distribution page.
            3. 
 
-
          3. As the result of the above, the ./authstuff directory,
+
          4. As the result of the above, the ./authstuff directory,
 intended as a development and testing aid for porting cryptographic
 routines to exotic architectures, has been removed. Developers should
 note the NTP authentication routines use the interface defined in the
 rsaref2.0 package available from RSA laboratories.
            5. 
 
-
          5. The enable and disable commands have a few
-changes in their arguments; see the ntpd Configuration Options page for details.
            6. 
-
-
          6. The protocol state machine has been modified to avoid certain
-cryptographic vulnerabilities. Authentication is normally required for
-configuration messages, including those for host name resolution, and to
-mobilize persistent associations. While authentication can be disabled
-with a disable auth command in the configuration file, this may
-result in some surprising behavior. See the Authentication Options page for details.
-
-
          7. Additional flags have been added to the ntpd command
-line. See the ntpd - Network Time Protocol (NTP)
-daemon page for details.
            8. 
+
          8. The enable and disable commands have a few changes in their
+arguments see the ntpd Configuration
+Options page for details.
            9. 
 
-
          9. The scheme for enabling the ppsclock line
+
          10. The scheme for enabling the ppsclock line
 discipline/streams module has changed. Formerly, it was enabled by
-setting fudge flag3 for the serial port connected to the PPS
+setting fudge flag3 for the serial port connected to the PPS
 signal. Now, there is an explicit command pps used to designate
 the device name. See the Reference Clock
 Options page for details.
            11. 
 
-
          11. While in fact not a new problem, some obscure option combinations
+
          12. While in fact not a new problem, some obscure option combinations
 require the server and peer commands to follow the
 others; in particular, the enable and pps commands
 should preceed these commands.
            13. 
@@ -165,21 +151,26 @@ should preceed these commands.
 
            Caveats
            
 
 This release has been compiled and tested on several systems, including
-SunOS 4.1.3, Solaris 2.5.1, 2.6 and 7, Digital Unix 4.0 and Ultrix
-4.4, Linux, FreeBSD 2.2.5 and 3.1, and HP-UX 10.02. It has not been
-compiled here for Windows NT or VMS. We are relying on the NTP volunteer
-brigade to do that. Known problems are summarized below:
+SunOS 4.1.3, Solaris 2.5.1 and 2.6, Alpha 4.0, Ultrix 4.4, Linux,
+FreeBSD and HP-UX 10.02. It has not been compiled for Windows NT or VMS.
+We are relying on the NTP volunteer brigade to do that. Known problems
+are summarized below:
 
 
              
 
-
            1. To work properly in all cases, the enable and
+
            2. To work properly in all cases, the enable and
 pps commands, if used, should appear before the server
 and fudge commands in the configuration file.
              3. 
 
-
            3. On Digital Unix 4.0 with reference clocks configured, debugging with the
+
            4. The precision time kernel modifications now in stock Solaris 2.6
+have bugs. The kernel discipline has been disabled by default. For
+testing, the kernel can be enabled using the enable kernel
+command either in the configuration file or via ntpdc.
              5. 
+
+
            5. On Alpha 4.0 with reference clocks configured, debugging with the
 -d options doesn't work.
              6. 
 
-
            6. The autokey function requires an NTP header extensions field,
+
            7. The autokey function requires an NTP header extensions field,
 which is documented in an internet draft and implemented in this
 release. This field holds the public-key signature and certificate;
 however, the detailed format for these data have not yet been
@@ -187,7 +178,7 @@ determined. It is expected this will happen in the near future and that
 implementation of the required algorithms will quickly follow using
 available cryptographic algorithms.
              8. 
 
-
            8. The manycast function still needs some work. Ideally, the
+
            9. The manycast function still needs some work. Ideally, the
 existing I/O routines would be enhanced to include the capability to
 determine the source address on every multicast packet sent, so that the
 autokey function could reliably construct the correct cryptosum.
@@ -195,7 +186,7 @@ Meanwhile, the utility of manycast in conjunction with autokey is
 limited to clients with only a single network
 interface.
              10. 
 
-
            10. The HTML documentation has been partially updated. However, most
+
            11. The HTML documentation has been partially updated. However, most
 of the NTPv3 documentation continues to apply to NTPv4. Until the update
 happens, what you see is what you get. We are always happy to accept
 comments, corrections and bug reports. However, we are most thrilled
@@ -203,51 +194,6 @@ upon receipt of patches to fix the dang bugs.
              12. 
 
 
            
 
-
            Wet Paint Department
            
-
-Beginning with the ntp-4.0.92e release, the following changes
-have been made:
-
-
              
-
-
            1. The clock state machine has been modified to improve behavior
-under extreme conditions of network congestion together with large
-intrinsic hardware frequency errors in the hundreds of parts-per-million
-(PPM).
              2. 
-
-
            2. The interface for external clock hardware and software has been
-refined. The refinements allow the external clock driver or software to
-alert the NTP daemon when something goes wrong, in which case an orderly
-fallback, first to one or more external servers and finally to the local
-clock driver can occur, if configured. See the Undisciplined Local Clock page for further
-information. Developers should see the extensive commentary in the
-./ntpd/ntp_loopfilter.c file for details.
              3. 
-
-
            3. The kernel interface has been modified to support the new
-nanokernel precision time support, if available. This extends the
-potential accuracy and precision well below the microsecond using fast
-workstations and networks. The scheme is such that both this and
-previous distributions of NTPv3 and NTPv4 are automatically recognized
-and configured for the highest accuracy available. The current interface
-works with stock Digital Unix 4.0 (compiled with the NTP_TIME and
-MICRO_TIME kernel configuration file defines), but the precision time
-kernel modifications now in stock Solaris 2.6 and 7 have bugs. The
-kernel discipline has been disabled by default for this version. For
-testing, the kernel can be enabled using the enable kernel
-command either in the configuration file or via ntpdc.
              4. 
-
-
            4. Certain bugs which can lead to lost associations when the autokey
-list is regenerated have been fixed.
-
-
            5. A number of documentation corrections and updates have been made,
-including an extensive update to the NTP Debugging
-Techniques page. Links to some relatively obscure but important
-information, but frequently asked, have been planted in more obvious
-places, primarily to reduce the volume of mail messages here.
              6. 
-
-
            
-
 
             David L. Mills <mills@udel.edu>
-
            
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+
diff --git a/html/tickadj.htm b/html/tickadj.htm
index 509379c3bd..7d3a863e56 100644
--- a/html/tickadj.htm
+++ b/html/tickadj.htm
@@ -23,7 +23,7 @@ microseconds added to the system time during a clock interrupt, tickadj
 which sets the slew rate and resolution used by the adjtime system
 call, and dosynctodr, which indicates to the kernels on some machines
 whether they should internally adjust the system clock to keep it in line
-with the time-of-day clock or not.
+with time-of-day clock or not.
 
 
            By default, with no arguments, tickadj reads the variables
 of interest in the kernel and displays them. At the same time, it determines
@@ -68,7 +68,7 @@ specified.
 
            
 Set the kernel variable dosynctodr to zero, which disables the
 hardware time-of-year clock, a prerequisite for running the ntpd
-daemon under SunOS 4.
            
+daemon under SunOS4.
 
 
            
 -q
            
@@ -83,9 +83,10 @@ Files
 
 
             /vmunix
+
 /unix
-/dev/kmem
-
            
+
+/dev/kmem
    
 
 
    
 Bugs
    
@@ -93,8 +94,10 @@ Fiddling with kernel variables at run time as a part of ordinary operations
 is a hideous practice which is only necessary to make up for deficiencies
 in the implementation of adjtime in many kernels and/or brokenness
 of the system clock in some vendors' kernels. It would be much better if
-the kernels were fixed and the tickadj program went away.
+the kernels were fixed and the tickadj program went away. 
+
    
+
    
+David L. Mills (mills@udel.edu)
    
 
-
     David L. Mills <mills@udel.edu>
-
    
+
+
diff --git a/html/vxworks.htm b/html/vxworks.htm
index 21a8756193..b6fae80699 100644
--- a/html/vxworks.htm
+++ b/html/vxworks.htm
@@ -143,7 +143,7 @@ and configurations. 
    
 

    
 
    
 
-
    Casey Crellin
    
+
    Casey Crellin 
    
 casey@csc.co.za 
    
 
 

    
diff --git a/html/y2k.htm b/html/y2k.htm
index 7653ddeb20..3609ee32c9 100644
--- a/html/y2k.htm
+++ b/html/y2k.htm
@@ -137,5 +137,5 @@ redundancy and mutual backup should the reference sources themselves
 fail or operate incorrectly.
 
 
     David L. Mills <mills@udel.edu>
-
    
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu>
+