The basic NTP robustness model is that a host has no other
means to verify time other than NTP itself. In some equipment a battery-backed clock/calendar is available for a sanity check. If such
a device is available, it should be used only to confirm sanity of the timekeeping system, not as the source of system time. In the
common assumption (not always justified) that the clock/calendar is more reliable, but less accurate, than the NTP synchronization
subnet, the recommended approach at initialization is to set the Clock register as determined from the clock/calendar and the other
registers, counters and flags as described above. On subsequent updates if the time offset is greater than a configuration parameter
(e.g., 1000 seconds), then the update should be discarded and an error condition reported. Some implementations periodically record
the contents of the Skew-Compensation register in stable storage such as a system file or NVRAM and retrieve this value at
initialization. This can significantly reduce the time to converge to the nominal stability and accuracy regime.
Conversion from NTP format to the common date and time formats used by application programs is simplified if the internal local-clock
format uses separate date and time variables. The time variable is designed to roll over at 24 hours, give or take a leap second as
determined by the leap-indicator bits, with its overflows (underflows) incrementing (decrementing) the date variable. The date and
time variables then indicate the number of days and seconds since some previous reference time, but uncorrected for intervening leap
seconds.
On the day prior to the insertion of a leap second the leap bits (sys.leap) are set at the primary servers, presumably by manual
means. Subsequently, these bits show up at the local host and are passed to the local-clock procedure. This causes the modulus of the
time variable, which is the length of the current day, to be increased or decreased by one second as appropriate. Immediately
following insertion the leap bits are reset. Additional discussion on this issue can be found in Appendix
E.
Lack of a comprehensive mechanism to administer the leap bits in the primary servers is presently an awkward problem better suited to
a comprehensive network-management mechanism yet to be developed. As a practical matter and unless specific provisions have been made
otherwise, currently manufactured radio clocks have no provisions for leap seconds, either automatic or manual. Thus, when a leap
actually occurs, the radio must resynchronize to the broadcast timecode, which may take from a few minutes to some hours. Unless
special provisions are made, a primary server might leap to the new time scale, only to be yanked back to the previous time scale when
it next synchronizes to the radio. Subsequently, the server will be yanked forward again when the radio itself resynchronizes to the
broadcast timecode.
This problem can not be reliably avoided using any selection algorithm, since there will always exist an interval of at least a couple
of minutes and possibly as much as some hours when some or all radios will be out of synchronization with the broadcast timecode and
only after the majority of them have resynchronized will the subnet settle down. The CLOCK.MINSTEP delay is designed to cope with this
problem by forcing a minimum interval since the last gradual adjustment was made before allowing a step change to occur. Therefore,
until the radio resynchronizes, it will continue on the old time scale, which is one second off the local clock after the leap and
outside the maximum aperture CLOCK.MAX permitted for gradual phase adjustments. When the radio eventually resynchronizes, it will
almost certainly come up within the aperture and again become the reference source. Thus, even in the unlikely case when the local
clock incorrectly leaps, the server will go no longer than CLOCK.MINSTEP seconds before resynchronizing.
|
|