tcp-ip@ucbvax.ARPA (07/01/85)
From: mills@dcn6.arpa Folks, The Internetional Clockwatching Weekend was a mixed bag. I was loaded for bear, with half a dozen radios listening and machines whirring the protocols and data recorders, when the great one-second leap (forward, backward?) ocurred on Sunday evening. NBS radio WWV was buried in static and D-region absorption on all frequencies, but Canadian radio CHU was beeping happily on several frequencies. From the latter, the offset from atomic time (UT0) to navigation time (UT1) was broadcast as -500 milliseconds before the leap and +400 milliseconds afterward. I assume the missing 100 milliseconds was either roundoff error or was dropped in a gateway. Since WWV was unhearable from here at the time, the Backroom WWV radio clock wasn't even aware of the leap until an hour and a half later, when it was heard again and began telling the corrected time. The Pogo WWVB radio clock took over three hours to realize something had changed, presumably due to low signal levels from the Boulder transmitter as received here near Washington, DC. The Ford GOES satellite clock near Detroit apparently had antenna fever, since its quality indicator indicated confidence only to the +-500 millisecond order. Its offset relative to the WWVB radio clock drifted lazily from +60 to -90 millsiseconds over the weekend. I gleefully watched the power grid, which normally wanders +-2000 milliseconds over the 24-hour period, crank in 60 additional cycles of steam so that ordinary synchronous-motor clocks would read correctly (are there any of these left?). One question remains: who paid for the extra steam? I have quite a collection of data, with raw sample offsets recorded every sixteen seconds, formatted ASCII transcriptions, data-reduction programs (in BASIC) and a bunch of graphics plots in gorgeous color for the Peritek (512 x 640) bit-map display. All this stuff is online, if anybody is interested. The results demonstrate that the fuzzballs and DCNet protocols really can synchronize clocks within a residual error of a few milliseconds. They also demonstrate that the Heath WWV radio clock is surprisingly good and easily makes the specifications of +-100 milliseconds in lock. In fact, most of the time it wanders within +-30 milliseconds unsmoothed, even after nearly 24 hours without a radio fix. However, the results also demonstrate a clear lack of functionality in all broadcast formats in that no advance notice is provided for a leap second, even though extra bits are available in the frame. Unless this is done, there is no way a device that must integrate information over several minutes or hours can determine in which minute an epochal event like a leap second occurs. One way to solve this problem, as well as the year ambiguity (the broadcast formats don't provide for this either, but some formats provide for a Daylight-Savings time indicator!), is with a manual command to the radio clock itself, which then hiccups at 23:59:60Z as required. Note that this command must be broadcast everywhere in the net, so that all dependent host clocks hiccup at the same time. Dave -------