Mills@UDEL.EDU (01/18/88)
Folks, Two of the four Internet timetellers normally synchronized to NBS radio time have blown their springs. ISI (128.9.2.129) is ticking one year in the past and NCAR (128.116.64.3) is ticking one day in the future. The remaining two, UMD1 (128.8.10.1) and FORD1 (128.5.0.1), are presently in-chime with NBS; however, access to FORD1 is frequently unstable due to network problems. Since all NSFNET Backbone fuzzballs except U Maryland are synchronized to NCAR, these tockers will also be ticking one day in the future. At ISI the system startup file must be updated to the present year. Apparently, probably due to known hardware problems, the file was restored as of last year. At NCAR the bugfix I left on the disk there must be installed. Cornell was notified of the NCAR bug last week but so far has not installed the fix. I cannot do either of these things from here. Dave
swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) (01/18/88)
I'd like to ask everyone **not** to use NCAR.NSF.NET (128.116.64.3) or any of the other *.nsf.net fuzzballs as time servers. Granted time service doesn't take too many resources, the NCAR fuzzball is a central node in NSFNET, with about 30-40 institutions on the other side of the ethernet it is connected to and lots of traffic going through it on its point-to-point links. It is already so congested that it spasms from time to time. A few cycles here and there at this point make a tremendous difference in the survivability of NSFNET. So PLEASE use one of the others to NTP-peer with. Scott
CASNER@VENERA.ISI.EDU (Stephen Casner) (01/20/88)
Folks, The system startup file for WWVB.ISI.EDU has been reentered to bring it up to 1988, so it should once again be ticking the correct time. -- Steve -------
Mills@UDEL.EDU (01/21/88)
Steve, Great. NCAR is apparently ticking to-date as well. Have you any idea why I can't barge into the WWVB fuzzy and refertilize its disk? All stations, be advised reports from our commando unit operating in Vienna, VA, has just liberated a WWVB clock (which used to tick at Linkabit). Said clock and commando also sighted leaving Metroliner Wilmington, DE. There are persistent rumors to effect this clock may soon tick from U Delaware. This was a very clean operation with the only casulty a Property Control Officer and a DSSW beancounter or two. Dave
perry@MCL.UNISYS.COM (Dennis Perry) (01/21/88)
Dave, I am disappointed. Beancounters usually are high priority and to only take out two of them is not very good field operations :-) dennis
Mills@UDEL.EDU (01/22/88)
Dennis, Yeah, but I sure got funny looks as I hauled the clock and antenna through Union Station. I just told the doorperson the antenna was a new-model M16 and got wonderful service. It seems to be working okay at the moment, so its appearance on the net should be eminent (sic). Dave
Mills@UDEL.EDU (01/22/88)
Scott, I concur with your feeling that the NCAR fuzzball should be protected from cycle stealers as much as possible, but maybe you are missing something. First, application-level services, including NTP, are run at the lowest priority level in the multi-level scheduler, so that packet-forwarding functions always take precedence. Furthermore, the memory allocations are disjoint, so that even relatively large numbers of UDP users do not impact the resources used by packet-forwarding functions. Notwithstanding the above, I would very much recommend the use of the backbone fuzzies to provide time service directly to their Ethernet population simply to avoid those time-service packets transiting the seriously overloaded backbone links to other time servers removed from the backbone. As you know, the fuzzballs are carefully synchronized to various radio clocks using their local-net routing protocol, so there is no need for time-service packets between them or for timewatchers to chime any but the nearest fuzzball as the ethernet flies. What I think is a much more productive strategy is to suggest to your timewatchers to avoid the urge to chime any particular fuzzball with multiple hosts on the same network. Far better to chime with one host using NTP and then redistribute time locally. It would seem that each backbone fuzzball could serve as chimee for any or all the nets it normally serves in its respective configuration. This would avoid the chimepackets even coming near the overloaded serial lines. Dave