[ntp:questions] Troubleshooting who's at fault

Ronaldo Mexico ronaldo.hawk.mexico at gmail.com
Thu Jun 25 15:57:23 UTC 2009


Replies to David Woolley:

> This is pretty much a worst case configuration.  Drop the local clock,
> or add enough real servers to outvote it.  However, I don't think that
> would produce a reject status.  There is an aberration in most ntpd
> based packages that they contain a local clock pseudo clock driver, when
> this should be an opt in for people who understand the tradeoffs.  It
> should never be configured on a leaf node, as it serves no purpose
> except confusion.

In the system I'm configuring, we have a real time source (the PTS,
sync'd via GPS to an authentic time source) and for the extreme backup
case (physical failure), the local clock.
Steps were taken (fudge 10) to make sure the local clock is only
chosen in the worst-case scenario.  Even if I remove the local clock
(127.127.1.0), it'll still never sync to the only choice it has (the
PTS).

> >   2 62826  9014   yes   yes  none    reject   reachable  1
>
> rv 62826
>
> will tell you why it is being rejected.  

Unfortnately, I can't read the output to figure it out:

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 62339  9614   yes   yes  none  sys.peer   reachable  1  (local
clock)
  2 62340  9014   yes   yes  none    reject   reachable  1     (PTS)
ntpq> rv 62340
assID=62340 status=9014 reach, conf, 1 event, event_reach,
srcadr=ntp, srcport=123, dstadr=147.159.120.206, dstport=123, leap=00,
stratum=2, precision=-20, rootdelay=0.000, rootdispersion=0.000,
refid=LOCAL(0), reach=377, unreach=0, hmode=3, pmode=4, hpoll=7,
ppoll=7, flash=800 peer_loop, keyid=0, ttl=0, offset=-5.276,
delay=0.758, dispersion=4.149, jitter=9.096,
reftime=cdee1b0c.00000000  Thu, Jun 25 2009 15:49:32.000,
org=cdee1b0d.0869d4a6  Thu, Jun 25 2009 15:49:33.032,
rec=cdee1b0d.0b554347  Thu, Jun 25 2009 15:49:33.044,
xmt=cdee1b0d.037abdce  Thu, Jun 25 2009 15:49:33.013,
filtdelay=    29.71    0.78    0.78    0.76   45.74    0.76    0.77
0.80,
filtoffset=    3.45   -9.86   -8.71   -7.56   16.14   -5.28   -4.14
-3.00,
filtdisp=      0.00    0.95    1.94    2.91    3.90    4.85    5.81
6.78
ntpq> rv 62339
assID=62339 status=9614 reach, conf, sel_sys.peer, 1 event,
event_reach,
srcadr=LOCAL(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00,
stratum=10, precision=-20, rootdelay=0.000, rootdispersion=10.000,
refid=LOCL, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=10,
flash=00 ok, keyid=0, ttl=0, offset=0.000, delay=0.000,
dispersion=0.933, jitter=0.001,
reftime=cdee1b2f.02ba5766  Thu, Jun 25 2009 15:50:07.010,
org=cdee1b2f.02ba5766  Thu, Jun 25 2009 15:50:07.010,
rec=cdee1b2f.02ba848c  Thu, Jun 25 2009 15:50:07.010,
xmt=cdee1b2f.02ba35c9  Thu, Jun 25 2009 15:50:07.010,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00
0.00,
filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00
0.00,
filtdisp=      0.00    0.95    1.94    2.93    3.92    4.89    5.88
6.84

>However, when you said various
> Windows systems worked, did you mean ntpd on Windows or w32time.  By
> default, and in some cases, without choice, w32time will synchronise to
> servers that are  broken in a Windowsy way, or which having been running
> unsynchronised for too long for the real protocol to tolerate them.

Hmm, that's a good question.  I'm using Windows XP and set the ntp
server based on the Date and Time Properties --> Internet Time.  I
have no idea if it's being governed by the w32time service.




More information about the questions mailing list