] orphan mode, manycast, and virtualization
unruh un...@invalid.ca wrote:
On 2013-09-09, Horvath Bob-BHORVAT1 bob.horv...@motorolasolutions.com
wrote:
Another question if you guys have the time :),
We situations in which we have almost everything deployed as virtualized
servers running
Horvath Bob-BHORVAT1 bob.horv...@motorolasolutions.com wrote:
Use A. C is horrible, and it is very easy for the VM's to exceed the
500PPM ntpd threshold. And ntpd does a really horrible job of
disciplining a clock that keeps changing and losing time on a short
timescale. It is designed for
Another question if you guys have the time :),
We situations in which we have almost everything deployed as virtualized
servers running inside of VMware ESXi.It seems like the recommendation on
time synchronization with ESXi has changed from release to release. It seems
to boil down to
On 2013-09-09, Horvath Bob-BHORVAT1 bob.horv...@motorolasolutions.com wrote:
Another question if you guys have the time :),
We situations in which we have almost everything deployed as virtualized
servers running inside of VMware ESXi.It seems like the recommendation on
time
To: questions@lists.ntp.org
Subject: [ntp:questions] orphan mode, manycast, and virtualization
Another question if you guys have the time :),
We situations in which we have almost everything deployed as virtualized
servers running inside of VMware ESXi.It seems like the recommendation on
time
unruh un...@invalid.ca wrote:
On 2013-09-09, Horvath Bob-BHORVAT1 bob.horv...@motorolasolutions.com wrote:
Another question if you guys have the time :),
We situations in which we have almost everything deployed as virtualized
servers running inside of VMware ESXi.It seems like the
Horvath Bob-BHORVAT1 wrote:
A) Run ntpd on the bare iron at the ESXi layer
and let it change the virtual hardware clock
(without ntpd running on VMs)
B) Run ntpd on the bare iron at the ESXi layer
and let ntpd on the VMs use it as a time source
C) Run ntpd on all the VMs and
Hi,
I am still confused about the proper use of the tos orphan # statement.
Thanks for the replies to my last question and I have read the relevant docs at
ntp.org. I am pretty confident that I understand how to choose an appropriate
orphan stratum. However, I am not 100%, and I have
On 6/1/2011 2:42 PM, Frank Alsop wrote:
Hi,
I am still confused about the proper use of the tos orphan # statement.
Thanks for the replies to my last question and I have read the relevant docs at
ntp.org. I am pretty confident that I understand how to choose an appropriate
orphan stratum.
Richard B. Gilbert wrote:
If you have GPS, a WWV receiver, LORAN or other primary sources of time
I don't understand why you should need or want Orphan Mode!
Because it is important for the machines to track each other when
internet connectivity is lost.
Frank Alsop wrote:
to: A host is enabled for orphan mode using the tos orphan stratum command,
where stratum is some stratum less than 16 and greater than any anticipated
stratum that might occur with configured Internet time servers. I am assuming
This describes the permissible range.
To: questions@lists.ntp.org
Sent: Wed, June 1, 2011 5:26:21 PM
Subject: Re: [ntp:questions] orphan mode
Richard B. Gilbert wrote:
If you have GPS, a WWV receiver, LORAN or other primary sources of time I
don't
understand why you should need or want Orphan Mode!
Because it is important
On May 19, 1:30 pm, Steve Kostecke koste...@ntp.org wrote:
On 2011-05-17, Frank Alsop feal...@yahoo.com wrote:
We have a relatively small network and are trying to use ntp
peering andorphanmodeand I have a couple of questions. I have read
the info
I ended up doing this:
On the local NTP servers A ... F:
###
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict bunch mask 255.255.0.0 nomodify notrap
restrict ofmask 255.255.0.0 nomodify notrap
restrict internal mask
A few local NTP servers, feeding off of the US pool. Multiple clients,
grouped in clusters; it is important that the cluster members stay
synced to each other. I could use ntp-4.2.6p3, but more recent than that
would be problematic.
If the Internet feed goes offline, I want the local NTP
On Thu, May 26, 2011 at 22:04 UTC, Florin Andrei flo...@andrei.myip.org wrote:
It is unclear to me whether tos orphan N needs to have different values
between NTP servers and cluster members. I assumed it needs to be higher for
cluster members.
Only cluster members need orphan mode (for when
On 05/26/2011 04:40 PM, Dave Hart wrote:
On Thu, May 26, 2011 at 22:04 UTC, Florin Andreiflo...@andrei.myip.org wrote:
It is unclear to me whether tos orphan N needs to have different values
between NTP servers and cluster members. I assumed it needs to be higher for
cluster members.
Only
On Fri, May 27, 2011 at 00:28 UTC, Florin Andrei flo...@andrei.myip.org wrote:
But could I use orphan mode on the local NTP servers, with a lower stratum?
The clusters are not the only NTP clients, and I'd like the local NTP
servers to keep some semblance of consistency in case the Internet
Hi,
We have a relatively small network and are trying to use ntp peering and
orphan mode and I have a couple of questions. I have read the info at
http://www.eecis.udel.edu/~mills/ntp/html/orphan.html
but I am having trouble figuring out the correct tos orphan statement we
should use.
We
Instead of using orphan mode you could try to setup local reference clock,
see here http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.htmlThan, It's
not clear why you need orphan mode at all?
In any case you could set orphan
On 2011-05-17, Frank Alsop feal...@yahoo.com wrote:
We have a relatively small network and are trying to use ntp
peering and orphan mode and I have a couple of questions. I have read
the info at http://www.eecis.udel.edu/~mills/ntp/html/orphan.html
That is the documentation for the
Nickolay Orekhov wrote:
Instead of using orphan mode you could try to setup local reference clock,
see here http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html
Orphan mode is an attempt to do time islands properly. The local clock
driver should have been used in hardly any of the
David Woolley wrote:
[EMAIL PROTECTED] wrote:
condition change from sys.peer to reject, status also changed
ntpq -crv 46864
assID=46864 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.200.98.51, srcport=123, dstadr=10.200.98.110, dstport=123,
leap=00, stratum=5, precision=-20,
23 matches
Mail list logo
