Re: [OMPI devel] PLM consistency: priority

[Jeff Squyres]

FWIW -- we talked about this a bunch in the Louisville and have some  
ideas.  More details coming in meeting wrapup notes...



On Jul 11, 2008, at 11:14 AM, Ralph H Castain wrote:


Ummm...I actually was talking about the "PLM", not the "PML".

But I believe what you suggest concurs with what I said. In the PLM,  
you
could still provide multiple components you want considered, though  
it has

less meaning there. My suggestion really is only that we eliminate the
params to adjust relative priority as they are just confusing the  
user and

potentially misleading them as to what is going to happen.

Ralph



On 7/11/08 9:07 AM, "Aurélien Bouteiller"   
wrote:



We don't want the user to have to select by hand the best PML. The
logic inside the current selection process selects the best pml for
the underlying network. However changing the priority is pretty
meaningless from the user's point of view. So while retaining the
selection process including priorities, we might want to remove the
priority parameter, and use only the pml=ob1,cm syntax from the  
user's

point of view.

Aurelien

Le 11 juil. 08 à 10:56, Ralph H Castain a écrit :


Okay, another fun one. Some of the PLM modules use MCA params to
adjust
their relative selection priority. This can lead to very unexpected
behavior
as which module gets selected will depend on the priorities of the
other
selectable modules - which changes from release to release as people
independently make adjustments and/or new modules are added.

Fortunately, this doesn't bite us too often since many environments
only
support one module, and since there is nothing to tell the user that
the plm
module whose priority they raised actually -didn't- get used!

However, in the interest of "least astonishment", some of us working
on the
RTE had changed our coding approach to avoid this confusion. Given
that we
have this nice mca component select logic that takes the specified
module -
i.e., "-mca plm foo" always yields foo if it can run, or errors out
if it
can't - then the safest course is to remove MCA params that adjust
module
priorities and have the user simply tell us which module they want
us to
use.

Do we want to make this consistent, at least in the PLM? Or do you
want to
leave the user guessing? :-)

Ralph


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel




___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] PLM consistency: priority

[Ralph H Castain]

Ummm...I actually was talking about the "PLM", not the "PML".

But I believe what you suggest concurs with what I said. In the PLM, you
could still provide multiple components you want considered, though it has
less meaning there. My suggestion really is only that we eliminate the
params to adjust relative priority as they are just confusing the user and
potentially misleading them as to what is going to happen.

Ralph



On 7/11/08 9:07 AM, "Aurélien Bouteiller"  wrote:

> We don't want the user to have to select by hand the best PML. The
> logic inside the current selection process selects the best pml for
> the underlying network. However changing the priority is pretty
> meaningless from the user's point of view. So while retaining the
> selection process including priorities, we might want to remove the
> priority parameter, and use only the pml=ob1,cm syntax from the user's
> point of view.
> 
> Aurelien
> 
> Le 11 juil. 08 à 10:56, Ralph H Castain a écrit :
> 
>> Okay, another fun one. Some of the PLM modules use MCA params to
>> adjust
>> their relative selection priority. This can lead to very unexpected
>> behavior
>> as which module gets selected will depend on the priorities of the
>> other
>> selectable modules - which changes from release to release as people
>> independently make adjustments and/or new modules are added.
>> 
>> Fortunately, this doesn't bite us too often since many environments
>> only
>> support one module, and since there is nothing to tell the user that
>> the plm
>> module whose priority they raised actually -didn't- get used!
>> 
>> However, in the interest of "least astonishment", some of us working
>> on the
>> RTE had changed our coding approach to avoid this confusion. Given
>> that we
>> have this nice mca component select logic that takes the specified
>> module -
>> i.e., "-mca plm foo" always yields foo if it can run, or errors out
>> if it
>> can't - then the safest course is to remove MCA params that adjust
>> module
>> priorities and have the user simply tell us which module they want
>> us to
>> use.
>> 
>> Do we want to make this consistent, at least in the PLM? Or do you
>> want to
>> leave the user guessing? :-)
>> 
>> Ralph
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] PLM consistency: priority

[Aurélien Bouteiller]

We don't want the user to have to select by hand the best PML. The  
logic inside the current selection process selects the best pml for  
the underlying network. However changing the priority is pretty  
meaningless from the user's point of view. So while retaining the  
selection process including priorities, we might want to remove the  
priority parameter, and use only the pml=ob1,cm syntax from the user's  
point of view.


Aurelien

Le 11 juil. 08 à 10:56, Ralph H Castain a écrit :

Okay, another fun one. Some of the PLM modules use MCA params to  
adjust
their relative selection priority. This can lead to very unexpected  
behavior
as which module gets selected will depend on the priorities of the  
other

selectable modules - which changes from release to release as people
independently make adjustments and/or new modules are added.

Fortunately, this doesn't bite us too often since many environments  
only
support one module, and since there is nothing to tell the user that  
the plm

module whose priority they raised actually -didn't- get used!

However, in the interest of "least astonishment", some of us working  
on the
RTE had changed our coding approach to avoid this confusion. Given  
that we
have this nice mca component select logic that takes the specified  
module -
i.e., "-mca plm foo" always yields foo if it can run, or errors out  
if it
can't - then the safest course is to remove MCA params that adjust  
module
priorities and have the user simply tell us which module they want  
us to

use.

Do we want to make this consistent, at least in the PLM? Or do you  
want to

leave the user guessing? :-)

Ralph


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel