> As for grandfather's two stratum-1 backup servers, here's the current
> info on bigben.cac.washington.edu:
>
> ntpq> host
> current host is bigben.cac.washington.edu
> ntpq> peers
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *GPS_VME(0) .USNO. 0 l 9 16 377 0.000 -0.014 0.058
> 192.5.40.40 .INIT. 16 u - 1024 0 0.000 0.000 4000.00
> 204.34.198.40 .INIT. 16 u 26h 1024 0 0.000 0.000 4000.00
> ntpq> rl 0
> associd=0 status=0444 leap_none, sync_uhf_radio, 4 events, freq_mode,
> version="ntpd 4....@1.1161-r Tue Mar 23 22:34:33 UTC 2004 (19)",
> processor="9000/800", system="HP-UX/B.11.11", leap=00, stratum=1,
> precision=-18, rootdelay=0.000, rootdispersion=0.643, peer=25020,
> refid=USNO, reftime=cde2500a.4f0dec40 Tue, Jun 16 2009 10:08:26.308,
> poll=4, clock=cde2500d.8a678bfe Tue, Jun 16 2009 10:08:29.540, state=4,
> offset=-0.028, frequency=-38.586, jitter=0.043, stability=0.001,
> hostname="bigben", signature="md5WithRSAEncryption", flags=0x80001,
> hostkey=3279293228, refresh=3454105890
>
> I note that both grandfather.stanford.edu and bigben.cac.washington.edu
> seem to be on good terms with their respective reference clocks, and
> yet Stanford is seeing a significant offset w/r/t Washington right now.
Another perspective on bigben.cac.washington.edu (some associations
elided for brevity):
C:\NTPb\bin>ntpq -p -crv ntp.davehart.net
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.5p...@1.1884-o Jun 16 6:43:12.67 (UTC-00:00) 2009 (1)",
processor="x86", system="Windows", leap=00, stratum=1, precision=-19,
rootdelay=0.000, rootdisp=0.458, refid=kPPS,
reftime=cde26107.c6915af4 Tue, Jun 16 2009 18:20:55.775,
clock=cde26116.70129ab2 Tue, Jun 16 2009 18:21:10.437, peer=21579,
tc=4, mintc=3, offset=0.012, frequency=-22.794, sys_jitter=0.003,
clk_jitter=0.003, clk_wander=0.000
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(1) .kGPS. 0 l 15 16 377 0.000 -0.034 0.004
oPPS(1) .kPPS. 0 l 15 16 377 0.000 0.012 0.003
-ntp3.isc.org 204.152.187.43 2 u 9 64 377 47.429 0.203 0.128
-clock.via.net .GPS. 1 u 47 128 377 45.268 0.843 11.658
+usno.pa-x.dec.c .USNO. 1 u 7 128 377 46.733 -0.435 1.508
-clepsydra.dec.c .GPS. 1 u 27 128 377 45.070 0.048 0.135
-montpelier.ilan .USNO. 1 u 5 128 377 57.099 2.170 0.722
-tick.ucla.edu .GPS. 1 u 45 128 377 54.166 0.892 16.096
#bigben.cac.wash .USNO. 1 u 5 128 377 53.234 -12.807 0.436
-time-nw.nist.go .ACTS. 1 u 95 128 377 24.547 2.266 0.290
My association with ntp3.isc.org is using interleaved mode, and so
should be correcting for asymmetric delays. As you can see, bigben is
on the order of 10ms off from the consensus, at least from
ntp.davehart.net's perspective on a verizon business-class DSL. I had
also considered that the offset could be due to asymmetric routing,
but given the same ~10ms offset seen from Stanford, and that bigben's
backup sources are .INIT., I'm guessing bigben's clock-winder has left
the building.
Cheers,
Dave Hart
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
