Listen carefully to what I say; it is very complicated.
Last update: 08-Apr-2009 2:47 UTC
This page summarizes the criteria for choosing from among a number of potential sources suitable contributors to the clock discipline process. The criteria are very meticulous, since they have to handle many different scenarios that may be optimized for peculiar circumstances, including some scenarios designed to support planetary and deep space missions.
Recall the suite of NTP data acquisition and grooming algorithms as these algorithms proceed in five phases. Phase one discovers the available sources and mobilizes an association for each candidate found. These candidates can result from explicit configuration, broadcast discover or the pool and manycast autonomous configuration schemes. Phase two grooms the selectable candidates excluding those sources showing one or more of the following errors
Phase three uses an intersection algorithm to select the truechimers from among the candidates, leaving behind the falsetickers. Phase four uses a clustering algorithm to cast off statistically insignificant outliers from the truechimers until a set of survivors not less than the number specified as the minclock option of the tos command, with default 3. Phase five uses a set of mitigation rules to select from among the survivors a system peer from which a set of system statistics can be inherited and passed along to a dependent client population. The system offset developed from these algorithms can discipline the system clock either using the ntpd clock discipline algorithm or enable the kernel to discipline the clock directly, as described on the A Kernel Model for Precision Timekeeping page. Phase five is the topic of this page.
The behavior of the various algorithms and mitigation rules involved depends on how the various synchronization sources are classified. This depends on whether the source is local or remote and if local the type of source. The following classes are defined:
The mitigation rules are designed to provide an intelligent selection of the system peer from among the survivors of different types. When used with the server or peer commands, the prefer option designates one or more survivors as preferred over all others. While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; however, if more than one source is so designated, they are used in the order specified in the configuration file; that is, if the first one becomes unselectable, the second one is used and so forth. This order of priority is also applicable to multiple modem drivers and even multiple local drivers, although that would not normally be useful.
The prefer scheme works on the set of truechimers produced by the intersection algorithms. Ordinarily, any one of them can in principle provide correct time; however, due to various latency variations, not all can provide the most accurate and stable time. The clustering algorithm, which is invoked at this point, operates in one or more rounds to cast off the statistically least significant to the current ensemble until no more than the minclock option of the tos command are left.
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 rounds-termination condition. However, the prefer peer can still be discarded by the intersection algorithm as a falseticker. To avoid this, it is usually wise to increase the mindist option of the tos command from the default .005 s to something like .05 s. s.
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.
As the selection algorithm scans the associations for selectable candidates, the modem driver, local driver and PPS driver, are segregated for later, but only if not designated a prefer peer. If so designated, a driver is included among the selectable candidate population along with the others. In addition if orphan servers are found the parent with the lowest distnace is segregated for later; the others are discarded. Here, distance is defined as the IPv4 address of the first four octets of the hashed IPv6 address. The resulting candidates, including the first prefer peer found, are processed by the intersection and clustering algorithms to yield a possibly empty set of survivors. The clustering algorithm ranks the survivors by synchronization distance and designates the survivor with the lowest distance as the potential system peer.
The mitigation algorithm proceeds in three steps in turn.
If none of the above is the case, the data are disregarded and the system variables remain as they are.
The minsane option of the tos command, the prefer option of the server and peer commands and the flag1 option of the fudge command for the PPS driver can be used in conjunction with the mitigation rules to provide many useful configurations. The minsane option specifies the minimum number of survivors required to synchronized the system clock. The prefer option designates the prefer peer. The flag1 option enables the PPS driver even if no prefer peer is available.
In the intended mode of operation, a GPS clock driver is configured along with the PPS driver and the GPS driver set as the prefer peer. If the serial timecode of the GPS driver is within 0.4 s of the PPS driver, the PPS driver disciplines the system clock. If no GPS satellites are in view, or if the antenna is disconnected, this condition is visible to the GPS driver, which then indicates this by ceasing updates to the ntpd daemon. The result is that the GPS driver becomes unreachable and in turn the PPS driver is disabled. This is the preferred behavior, as the holdover stability of the PPS signal from the GPS receiver is no better than the system clock stability.
As in the above scenario, if the minsane option is set to 0 and there is a prefer peer, it can be used in the same manner. However, this would normally disable the PPS driver if the prefer peer were to become unavailable. This behavior can be altered with the flag1 option for the PPS driver. In the default case (dim) the behavior is as above; if lit, the prefer peer is disregarded and the PPS driver is enabled no matter what the state of the prefer peer or if there is no designated prefer peer.
A scenario where the latter behavior can be most useful is for a planetary orbiter fleet, for instance in the vicinity of Mars, where contact between orbiters is only one or two times per Sol (Mars day). These orbiters have a precise timing reference based on a Ultra Stable Oscillator (USO) with accuracy in the order of a Cesium oscillator. A PPS signal is derived from the USO and can be disciplined from Earth on rare occasion or from another orbiter via NTP. In the above scenario the PPS signal disciplines the spacecraft clock between NTP updates.
In a similar scenario a PPS signal can be used to discipline the clock between updates produced by the modem driver. This would provide precise synchronization without needing the Internet at all.