Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!UDEL.EDU!Mills From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Time synchronization and distribution plan Message-ID: <8801231820.aa17884@Huey.UDEL.EDU> Date: 23 Jan 88 23:20:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 135 Folks, There is good news for clockwatchers, timewarpers and chron daemons. All radio clocks known to me are now finally repaired and ticking to standard time. Also, venerable WWVB ticker dcn1.arpa (aka pogo), which some of you may fondly remember from years past, has resumed this life. There is even a NTP secondary time server on the European MILNET which is keeping pretty good time. There are a half-dozen or so gents who have scrounged up an old PDP11-compatible system and volunteered additional GOES or WWV servers as well. It may be time (!) to bring some order to the clockwatching business. A treaty is suggested in this note. As in the telephone systems NTP uses a model of stratified clocks and servers. A primary server is one directly synchronized to a radio clock, so it can keep accurate time even in the absence of NTP itself. However, from long experience with such things, the radio clocks sometimes feature scrambled time due radio propagation conditions or broken logic. Thus, the primary servers ordinarily run NTP with a couple of their buddies as a sanity check. Should the radio clock itself become suspect, time synchronization shifts to the NTP peer group. Secondary servers are synchronized with NTP using special filtering and deglitching mechanisms ordinarily accurate to a few tens of milliseconds, even across intransigent gateways. NTP can be used in either a remote-procedure-call (asymmetric) mode, in which a client sends a single message to the server and receives the time in reply, or a distributed (symmetric) mode, in which the protocol runs continuously and time is continuously compared between the peers and corrected as required. The asymmetric mode is designed for casual use, such as setting the time and date when a PC comes up, for example, while the symmetric mode is designed for more accurate and precise applications, such as transaction timestamping and time redistribution. This note is concerned only with use of the symmetric mode. Not everybody can chime with a primary server, since this would eventually lead to severe congestion and degraded service. Therefore, a system of hierarchical time servers is suggested. Assume that each of the 400-odd networks now active has a secondary time server synchronized to one or more primary servers and providing time service to other hosts in its community. In order to provide the highest robustness, the secondary server should chime with more than one primary server, perhaps three, so we are talking about 1200 peer paths. The existing LSI-11 fuzzball gateways can support at least 60 peer paths each, so some twenty primary servers would be needed. At the moment NTP chimes one packet each direction per peer per minute, so the aggregate time traffic works out to about one packet each direction per fuzzball per second. It is planned to introduce NTP protocol modifications that would reduce this rate by a factor of ten. The twenty-odd primary servers should be located at strategic spots designed to minimize the impact of the NTP traffic itself, yet provide low delay dispersion for their customers. The existing and planned NSFNET Backbone sites would seem ideal candidates and, indeed, time-synchronized fuzzballs are already installed at seven of these sites. Without admitting agenda on how the time-synchronization capability came to pass or on the likely disposition of the fuzzballs once the new NSFNET Backbone is deployed, I suggest a nucleus of timetellers is already in place. Additional timetellers are now ticking on ARPANET and local nets gatewayed to ARPANET, MILNET and elsewhere. At the U Delaware campus and at several other campuses known to me, one or more relatively inexpensive WWV clocks are installed as backups should connectivity to a primary server be lost for one reason or another. The WWV clocks are distinctly inferior in accuracy and reliability with respect to the WWVB and GOES clocks now used at the primary servers; however, as some may remember, there have been occasions over the last several years when all primary servers in the experimental system were down and the entire NTP-speaking Internet was synchronized to a dinky WWV clock on my desk at home. I suspect several institutions that cherish accurate time will install GOES, WWVB or even GPS clocks and join the NTP chorus as well, so there may be in fact no need for an overt program to buy and install additional clocks. I saved specific recommendations for last. I suggest an appropriate first step is that those sites with good connectivity to an NSFNET regional system chime NTP with the NSFNET Backbone fuzzball serving that regional system. Other sites may wish to choose one or another fuzzball listed below. However, it is most important to understand that time service is provided by each of these gizmos on a secondary basis only, is still in an experimental phase and may be limited or curtailed should it interfere with the primary functions of the machine. Speaking for myself and I suspect the other operators listed, we would expect users to set up their own time-redistribution network, perhaps using the 4.3 bsd ntpd daemon specifically designed for this purpose, and to avoid ganging up on the servers with many hosts from the same net. We would also expect users planning long-term use of the servers to express their intent to the operators and comply with requests to reaffiliate with other servers should that become necessary. Finally, we are looking for volunteers to install additional primary servers and join the chorus as well. Name Address Clock Operator and notes -------------------------------------------------------------------------- Primary servers umd1.umd.edu 128.8.10.1 WWVB Mike Petry (petry@trantor.umd.edu) U Maryland (gatewayed to NSFNET Backbone, ARPANET PSNs 17 and 20 and MILNET PSN 57. wwvb.isi.edu 128.9.2.129 WWVB Steve Casner (casner@isi.edu) ISI (gatewayed to ARPANET PSN 22) ncar.nsf.net 128.116.64.3 WWVB Scott Brim (swb@devvax.tn.cornell.edu) NCAR (NSFNET Backbone gateway) dcn1.arpa 128.4.0.1 WWVB Dave Mills (mills@udel.edu) 10.2.0.96 U Delaware (directly connected to ARPANET PSN 96) ford1.arpa 128.5.0.1 GOES Fred Ball (ball@ford-vax.arpa) Ford Research (gatewayed via 9600-bps line to ARPANET PSN 111. Secondary servers (please do NOT chime with these except by permission) macom1.arpa 192.5.8.1 NTP Woody Woodburn (woody@macom2.arpa) 10.0.0.111 Linkabit, Vienna, VA swamprat.arpa 192.5.8.2 NTP Woody Woodburn (woody@macom2.arpa) Linkabit, Vienna, VA patch.arpa 26.6.0.2 NTP Dave Park (dpark@dca-eur.arpa) USECOM Stuttgart, FRG gw.umich.edu 35.1.1.1 NTP Hans-Werner Braun (hwb@mcr.umich.edu) U Michigan (WWV backup) xyzzy.umich.edu 35.1.1.3 NTP Hans-Werner Braun (hwb@mcr.umich.edu) U Michigan libra.rice.edu 128.42.1.64 NTP Paul Milazzo (milazzo@rice.edu) 10.4.0.62 Rice U dcn6.arpa 128.4.0.6 NTP Dave Mills (mills@udel.edu) Newark, DE (WWV backup) sdsc.nsf.net 192.12.207.1 NTP Scott Brim (swb@devvax.tn.cornell.edu) San Diego Supercomputing Center uiuc.nsf.net 128.174.5.14 NTP Scott Brim (swb@devvax.tn.cornell.edu) National Center for Supercomputing Aplications psc.nsf.net 128.182.1.2 NTP Scott Brim (swb@devvax.tn.cornell.edu) Pittsburg Supercomputing Center cornell.nsf.net 128.84.238.50 NTP Scott Brim (swb@devvax.tn.cornell.edu) Cornell U (NYSERNET) jvnc.nsf.net 128.121.50.20 NTP Scott Brim (swb@devvax.tn.cornell.edu) John von Neumann Center (JVNCNET) nsfnet-gw.umd.edu 128.8.10.6 NTP Mike Petry (petry@trantor.umd.edu) U Maryland (SURANET) Corrections or additions to this list would be appreciated Dave