David,
I'm not learning anything at all in our exchange, and that is a real
disappointment. Apparently, there are complaints NTPv4 does not play
nicely with Microsoft. Microsoft is not about to change. 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. Whether this
is good or bad corporate practice is not based on sound engineering
principles, but on corporate convenience. I see absolutely no need to
care about that or especially to prolong this discussion.
Dave
David Woolley wrote:
David L. Mills wrote:
David,
I'm not making myself absolutely crystal clear and you are obscuring
the point.
Windows has an awesome protocol that sets the time. 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,
which SHOULD NOT BE USED. Use one of the SNTP variants instead.
To a large extent I would agree with you, but the net effect of this
is to say "if you work for a marketing led company (probably true of
most of the Fortune 500), do not use NTP as it is almost certain that
your IT department has a strict Microsoft policy for their core
systems, and are not time synchronisation experts".
As a diehard workaround, use the tos maxdist command to set the
distance threshold to something really high, like ten seconds. There
is nothing whatsoever to be gained by this, as the expected error
with update intervals of a week will be as bad or worse than with SNTP..
Dave
David Woolley wrote:
David L. Mills wrote:
BlackList,
I say again with considerable emphasis: this is a Microsoft
product, not the NTPv4 distribution that leaves here. What you see
is what you get,
But it is often NTPv4 reference version that is used as the client
and fails to synchronize because the root dispersion is too high.
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. People deeper in the tree then see
the effects, even if they are using the reference implementation.
warts and all. I doubt it has anything to do with root distance, or
any other public specification, but that doesn't make any
difference if the customer is satisfied with the performance. Just
don't compare it with anything in the NTP distribution,
documentation or specification.
Dave
E-Mail Sent to this address will be added to the BlackLists wrote:
David L. Mills wrote:
I had no idea somebody would try to configure current
NTPv4 with a poll interval of a week.
The current maximum allowed is 36 h.
<http://technet.microsoft.com/en-us/library/cc773263%28WS.10%29.aspx>
<BlockQuote>
SpecialPollInterval
This entry specifies the special poll interval in seconds
for manual peers. ...
The default value on stand-alone clients and servers is 604,800.
</BlockQuote>
{7 days}
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions