mills@DCN6.ARPA (10/12/85)
Folks, Experimental servers for the Network Time Protocol (NTP) announced in RFC958 are running now on several fuzzballs, including DCN1, DCN6, FORD1 and UMICH1. These are servers only and do not implement the distributed algorithms suggested in RFC958. The servers are implemented as a user process, so are not as accurate as ICMP Timestamp messages. Our experience indicates accuracies in the order of 50-ms relative to NBS time should be expected as the NTP reply timestamp leaves one of these hosts. Two new hosts each specifically associated with a radio clock have been activated. One of these (128.4.0.15) tracks WWVB and the other (128.4.0.14) tracks WWV. Particular care was taken in their design to preserve the highest accuracy of ICMP Timestamp messages. For all other protocols, including TCP and UDP, these hosts perform only the standard echo function (RFC862). We have made a number of changes to our fuzzballs and timetellers in order to improve timekeeping robustness and move toward a truly distributed clock service. In summary, we have direct access to two radio clocks (WWVB and WWV) and indirect access to a third (GOES), all of which are available to the local-net routing and timekeeping functions. We have arranged automatic fallback to secondary clocks should the primary ones fail. For this prupose a clock which has never synchronized or has either failed to respond to a poll or has indicated loss of signal for over two minutes is considered to have failed. Only one radio clock will be used at any time to synchronize our local network and its dependencies, including timestamps returned from all 128.4 hosts. In order of preference, the WWVB clock will be chosen first. If it is down the next choice will be the WWV clock and the last the GOES clock. If no radio clock is up the host clock will free-run relative to the last radio-clock update and the intrinsic drift of its crystal. The fallback procedure is automatic and should be glitch-free, except possibly for a step offset if a difference of over 128 milliseconds is involved. If for some reason the host clock was never synchronized, such as when first booted and before any radio-clock updates have occured, that host will not respond to UDP time requests and will close TCP time requests immediately without sending data, which is consistent with RFC868. At present there is no provision for marking a host clock unsynchronized once it has been synchronized; however, our experience indicates the stability of the host clocks is such that this would be indicated only after a prolonged outage (a matter of days) of all radio clocks, which is considered unlikely. The intended result of all this effort is that rotten timestamps such as recently escaped our swamp due thunderstorms and hurricanes will not recur to destabilize the files, messages and bombs of our friends. Dave -------