davy@itstd.sri.com (07/11/90)
From: Mills@udel.edu
Date: Tue, 3 Jul 90 1:09:22 GMT
Subject: Re: New clock in the world
Notwithstanding all this clap, I have concern about the wwvb huge offset
of many tens of milliseconds relative to its friends, as well as the
humungus dispersion, easily 50 times what I would expect. It is apparent
that either the driver or local-clock machinery is causing rather severe
timewarps. If those warps reach +-128 milliseconds, the effective radiated
chronon flux may well disturb the underlying strata and result in timequake
or worse.
I've noticed this, but usally only after a reboot. For example, I currently
get:
(rem) Address (lcl) Strat Poll Reach Delay Offset Disp
==========================================================================
*0.0.0.0 wildcard 1 64 377 1.0 -10.0 0.0
-apple.com wildcard 1 64 000 27.0 -126.0 64000.0
+clepsydra.dec.c 128.18.4.81 1 1024 377 39.0 -16.0 9.0
+norad.arc.nasa. 128.18.4.81 2 1024 377 20.0 -28.0 7.0
dcn6.udel.edu 128.18.4.81 1 64 145 479.0 6.0 15601.0
which as I understand things is okay. (The offset was something like 4.0
this morning when I logged in... it gets a little worse over the day as
I use the box, and then improves as I sit idle - this will change when the
clock moves to a server later this summer.)
As for the deepening reachability mystery, how do I explain I can ntpdc
wwvb from a net 128.175 host and can telnet to it from a 128.4 host (one
hop further) and even read the time via UDP/TIME from that host, but
have no joy of NTP from the same host? 200-odd other clients don't seem
to have that trouble. I'm getting no NTP replies at all - no recorded
lost packets, not czechsum errors, not broken headers - nuttin.
Beats me... the vagaries of network routing, I guess. I was wondering
if the fact that your subnet number is ".0." had something to do with
it since the RFCs say that's not totally kosher, but I've seen it work
elsewhere, so I can't figure what it'd be messing up....
Late flash: I tried honking wwvb from another 128.4 host and then from
a SESQUINET fuzzball. No honk. Have you nudged the ntpd code other than
the driver? Could there be a version mismatch? Note that the fuzz, as per
spec, use version 2 in configured honks, but respond with the version of
the peer after receiving the first quack from the peer.
I didn't touch any code other than the driver, except to add the two or
three lines to call the driver routines.
--Dave