Association Management

From: Harlan Stenn Date: Wed, 28 Jul 2010 02:59:12 +0000 (-0400) Subject: orphanwait documentation changes X-Git-Tag: NTP_4_2_7P41~2^2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f6629aef3fda4ba414459493b91610633db6069a;p=thirdparty%2Fntp.git orphanwait documentation changes bk: 4c4f9d00yUKrh14zMA5yR9W3C9LLLA --- diff --git a/ChangeLog b/ChangeLog index f2885606c..2b2bd22de 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +* orphanwait documentation updates. (4.2.7p40) 2010/07/12 Released by Harlan Stenn * [Bug 1395] ease ntpdate elimination with ntpd -w/--wait-sync * [Bug 1396] allow servers on ntpd command line like ntpdate diff --git a/html/assoc.html b/html/assoc.html index 6bd0d75ad..33dffa6d2 100644 --- a/html/assoc.html +++ b/html/assoc.html @@ -7,7 +7,7 @@ Association Management - +

Association Management

@@ -30,7 +30,7 @@

Association Modes

This page describes the various modes of operation provided in NTPv4. Details about the configuration commands and options are given on the Configuration Options page. Details about the cryptographic authentication schemes are given on the Authentication Options page. Details about the automatic server discovery schemes are described on the Automatic Server Discovery Schemes page. Additional information is available in the papers, reports, memoranda and briefings on the NTP Project page.

There are three types of associations in NTP: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the prempt option and are demobilized by a "better" server or by timeout, but only if the number of survivors exceeds the threshold set by the tos maxclock configuration command. Ephemeral associations are mobilized upon arrival of designated messages and demobilized by timeout.

There are three types of associations in NTP: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the preempt option and are demobilized by a "better" server or by timeout, but only if the number of survivors exceeds the threshold set by the tos maxclock configuration command. Ephemeral associations are mobilized upon arrival of designated messages and demobilized by timeout.

Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described in the Authentication Options page.

There are three principal modes of operation in NTP: client/server, symmetric active/passive and broadcast/multicast. There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and pool described on the Automatic Server Discovery Schemes page. In addition, the orphan mode and burst options described on this page can be used in appropriate cases.

Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the Configuration Options page. See that page for applicability and defaults.

@@ -62,7 +62,8 @@

A common configuration for private networks includes one or more core servers operating at the lowest stratum. Good practice is to configure each of these servers as backup for the others using symmetric or broadcast modes. As long as at least one core server can reach a UTC source, the entire subnet can synchronize to it.

If no UTC sources are available to any core server, one of them can provide a simulated UTC source for all other hosts in the subnet. However, only one core server can simulate the UTC source and all direct dependents, called orphan children, must select the same one, called the orphan parent.

A host is enabled for orphan mode using the tos orphan stratum command, where stratum is some stratum less than 16 and greater than any anticipated stratum that might occur with configured Internet time servers. However, sufficient headroom should remain so every subnet host dependent on the orphan children has stratum less than 16. Where no associations for other servers or reference clocks are configured, the orphan stratum can be set to 1. These are the same considerations that guide the local clock driver stratum selection.

A orphan parent with no sources shows reference ID LOOP if +

In order to avoid premature enabling orphan mode, a holdoff delay occurs when the daemon is first started and when all sources have been lost after that. The delay is intended to allow time for other sources to become reachable and selected. Only when the delay has expired with no sources will orphan mode be enabled. By default the delay is 600 s (five minutes), but this can be changed using the tos orphanwait delay command.

A orphan parent with no sources shows reference ID LOOP if operating at stratum 1 and 127.0.0.1 (Unix loopback address) otherwise. While ordinary NTP clients use a selection metric based on delay and dispersion, orphan children use a metric computed from the IP diff --git a/html/miscopt.html b/html/miscopt.html index 6cfd0ca60..9dc050158 100644 --- a/html/miscopt.html +++ b/html/miscopt.html @@ -6,7 +6,7 @@ Miscellaneous Options - +

Miscellaneous Options

@@ -125,8 +125,8 @@ command is 900 s. If set to zero, popcorn spikes will not be suppressed. -

tos [ beacon beacon | ceiling ceiling | cohort {0 | 1} | floor floor | maxclock maxclock | maxdist maxdist | minclock minclock | mindist mindist | minsane minsane | orphan stratum ]

This command alters certain system variables used by the the clock selection and clustering algorithms. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in dynamic server discovery schemes. The options are as follows:

tos [ beacon beacon | ceiling ceiling | cohort {0 | 1} | floor floor | maxclock maxclock | maxdist maxdist | minclock minclock | mindist mindist | minsane minsane | orphan stratum | orphanwait delay ]

beacon beacon: The manycast server sends packets at intervals of 64 s if less than maxclock servers are available. Otherwise, it sends packets at the beacon interval in seconds. The default is 3600 s. See the Automatic Server Discovery page for further details.; Specify the number of servers used by the selection algorithm as the minimum to set the system clock. The default is 1 for legacy purposes; however, for critical applications the value should be somewhat higher but less than minclock.
orphan stratum: Specify the orphan stratum with default 16. If less than 16 this is the stratum assumed by the root servers. See the Association Management page for further details.

orphanwait delay

Specify the delay in seconds from the time all sources are lost until orphan mode is enabled with default 500 s (five minutes). This allows time for one or more sources to be found without enabling orphan mode and later disabline it.

+ +

trap host_address [port port_number] [interface interfSace_address]

This command configures a trap receiver at the given host address and port number for sending messages with the specified local interface address. If the port number is unspecified, a value of 18447 is used. If the interface address is not specified, the message is sent with a source address of the local interface the message is sent through. Note that on a multihomed host the interface used may vary from time to time with routing changes.

The trap receiver will generally log event messages and other information from the server in a log file. While such monitor programs may also request their own trap dynamically, configuring a trap receiver will ensure that no messages are lost when the server is started.