mohamed%hscfvax@HARVARD.HARVARD.EDU.UUCP (04/03/87)
I would like to hear from sites that keep exact time and make it available (RFC 868) to others. Also whether it is available via TCP or UDP. Thanks ellozy@harvard.harvard.edu
Mills@UDEL.EDU.UUCP (04/05/87)
You can't keep "exact time" with RFC-868 time servers, since that protocol provides resolution only to the second. You should really and truly avoid TCP-based time, since not only is the accuracy udually degraded by the clank-and-bump of the connection-open sequence, but the sometimes meager resources of the time server can be strained. The protocol of choice is the Network Time Protocol (NTP), documented in RFC-958, for which Unix- based server and client programs are available (e.g. Mike Petry petry@trantor.umd.edu, Milo Medin medin@orion.arpa, both for 4.3 systems). As for the most accurate clocks in town, a fair number of "fuzzball" gateways and hosts are equipped with WWVB and WWV radio clocks that can deliver time accurate to a millisecond or two. Typical accuracies using NTP via ARPANET/MILNET are within 20 to 100 milliseconds, depending on the path and state of congestion. The fuzzballs are interconnected with NTP and, in some cases an interior-gateway protocol called hellospeak (c.f. RFC-891), so a failure in one radio clock does not frustrate the clockwatchers. At present the NSFNET Backbone sites are all synchronized to a WWVB radio clock at Boulder, CO, and capable of very accurate and robust time service using RFC-868 or NTP protocols. Use of TCP is adamantly discourged with the former and not available with the latter. UDP is the prefered envelope in any case. In addition, several WWVB-equipped servers are scattered about, including macom1.arpa (192.5.8.1), umd1.umd.edu (128.8.10.6) and ford1.arpa (182.5.0.1 - actually a GOES clock). Finally, a few hosts scattered over the swamps support less-accurate WWV radio which are also used as backups for the NTP system, including gw.umich.edu (35.1.1.1) and udel2.udel.edu (192.5.39.87). If present plans work out, the best places to watch clocks will be the NSFNET Backbone fuzzballs or other hosts synchronized directly to them. An announcement will be posted to this list when the details stabilize. Meanwhile, feel free watch one or more of the clocks above, with the first two (macom1.arpa or umd1.umd.edu) as the primary choice, but please don't use TCP. Dave
howard@cos.UUCP.UUCP (04/06/87)
Time synchronization has been a major issue in performance work. Several lessons learned may help. First, if at all possible, do not depend on a single time of day "message," but iterate to get a sense of path delay. A technique developed jointly by the Commerce Department (NBS Time Lab and Institute for Telecommunications Sciences) and Bell Labs illustrates. In this technique, assume a master-slave relationship for time setting, initiated by the slave. The slave contacts one (or more) master clock sites, and requests a download of the time of day. So far, this is traditional. However, the enhancement takes place after the master sends its time of day: the slave RETRANSMITS what it received. The master then calculates the difference (in time units) between what it sent and what the slave received, and sends that as a correction factor. The slave then algebraically adds this correction factor to its clock and retransmits the new value.This process repeats until the desired resolution is achieved. The first implementation of this method was over the AT&T dial network (there was one at the time). It turns out that the widely held belief that you cannot assume equal delay on both sides of a dial call is FALSE, at least for the AT&T routing plan. They do not, for example, assign one side to a terrestrial and one to a satellite facility; both go in the same way.
Mills@UDEL.EDU.UUCP (04/07/87)
Howard, I would like to recommend RFC-958 and the references cited there as input to this work. A reasonable volume of swampslush has washed under the keel of the DARPA Internauts in the area of time synchronization. Dave