[ntp:questions] Syncing to nearby vs. faraway servers

Dave Hart davehart at gmail.com
Tue Jun 16 18:29:17 UTC 2009


> 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.2.0 at 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.5p181 at 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



More information about the questions mailing list