Hi,
Seqf bug fixed in r18706.
Best Regards
Lenny.
On Thu, Jun 19, 2008 at 5:37 PM, Lenny Verkhovsky <
lenny.verkhov...@gmail.com> wrote:
> Sorry,
> I checked it without sm.
>
> pls ignore this mail.
>
>
>
> On Thu, Jun 19, 2008 at 4:32 PM, Lenny Verkhovsky <
> lenny.verkhov...@gmail.com> wrote:
>
On Wed, Jun 18, 2008 at 05:13:28PM -0700, Muhammad Atif wrote:
> Hi again... I was on a break from Xensocket stuff This time some
> general questions...
Hi.
> question. What if I have multiple Ethernet cards (say 5) on two of my
> quad core machines. The IP addresses (and the subnets of c
Those who care about the openib BTL:
What do you think about warning when fork() is used with the openib
BTL? See https://svn.open-mpi.org/trac/ompi/ticket/1244 for details.
Rationale: Several Cisco customers have been bitten by not realizing
that they had calls to system() in their MPI co
Should we .ompi_ignore dr?
It's not complete and no one wants to support it. I'm thinking that
we shouldn't even include it in v1.3.
Thoughts?
--
Jeff Squyres
Cisco Systems
Yo all
I've been doing further research into the modex and came across something I
don't fully understand. It seems we have each process insert into the modex
the name of the PML module that it selected. Once the modex has exchanged
that info, it then loops across all procs in the job to check the
Until someone can work on it, sure, ompi_ignore DR sounds right.
Unfortunately, IU may *need* to work on it this fall... hopefully we (I)
will have a new student to help do the work. As for inclusion in 1.3,
I don't think we care.
On Mon, Jun 23, 2008 at 11:01 AM, Jeff Squyres wrote:
> Should we
The first approach sounds fair enough to me. We should avoid 2 and 3
as the pml selection mechanism used to be
more complex before we reduced it to accommodate a major design bug in
the BTL selection process. When using the complete PML selection, BTL
would be initialized several times, leadi
I see in a few places in ob1 we do things like this:
OPAL_THREAD_ADD32(&sendreq->req_state, -1);
Why do we do this? req_state is technically an enum value, so we
shouldn't be adding/subtracting to it (granted, it looks like the enum
values were carefully chosen to allow this). Addition
Since my goal is to eliminate the modex completely for managed
installations, could you give me a brief understanding of this eventual PML
selection logic? It would help to hear an example of how and why different
procs could get different answers - and why we would want to allow them to
do so.
Th
Just because it's volatile doesn't mean that adds are atomic. There's at
least one place in the PML (or used to be) where two threads could
decrement that counter at the same time.
Brian
On Mon, 23 Jun 2008, Jeff Squyres wrote:
I see in a few places in ob1 we do things like this:
OPAL_TH
On Jun 23, 2008, at 3:17 PM, Brian W. Barrett wrote:
Just because it's volatile doesn't mean that adds are atomic.
There's at least one place in the PML (or used to be) where two
threads could decrement that counter at the same time.
With atomics, then both subtracts should occur, right?
The selection code was added because frequently high speed interconnects
fail to initialize properly due to random stuff happening (yes, that's a
horrible statement, but true). We ran into a situation with some really
flaky machines where most of the processes would chose CM, but a couple
woul
On Mon, 23 Jun 2008, Jeff Squyres wrote:
On Jun 23, 2008, at 3:17 PM, Brian W. Barrett wrote:
Just because it's volatile doesn't mean that adds are atomic. There's at
least one place in the PML (or used to be) where two threads could
decrement that counter at the same time.
With atomics, t
My fault - I should be more precise in my language. ;-/
#1 is not adequate, IMHO, as it forces us to -always- do a modex. It seems
to me that a simpler solution to what you describe is for the user to
specify -mca pml ob1, or -mca pml cm. If the latter, then you could deal
with the failed-to-initi
The problem is that we default to OB1, but that's not the right choice for
some platforms (like Pathscale / PSM), where there's a huge performance
hit for using OB1. So we run into a situation where user installs Open
MPI, starts running, gets horrible performance, bad mouths Open MPI, and
now
Okay, so let's explore an alternative that preserves the support you are
seeking for the "ignorant user", but doesn't penalize everyone else. What we
could do is simply set things up so that:
1. if -mca plm xyz is provided, then no modex data is added
2. if it is not provided, then only rank=0 in
That sounds like a reasonable plan to me.
Brian
On Mon, 23 Jun 2008, Ralph H Castain wrote:
Okay, so let's explore an alternative that preserves the support you are
seeking for the "ignorant user", but doesn't penalize everyone else. What we
could do is simply set things up so that:
1. if -mc
I concur
- galen
On Jun 23, 2008, at 3:44 PM, Brian W. Barrett wrote:
That sounds like a reasonable plan to me.
Brian
On Mon, 23 Jun 2008, Ralph H Castain wrote:
Okay, so let's explore an alternative that preserves the support
you are
seeking for the "ignorant user", but doesn't penalize e
We use req_state currently to track that we receive both RNDV
completion and RNDV ack prior to freeing the request..
- Galen
On Jun 23, 2008, at 3:23 PM, Brian W. Barrett wrote:
On Mon, 23 Jun 2008, Jeff Squyres wrote:
On Jun 23, 2008, at 3:17 PM, Brian W. Barrett wrote:
Just because
On Jun 23, 2008, at 4:43 PM, Shipman, Galen M. wrote:
We use req_state currently to track that we receive both RNDV
completion and RNDV ack prior to freeing the request..
Does that mean you're not using the enum values, but rather just to
indicate that the value is >= 0?
--
Jeff Squyres
C
Oh, I see, you are confusing the req_state on the OMPI request with
the req_state on the PML request.
The ompi request state is for persistent requests, the PML request
state is not and does not use that enum.
- Galen
On Jun 23, 2008, at 5:18 PM, Jeff Squyres wrote:
On Jun 23, 2008, at
Ah -- I see -- we have 2 different fields with the same name (just
different places within the struct hierarchy) with different
meanings. That was a good idea. ;-)
Thanks; that actually helps understand things quite a bit.
On Jun 23, 2008, at 5:45 PM, Shipman, Galen M. wrote:
Oh, I see,
On Jun 23, 2008, at 5:51 PM, Jeff Squyres wrote:
Ah -- I see -- we have 2 different fields with the same name (just
different places within the struct hierarchy) with different
meanings. That was a good idea. ;-)
exactly
Thanks; that actually helps understand things quite a bit.
On
23 matches
Mail list logo
