Mills@udel.edu (01/01/91)
Folks, Amongst the battery of instruments clicking, humming and flickering here this evening all eyes and ears were tuned for The Leap. In spite of the fact I broke a couple of fuzzballs that, with Louie Mamakos' help, got put right only a couple of minutes before the Event, all clocks and monitors were running okay. I am happy to report the pinball-machine behavior I was so ashamed of at the last Leap was notably absent on this one. All the fuzzbugs sailed right through the Leap doing exactly what they were supposed to. The radios, of course, got scrambled, but the fuzzies just ignored the nonsense and waited until the ions cooled before relatching the radios. I was most concerned about the fuzzbugs in Oslo, which are chimed to the Norwegian standards - one a cesium clock and the other a LORAN-C receiver, since those bugs still have to disambiguate the seconds via the U.S. chimers. Therefore, it's not just a question of retiming the tick, but knowing what tick is the right one. Think about it. Anyway, the bugs figured it all out and the times tick true. Well, the fuzzballs got it right this time. Now, about the others. Don't ask. Dave
iglesias@draco.acs.uci.edu (Mike Iglesias) (01/01/91)
In article <9012312226.aa10954@huey.udel.edu> Mills@udel.edu writes: >Folks, > >Amongst the battery of instruments clicking, humming and >flickering here this evening all eyes and ears were tuned >for The Leap. In spite of the fact I broke a couple of >fuzzballs that, with Louie Mamakos' help, got put right >only a couple of minutes before the Event, all clocks >and monitors were running okay. I am happy to report the >pinball-machine behavior I was so ashamed of at the last >Leap was notably absent on this one. All the fuzzbugs >sailed right through the Leap doing exactly what they >were supposed to. The radios, of course, got scrambled, >but the fuzzies just ignored the nonsense and waited until >the ions cooled before relatching the radios. Well, almost Dave. Fuzz.sdsc.edu thinks it's 1989(!). Here's the output of ntp -v: Script started on Mon Dec 31 17:28:39 1990 draco% ntp -v fuzz.sdsc.edu Packet from: [132.249.16.1] Leap 0, version 1, mode Server, poll 6, precision -10 stratum 1 (WWVB) Synch Distance is 0000.0000 0.000000 Synch Dispersion is 0000.0312 0.011993 Reference Timestamp is a94930b5.49780000 Sun Dec 31 17:28:21 1989 Originate Timestamp is ab2a6450.9d1e53a8 Mon Dec 31 17:28:48 1990 Receive Timestamp is a94930d0.a5a10000 Sun Dec 31 17:28:48 1989 Transmit Timestamp is a94930d0.d0a30000 Sun Dec 31 17:28:48 1989 Input Timestamp is ab2a6450.d21d755a Mon Dec 31 17:28:48 1990 fuzz.sdsc.edu: delay:0.039019 offset:-31535999.986265 Sun Dec 31 17:28:48 1989 draco% ^D script done on Mon Dec 31 17:28:51 1990 One second forward and one year back. :-) Mike Iglesias University of California, Irvine Internet: iglesias@draco.acs.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
Mills@udel.edu (01/01/91)
Guys, Well, one of the lords stumbled. Before I could update the startup file on fuzz.sdsc.edu, for some reason that lord was rebooted. That of course exlains the great leap backward 31,536,001 seconds. We gotta get new radios that know what year it is and, for that matter, when the lords should leap. As seen from here (net 128.4), wwvb.isi.edu, bitsy.mit.edu and apple.com are oscillating on and off the planet every few minutes. This is getting worse, as is the packet-drop rate on SURA-NSFNET paths. Also, dear hears, can I once again plead for help in resisting the urge to ping NTP with dinky dcn6.udel.edu? This is a test host located at the end of a dinky 9600-bps line in my shack. As noted in the NTP atlas pub/ntp/clock.txt on louie.udel.edu, the operator wishes it not be used except for experiment and development. Well, the situation has gotten out of hands, with some 33 developers now chiming away. This makes it moderately irky when trying new software. Thanks for your support. Dave
davy@ERG.SRI.COM (01/02/91)
From: Mills@udel.edu
Date: Mon, 31 Dec 90 22:26:09 EST
Subject: Not a Lord a-leaping
Well, the fuzzballs got it right this time. Now, about the
others. Don't ask.
Dave
I had one machine here complain about it three times, but nothing bad happened,
i.e. no time warps:
Dec 31 21:57:19 san ntpd[127]: Clock is too far off -31536000.142805 sec. [132.249.16.1]
Dec 31 21:58:23 san ntpd[127]: Clock is too far off -31536000.142805 sec. [132.249.16.1]
Dec 31 21:59:27 san ntpd[127]: Clock is too far off -31536000.142805 sec. [132.249.16.1]
The "Dec 31 ..." times are in PST. 132.249.16.1 is fuzz.sdsc.edu.
The leap didn't seem to bother ntp3.4 and my WWVB clock... although the
dispersion has jumped way up:
(rem) Address (lcl) Strat Poll Reach Delay Offset Disp
==========================================================================
*0.0.0.0 wildcard 1 64 377 1.0 -64.0 7522.0
It usually runs down at something less than 10.0. I'll have to wait and
see if it stabilizes again in the next 24 hours or so.
--DaveMills@udel.edu (01/02/91)
davy, Yeah, yours got zapped by the lord's boot. If you watched your 'VB clock, you would have seen it sail on the old timescale for a few minutes, then scramble to the new one. The Unix daemons may or may not do something wonderful in such cases. The fuzzy ones anticipate the leap and scramble at the leap instant. Also sprach timewarp. Dave
paal@TOR.NTA.NO (Paul Spilling) (01/03/91)
Congratulations Dave and happy ticking in the new year. Paal