More accurate clocks


mills@dcn6.arpa
06-Mar-86 18:28:47-UT


Folks,

Our clockwatching team, with kind help from the folk at U Maryland, Ford
Research and U Michigan, continues to refine the accuracies of timestamps
produced by the radio-clock equipped fuzzball hosts, including DCN1.ARPA
(128.4.0.1), UMD1.ARPA (128.8.0.1) and FORD1.ARPA (128.5.0.1). A painstaking
calibration using local-net paths between these hosts, which are in Vienna,
VA, College Park, MD, and Dearborn, MI, respectively, reveals UMD1.ARPA (WWVB
clock) to lead DCN1.ARPA (WWVB clock) by 4 +-2 milliseconds and FORD1.ARPA
(GOES clock) to lead DCN1.ARPA by 6 +-2 milliseconds.

Although we have at the moment no independent means (e.g. portable atomic
clock) to precisely calibrate these clocks with respect to NBS Standard Time,
the fact that two of them use low-frequency radio transmissions (WWVB) and the
third uses satellite transmisssions (GOES), as well as the fact that separate
less-accurate WWV high-frequency radio clocks in University Park, MD, and Ann
Arbor, MI, indicate agreement within expected nominals, suggests they can be
trusted to within a few milliseconds.

In the latest implementation the first derivative of offset (drift) is
separately estimated and the timestamps compensated accordingly, so the
highest accuracy is available with all protocols: ICMP Timestamp, NTP/TIME and
UDP/TIME without special addressing. The highest accuracy is available using
ICMP Timestamp, then the other two protocols in order. We estimate the
accuracy using ICMP Timestamp protocol to be better than +-10 milliseconds.

Note that UMD1.ARPA is normally reachable via MILNET paths (MARYLAND gateway),
while DCN1.ARPA and FORD1.ARPA are normally reachable via ARPANET paths
(DCN-GATEWAY). In any conceivable experiment involving nontrivial network
paths, the measurement errors due to these hosts or clocks should be
negligible. Under normal conditions, the clocks operate independently;
however, in case of failure, each clock is backed up by one of the others
using local-net paths. In other words, the service should be very reliable,
but with no protection at the moment against clocks that are operating but
indicate the wrong time.

The present configuration invites some interesting experiments which might
shed light on present ARPANET/MILNET network performance. You are welcome to
scheme such things, especially if you report your findings; however, we would
very much like you to avoid TCP/TIME and also limit the barrage to the above
hosts while avoiding our other timeteller fuzzthings, which use one of the
above hosts for timetelling anyway. However, the incurably curious and
persistent can still find the WWV clocks at their previously announced
addresses.

Dave
-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:04 GMT