Re: [OMPI devel] ob1 and req->req_state

2008-06-23 Thread Shipman, Galen M.
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

Re: [OMPI devel] ob1 and req->req_state

2008-06-23 Thread Jeff Squyres
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,

Re: [OMPI devel] ob1 and req->req_state

2008-06-23 Thread Shipman, Galen M.
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

Re: [OMPI devel] PML selection logic

2008-06-23 Thread Ralph H Castain
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

Re: [OMPI devel] PML selection logic

2008-06-23 Thread Brian W. Barrett
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

Re: [OMPI devel] PML selection logic

2008-06-23 Thread Ralph H Castain
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

Re: [OMPI devel] ob1 and req->req_state

2008-06-23 Thread Brian W. Barrett
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,

Re: [OMPI devel] PML selection logic

2008-06-23 Thread Brian W. Barrett
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

Re: [OMPI devel] ob1 and req->req_state

2008-06-23 Thread Jeff Squyres
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?

Re: [OMPI devel] ob1 and req->req_state

2008-06-23 Thread Brian W. Barrett
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:

[OMPI devel] ob1 and req->req_state

2008-06-23 Thread Jeff Squyres
I see in a few places in ob1 we do things like this: OPAL_THREAD_ADD32(>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). Additionally,

Re: [OMPI devel] PML selection logic

2008-06-23 Thread Aurélien Bouteiller
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,

Re: [OMPI devel] ompi_ignore dr pml?

2008-06-23 Thread Tim Mattox
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

[OMPI devel] PML selection logic

2008-06-23 Thread Ralph H Castain
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

Re: [OMPI devel] multiple GigE interfaces...

2008-06-23 Thread Adrian Knoth
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

Re: [OMPI devel] BW benchmark hangs after r 18551

2008-06-23 Thread Lenny Verkhovsky
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: