In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>
>I tried a number of different NTP servers (from the global pool, as
>well as from my company's internal server).  It appears that I am
>sending and getting responses from the servers, but my NTP client is
>rejecting them for some reason.  Here is some pertinent output from my
>ntpq:
>
>ntpq> pe
>     remote           refid      st t when poll reach   delay   offset
>jitter
>==============================================================================
> 172.16.2.2      66.229.200.200   2 u   30   64  377   71.722  -6522.1
>1638.79

>ntpq> rv 27340
>assID=27340 status=9014 reach, conf, 1 event, event_reach,
>srcadr=172.16.2.2, srcport=123, dstadr=10.0.0.2, dstport=123, leap=01,
>stratum=2, precision=-18, rootdelay=19.928, rootdispersion=70.419,
>refid=66.229.200.200, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6,
>ppoll=6, flash=00 ok, keyid=0, ttl=0, offset=-6522.145, delay=71.722,
>dispersion=2.130, jitter=1638.794,
>reftime=c8444eb8.dd4ca925  Wed, Jun 21 2006 13:03:20.864,
>org=c84456b0.9a19b90e  Wed, Jun 21 2006 13:37:20.601,
>rec=c84456b7.8e9728a6  Wed, Jun 21 2006 13:37:27.556,
>xmt=c84456b7.7b0da5da  Wed, Jun 21 2006 13:37:27.480,
>filtdelay=    76.28   71.72   74.80   72.46   72.35  117.00  101.90
>108.72,
>filtoffset= -6916.9 -6522.1 -6123.9 -5652.6 -5168.1 -4737.3 -4291.7
>-3740.8,
>filtdisp=      0.01    1.00    1.96    2.95    3.91    4.85    5.80
>6.79

The list of "filtoffset" values (same as you would see as 'offset' in
64-second-spaced runs of 'ntpq -p') shows that your host is running away
from the one at 172.16.2.2 with something like 7000+ ppm, or ~ 10
minutes per day. This is way outside what ntpd can correct for (limit is
500 ppm), at best you will see the clock being stepped back repeatedly.
>From this single sample it could be thought that it was actually
172.16.2.2 falling behind, but your other posts indicate that it is
server-independant.

I believe this is also way too much to simply be a "bad clock", and
since it is running fast, it can't be due to lost timer interrupts.
Maybe there are BIOS settings that can cause this, I've seen hints to
that effect in other threads, but I have no persoal experience with
that. Just thought I should point out this obvious problem since it
seems to have been overlooked by others commenting...

--Per Hedeland
[EMAIL PROTECTED]

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions

Reply via email to