mills@huey.udel.edu.UUCP (01/01/87)
Folks, Every year it's the same - I forget UT midnight comes five hours before the ball drops in Times Square. For an hour and sixteen minutes after the hoot and holler in Trafalgar Square at least four radiofuzz timetellers still squawked yesteryear. DCN1, UMD1, FORD1 and NCAR springs have now been rewound to 1987 and all you guys can forget those whopping disk-usage refunds. Thanks to Hans-Werner Braun, who reminded me of my annual first duty of the new year and annual first resolution to figure out how to avoid paw to keyboard in the absence throughout the world, as far I know, of a highly reliable electronic way to find out what year it is. Dave -------
Mills%udel.edu@LOUIE.UDEL.EDU.UUCP (01/01/87)
Vint, Every single clock I can reach out and touch, and some others I can bully, ALWAYS tick UT. Fuzzballs would never come within two picofarads of anything local or I would pull their ears off. In fact, there are a few people out there that get mad at me for this hard-line position. Now I can tell my buddies MCI Mail came to the same conclusion. Goodie. The problem occurs because the radio formats do not include the year; so, from first principles a Rip van Winkle waking up with no prior information doesn't know the year. Yes, thee have been numerous suggestions to avoid the problem, but they all use previous state in the file system, collective buddies and so forth. In principle, all it takes is one grand HEMP and the chimes would tinkle for us, no matter who asks. Dave
mckee@MITRE.ARPA.UUCP (01/02/87)
>Every single clock I can reach ... never come within two picofarads ...
Come now Dave - the capacity of a clock that ticks farads is bound
to have an erratic charge; no doubt you meant two mho milli-henries;
or is this the sort of pedantic nonsense up with which you will not put.
You mentioned the lack of year information in the radio format; what
about date info? Do your fuzzballs handle years divisible by
4, 40, and 400; or must we place our (recently abused) trust in the
clock czar?
Regards - CraigMills%udel.edu@LOUIE.UDEL.EDU.UUCP (01/02/87)
Craig, Your current is clear. Millsiamps it is and don't resistor or you'll be rectified. I know when my grid leaks anyway. Fuzzballs leap the years properly, but sometimes don't leap the seconds, as you might know from my experiments previously reported to this list. Time and day-of-year are reliably reported in both US (WWV, WWVH, WWVB) and UK (MSF) broadcasts, but not the year. A "daylight-time" bit is now included (which I consider useless to dangerous), but not advance notice of a leap-second (see NTP in RFC-958). We gotta infiltrate more computer hackers into NBS. Scenario: Martian comes to Earth, asks the year. Whatever you say, he says he doesn't believe you. Think about it. Did Julian's astronomers get the rate right but the date wrong? Think about that, too, and mumble a prayer to the Axioms Peano. Dave
Mills%udel.edu@LOUIE.UDEL.EDU.UUCP (01/03/87)
Vint, International clocks are coordinated by the BIH in Paris, so I suppose they might take a timewarp or to of blame; however, my quarrel is only with the shadowy figures who design the radio-time broadcast formats. Originally we could blame the Inter_Range Instrumentation Group (IRIG), which coordinated the Atlantic Missile Testing Range long, long ago when WWV was in Beltsville, MD, and kept time with eight buried crystal oscillators. The original WWV format as developed by the IRIG and still used, provides 54 bits per minute, but I count only 27 being used in the WWV format (one less in the WWVB format). The day of year takes 23 bits (in BCD!), the UTC-1 correction three and the daylight indicator one. The 23 bits are coded minutes/hours/days in BCD fergawshakes, and this in our age of microcomputers. Now, if the slate could be wiped clean, it should not be hard to include the year, leap-second alert, propagation forecasts, UTC-1 correction, daylight indicator (ugh) and probably lots more, while encoding the whole thing in the same 54-bit frame with some error-correction info to reduce the vulnerability to time-warps, as every Heath clock owner knows. Dave
LYNCH@A.ISI.EDU.UUCP (01/04/87)
Dave, Your IRIG time story brings back gorry memories for me. I was a "computor" in the USAF about 20 years ago and the reason we had those ghastly BCD encodings of time was because we humans had to read that time data manually when in debug or panic mode. Have you ever tried to look for a specific time, like 3 PM, in binary milleseconds since anything??? We were grateful for that encoding scheme even though we knew it was wasteful. The bit about not being able to note the change of year was also amusing. Because I was designing a missile tracking system and we did not think the enemy would give us a grace period on New Year's Eve, we had to put in logic to snake around that wraparound so we could track the suckers through the (last?) champaigne toasts. And, oh yes, we even tested that code... Dan -------
Perrine@LOGICON.ARPA (Tom Perrine) (01/09/87)
WARNING! TIME WARPS AHEAD! Well the chimes sure tinkled for us! On Thursday 8 Jan (1987 A.D.) at about 1400 PST we queried DCN1 as we booted our PWB UNIX system and received a 1986 date stamp! (Gee Mr. Peabody, set the Wayback machine for 1987!) Further investigation shows that DCN6 and GW.UMICH.EDU are also stuck in a time warp. UMD1 seems to be the only un-nostalgic clock. (FORD1 was not reachable.) For now, everyone better keep one eye on the Timex, and another on the packets, and another on the Seiko! Tom Perrine Logicon - OSD p.s. What (Where?) is the previously mentioned NCAR clock/site? I can't find a net address for this place in the NIC host table.
Hans-Werner_Braun@um.cc.umich.edu (01/09/87)
Tom:
GW.UMICH.EDU is NTP synchronized to a bunch of machines and a change in
DCN1's view of the year has noticable impact on the well-behaving of
GW.UMICH.EDU. There is another host on the same machine (WWV.UMICH.EDU)
which is locked on a local WWV clock and which will tell you the right
year. WWV.UMICH.EDU is probably slightly more inaccurate (may be by some
50 msec or so (may be less (infinity in Dave Mills' terms!))) than the
GW.UMICH.EDU time.
I will tell you the NCAR address if you promise not to send TCP/TIME
requests.
-- Hans-WernerMills%udel.edu@LOUIE.UDEL.EDU (01/09/87)
Tom, [expletive deleted]. From the DCN1 log, it appears some NTP peer came up claiming to be an NTP primary radio clock, but one year off, argued with DCN1 and won. I suspect it happened during the interval immediately following reboot and when the radio clock direclty attached to DCN1 stabilized. Although the year is initialized from the file system during reboot, until the local radio clock engages an broken NTP peer can latch the wrong year. DCN1 has been rebooted maybe once every two weeks, almost always to install software updates. The spoof window lasts maybe a minute. What can I say? Yes, the window can probably be shut. Independent, operational radio clocks are presently at DCN1 (128.4.0.1), UMD1 (128.8.0.1) and FORD1 (128.5.0.1). The new NCAR clock is probably best left alone until the NSFnet Backbone configuration changes have completely stabilized. What these should do is provide up to six NTP "servers" on various campus nets, all slaved to NCAR and will avoid congestion on the network links serving NCAR itself. Dave
Mills%udel.edu@LOUIE.UDEL.EDU (01/09/87)
HW, Unfortunately, Hans-Werner's clock can be spoofed in the same way mine was (both us the same synchronization code). The problem is rather tricky. Every host is told at reboot what year it is and remembers this until told otherwise. Let's assume some j-random glitch comes along and sets the local clock using NTP or even eyeball-and-wristwatch, which causes the year to be changed. Then the radio clock comes up and starts ticking the seconds but using the bogus year. How can you protect against this? The radio clock may never come up. In its absence the local host falls back to NTP and believes what it is told. If it is peering with a sufficient number of other reliable clocks, then the bog should be overcome. However, the fuzzball bog-suppressant code does not yet do all it can in comparing multiple clocks and at the moment of failure had only one other (presumably broken) player. Once again to the breech, dear hearts, and reflect on the fact that nothing is quite so public and excites so many so quickly as a timewarp. Mr. Sulu would understand. Dave
Hans-Werner_Braun@um.cc.umich.edu.UUCP (01/09/87)
Dave, I don't think this is true for the Heath clock. After all, I don't
have a DATE statement in STARTF.COM as I think you do. This thing needs
to be opened every 31st December in the hours between the time where
UT and local time think that the next day started and a switch gets thrown
to define the exact year (!@#$%^&). While you were able to fix your chimes
from home I had to go to the radio clock and use a screwdriver.
-- Hans-WernerMills%udel.edu@LOUIE.UDEL.EDU.UUCP (01/09/87)
HW, You are right, as usual, and I wrote the code. The year is in fact read off the clock and I twitched my screwdriver just like you. I double-checked all the configuration files on all the fuzzies known to me and found the right year in the startup files. The mystery deepens, because now we have to find some player somewhere who has his year wrong and is torqueing via NTP. Distributed algorithms are a gas... Dave
weltyc%cieunix@CSV.RPI.EDU.UUCP (01/11/87)
>You are right, as usual, and I wrote the code. The year is in fact read off >the clock and I twitched my screwdriver just like you...... Isn't it funnay how things like this happen... Right after I got this message I saw the following "fortune" when I logged out: "Beware of programmers carrying screwdrivers" Hmmm. perhaps I should notify the police... -Chris