Dave Close wrote: > David Woolley <[EMAIL PROTECTED]> writes: > >> Dave Close wrote: > >>> What I haven't found while reading is how it is possible for a server to >>> be both reachable and rejected. Note that the reject condition is not > >> That's quite easy, but I can't see a case which applies here (using a >> not recently synchronised w32time server (NAT would make no difference), >> kiss of death because of the excess query rate from the router (I think >> the refid would be special); the two servers have error bands that do >> not overlap (I can't remember whether this would produce a special flag >> in the ntpq output)) > >>> constant; the servers are accepted occasionally, but not for very long. > >> That does sound like kiss of death, except for the refid. > >> What would help is the result of running rv against each association ID, >> to get the detailed state for the association. > > Ok, here goes. I hope this means something to someone else... > > # ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > server1 172.16.2.5 2 u 24 64 377 2.159 -51835. 8.729 > server2 172.16.2.5 2 u 46 64 377 2.200 -51822. 19.581 > # ntpq -c as > ind assID status conf reach auth condition last_event cnt > =========================================================== > 1 20192 9024 yes yes none reject reachable 2 > 2 20193 9024 yes yes none reject reachable 2 > # ntpq > ntpq> rv 20192 > assID=20192 status=9024 reach, conf, 2 events, event_reach, > srcadr=taus-idc2.dom1.taus.us.thales, srcport=123, > dstadr=192.168.58.250, dstport=123, leap=00, stratum=2, precision=-7, > rootdelay=0.000, rootdispersion=14089.050, refid=172.16.2.5, reach=377, > unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, > keyid=0, ttl=0, offset=-51835.943, delay=2.159, dispersion=9.549, > jitter=10.021, reftime=cc74ddf3.bd083558 Fri, Sep 12 2008 5:24:19.738, > org=cc754432.c147ae14 Fri, Sep 12 2008 12:40:34.755, > rec=cc754466.9b66e174 Fri, Sep 12 2008 12:41:26.607, > xmt=cc754466.9ad85a70 Fri, Sep 12 2008 12:41:26.604, > filtdelay= 2.17 2.20 2.16 3.68 4.14 2.25 4.47 2.24, > filtoffset= -51850. -51846. -51835. -51848. -51831. -51832. -51829. -51846., > filtdisp= 7.81 8.80 9.75 10.72 11.70 12.66 13.65 14.59 > ntpq> rv 20193 > assID=20193 status=9024 reach, conf, 2 events, event_reach, > srcadr=taus-idc1.dom1.taus.us.thales, srcport=123, > dstadr=192.168.58.250, dstport=123, leap=00, stratum=2, precision=-7, > rootdelay=0.000, rootdispersion=14089.630, refid=172.16.2.5, reach=377, > unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, > keyid=0, ttl=0, offset=-51822.970, delay=2.200, dispersion=12.060, > jitter=24.499, reftime=cc7533f1.d8de6ddf Fri, Sep 12 2008 11:31:13.847, > org=cc754459.c0418937 Fri, Sep 12 2008 12:41:13.751, > rec=cc75448d.9bb36a6e Fri, Sep 12 2008 12:42:05.608, > xmt=cc75448d.9b19fbd7 Fri, Sep 12 2008 12:42:05.605, > filtdelay= 2.34 2.64 4.18 3.24 2.71 2.40 2.93 2.20, > filtoffset= -51856. -51847. -51849. -51851. -51844. -51838. -51840. -51822., > filtdisp= 7.81 8.76 9.72 10.69 11.65 12.63 13.59 14.56
The offset is large enough that ntpd would need several DAYS to work it off. Try setting your clock to a reasonable approximation of the correct time before starting ntpd. ntpd -g should do the job if you are running a reasonably recent version. If your version is too old to support -g, then use ntpdate to set the clock before starting ntpd. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
