On Tue, Sep 9, 2008 at 2:52 PM, Richard B. Gilbert
[EMAIL PROTECTED] wrote:
FWIW, a system that has been
synchronized by NTP will tend to stay close to the correct time for a
reasonable period of time as long as the environment does not change
significantly. If the network fails AND the air
Danny Mayer wrote:
Kay Hayen wrote:
And iburst and minpoll=maxpoll=5 to improve the results.
This indicates that you don't understand NTP. You should never ever
change the minpoll and maxpoll values unless you understand the NTP
algorithms in detail and understand the consequences of
[EMAIL PROTECTED] (Danny Mayer) writes:
...
Briefly, you use the defaults for MINPOLL and MAXPOLL. You may use the
iburst keyword in a server statement for fast startup. You may use
the burst keyword ONLY with the permission of the the server's owner.
99.99% of NTP installations will work
Kay Hayen wrote:
What worried me more was how often we can query the local ntpd before it will
have an adverse effect. Meantime I somehow I sought to convince me I should
be able to convince myself that ntpq requests are served at a different
priority (other socket) than ntpd requests are.
Steve,
Steve Kostecke wrote:
On 2008-09-08, Martin Burnicki [EMAIL PROTECTED] wrote:
In Kay's original thread Steve Kostecke mentioned he had removed the
moderation bit for Kay, but obviously that did not fully help.
I stated that I released Kay's messages but that I left the moderation
The rules about how often to query a daemon are not all that
complicated. The fact that there ARE rules is due to some history;
google for Netgear Wisconsin for the sordid details. For a second
opinion google for DLink PHK.
There is a good summary at:
NTP server misuse and abuse
Unruh wrote:
Yes, that is with reference to the road. Car three should thus completely
ignore the other two cars and use his speedometer.
Ie, put up a GPS receiver with a PPS and use that as your time source, and
ignore all the other ntp time sources, except perhaps as sanity checks (eg
On 2008-09-09, Martin Burnicki [EMAIL PROTECTED] wrote:
Has the moderation bit for Kay been set because he posted to the questions@
list without having subscribed to the list?
Kay did the right thing and subscribed to the list before posting to it.
Posts from all new subscribers are held for
Uwe Klein [EMAIL PROTECTED] writes:
Unruh wrote:
Yes, that is with reference to the road. Car three should thus completely
ignore the other two cars and use his speedometer.
Ie, put up a GPS receiver with a PPS and use that as your time source, and
ignore all the other ntp time sources,
Unruh wrote:
Uwe Klein [EMAIL PROTECTED] writes:
Unruh wrote:
Yes, that is with reference to the road. Car three should thus completely
ignore the other two cars and use his speedometer.
Ie, put up a GPS receiver with a PPS and use that as your time source, and
ignore all the other ntp
Unruh wrote:
Uwe Klein [EMAIL PROTECTED] writes:
Unruh wrote:
Yes, that is with reference to the road. Car three should thus completely
ignore the other two cars and use his speedometer.
Ie, put up a GPS receiver with a PPS and use that as your time source, and
ignore all the other ntp
Uwe Klein [EMAIL PROTECTED] writes:
Unruh wrote:
Uwe Klein [EMAIL PROTECTED] writes:
Unruh wrote:
Yes, that is with reference to the road. Car three should thus completely
ignore the other two cars and use his speedometer.
Ie, put up a GPS receiver with a PPS and use that as your time
Kay Hayen wrote:
They are owned by the same people who then own installations of our system,
so
that wouldn't be an issue.
You will still have to ensure that they do not enable kiss of death on
those servers. Also you should make sure that they don't try to use
w32time, especially older
David,
David Woolley wrote:
Kay Hayen wrote:
thanks to all who replied. Unfortunately the moderation bit made all of
my last replies expire and instead of reposting them, I choose to sum
things up in a single post.
Expiration is not a moderation thing, it is something done by your
Hello David,
When I say restrict it is our own system that decides that x ms
offset is too bad and prevents ntpd from talking to it any further with a
restrict command. If all 2 servers of an other host are restricted,
it will crash the software.
You are overriding NTP's selection
[EMAIL PROTECTED] (Kay Hayen) writes:
Hello David,
When I say restrict it is our own system that decides that x ms
offset is too bad and prevents ntpd from talking to it any further with a
restrict command. If all 2 servers of an other host are restricted,
it will crash the software.
Unruh wrote:
[EMAIL PROTECTED] (Kay Hayen) writes:
Hello David,
When I say restrict it is our own system that decides that x ms
offset is too bad and prevents ntpd from talking to it any further with a
restrict command. If all 2 servers of an other host are restricted,
it will crash the
Kay Hayen wrote:
Hello David,
When I say restrict it is our own system that decides that x ms
offset is too bad and prevents ntpd from talking to it any further with a
restrict command. If all 2 servers of an other host are restricted,
it will crash the software.
You are overriding NTP's
On 2008-09-08, Martin Burnicki [EMAIL PROTECTED] wrote:
If I understand Kay correctly then the problem is that he responded
via the questions@ list and the moderation bit was set there, which
prevented some of his articles from being gatewayed to the usenet.
When messages are held for
Kay Hayen wrote:
How would it be difference from using the restrict command manually?
Because manual use would normally be based on significant thought and
measurements over an extended period.
And why would it not be NTP?
Because a key part of NTP is the algorithm used to identify and
Richard B. Gilbert [EMAIL PROTECTED] writes:
Unruh wrote:
[EMAIL PROTECTED] (Kay Hayen) writes:
Hello David,
When I say restrict it is our own system that decides that x ms
offset is too bad and prevents ntpd from talking to it any further with a
restrict command. If all 2 servers of an
Hello Mr. Unruh,
What worried me more was how often we can query the local ntpd before it
will have an adverse effect. Meantime I somehow I sought to convince me I
should be able to convince myself that ntpq requests are served at a
different priority (other socket) than ntpd requests
Hello David,
Am Freitag, 5. September 2008 23:50:39 schrieb David Woolley:
Kay Hayen wrote:
External NTPs - 2 entry hosts - 8 other hosts.
And iburst and minpoll=maxpoll=5 to improve the results.
If these External NTPs really are external, i.e. not owned by you, do
not do this without
Kay,
If you use iburst in your config files and have a good value in the
ntp.drift file, ntpd should sync up and be ready to go in about 11 seconds.
Please see:
https://support.ntp.org/bin/view/Support/ConfiguringNTP
and
https://support.ntp.org/bin/view/Support/StartingNTP
--
Harlan Stenn
Hello Harlan,
you wrote:
If you use iburst in your config files and have a good value in the
ntp.drift file, ntpd should sync up and be ready to go in about 11 seconds.
Please see:
https://support.ntp.org/bin/view/Support/ConfiguringNTP
and
Harlan Stenn wrote:
If you use iburst in your config files and have a good value in the
ntp.drift file, ntpd should sync up and be ready to go in about 11 seconds.
It may be in error by up to 128ms under these circumstances, which will
take an hour or so to correct, during which there will
Hello David,
Am Sonntag, 7. September 2008 10:36:35 schrieb David Woolley:
Kay Hayen wrote:
We could alternatively want to change ntpd in a way that the iburst lasts
until a sufficient synchronization was achieved. But it appears to be
more simply to delay the iburst by delaying the ntpd
In article [EMAIL PROTECTED], David Woolley [EMAIL PROTECTED] writes:
David Harlan Stenn wrote:
If you use iburst in your config files and have a good value in the
ntp.drift file, ntpd should sync up and be ready to go in about 11
seconds.
David It may be in error by up to 128ms under these
Hello,
Now speaking about our system, not the middleware, with connections as
follows:
External NTPs - 2 entry hosts - 8 other hosts.
What do you mean by entry hosts?
From our 10 machines, only 2 have connection to the external NTP servers.
The entry hosts are these and servers of the
Hello,
thanks to all who replied. Unfortunately the moderation bit made all of my
last replies expire and instead of reposting them, I choose to sum things up
in a single post.
The original question was answered. What I really wanted was a libntpq anyway,
and Heiko has already contributed a
Kay Hayen wrote:
Hello,
thanks to all who replied. Unfortunately the moderation bit made all of my
last replies expire and instead of reposting them, I choose to sum things up
in a single post.
snip
5. The NTP rules about how often to query a daemon. I have tried to read up
about it,
Kay Hayen wrote:
Hello Richard,
you wrote:
The rules about how often to query a daemon are not all that
complicated. The fact that there ARE rules is due to some history;
google for Netgear Wisconsin for the sordid details. For a second
opinion google for DLink PHK.
Fascinating
Kay,
I think most of your questions are answered at:
http://support.ntp.org/Support
I'd also be happy to discuss with you or anybody else at your company how
membership in the NTP Forum would be of benefit.
--
Harlan Stenn [EMAIL PROTECTED]
http://ntpforum.isc.org - be a member!
Kay Hayen wrote:
External NTPs - 2 entry hosts - 8 other hosts.
And iburst and minpoll=maxpoll=5 to improve the results.
If these External NTPs really are external, i.e. not owned by you, do
not do this without explicit permission from their owners. There is a
real risk of
[EMAIL PROTECTED] (Kay Hayen) writes:
Hello Richard,
you wrote:
The rules about how often to query a daemon are not all that
complicated. The fact that there ARE rules is due to some history;
google for Netgear Wisconsin for the sordid details. For a second
opinion google for DLink PHK.
Richard B. Gilbert [EMAIL PROTECTED] writes:
Kay Hayen wrote:
Hello Richard,
you wrote:
The rules about how often to query a daemon are not all that
complicated. The fact that there ARE rules is due to some history;
google for Netgear Wisconsin for the sordid details. For a second
36 matches
Mail list logo
