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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
