[ntp:questions] ntpd service doesn't connect to remote servers on Windows XP
Richard B. Gilbert
rgilbert88 at comcast.net
Wed Apr 1 22:31:22 UTC 2009
David J Taylor wrote:
> David J Taylor wrote:
>> Heiko Gerstung wrote:
>>> Can you try to run ntpdate -q <IP of remote server> on the machine
>>> and check if that works? If not, try ntpdate -qu <IP> to use an
>>> unprivileged port. You would need to stop the NTP service on that
>>> machine first (net stop ntp).
>> E:\NTP\bin>ntpdate -q 22.214.171.124
>> server 126.96.36.199, stratum 3, offset 6.949179, delay 0.05679
>> 1 Apr 16:01:27 ntpdate: step time server 188.8.131.52 offset
>> 6.949179 sec
>> E:\NTP\bin>ntpdate -qu 184.108.40.206
>> server 220.127.116.11, stratum 3, offset 6.955597, delay 0.05684
>> 1 Apr 16:02:15 ntpdate: step time server 18.104.22.168 offset
>> 6.955597 sec
>> I see that the error is quite large at 6.9 seconds, but I thought that
>> ntpd would see that, and step the clock when it is first run? Both
>> the -q and -qu versions worked correctly, I believe.
>>> It could be helpful to see the output of "ntpq -p" and "ntpq -c rv
>>> <id>" where <id> is the association ID of one of the remote servers.
>>> This id can be found out using "ntpq -c as" .. and yes, the event log
>>> would be helpful as well.
>>> Best Regards,
>> There was an error in the user typing the ntpq -c "rv 12345" as they
>> missed off the quotation marks. I've asked for this information
>> again. However, the ntpq -c as worked:
>> E:\NTP\bin>ntpq -c as
>> ind assID status conf reach auth condition last_event cnt
>> 1 13978 8000 yes yes none reject
>> 2 13979 8000 yes yes none reject
>> 3 13980 8000 yes yes none reject
>> 4 13981 8000 yes yes none reject
>> 5 13982 8000 yes yes none reject
>> I'm guessing that the reject is because of the 7 second error,
>> although I'm uncertain about this. Would I expect to see last event
>> as "reachable" rather than blank?
>> Puzzled of Edinburgh!
> ... and more info:
> E:\NTP\bin>ntpq -c as
> ind assID status conf reach auth condition last_event cnt
> 1 22554 8000 yes yes none reject
> 2 22555 8000 yes yes none reject
> 3 22556 8000 yes yes none reject
> 4 22557 8000 yes yes none reject
> 5 22558 8000 yes yes none reject
> I then tried ntpq -c "rv 22554" here's the result of that
> E:\NTP\bin>ntpq -c "rv 22554"
> assID=22554 status=8000 unreach, conf, no events,
> srcadr=eu1.develooper.com, srcport=123, dstadr=192.168.1.10,
> dstport=123, leap=11, stratum=16, precision=-20, rootdelay=0.000,
> rootdispersion=0.000, refid=INIT, reach=000, unreach=7, hmode=3,
> pmode=0, hpoll=6, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=0.000,
> delay=0.000, dispersion=15937.500, jitter=0.000,
> reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
> org=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
> rec=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
> xmt=cd7e23f5.f65dc9b7 Wed, Apr 1 2009 18:33:41.962,
> 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= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
> I feel that leave me where I started - ntpq -p <remote> works, but ntpd
> does not. Oh, and that ntpd thinks it is sending packets.....
> Any help welcome.
Have you tried "ntpd -g"? That should take care of your offset and give
ntpd a chance to maintain the correct time. Let it run for a day or
two and try "ntpq -p". On a "cold" start, ntpd will need at least 24
hours to beat your clock into submission.
More information about the questions