On Sep 25, 10:33 pm, [EMAIL PROTECTED] (Danny Mayer) wrote: > Ryan Malayter wrote: > > You can also just mointor from the Windows client, and run the built > > in windows command 'w32tm' in a loop in a batch file and record the > > results for later analysis, but I have no idea how good the data would > > actually be: > > C:\>w32tm /monitor /computers:0.us.pool.ntp.org > > 0.us.pool.ntp.org [155.97.17.169]: > > ICMP: 50ms delay. > > NTP: +0.0102014s offset from local clock > > RefID: time-b.utah.edu [155.97.154.154] > > This doesn't make a lot of sense. ICMP is a protocol which NTP doesn't > use. It uses UDP instead. RefID is incorrect. The RefID is > 155.97.154.154. You cannot do a reverse lookup on it as if it were an IP > address. It isn't, even though it makes use of the IP address for loop > prevention/mitigation. > > You have no information on the accuracy of the offset and for that > matter it's not clear what the "ICMP" delay means.
It's just the millisecond value of an ICMP ping roundtrip. Why Microsoft doesn't measure this from the ntp packets driectly I don't know. It is potentially useful diagnostic information - if you get no NTP response, but you do get an ICMP ping response, you know that the server isn't dead, it just isn't listening on UDP port 123. Please note that w32tm is a command-line utility for monitoring and configuring the w32time service. It is not the service itself. It's really something more like ntpq (with a lot less functionality). > w32time takes the > value handed to it and assumes that it's correct and makes no judgement > calls on the quality of the data. That is only true if w32time is configured with a single source server. At least in Windows 2003 SP1 and later, w32time does perform clock selection when multiple NTP servers are specified. I'm sure the algorithms are not the same as those in ntpd, nor as robust. But it does seem to protect against a failing and/or insane server in my limited testing. When a different server is selected by the service for some reason, an entry is made into the Windows Event viewer. That is the only diagnostic information related to w32time's clock selection that I have found. Not terribly useful, but it does show that the service has some clock-selection magic going on. > it was 5 minutes off, how would you tell? Yes, you can compare it to > other ntp servers but then you might as well just use ntp and ignore > w32time. Evandro is getting erratic behavior from the Meinberg packaging of ntpd, but not from w32time. Which is why he's trying to use tools besides ntpd to figure out what's going on. ISC's ntpd is indeed the reference implementation, but it is not the only implementation of the NTP protocol. While it is standard on most POSIX platforms, it doesn't support other platforms all that well. So other implementations of the (S)NTP protocol exist. This newsgroup has also seen plenty of discussions around Cisco's implementation, those in appliances, and OpenNTP. This makes sense to me, as the group is called "comp.PROTOCOLS.time.ntp", not "comp.software.isc.ntpd". "Use ISC's ntpd" is not always the best answer in every situation. -- RPM _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
