Mitigation Rules and the prefer Keyword

The clock cluster algorithm processes the truechimers produced by the clock select algorithm to produce a list of survivors. These survivors are used by the mitigation algorithms to discipline the system clock. The cluster algorithm operates in a series of rounds, where at each round the truechimer furthest from the offset centroid is pruned from the population. The rounds are continued until a specified termination condition is met. This page discusses the algorithm in detail.

First, the truechimer associations are saved on a list with each candidate entry identified with index i (i = 1, ..., n), where n is the number of candidates. Let q(i), be the offset and l(i) be the root distance of the ith entry. Recall that the root distance is equal to the root dispersion plus half the root delay. For the ith candidate on the list, a statistic called the select jitter relative to the ith candidate is calculated as follows. Let

First, the truechimer associations are saved on an unordered list with each candidate entry identified with index i (i = 1, ..., n), where n is the number of candidates. Let q(i), be the offset and l(i) be the root distance of the ith entry. Recall that the root distance is equal to the root dispersion plus half the root delay. For the ith candidate on the list, a statistic called the select jitter relative to the ith candidate is calculated as follows. Let

where q(i) is the peer offset of the ith entry and q(j) is the peer offset of the jth entry, both produced by the clock filter algorithm. The metric used by the cluster algorithm is the select jitter j_S(i) computed as the root mean square (RMS) of the d_i(j) as j ranges from 1 to n. For the purpose of notation in the example to follow, let j_R(i) be the peer jitter computed by the clock filter algorithm for the ith candidate.

The object at each round is to prune the entry with the largest metric until the termination condition is met. Note that the select jitter must be recomputed at each round, but the peer jitter does not change. At each round the remaining entries on the list represent the survivors of that round. If the candidate to be pruned is preemptable and the number of candidates is greater than the maxclock threshold, the association is demobilized. This is useful in the schemes described on the Automatic Server Discovery Schemes page. The maxclock threshold default is 10, but it can be changed using the maxclock option of the tos command. Further pruning is subject to the following termination conditions, but no associations will be automatically demobilized.

The termination condition has two parts. First, if the number of candidates is not greater than the minclock threshold set by the minclock option of the tos command, the pruning process terminates. The minclock default is 3, but can be changed to fit special conditions, as described on the Mitigation Rules and the prefer Keyword page.

The termination condition has two parts. First, if the number of survivors is not greater than the minclock threshold set by the minclock option of the tos command, the pruning process terminates. The minclock default is 3, but can be changed to fit special conditions, as described on the Mitigation Rules and the prefer Keyword page.

The second termination condition is more intricate. Figure 1 shows a round where a candidate of (a) is pruned to yield the candidates of (b). Let j_max be the maximum select jitter and j_min be the minimum peer jitter over all candidates on the list. In (a), candidate 1 has the highest select jitter, so j_max = j_S(1). Candidate 4 has the lowest peer jitter, so j_min = j_R(4). Since j_max > j_min, select jitter dominates peer jitter,the algorithm prunes candidate 1. In (b), j_max = j_S(3) and j_min= j_R(4). Since j_max < j_min, pruning additional candidates does not reduce select jitter, the algorithm terminates with candidates 2, 3 and 4 as survivors.

The survivor list is passed on to the the mitigation algorithms, which combine the survivors, select a system peer, and compute the system statistics passed on to dependent clients. Note the use of root distance l as a weight factor at each round in the clock cluster algorithm. This is to favor the survivors with the lowest root distance and thus the smallest maximum error.

Clock Filter Algorithm

The clock filter algorithm processes the offset and delay samples produced by the on-wire protocol for each peer process separately. It uses a sliding window of eight samples and picks out the sample with the least expected error. This page describes the algorithm design principles along with an example of typical performance.

Figure 1 shows a wedge scattergram plotting sample points of offset versus delay collected over a 24-hr period. As the delay increases, the offset variation increases, so the best samples are those at the lowest delay. There are two limb lines at slope ±0.5, representing the limits of sample variation. This turns out to be useful, as described on the Huff-n'-Puff Filter page. However, it is apparent that, if a way could be found to find the sample of least delay, it would have the least offset variation and would be the best candidate to synchronize the system clock.

Figure 1 shows a wedge scattergram plotting sample points of offset versus delay collected over a 24-hr period. As the delay increases, the offset variation increases, so the best samples are those at the lowest delay. There are two limb lines at slope ±0.5, representing the limits of sample variation. This turns out to be useful, as described on the Huff-n'-Puff Filter page. However, it is apparent that, if a way could be found to find the sample of lowest delay, it would have the least offset variation and would be the best candidate to synchronize the system clock.

In the clock filter algorithm the offset and delay samples from the on-wire protocol are inserted as the youngest stage of an eight-stage shift register, thus discarding the oldest stage. Each time an NTP packet is received from a source, a dispersion sample is initialized as the sum of the precisions of the server and client. Precision is defined by the latency to read the system clock and varies from 1000 ns to 100 ns in modern machines. The dispersion sample is inserted in the shift register along with the offset and delay samples. Subsequently, the dispersion sample in each stage is increased at a fixed rate of 15 ms/s, representing the worst case error due to skew between the server and client clock frequencies.

In each peer process the clock filter algorithm selects the stage with the smallest delay, which generally represents the most accurate data, and it and the associated offset sample become the peer variables of the same name. The peer jitter statistic is computed as the root mean square (RMS) differences between the offset samples and the offset of the selected stage.

The peer dispersion statistic is determined as a weighted sum of the dispersion samples in the shift register. Initially, the dispersion of all shift register stages is set to a large number "infinity" equal to 16 s. The weight factor for each stage, starting from the youngest numbered i = 1, is 2^-i, which means the peer dispersion is approximately 16. As samples enter the register, the peer dispersion drops from 16 to 8, 4, 2... and so forth. In practice, the dispersion falls below the select threshold of 1.5 s in about four updates. This gives some time for meaningful comparison between sources, if more than one are available. The dispersion continues to grow at the same rate as the sample dispersion. As explained elsewhere, when a source becomes unreachable, the poll process inserts a dummy infinity sample in the shift register for each poll sent. After eight polls, the register returns to its original state.

As samples enter the register, the peer dispersion drops from 16 to 8, 4, 2... and so forth. In practice, the dispersion falls below the select threshold of 1.5 s in about four updates. This gives some time for meaningful comparison between sources, if more than one are available. The dispersion continues to grow at the same rate as the sample dispersion. As explained elsewhere, when a source becomes unreachable, the poll process inserts a dummy infinity sample in the shift register for each poll sent. After eight polls, the register returns to its original state.

Figure 2. Raw (left) and Filtered (right) Offsets

Figure 2 shows the performance of the algorithm using offsets for a typical Internet path over a 24-hr period. The graph on the left shows the raw offsets produced by the on-wired protocol, while the figure on the right shows the filtered offsets produced by the algorithm. If we consider the series formed as the absolute value of the offset samples, the mean error is defined as the mean of this series. Thus, the mean error of the raw samples is 0.724 ms, while the mean error of the filtered series is 0.192 ms. Radio engineers would interpret this as a processing gain of 11.5 dB.

The reader may notice the somewhat boxy characteristic of the filtered offsets. Once a sample is selected, it remains selected until a newer sample with lower delay is available. This commonly occurs when an older selected sample is discarded from the shift register. The reason for this is to preserve causality; that is, time always moves forward, never backward. The result can be the loss of up to seven samples in the shift register, or more to the point, the output sample rate can never be less than one in eight input samples. The clock discipline algorithm is specifically designed to operate at this rate.

Figure 2 shows the performance of the algorithm for a typical Internet path over a 24-hr period. The graph on the left shows the raw offsets produced by the on-wired protocol, while the figure on the right shows the filtered offsets produced by the clock filter algorithm. If we consider the series formed as the absolute value of the offset samples, the mean error is defined as the mean of this series. Thus, the mean error of the raw samples is 0.724 ms, while the mean error of the filtered series is 0.192 ms. Radio engineers would interpret this as a processing gain of 11.5 dB.

The reader might notice the somewhat boxy characteristic of the filtered offsets. Once a sample is selected, it remains selected until a newer sample with lower delay is available. This commonly occurs when an older selected sample is discarded from the shift register. The reason for this is to preserve causality; that is, time always moves forward, never backward. The result can be the loss of up to seven samples in the shift register, or more to the point, the output sample rate can never be less than one in eight input samples. The clock discipline algorithm is specifically designed to operate at this rate.

diff --git a/html/prefer.html b/html/prefer.html index 7d1a1249e..f402a2dbc 100644 --- a/html/prefer.html +++ b/html/prefer.html @@ -3,14 +3,13 @@ Mitigation Rules and the prefer Keyword - - +

Mitigation Rules and the `prefer` Keyword

from Alice's Adventures in Wonderland, Lewis Carroll

Listen carefully to what I say; it is very complicated.

Last update: - 01-Nov-2011 3:24 + 05-Dec-2011 7:21 UTC

General Overview

This page summarizes the criteria for choosing from among a number of potential sources suitable contributors to the clock discipline algorithm. 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 discovery or the pool and manycast autonomous configuration schemes. See the Automatic Server Discovery Schemes page for further information.

Phase two refines the selectable candidates by excluding those sources showing one or more of the following errors:

A stratum error occurs if (1) the source had never been synchronized or (2) the stratum of the source is below the floor option or not below the ceiling option of the tos command. The default value for these options are 0 and 16, respectively.
A distance error occurs for a remote source if the root distance is not below the distance threshold maxdist option of the tos command. The default value for this option is 1.5 s for networks including only the Earth, but this should be increased to 2.5 s for networks including the Moon.
A loop error occurs if the source is synchronized to the client or if the source is synchronized to the same source as the client.
An unreachable error occurs if the source is unreachable or if the server or peer command for the source includes the noselect option.

Phase three uses the algorithm described on the Clock Select Algorithmm page to determine the truechimers from among the selectable candidates, leaving behind the falsetickers. A server or peer configured with the true option is declared a truechimer independent of this algorithm. Phase four uses the algorithm described on the Clock Cluster Algorithm page to cast off statistical outliers from the truechimers until a number of survivors not less than minclock remain. The minclock has default 3, but can be changed with the minclock option of the tos command.

Phase five uses a set of algorithms and mitigation rules described on this page. The algorithms rank the survivors to produce combined statistics used to discipline the clock. The mitigation rules select from among the survivors a system peer from which a set of system statistics can be inherited and passed along to dependent clients, if any. The algorithms and rules are the main topic of this page. The clock offset developed from these algorithms can discipline the system clock either using the clock discipline algorithm or enable the kernel to discipline the system clock directly, as described on the A Kernel Model for Precision Timekeeping page.

This page summarizes the criteria for choosing from among the survivors of the clock cluster algorithm a set of contributors to the clock discipline algorithm. The criteria are very meticulous, since they have to handle many different scenarios that may be optimized for special circumstances, including some scenarios designed to support planetary and deep space missions.

Recall the suite of NTP data acquisition and grooming algorithms. These algorithms proceed in five phases. Phase one discovers the available sources and mobilizes an association for each source found. These sources can result from explicit configuration, broadcast discovery or the pool and manycast autonomous configuration schemes. See the Automatic Server Discovery Schemes page for further information.

Phase two selects the candidates from among the sources by excluding those sources showing one or more of the errors summarized on the Clock Select Algorithmm page and to determine the truechimers from among the candidates, leaving behind the falsetickers. A server or peer configured with the true option is declared a truechimer independent of this algorithm. Phase four uses the algorithm described on the Clock Cluster Algorithm page to trim the statistical outliers from the truechimers, leaving the survivor list as result.

Phase five uses a set of algorithms and mitigation rules to combined the survivor statistics antdiscipline the systen clock. The mitigation rules select from among the survivors a system peer from which a set of system statistics can be inherited and passed along to dependent clients, if any. The algorithms and rules are the main topic of this page. The clock offset developed from these algorithms can discipline the system clock either using the clock discipline algorithm or enable the kernel to discipline the system clock directly, as described on the A Kernel Model for Precision Timekeeping page.

Combine Algorithm

The clock combine algorithm uses the survivor list to produce a weighted average of both offset and jitter. Absent other considerations discussed later, the combined offset is used to discipline the system clock, while the combined jitter is augmented with other components to produce the system jitter statistic inherited by dependent clients, if any.

The clock combine algorithm uses a weight factor for each survivor computed as the select threshold minus the synchronization distance. Since the select algorithm rejects candidates with synchronization distance greater than the select threshold, the weight factor is always positive. This design favors the survivors at the smaller distance, which have the smaller maximum error statistics.

The clock combine algorithm uses the survivor list to produce a weighted average of both offset and jitter. Absent other considerations discussed later, the combined offset is used to discipline the system clock, while the combined jitter is augmented with other components to produce the system jitter statistic inherited by dependent clients, if any.

The clock combine algorithm uses a weight factor for each survivor equal to the reciprocal of the root distance. This is normalized so that the sum of the reciprocals is equal to unity. This design favors the survivors at the smallest root distance and thus the smallest maximum error.

Anti-Clockhop Algorithm

The anti-clockhop algorithm is intended for cases where multiple servers are available on a fast LAN with modern computers. Typical offset differences between servers in such cases are less than 0.5 ms. However, changes between servers can result in unnecessary system jitter. The object of the anti-clockhop algorithm is to avoid changing the server unless it becomes stale or the distance increases substantially over other candidates on the list.

To help compact this discussion, we will call the last selected system peer the old peer, and the peer at the head of the survivor list the candidate peer. The anti-clockhop algorithm is called immediately after the combine algorithm. First, the survivor list produced by the clock cluster algorithm is sorted by increasing synchronization distance. The algorithm then initializes the anti-clockhop threshold with the value of mindist, by default 1 ms.

If there was no old peer or the old and candidate peers are the same, the candidate peer becomes the system peer. If not, the algorithm measures the difference between the offset of the old peer and the candidate peer. If the difference exceeds the anti-clockhop threshold, the candidate peer becomes the system peer and the anti-clockhop threshold is restored to its original value. If not, the old peer continues as the system peer. However, at each subsequent call, the algorithm reduces the anti-clockhop threshold by half. Should operation continue in this way, the candidate peer will eventually become the system peer.

The anti-clockhop algorithm is intended for cases where multiple servers are available on a fast LAN with modern computers. Typical offset differences between servers in such cases are less than 0.5 ms. However, changes between servers can result in unnecessary system jitter. The object of the anti-clockhop algorithm is to avoid changing the current server unless it becomes stale or the offset differences between it and the others on the survivor list becomes substantial.

To help compact this discussion, we will call the last selected server as the old peer, and the server at the head of the survivor list the candidate peer. The anti-clockhop algorithm is called immediately after the combine algorithm. First, the survivor list produced by the clock cluster algorithm is sorted by increasing root distance. The algorithm then initializes the anti-clockhop threshold with the value of mindist, by default 1 ms.

If there was no old peer or the old and candidate peers are the same, the candidate peer becomes the system peer. If not, the algorithm measures the difference between the offset of the old peer and the candidate peer. If the difference exceeds the anti-clockhop threshold, the candidate peer becomes the system peer and the anti-clockhop threshold is restored to its original value. If not, the old peer continues as the system peer. However, at each subsequent update, the algorithm reduces the anti-clockhop threshold by half. Should operation continue in this way, the candidate peer will eventually become the system peer.

Peer Classification

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:

An association configured for a remote server or peer is classified simply as a server. All other associations are classified as a device driver of one kind or another. In general, one or more sources of either or both types will be configured in each installation.
An association configured for a remote server or peer is classified as a server. All other associations are classified as device drivers of one kind or another. In general, one or more sources of either type will be configured in each installation.
If all sources have been lost and one or more hosts on a common DMZ network have specified the orphan stratum in the orphan option of the tos command, each of them becomes an orphan parent. Dependent orphan children on the same DMZ network will see the orphan parents as if synchronized to a server at the orphan stratum. Note that, as described below, all the orphan children having the same set of orphan parents will select the same parent.
When a device driver has been configured for pulse-per-second (PPS) signals and PPS signals are being received, it is designated the PPS driver. Note that the Pulse-per-Second driver (type 22) is often used as a PPS driver, but any driver can be configure as a PPS driver if the hardware facilities are available. The PPS driver provides precision clock discipline only within ±0.4 s, so it is always associated with another source or sources that provide the seconds numbering function.
When the Undisciplined Local Clock driver (type 1) is configured, it is designated the local driver. This driver is used either as a backup source (stratum greater than zero) should all sources fail, or as the primary source (stratum zero) in cases where the kernel time is disciplined by some other means of synchronization, such as the NIST lock clock scheme, or another synchronization protocol such as the IEEE 1588 Precision Time Protocol (PTP) or Digital Time Synchronization Service (DTSS).
When the Automated Computer Time Service driver (type 18) is configured, it is designated the modem driver. This is used either as a backup source, should all other sources fail, or as the primary source if the prefer option is present.
When the Undisciplined Local Clock driver (type 1) is configured, it is designated the local driver. It can be used either as a backup source (stratum greater than zero) should all sources fail, or as the primary source (stratum zero) whether or not other sources are available if the prefer option is present. The local driver can be used when the kernel time is disciplined by some other means of synchronization, such as the NIST lock clock scheme, or another synchronization protocol such as the IEEE 1588 Precision Time Protocol (PTP) or Digital Time Synchronization Service (DTSS).
When the Automated Computer Time Service driver (type 18) is configured, it is designated the modem driver. It is used either as a backup source, should all other sources fail, or as the primary source if the prefer option is present.

The `prefer` Peer

The mitigation rules are designed to provide an intelligent selection of the system peer from among the selectable sources of different types. When used with the server or peer commands, the prefer option designates one or more sources 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. If the first one becomes un selectable, the second one is considered and so forth. This order of priority is also applicable to multiple PPS drivers, multiple modem drivers and even multiple local drivers, although that would not normally be useful.

@@ -66,20 +58,15 @@ remains operational. However, if the radio fails or becomes a falseticker, the averaged backup sources continue to discipline the system clock.

Mitigation Rules

As the select algorithm scans the associations for selectable candidates, the modem driver and local driver are segregated for later, but only if not designated a prefer peer. If so designated, the driver is included among the candidate population. In addition, if orphan parents are found, the parent with the lowest metric is segregated for later; the others are discarded. For this purpose the metric is defined as the four-octet IPv4 address or the first four octets of the hashed IPv6 address. The resulting candidates, including any prefer peers found, are processed by the select algorithm to produce a possibly empty set of truechimers.

As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The combine algorithm ranks the survivors by synchronization distance and temporarily designates the first one as the system peer.

If one or more truechimers support a pulse-per-second (PPS) signal and the - PPS signal is operating correctly, it is designated a PPS driver. If more than - one PPS diver are found, only the first one is used. The PPS driver is not included - in the combine algorithm and is mitigated separately.

At this point the following contributors to the system clock discipline may be available:

As previously noted, the cluster algorithm casts out outliers, leaving the survivor list for later processing. The survivor list is then sorted by increasing root distance and the first entry temporarily designated the system peer. At this point the following contributors to the system clock discipline may be available:

(potential) system peer, if there are survivors;
orphan parent, if present;
local driver and zero offset, if present;
modem driver and modem offset, if present;
prefer peer and offset, if present;
PPS driver and offset, if present.
local driver, if present;
modem driver, if present;
prefer peer, if present;
PPS driver, if present.

The mitigation algorithm proceeds in three steps in turn.

Clock Select Algorithm

Last update: - 19-Oct-2011 18:17 + 04-Dec-2011 14:27 UTC

The clock select algorithm determines from a set of candidates, which are correct (truechimers) and which are not (falsetickers) according to a set of formal correctness assertions. The principles are based on the observation that the maximum error in determining the offset of a candidate cannot exceed one-half the roundtrip delay to the primary reference clock at the time of measurement. This must be increased by the maximum error that can accumulate since then. In NTP the total, called the synchronization distance, is one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here.

Given the measured offset q₀ and synchronization distance l, this defines a correctness interval [q₀ - l, q₀ + l] of points where the true value of q lies somewhere on the interval. The given problem is to determine from a set of correctness intervals, which represent truechimers and which represent falsetickers. The principles must be given a precise definition. The intersection interval is the smallest interval containing points from the largest number of correctness intervals. An algorithm that finds the intersection interval was devised by Keith Marzullo in his doctoral dissertation. It was first implemented in the DTSS (Digital Time Synchronization Service) in the VMS operating system for the VAX.

The clock select algorithm determines from a set of sources , which are correct (truechimers) and which are not (falsetickers) according to a set of formal correctness assertions. The principles are based on the observation that the maximum error in determining the offset of a candidate cannot exceed one-half the roundtrip delay to the primary reference clock at the time of measurement. This must be increased by the maximum error that can accumulate since then. The selection metric, called the root distance,, is one-half the roundtrip root delay plus the root dispersion plus minor error contributions not considered here.

First, a number of sanity checks is performed to sift the selectable candidate from among the source population. The sanity checks are sumarized as follows:.

A stratum error occurs if (1) the source had never been synchronized or (2) the stratum of the source is below the floor option or not below the ceiling option of the tos command. The default values for these options are 0 and 15, respectively. Note that 15 is a valid stratum, but a server operating at that stratum cannot synchronize clients.
A distance error occurs for a remote source if the root distance (also known ad synchronization distance) of the source is not below the distance threshold maxdist option of the tos command. The default value for this option is 1.5 s for networks including only the Earth, but this should be increased to 2.5 s for networks including the Moon.
A loop error occurs if the source is synchronized to the client. This can occur if two peers are configured with each other in symmetric modes.
An unreachable error occurs if the source is unreachable or if the server or peer command for the source includes the noselect option.

q₀

correctness interval

q₀

intersection interval

While the NTP algorithm is based on DTSS, it remains to establish which point represents the best estimate of the offset for each candidate. The best point is at the midpoint q₀ of the correctness interval; however, the midpoint might not be within the intersection interval. A candidate with a correctness interval that contains points in the intersection interval is a truechimer and the best offset estimate is the midpoint of its correctness interval. A candidate with a correctness interval that contains no points in the intersection interval is a falseticker.

Figure 1. Intersection Interval

diff --git a/html/warp.html b/html/warp.html index 889b47cb4..85b030482 100644 --- a/html/warp.html +++ b/html/warp.html @@ -9,7 +9,7 @@

How NTP Works

Last update: - 23-Oct-2011 16:21 + 05-Dec-2011 16:26 UTC

Statistics Budget

Each NTP synchronization source is characterized by the offset and delay samples measured by the on-wire protocol using the equations above. The dispersion sample is initialized with the sum of the server precision and the client precision as each sample is received. The dispersion increases at a rate of 15 ms/s after that. For this purpose, the precision is equal to the latency to read the system clock. The offset, delay and dispersion are called the sample statistics.

In a window of eight (offset, delay, dispersion) samples, the clock filter algorithm selects the sample with minimum delay, which generally represents the most accurate offset statistic. The selected sample becomes the peer offset and peer delay statistics. The peer dispersion is a weighted average of the dispersion samples in the window. It is recalculated as each sample update is received from the server. Between updates, the dispersion continues to grow at the same rate as the sample dispersion, 15 ms/s. Finally, the peer jitter is determined as the root mean square (RMS) of the offset samples in the window relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter statistics are recorded by the peerstats option of the filegen command. Peer variables are displayed by the rv command of the ntpq program.

Each NTP synchronization source is characterized by the offset and delay samples measured by the on-wire protocol using the equations above. The dispersion sample is initialized with the sum of the server precision and the client precision as each update is received. The dispersion increases at a rate of 15 ms/s after that. For this purpose, the precision is equal to the latency to read the system clock. The offset, delay and dispersion are called the sample statistics.

In a window of eight (offset, delay, dispersion) samples, the algorithm described on the Clock Filter Algorithm page selects the sample with minimum delay, which generally represents the most accurate offset statistic. The selected sample becomes the peer offset and peer delay statistics. The peer dispersion is a weighted average of the dispersion samples in the window. These quantities are recalculated as each update is received from the server. Between updates, both the sample dispersion and peer dispersion continue to grow at the same rate, 15 ms/s. Finally, the peer jitter is determined as the root mean square (RMS) of the offset samples in the window relative to the selected offset sample. The peer statistics are recorded by the peerstats option of the filegen command. Peer variables are displayed by the rv command of the ntpq program.

The clock filter algorithm continues to process packets in this way until the source is no longer reachable. Reachability is determined by an eight-bit shift register, which is shifted left by one bit as each poll packet is sent, with 0 replacing the vacated rightmost bit. Each time an update is received, the rightmost bit is set to 1. The source is considered reachable if any bit is set to 1 in the register; otherwise, it is considered unreachable.

A server is considered selectable only if it is reachable, the dispersion is below the select threshold and a timing loop would not be created. The select threshold is by default 1.5 s, but can be changed by the maxdist option of the tos command. A timing loop occurs when the server is apparently synchronized to the client or when the server is synchronized to the same server as the client. When a source is unreachable, a dummy sample with "infinite" dispersion is inserted in the shift register at each poll, thus displacing old samples.

The composition of the survivor population and the system peer selection is re determined as each update from each source is received. The system variables are copied from the system peer variables of the same name and the system stratum set one greater than the system peer stratum. System variables are displayed by the rv command of the ntpq program.

The system dispersion increases at the same rate as the peer dispersion, even if all sources have become unreachable. The server appears to dependent clients at ever increasing dispersion. If the system dispersion exceeds the select threshold as apparent to dependent clients, the server is considered nonselectable It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.

A server is considered nonselectable if it is unreachable, or the peer synchronization distance abbreviated to peer distance (see below) is above the select threshold, or if a timing loop is present. If none of these conditions exist, the server is considered selectable. The select threshold is by default 1.5 s, but can be changed by the maxdist option of the tos command. A timing loop is presentif the server is synchronized to the client, which can occur, for example, if they are configured in symmetric modes with each other. When a source becomes unreachable, a dummy sample with "infinite" dispersion is inserted in the shift register at each poll, thus displacing old samples. This causes the peeer dispersion, and thus the peer distance, to increase and eventually to exceed the select threshold.

The composition of the survivor population and the system peer selection is re determined as each update from each source is received. The system peer and system variables are determined as described on the Mitigation Rules and the prefer Keyword page. The system variables are copied from the system peer variables of the same name and the system stratum set one greater than the system peer stratum. The system statistics are recorded by the loopstats option of the filegen command. System variables are displayed by the rv command of the ntpq program.

The system synchronization distance, usually called the root distance, is defined as half the system peer delay plus the system peer dispersion. Between updates it increases at the same rate as the system peer dispersion, even if all sources have become unselectable. If the server root distance exceeds the client select threshold, as apparent to dependent clients, the server is considered nonselectable. It is important to understand that a server in this condition remains a reliable source of synchronization within its error bounds, as described in the next section.

Quality of Service

The mitigation algorithms deliver several important statistics, including system offset and system jitter. These statistics are determined by the mitigation algorithms from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported by the loopstats option of the filegen command.

Of interest in this discussion is how the client determines the quality of service from a particular reference clock or remote server. This is determined from two statistics, expected error and maximum error. Expected error, or system jitter, is determined from various jitter components; it represents the nominal error in determining the mean clock offset.

Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called synchronization distance. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the ntp_gettime() kernel system call. See the Kernel Model for Precision Timekeeping page for further information.

The maximum error is computed as one-half the root delay to the primary source of time; i.e., the primary reference clock, plus the root dispersion. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.

The algorithms described on the Mitigation Rules and the prefer Keyword page deliver several important statistics, including system offset and system jitter. These statistics are determined by the mitigation algorithms from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum-likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate.

Of interest in the following discussion is how the client determines these statistics from a survivor population including reference clocks and remote servers. This is determined from two statistics, expected error and maximum error. Expected error, also called system jitter, is determined from various jitter components; it represents the nominal error in determining the clock offset.

Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called system synchronization distance or root distance. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the ntp_gettime() kernel system call. See the Kernel Model for Precision Timekeeping page for further information.

The maximum error statistic is computed as one-half the root delay to the primary source of time; i.e., the primary reference clock, plus the root dispersion. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.

A source is considered selectable only if its maximum error is less than the select threshold, by default 1.5 s, but can be changed according to client preference using the maxdist option of the tos command. A common consequence is when an upstream server loses all sources and its maximum error apparent to dependent clients begins to increase. The clients are not aware of this condition and continue to accept synchronization as long as the maximum error is less than the select threshold.

Although it might seem counterintuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the clock select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. The reason for these rules is to limit the time delay in the clock discipline algorithm. This is necessary to preserve the optimum impulse response and thus the risetime and overshoot.

This means that not every sample can be used to update the peer variables, and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration for feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.

@@ -66,7 +66,7 @@

When the client is restarted after a period when the power is off, the clock may have significant error. The provisions described in this section insure that, in all but pathological situations, the startup transient is suppressed to within nominal levels in no more than five minutes after a warm start or ten minutes after a cold start. Following is a summary of these procedures. A detailed discussion of these procedures is on the Clock State Machine page.

The reference implementation measures the clock oscillator frequency and updates a frequency file at intervals of one hour or more, depending on the measured frequency wander. This design is intended to minimize write cycles in NVRAM that might be used in a laptop or portable device. In a warm start, the frequency is initialized from this file, which avoids a possibly lengthy discipline time. In a cold start when no frequency file is available, the reference implementation first measures the oscillator frequency over a five-min interval. This generally results in a residual frequency error of less than 1 PPM. The measurement interval can be changed using the stepout option of the tinker command.

In order to further reduce the clock offset error at restart, the reference implementation mext disables oscillator frequency discipline and enables clock offset discipline with a small time constant. This is designed to quickly reduce the clock offset error without causing a frequency surge. This configuration is continued for an interval of five-min, after which the clock offset error is usually no more than a millisecond. The measurement interval can be changed using the stepout option of the tinker command.

Another concern at restart is the time necessary for the selection and clustering algorithms to refine and validate the initial clock offset estimate. Normally, this takes several updates before setting the system clock. As the default minimum poll interval in most configurations is about one minute, it can take several minutes before setting the system clock. The iburst option of the server command changes the behavior at restart and is recommended for client/server configurations. When this option is enabled, the client sends a volley of six requests at intervals of two seconds. This insures a reliable estimate is available in about ten seconds before setting the clock. Once this initial volley is complete, the procedures described above are executed.

Another concern at restart is the time necessary for the select and cluster algorithms to refine and validate the initial clock offset estimate. Normally, this takes several updates before setting the system clock. As the default minimum poll interval in most configurations is about one minute, it can take several minutes before setting the system clock. The iburst option of the server command changes the behavior at restart and is recommended for client/server configurations. When this option is enabled, the client sends a volley of six requests at intervals of two seconds. This insures a reliable estimate is available in about ten seconds before setting the clock. Once this initial volley is complete, the procedures described above are executed.

As a result of the above considerations, when a backup source, such as the local clock driver, ACTS modem driver or orphan mode is included in the system configuration, it may happen that one or more of them are selectable before one or more of the regular sources are selectable. When backup sources are included in the configuration, the reference implementation waits an interval of several minutes without regular sources before switching to backup sources. This is generally enough to avoid startup transients due to premature switching to backup sources. The interval can be changed using the orphanwait option of the tos command.

Clock Cluster Algorithm

Clock Filter Algorithm

Mitigation Rules and the `prefer` Keyword

Related Links

General Overview

Combine Algorithm

Anti-Clockhop Algorithm

Peer Classification

The `prefer` Peer

Mitigation Rules

Clock Select Algorithm

How NTP Works

Related Links

Statistics Budget

Quality of Service

Clock Cluster Algorithm

Clock Filter Algorithm

Mitigation Rules and the prefer Keyword

Related Links

General Overview

Combine Algorithm

Anti-Clockhop Algorithm

Peer Classification

The prefer Peer

Mitigation Rules

Clock Select Algorithm

How NTP Works

Related Links

Statistics Budget

Quality of Service

Mitigation Rules and the `prefer` Keyword

The `prefer` Peer