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
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.