Re: [ntp:questions] synchronization distance
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
Re: [ntp:questions] synchronization distance
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.
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
Re: [ntp:questions] synchronization distance
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
Re: [ntp:questions] synchronization distance
David Woolley wrote: 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 Also, all I was saying in the beginning is that a likely cause of this symptom is trying to operate a real implementation of NTP in an otherwise pure Windows environment. I wasn't suggesting there was any valid workaround to that case, other than fixing or replacing the upstream servers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] synchronization distance
David Woolley da...@ex.djwhome.demon.invalid wrote in message news:ide3nn$6j...@news.eternal-september.org... [] 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. When I worked in industry this was absolutely not the case. We used a mixture of Microsoft and UNIX systems, according to the particular need of the application. Many of the electronics designers used UNIX systems for CAD, although the mechanical design was largely VMS-based. PCs performed many office tasks, and were moving into the design areas both in their own right and as X-terminals to other systems. Major servers, such as those providing Internet and Intranet facilities tended to be UNIX-based and ran NTP. The PC-server systems all ran official NTP as well - i.e. not Microsoft. I would be surprised if Fortune 500 companies restricted themselves only to Microsoft for their core systems. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] synchronization distance
David J Taylor wrote: of the application. Many of the electronics designers used UNIX systems That makes you unusual for a modern Western company. Most are in financial services or distribution these days. However, even engineering companies can be marketing led, i.e. have senior decisions makers who have no understanding of technology. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] synchronization distance
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
Re: [ntp:questions] synchronization distance
David Woolley da...@ex.djwhome.demon.invalid wrote in message news:idefp2$se...@news.eternal-september.org... David J Taylor wrote: of the application. Many of the electronics designers used UNIX systems That makes you unusual for a modern Western company. Most are in financial services or distribution these days. However, even engineering companies can be marketing led, i.e. have senior decisions makers who have no understanding of technology. OT now but: Do you really think that major financial services or distribution companies are exclusively using Microsoft for their core systems? I am uncertain that's correct. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
