David J Taylor
david-taylor at blueyonder.co.uk.invalid
Fri Jun 18 15:47:25 UTC 2010
"Ryan Malayter" <malayter at gmail.com> wrote in message
news:AANLkTik-L6S7b-XeCtEbAmfTt8V3Y3-9dUWYCKt4IWTV at mail.gmail.com...
> On Fri, Jun 18, 2010 at 5:34 AM, David J Taylor
> <david-taylor at blueyonder.co.uk.invalid> wrote:
>> versions (Server 2003 and later, I believe) had more NTP-like
>> behaviour, but
>> did not conform to the management protocols of NTP (so you can't check
>> offset), didn't use ntp.conf, couldn't be used as ref-clocks, and
>> didn't conform in dozens of other respects.
> None of these items are required parts of the NTP proptocol defined in
> RFC 1305, so you cannot really fault Microsoft for not implementing
> them. In fact, the only thing you mention even in present in the RFC
> are NTP mode 6 control packets as part of Appendix B, and they are
> very much optional. The RFC even specifically advises that they *not*
> be used when other out-of-band management means are available (which
> they are in Windows):
> "Ordinarily, these functions can be implemented using a
> network-management protocol such as SNMP and suitable extensions to the
> MIB database. However, in those cases where such facilities are not
> available, these functions can be implemented using special NTP control
> messages described herein."
> The configuration file format, reference clock support, etc. are
> totally implementation-specific and not part of any standard. Making
> an RFC-compliant NTP implementation does *not* mean "rewrite the
> reference implementation, including all of its design decisions and
Thanks for your observations, Ryan. The earlier implementations right up
to Windows XP were not NTP, only SNTP.
As to the later versions, you may, or may not, be correct by the letter of
the RFC law. Others will have looked in more detail than I have and may
choose to comment.
In practice, in a mixed environment, where other implementations of NTP do
conform to an accepted management standard, having the Microsoft Windows
W32time not conform to the same standard is, at the very least, an
operational inconvenience, and its inability to support reference clocks
forces you into extra hardware, which the reference implementation on
Windows does not. It also makes debugging and fault finding more
difficult, because you don't have a pool of expertise on which to fall
back. For those reasons, I would still recommend the reference NTP over
the Microsoft version.
RFC1305 refers to NTP v3, by the way, but I think most are now on NTP v4.
More information about the questions