Re: correct NTP-configuration for combined Microsoft ADS- and UNIX/Linux-environment

Richard B. Gilbert wrote:
It may also be worth noting that Windows does not use NTP software;
Microsoft supplies a broken implementation of SNTP called W32TIME. NTP
software is available for Windows if you wish to download and install it

Windows 2003 Standard Server with Service Pack 1 seems to have a much
better "almost real" NTP service. It's not just SNTP anymore. I've been
testing it compared with NTPv4 for a few weeks now, but I haven't had a
chance to do a full write up yet.

Here's a quick outline of the results, when Win2003sp1 or R2 is
compared with NTPv4 running against the same set of Stratum-1s from the
same network:
- it keeps reasonable average offsets with NTPv4 at stratum 2 for at
least a week (my test length)
- it selects its reference clocks roughly the same as NTPv4, usually
hopping to a new reference server a few minutes ahead or behind NTPv4
as network conditions warrant
- it polls servers at similar intervals to NTPv4
- it advertises stratum and reference ID correctly (tested with
stratum 1 & 2 servers)

The big caveat: Windows 2003 SP1 time service only advertises -6
precision in its packets, and unfortunately, this claimed precision
seems about right. On the graphs I've made so far, it looks like it
steps the clock in ~10 ms increments rather infrequently. The result is
a far higher jitter than you would see with NTPv4, although the offsets
are almost always within 20 ms of UTC, and a moving average is within a
couple of ms of NTPv4's offset moving average.

Basically, I'd say that w32time in Windows 2003 SP1 and R2 is
definitely more RFC-compliant than the SNTP service in previous
Microsoft offerings. It is usable for many applications, but still of
course not nearly as good as the full NTPv4.

Regards,
Ryan

.

Relevant Pages

  • Re: synchronization distance
    ... In any case, Windows NTP (not NTPv4 running in Windows) is cheerfully ignorant of most NTP parameters, including synchronization distance, and that is peachy keen as long as the users are satisfied. ... "default configuration" was talking about w32time. ... I think, if it has ever been synchronised, it will continue to report an increasing root dispersion and stratum 2, even if it never gets any more updates. ...
    (comp.protocols.time.ntp)
  • Re: synchronization distance
    ... It happens to use the NTP packet header format, but is not otherwise compliant with the NTPv4 specification, especially the 36-h poll interval limitation, which is an engineering parameter based on the expected wander of a commodity crystal oscillator. ... All that doesn't matter at all, other than Windows servers are compatible with Windows clients. ... What does matter is that Windows servers are NOT compatible with NTPv4 clients, ... David Woolley wrote: ...
    (comp.protocols.time.ntp)
  • Re: synchronization distance
    ... It happens to use the NTP packet header format, but is not otherwise compliant with the NTPv4 specification, especially the 36-h poll interval limitation, which is an engineering parameter based on the expected wander of a commodity crystal oscillator. ... All that doesn't matter at all, other than Windows servers are compatible with Windows clients. ... What does matter is that Windows servers are NOT compatible with NTPv4 clients, ... Corporate politics are such that it is difficult to get a Unix system, or even Windows running the reference version, near the root of the time distribution tree. ...
    (comp.protocols.time.ntp)
  • Re: synchronization distance
    ... there are complaints NTPv4 does not play nicely with Microsoft. ... NTPv4 is not about to change; however, there is a minor configuration option that makes NTPv4 work almost as well or maybe worse than SNTP. ... All that doesn't matter at all, other than Windows servers are compatible with Windows clients. ... What does matter is that Windows servers are NOT compatible with NTPv4 clients, ...
    (comp.protocols.time.ntp)
  • SNTPv4 Client Vs NTPv4 Server
    ... Can we expect the same while we move to NTPv4. ... same SNTPv4 client sync to a server that gets upgraded to NTPv4. ... Or not even able to find an sntp package. ...
    (comp.protocols.time.ntp)