On Wed, Oct 24, 2007 at 08:01:44PM -0400, Jeff Squyres wrote:
> My proposal is that the "connect" field can be added to the INI file
> and take a comma-delimited list of values of acceptable CPCs for a
> given device. For example, the ConnectX HCA can take the following
> value:
>
> co
On Oct 25, 2007, at 10:35 AM, Gleb Natapov wrote:
I don't think xrc should be used by default even if HW supports it.
Only if
special config option is set xrc should be attempted.
Why?
And xrc availability
can be tested in runtime without additional options in ini file.
Is there a flag o
On Thu, Oct 25, 2007 at 10:55:25AM -0400, Jeff Squyres wrote:
> On Oct 25, 2007, at 10:35 AM, Gleb Natapov wrote:
>
> > I don't think xrc should be used by default even if HW supports it.
> > Only if
> > special config option is set xrc should be attempted.
>
> Why?
XRC is a crippled RC protoc
Fixed in r16564. Thanks Paul!
On Oct 23, 2007, at 11:02 PM, Paul H. Hargrove wrote:
I was just looking at the Altix timer code in the OMPI trunk and
unless
I am missing something, the fd opened in opal_timer_altix_open() is
never closed. It can be safely closed right after the mmap().
-Pa
Hi Brian,
I have actually created a new MTL, in which I have added heterogeneous
support. To experiment whether CM worked in this environment, I took out
the safeguards that prevented one to use CM in a heterogeneous
environment. Miraculously, things have been working so far. I haven't
examine
I'm surprised that ompi_mtl_datatype_{pack, unpack} are properly handling
the heterogeneous issues - I certainly didn't take that into account when
I wrote them. The CM code has never been audited for heterogeneous
safety, which is why there was protection at that level for not running in
hete
On Oct 25, 2007, at 11:18 AM, Gleb Natapov wrote:
I don't think xrc should be used by default even if HW supports it.
Only if
special config option is set xrc should be attempted.
Why?
XRC is a crippled RC protocol for scalability sake. Its use makes
progress of one process depend on behavio
