[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 129.215.160.240
>> server 129.215.160.240, stratum 3, offset 6.949179, delay 0.05679
>> 1 Apr 16:01:27 ntpdate[744]: step time server 129.215.160.240 offset
>> 6.949179 sec
>>
>> E:\NTP\bin>ntpdate -qu 129.215.160.240
>> server 129.215.160.240, stratum 3, offset 6.955597, delay 0.05684
>> 1 Apr 16:02:15 ntpdate[5612]: step time server 129.215.160.240 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,
>>>   Heiko
>>
>> Heiko,
>>
>> 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!
>>
>> Cheers,
>> David
> 
> ... 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
> 
> E:\NTP\bin>
> 
> 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.
> 
> Thanks,
> David

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 mailing list