diff options
Diffstat (limited to 'contrib/ntp/html/manyopt.html')
| -rw-r--r-- | contrib/ntp/html/manyopt.html | 138 |
1 files changed, 76 insertions, 62 deletions
diff --git a/contrib/ntp/html/manyopt.html b/contrib/ntp/html/manyopt.html index d2003d3..83869ca 100644 --- a/contrib/ntp/html/manyopt.html +++ b/contrib/ntp/html/manyopt.html @@ -2,68 +2,82 @@ <html> - <head> - <meta name="generator" content="HTML Tidy, see www.w3.org"> - <title>Automatic NTP Configuration Options</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> + <head> + <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> + <meta name="generator" content="HTML Tidy, see www.w3.org"> + <title>Automatic NTP Configuration Options</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>Automatic NTP Configuration Options</h3> - <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a> - <p>Make sure who your friends are.</p> - <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="99">03:13 AM</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Monday, October 13, 2003</csobj></p> - <br clear="left"> - <h4>Related Links</h4> - <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script> - <h4>Table of Contents</h4> - <ul> - <li class="inline"><a href="#many">Manycasting</a> - <li class="inline"><a href="#auto">Manycast Interactions with Autokey</a> - <li class="inline"><a href="#opt">Manycast Options</a> - </ul> - <hr> - <h4 id="many">Manycasting</h4> - <p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes client associations with some number of the "best" of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail.</p> - <p>Note that the manycasting paradigm does not coincide with the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p> - <p>Manycasting can be used with either symmetric key or public key cryptography. The public key infrastructure (PKI) offers the best protection against compromised keys and is generally considered stronger, at least with relatively large key sizes. It is implemented using the Autokey protocol and the OpenSSL cryptographic library available from <a href="http://www.openssl.org">http://www.openssl.org</a>. The library can also be used with other NTPv4 modes as well and is highly recommended, especially for broadcast modes.</p> - <p>A persistent manycast client association is configured using the <tt>manycastclient</tt> command, which is similar to the <tt>server</tt> command but with a multicast (IPv4 class D or IPv6 prefix <tt>FF</tt>) group address. The IANA has designated IPv4 address 224.1.1.1 and IPv6 address FF05::101 (site local) for NTP. When more servers are needed, it broadcasts manycast client messages to this address at the minimum feasible rate and minimum feasible time-to-live (TTL) hops, depending on how many servers have already been found. There can be as many manycast client associations as different group address, each one serving as a template for a future ephemeral unicast client/server association.</p> - <p>Manycast servers configured with the <tt>manycastserver</tt> command listen on the specified group address for manycast client messages. Note the distinction between manycast client, which actively broadcasts messages, and manycast server, which passively responds to them. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies to the manycast client message with an ordinary unicast server message.</p> - <p>The manycast client receiving this message mobilizes an ephemeral client/server association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. Authentication is explicitly required and either symmetric key or public key (Autokey) can be used. Then, the client polls the server at its unicast address in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client runs the NTP intersection and clustering algorithms, which act to discard all but the "best" associations according to stratum and synchronization distance. The surviving associations then continue in ordinary client/server mode.</p> - <p>The manycast client polling strategy is designed to reduce as much as possible the volume of manycast client messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The strategy is determined by the <tt>manycastclient</tt>, <tt>tos</tt> and <tt>ttl</tt> configuration commands. The manycast poll interval is normally eight times the system poll interval, which starts out at the <tt>minpoll</tt> value specified in the <tt>manycastclient</tt>, command and, under normal circumstances, increments to the <tt>maxpolll</tt> value specified in this command. Initially, the TTL is set at the minimum hops specified by the <tt>ttl</tt> command. At each retransmission the TTL is increased until reaching the maximum hops specified by this command or a sufficient number client associations have been found. Further retransmissions use the same TTL.</p> - <p>The quality and reliability of the suite of associations discovered by the manycast client is determined by the NTP mitigation algorithms and the <tt>minclock</tt> and <tt>minsane</tt> values specified in the <tt>tos</tt> configuration command. At least <tt>minsane</tt> candidate servers must be available and the mitigation algorithms produce at least <tt>minclock</tt> survivors in order to synchronize the clock. Byzantine agreement principles require at least four candidates in order to correctly discard a single falseticker. For legacy purposes, <tt>minsane</tt> defaults to 1 and <tt>minclock</tt> defaults to 3. For manycast service <tt>minsane</tt> should be explicitly set to 4. assuming at least that number of servers are available.</p> - <p>If at least <tt>minclock</tt> servers are found, the manycast poll interval is immediately set to eight times <tt>maxpoll</tt>. If less than <tt>minclock</tt> servers are found when the TTL has reached the maximum hops, the manycast poll interval is doubled. For each transmission after that, the poll interval is doubled again until reaching the maximum of eight times <tt>maxpoll</tt>. Further transmissions use the same poll interval and TTL values. Note that while all this is going on, each client/server association found is operating normally it the system poll interval.</p> - <p>Administratively scoped multicast boundaries are normally specified by the network router configuration and, in the case of IPv6, the link/site scope prefix. By default, the increment for TTL hops is 32 starting from 31; however, the <tt>ttl</tt> configuration command can be used to modify the values to match the scope rules.</p> - <p>It is often useful to narrow the range of acceptable servers which can be found by manycast client associations. Because manycast servers respond only when the client stratum is equal to or greater than the server stratum, primary (stratum 1) servers fill find only primary servers in TTL range, which is probably the most common objective. However, unless configured otherwise, all manycast clients in TTL range will eventually find all primary servers in TTL range, which is probably not the most common objective in large networks. The <tt>tos</tt> command can be used to modify this behavior. Servers with stratum below <tt>floor</tt> or above <tt>ceiling</tt> specified in the <tt>tos</tt> command are strongly discouraged during the selection process; however, these servers may be temporally accepted if the number of servers within TTL range is less than <tt>minclock</tt>.</p> - <p>The above actions occur for each manycast client message, which repeats at the designated poll interval. However, once the ephemeral client association is mobilized, subsequent manycast server replies are discarded, since that would result in a duplicate association. If during a poll interval the number of client associations falls below <tt>minclock</tt>, all manycast client prototype associations are reset to the initial poll interval and TTL hops and operation resumes from the beginning. It is important to avoid frequent manycast client messages, since each one requires all manycast servers in TTL range to respond. The result could well be an implosion, either minor or major, depending on the number of servers in range. The recommended value for <tt>maxpoll</tt> is 12 (4,096 s).</p> - <p>It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance. For example, consider an NTP subnet of two primary servers and a hundred or more dependent clients. With two exceptions, all servers and clients have identical configuration files including both <tt>multicastclient</tt> and <tt>multicastserver</tt> commands using, for instance, multicast group address 239.1.1.1. The only exception is that each primary server configuration file must include commands for the primary reference source such as a GPS receiver.</p> - <p>The remaining configuration files for all secondary servers and clients have the same contents, except for the <tt>tos</tt> command, which is specific for each stratum level. For stratum 1 and stratum 2 servers, that command is not necessary. For stratum 3 and above servers the <tt>floor</tt> value is set to the intended stratum number. Thus, all stratum 3 configuration files are identical, all stratum 4 files are identical and so forth.</p> - <p>Once operations have stabilized in this scenario, the primary servers will find the primary reference source and each other, since they both operate at the same stratum (1), but not with any secondary server or client, since these operate at a higher stratum. The secondary servers will find the servers at the same stratum level. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.</p> - <p>Some administrators prefer to avoid running <tt>ntpd</tt> continuously and run either <tt>ntpdate</tt> or <tt>ntpd -q</tt> as a cron job. In either case the servers must be configured in advance and the program fails if none are available when the cron job runs. A really slick application of manycast is with <tt>ntpd -q</tt>. The program wakes up, scans the local landscape looking for the usual suspects, selects the best from among the rascals, sets the clock and then departs. Servers do not have to be configured in advance and all clients throughout the network can have the same configuration file.</p> - <h4 id="auto">Manycast Interactions with Autokey</h4> - <p>Each time a manycast client sends a client mode packet to a multicast group address, all manycast servers in scope generate a reply including the host name and status word. The manycast clients then run the Autokey protocol, which collects and verifies all certificates involved. Following the burst interval all but three survivors are cast off, but the certificates remain in the local cache. It often happens that several complete signing trails from the client to the primary servers are collected in this way.</p> - <p>About once an hour or less often if the poll interval exceeds this, the client regenerates the Autokey key list. This is in general transparent in client/server mode. However, about once per day the server private value used to generate cookies is refreshed along with all manycast client associations. In this case all cryptographic values including certificates is refreshed. If a new certificate has been generated since the last refresh epoch, it will automatically revoke all prior certificates that happen to be in the certificate cache. At the same time, the manycast scheme starts all over from the beginning and the expanding ring shrinks to the minimum and increments from there while collecting all servers in scope.</p> - <h4 id="opt">Manycast Options</h4> - <dl> - <dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} |floor <i>floor</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt> - <dd>This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows: - <dl> - <dt><tt>ceiling <i>ceiling</i></tt> - <dd>Peers with strata above <i>ceiling</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 15, but can be changed to any number from 1 to 15. - <dt><tt>cohort { 0 | 1 }</tt> - <dd>This is a binary flag which enables (0) or disables (1) manycast server replies to manycast clients with the same stratum level. This is useful to reduce implosions where large numbers of clients with the same stratum level are present. The default is to enable these replies. - <dt><tt>floor <i>floor</i></tt> - <dd>Peers with strata below <i>floor</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15. - <dt><tt>minclock <i>minclock</i></tt> - <dd>The clustering algorithm repeatedly casts out outlyer associations until no more than <i>minclock</i> associations remain. This value defaults to 3, but can be changed to any number from 1 to the number of configured sources. - <dt><tt>minsane <i>minsane</i></tt> - <dd>This is the minimum number of candidates available to the clock selection algorithm in order to produce one or more truechimers for the clustering algorithm. If fewer than this number are available, the clock is undisciplined and allowed to run free. The default is 1 for legacy purposes. However, according to principles of Byzantine agreement, <i>minsane</i> should be at least 4 in order to detect and discard a single falseticker. - </dl> - <dt><tt>ttl <i>hop</i> ...</tt> - <dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31. - </dl> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> + <body> + <h3>Automatic NTP Configuration Options</h3> + <img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a> + <p>Make sure who your friends are.</p> + <p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:55</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="275">Tuesday, October 11, 2005</csobj></p> + <br clear="left"> + <h4>Related Links</h4> + <script type="text/javascript" language="javascript" src="scripts/links9.txt"></script> + <h4>Table of Contents</h4> + <ul> + <li class="inline"><a href="#bcst">Broadcasting</a> + <li class="inline"><a href="#mcst">Manycasting</a> + <li class="inline"><a href="#orphan">Orphan Mode</a> + <li class="inline"><a href="#opt">Server Discovery Options</a> + </ul> + <hr> + <h4 id="bcst">Broadcasting</h4> + <p>Broadcasting is the simplest way to provide automatic server discovery. It uses the multi-destination paradigm, where the subnet spanning tree is constructed automatically, either by the switches in an Ethernet LAN or the DVMRP or PIM protocols when spanning multiple networks.</p> + <p>A broadcast or multicast server is mobilized by the broadcast configuration command. The addresses can be either from the IPv4 broadcast/mulitcast address family or the IPv6 address family. Multiple broadcast server associations can be specified for a single host.</p> + <p>A host is enabled for broadcast reception using the <tt>broadcastclient</tt> configuration command, with or without the <tt>novolley</tt> option. Upon receiving the first message from a broadcast server, the client mobilizes an ephemeral client association and exchanges a volley of client/server messages in order to quickly authenticate the source, set the clock and measure the propagation delay, then reverts to listen-only mode. A multicast client is mobilized in the same way using the <tt>multicastclient</tt> configuration command and specified multicast group address.</p> + <p>Broadcasting can be used with either symmetric key or public key cryptography. Public key cryptography offers the best protection against compromised keys and is generally considered stronger. By default, either of these two means is required, but this can be overridden by the <tt>disable auth</tt> command.</p> + <p>In both broadcast and multicast client operations the client association is demobilized in case of error or timeout due to loss of server or connectivity. </p> + <h4 id="mcst">Manycasting</h4> + <p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each client mobilizes associations with a given number of the "best" nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail.</p> + <p>Note that the manycast paradigm does not coincide with the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p> + <p>Manycasting can be used with either symmetric key or public key cryptography. Public key cryptography offers the best protection against compromised keys and is generally considered stronger. By default, either of these two means is required, but this can be overridden by the <tt>disable auth</tt> command.</p> + <p>A manycast client association is configured using the <tt>manycastclient</tt> configuration command, which is similar to the <tt>server</tt> configuration command, but with a broadcast or multicast address. Depending on address family. The manycast client sends ordinary client mode messages, but with a broadcast address rather than a unicast address. It sends only if less than a given threshold of servers have been found and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. There can be as many manycast client associations as different broadcast addresses, each one serving as a template for a future unicast client/server association.</p> + <p>Manycast servers configured with the <tt>manycastserver</tt> command listen on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies to the manycast client message with an ordinary unicast server message.</p> + <p>The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum. The client runs the NTP mitigation algorithms, which act to demobilize all but a threshold number of associations according to stratum and synchronization distance. The surviving associations then continue in ordinary client/server mode.</p> + <p>If for some reason the number of available servers falls below the threshold, the manycast client resumes sending broadcast messages. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The strategy is determined by the <tt>tos</tt> and <tt>ttl</tt> configuration commands described below.</p> + <p>It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.</p> + <p>For example, consider an NTP subnet of two primary servers and several secondary servers and a number of dependent clients. With twoAll servers and clients have identical configuration files including both <tt>multicastclient</tt> and <tt>multicastserver</tt> commands using, for instance, multicast group address 239.1.1.1. Each primary server configuration file must include commands for the primary reference source such as a GPS receiver.</p> + <p>The remaining configuration files for all secondary servers and clients have the same contents, except for the <tt>tos</tt> command, which is specific for each stratum level. For stratum 1 and stratum 2 servers, that command is not necessary. For stratum 3 and above servers the <tt>tos floor</tt> value is set to the intended stratum number. Thus, all stratum 3 configuration files use <tt>tos floor 3</tt>, all stratum 4 files use <tt>tos floor 4</tt> and so forth.</p> + <p>Once operations have stabilized, the primary servers will find the primary reference source and each other, since they both operate at the same stratum (1), but not with any secondary server or client, since these operate at a higher stratum. The secondary servers will find the servers at the same stratum level. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.</p> + <h4 id="orphan">Orphan Mode</h4> + <p>Sometimes it is necessary to operate an NTP subnet in isolation, because a local reference clock is unavailable or connectivity to the Internet is not provided. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC timescale. Previously, this function was provided by the local clock driver, which could be configured for a server that could be reached, directly or indirectly from all other servers and clients in the subnet.</p> + <p>There are many disadvantages using the local clock driver: multiple source redundancy is not possible and the subnet is vulnerable to single-point failures. Orphan mode is intended to replace the need for the local clock driver. It operates in subnet configurations in all modes, including broadcast, and multiple servers and clients and handles seamless switching as primary sources fail and recover.</p> + <p>A server or client is enabled for orphan mode using the <tt>tos orphan <i>stratum</i></tt> command, where <tt><i>stratum</i></tt> is some stratum less than 16 and greater than any anticipated stratum that might occur with ordinary Internet servers. This is the same consideration that guides the local clock driver stratum.</p> + <p>As long as the stratum of any orphan is less than the orphan stratum, the servers and clients operate in the normal way. However, if the stratum equals or exceeds this stratum, the server or client is considered an orphan. If under these conditions a host has no sources of the same or lower stratum, it is designated an orphan parent; otherwise, it is considered an orphan child. Orphan parents show offset zero, root delay zero and reference ID 127.0.0.1, which of course is the Unix loopback address. Orphan children show the mitigated offset of their servers, root delay randomized over a moderate range and reference ID of their system peer. An important distinction is that the entire subnet operates at the same orphan stratum and that the order of preference is the root delay, not the stratum and root distance as usual.</p> + <p>For the most flexible and reliable operation, all servers and clients in the subnet should include the <tt>orphan</tt> command in the configuration file and with the same orphan stratum. This provides mutual redundancy and diversity for all NTP modes of operation, including broadcast.</p> + <p>For example, consider the case where several campus secondary (stratum 2) servers are configured for public Internet primary servers and with each other using symmetric modes. These servers provide synchronization with a number of department servers using broadcast mode, where each of these servers is configured as both a broadcast server and broadcast client. Individual workstations on the department LAN are configured as broadcast clients only. All servers (not necessarily the clients) have the <tt>orphan 5</tt> command, for example.</p> + <p>In normal operation all servers and clients operate below stratum 5, so operate with the subnet configuration determined by stratum and root distance. If all sources are lost at any stratum level, the server or client continues operation as orphan parent. However, if sources at the orphan stratum are found, the host synchronizes to the source with lowest root delay. Since orphan root delay is determined randomly at startup, loops are avoided, even in broadcast modes where multiple servers are available.</p> + <h4 id="opt">Server Discovery Options</h4> + <dl> + <dt><tt>tos [ ceiling <i>ceiling</i> | cohort {0 | 1} | floor <i>floor</i> | orphan <i>orphan</i> | maxdistance <i>maxdistance</i> | minclock <i>minclock</i> | minsane <i>minsane</i> ]</tt> + <dd>This command affects the clock selection and clustering algorithms. It can be used to select the quality and quantity of peers used to synchronize the system clock and is most useful in manycast mode. The variables operate as follows: + <dl> <dt><tt>beacon <i>beacon</i></tt> + <dd>The manycast server sends packets at intervals of 64 s if less than <i><tt>maxclock</tt></i> servers are available. Otherwise, it sends packets at the <i><tt>beacon</tt></i> interval in seconds. The default is 3600 s.<dt><tt>ceiling <i>ceiling</i></tt> + <dd>Servers with stratum at or above <i>ceiling</i> will be discarded if there are at least <i><tt>minclock</tt></i> peers remaining. This value defaults to 15, but can be changed to any number from 1 to 15. + <dt><tt>cohort { 0 | 1 }</tt> + <dd>This is a binary flag which enables (0) or disables (1) manycast server replies to manycast clients with the same stratum level. This is useful to reduce implosions where large numbers of clients with the same stratum level are present. The default is to enable these replies. + <dt><tt>floor <i>floor</i></tt> + <dd>Peers with strata below <i>floor</i> will be discarded if there are at least <i>minclock</i> peers remaining. This value defaults to 1, but can be changed to any number from 1 to 15. + <dt><tt>orphan <i>stratum</i></tt> + <dd>If <tt><i>stratum</i></tt> is set at some value less than 16 a special orphan mode is enterred when no outside source of synchronization is available. To use orphan mode a number of participants are identically configured both as broadcast client and as broadcast server. One or more participants are configured to use an outside source, either a reference clock or another Internet server. When the source or sources fail, the system stratum is set at <tt><i>stratum</i></tt> and a leader is elected to serve as the reference source. When an outside source of synchronization is again available, the orphan mode is disabled.<dt><tt>mindist <i>mindistance</i></tt> + <dd>The slection algorithm normally pads each intersection a minimum of one millisecond to avoid needless classification. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the padding. This command can be used for that purpose. As a general rule, set the mindistance to the maximum expected offset plus the maxiumum expected jitter, in seconds. + <dt><tt>maxdist <i>maxdistance</i></tt> + <dd>The selection algorithm accumulates a number of packets before setting the clock in order to use the best data available. The number is determined by the synchronization distance for each association and a limit called the distance threshold. The synchronization distance starts at 16, then drops by a factor of about two as each packet is received. The default distance threshold is 1.0, which usually results in four packets. Setting maxdistance to some value between 1 and 16 can be used to change the number of packets required. For instance, setting it to 16 will set the clock on the first packet received; howver, setting it to this value essentially disables the mitigation and grooming algorithms. + <dt><tt>minclock <i>minclock</i></tt> + <dd>The clustering algorithm repeatedly casts out outlyer associations until no more than <i>minclock</i> associations remain. This value defaults to 3, but can be changed to any number from 1 to the number of configured sources. + <dt><tt>minsane <i>minsane</i></tt> + <dd>This is the minimum number of candidates available to the clock selection algorithm in order to produce one or more truechimers for the clustering algorithm. If fewer than this number are available, the clock is undisciplined and allowed to run free. The default is 1 for legacy purposes. However, according to principles of Byzantine agreement, <i>minsane</i> should be at least 4 in order to detect and discard a single falseticker. + </dl> + + <dt><tt>ttl <i>hop</i> ...</tt> + <dd>This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31. + </dl> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> </html>
\ No newline at end of file |
