On 2007-11-06T09:53:13, Alan Robertson [EMAIL PROTECTED] wrote:
Cutting out that debug should be OK - or raising it to happen if debug is
1 would probably also be OK. If you're seeing this happen a lot, that's
not a good thing. Getting behind 200 messages seems like a lot to me - off
Lars Marowsky-Bree wrote:
On 2007-10-25T16:25:30, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
http://hg.linux-ha.org/dev/rev/69f0395c2ead seems to fix some of this
for me.
BTW, I was able to conclude a 100 cycle run with that patch applied on 7
nodes, and absolutely not a single BadNews,
Hi all,
on my 7 node cluster, I see the occasional - every 5-10 tests - bunch of
messages dropped during a burst; usually on the DC (what a surprise), on
the order of ~200 messages dropped per incident.
This occurs only with debug 1, and only above 5 nodes or so.
So yes, my cluster is fully
Hi,
On Thu, Oct 25, 2007 at 12:59:14PM +0200, Lars Marowsky-Bree wrote:
Hi all,
on my 7 node cluster, I see the occasional - every 5-10 tests - bunch of
messages dropped during a burst; usually on the DC (what a surprise), on
the order of ~200 messages dropped per incident.
This occurs
On 2007-10-25T13:11:56, Dejan Muhamedagic [EMAIL PROTECTED] wrote:
The network is fully virtual, so I can't be hitting that limit.
Probably your xen is better than mine. Here I have a transfer
rate (guest to host) at times around 10mbit.
Paravirtualized is quite fast. I also don't connect my
On 2007-10-25T16:25:30, Lars Marowsky-Bree [EMAIL PROTECTED] wrote:
http://hg.linux-ha.org/dev/rev/69f0395c2ead seems to fix some of this
for me.
BTW, I was able to conclude a 100 cycle run with that patch applied on 7
nodes, and absolutely not a single BadNews, which is a first.
Regards,
On 2007-10-25T19:39:23, Dejan Muhamedagic [EMAIL PROTECTED] wrote:
Probably this means that MAXMISSING and FLOWCONTROL_LIMIT might require
tuning.
Since both directly depend on MAXMSGHIST, I guess that it should
be OK as it is.
Exactly why. Those thresholds depend on a compile-time choice,
