On Nov 14, 2007 10:17 AM, Brad Penoff wrote:
>
> On Nov 14, 2007 5:11 AM, Terry Dontje wrote:
> >
> > Brad Penoff wrote:
> > > On Nov 12, 2007 3:26 AM, Jeff Squyres wrote:
> > >
> > >> I have no objections to bringing this into the trunk, but I agree that
> > >> an .ompi_ignore is probably a goo
If there is no objection I will commit this to the trunk next week.
On Sun, Dec 09, 2007 at 05:34:30PM +0200, Gleb Natapov wrote:
> Hi,
>
> Currently BTL has parameter btl_min_send_size that is no longer used.
> I want to change it to be btl_rndv_eager_limit. This new parameter will
> determine
On Fri, Dec 14, 2007 at 06:53:55AM -0500, Richard Graham wrote:
> If you have positive confirmation that such things have happened, this will
> go a long way.
I instrumented the code to log all kind of info about fragment reordering while
I chased a bug in openib that caused matching logic to malfu
We recently put in a feature on the trunk to put in ident strings in
the 3 OMPI libraries.
Short version:
--
We use "#ident foo" for GNU, but it emits a stderr warning that it's a
GCC extension when used with -pedantic (we check that #ident works in
configure). Does anyone car
This commit does what we previously discussed: it only compiles the
XOOB openib CPC if XRC support is actually present (vs. having a stub
XOOB when XRC is not present). This is on the /tmp-public/openib-cpc
branch.
I have some hermon hca's, but due to dumb issues, I don't have XRC-
capabl
On Fri, 14 Dec 2007, Adrian Knoth wrote:
Should we consider moving towards these mapped addresses? The
implications:
- less code, only one socket to handle
- better FD consumption
- breaks WinXP support, but not Vista/Longhorn or later
- requires non-default kernel runtime setting on Op
Hi!
The current BTL/TCP and OOB/TCP code contains separate sockets for IPv4
and IPv6. Though it has never been a problem for me, this might cause an
out-of-FDs-error in large clusters. (IIRC, rhc has already pointed out
this issue)
A possible way to reduce FD consumption would be the use of IPv4
If you have positive confirmation that such things have happened, this will
go a long way. I will not trust the code until this has also been done with
multiple independent network paths. I very rarely express such strong
opinions, even if I don't agree with what is being done, but this is the
co
On Thu, Dec 13, 2007 at 06:16:49PM -0500, Richard Graham wrote:
> The situation that needs to be triggered, just as George has mentions, is
> where we have a lot of unexpected messages, to make sure that when one that
> we can match against comes in, all the unexpected messages that can be
> matche
