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