When the magnitude of a correction exceeds the maximum
aperture CLOCK.MAX, the possibility exists that the clock is so far out of synchronization with the reference source that the best
action is an immediate and wholesale replacement of Clock register contents, rather than in gradual adjustments as described above.
However, in cases where the sample variance is extremely high, it is prudent to disbelieve a step change, unless a significant
interval has elapsed since the last gradual adjustment. Therefore, if a step change is indicated and the Watchdog counter is less than
the preconfigured value CLOCK.MINSTEP, the update is ignored and the local-clock procedure exits. These safeguards are especially
useful in those system configurations using a calibrated atomic clock or LORAN-C receiver in conjunction with a separate source of
seconds-numbering information, such as a radio clock or NTP peer.
If a step change is indicated the update is added directly to the Clock register and the Clock-Adjust register and Watchdog counter
both set to zero, but the other registers are left undisturbed. Since a step change invalidates data currently in the clock filters,
the leap bits are set to 112 (unsynchronized) and, as described elsewhere, the clear procedure is called to purge the clock filters
and state variables for all peers. In practice, the necessity to perform a step change is rare and usually occurs when the local host
or reference source is rebooted, for example. This is fortunate, since step changes can result in the local clock apparently running
backward, as well as incorrect delay and offset measurements of the synchronization mechanism itself.
Considerable experience with the Internet environment suggests the values of CLOCK.MAX tabulated in Table 6 as appropriate. In
practice, these values are exceeded with a single time-server source only under conditions of the most extreme congestion or when
multiple failures of nodes or links have occurred. The most common case when the maximum is exceeded is when the time-server source is
changed and the time indicated by the new and old sources exceeds the maximum due to systematic errors in the primary reference source
or large differences in path delays. It is recommended that implementations include provisions to tailor CLOCK.MAX for specific
situations. The amount that CLOCK.MAX can be increased without violating the monotonicity requirement depends on the Clock register
increment. For an increment of 10 ms, as used in many workstations, the value shown in Table 6 can be increased by a factor of
five.
|
|