Re: [OMPI devel] ompi_info "developer warning"

[r...@open-mpi.org]

Fine with me - I don’t care so long as we get rid of the annoying “warning”

> On Jun 5, 2017, at 6:51 AM, George Bosilca  wrote:
> 
> I do care a little as the default size for most terminal is still 80 chars. I 
> would prefer your second choice where we replace "disabled" by "-" to  losing 
> information on the useful part of the message.
> 
> George.
>  
> 
> On Mon, Jun 5, 2017 at 9:45 AM,  > wrote:
> George,
> 
>  
> it seems today the limit is more something like max 24 + max 56.
> 
> we can keep the 80 character limit (i have zero opinion on that) and move to
> 
> max 32 + max 48 for example.
> 
> an other option is to replace "(disabled) " with something more compact
> 
> "(-) " or even "- "
> 
>  
> Cheers,
> 
>  
> Gilles
> 
> - Original Message -
> 
> So we are finally getting rid of the 80 chars per line limit?
>  
>   George.
>  
>  
> 
> On Sun, Jun 4, 2017 at 11:23 PM, r...@open-mpi.org  
> > wrote:
> Really? Sigh - frustrating. I’ll change itas it gets irritating to keep get 
> this warning.
> 
> Frankly, I find I’m constantly doing --all because otherwise I have no 
> earthly idea how to find what I’m looking for anymore...
> 
> 
> > On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet  > > wrote:
> >
> > Ralph,
> >
> >
> > in your environment, pml/monitoring is disabled.
> >
> > so instead of displaying "MCA pml monitoring", ompi_info --all displays
> >
> > "MCA (disabled) pml monitoring" which is larger than 24 characters.
> >
> >
> > fwiw, you can observe the same behavior with
> >
> > OMPI_MCA_sharedfp=^lockedfile ompi_info --all
> >
> >
> > one option is to bump centerpoint (opal/runtime/opal_info_support.c) from 
> > 24 to something larger,
> > an other option is to mark disabled components with a shorter string, for 
> > example
> > "MCA (-) pml monitoring"
> >
> >
> > Cheers,
> >
> > Gilles
> >
> > On 6/3/2017 5:26 AM, r...@open-mpi.org  wrote:
> >> I keep seeing this when I run ompi_info --all:
> >>
> >> **
> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
> >> *** will appear poorly in the prettyprint output.
> >> ***
> >> ***   Value:  "MCA (disabled) pml monitoring"
> >> ***   Max length: 24
> >> **
> >> **
> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
> >> *** will appear poorly in the prettyprint output.
> >> ***
> >> ***   Value:  "MCA (disabled) pml monitoring"
> >> ***   Max length: 24
> >> **
> >>
> >> Anyone know what this is about???
> >> Ralph
> >>
> >>
> >>
> >> ___
> >> devel mailing list
> >> devel@lists.open-mpi.org  
> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel  
> >> 
> >
> > ___
> > devel mailing list
> > devel@lists.open-mpi.org  
> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel  
> > 
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org  
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel 
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org 
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel 
> 
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] ompi_info "developer warning"

[r...@open-mpi.org]

I added the change to https://github.com/open-mpi/ompi/pull/3651 
. We’ll just have to hope that 
people intuitively understand that “-“ means “disabled”.

> On Jun 5, 2017, at 7:01 AM, r...@open-mpi.org wrote:
> 
> Fine with me - I don’t care so long as we get rid of the annoying “warning”
> 
>> On Jun 5, 2017, at 6:51 AM, George Bosilca > > wrote:
>> 
>> I do care a little as the default size for most terminal is still 80 chars. 
>> I would prefer your second choice where we replace "disabled" by "-" to  
>> losing information on the useful part of the message.
>> 
>> George.
>>  
>> 
>> On Mon, Jun 5, 2017 at 9:45 AM, > > wrote:
>> George,
>> 
>>  
>> it seems today the limit is more something like max 24 + max 56.
>> 
>> we can keep the 80 character limit (i have zero opinion on that) and move to
>> 
>> max 32 + max 48 for example.
>> 
>> an other option is to replace "(disabled) " with something more compact
>> 
>> "(-) " or even "- "
>> 
>>  
>> Cheers,
>> 
>>  
>> Gilles
>> 
>> - Original Message -
>> 
>> So we are finally getting rid of the 80 chars per line limit?
>>  
>>   George.
>>  
>>  
>> 
>> On Sun, Jun 4, 2017 at 11:23 PM, r...@open-mpi.org 
>>  > 
>> wrote:
>> Really? Sigh - frustrating. I’ll change itas it gets irritating to keep get 
>> this warning.
>> 
>> Frankly, I find I’m constantly doing --all because otherwise I have no 
>> earthly idea how to find what I’m looking for anymore...
>> 
>> 
>> > On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet > > > wrote:
>> >
>> > Ralph,
>> >
>> >
>> > in your environment, pml/monitoring is disabled.
>> >
>> > so instead of displaying "MCA pml monitoring", ompi_info --all displays
>> >
>> > "MCA (disabled) pml monitoring" which is larger than 24 characters.
>> >
>> >
>> > fwiw, you can observe the same behavior with
>> >
>> > OMPI_MCA_sharedfp=^lockedfile ompi_info --all
>> >
>> >
>> > one option is to bump centerpoint (opal/runtime/opal_info_support.c) from 
>> > 24 to something larger,
>> > an other option is to mark disabled components with a shorter string, for 
>> > example
>> > "MCA (-) pml monitoring"
>> >
>> >
>> > Cheers,
>> >
>> > Gilles
>> >
>> > On 6/3/2017 5:26 AM, r...@open-mpi.org  wrote:
>> >> I keep seeing this when I run ompi_info --all:
>> >>
>> >> **
>> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
>> >> *** will appear poorly in the prettyprint output.
>> >> ***
>> >> ***   Value:  "MCA (disabled) pml monitoring"
>> >> ***   Max length: 24
>> >> **
>> >> **
>> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
>> >> *** will appear poorly in the prettyprint output.
>> >> ***
>> >> ***   Value:  "MCA (disabled) pml monitoring"
>> >> ***   Max length: 24
>> >> **
>> >>
>> >> Anyone know what this is about???
>> >> Ralph
>> >>
>> >>
>> >>
>> >> ___
>> >> devel mailing list
>> >> devel@lists.open-mpi.org  
>> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel  
>> >> 
>> >
>> > ___
>> > devel mailing list
>> > devel@lists.open-mpi.org  
>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel  
>> > 
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org  
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel 
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org 
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel 
>> 
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org 
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] ompi_info "developer warning"

[George Bosilca]

I do care a little as the default size for most terminal is still 80 chars.
I would prefer your second choice where we replace "disabled" by "-" to
 losing information on the useful part of the message.

George.


On Mon, Jun 5, 2017 at 9:45 AM,  wrote:

> George,
>
>
>
> it seems today the limit is more something like max 24 + max 56.
>
> we can keep the 80 character limit (i have zero opinion on that) and move
> to
>
> max 32 + max 48 for example.
>
> an other option is to replace "(disabled) " with something more compact
>
> "(-) " or even "- "
>
>
>
> Cheers,
>
>
>
> Gilles
>
> - Original Message -
>
> So we are finally getting rid of the 80 chars per line limit?
>
>   George.
>
>
>
> On Sun, Jun 4, 2017 at 11:23 PM, r...@open-mpi.org 
> wrote:
>
>> Really? Sigh - frustrating. I’ll change itas it gets irritating to keep
>> get this warning.
>>
>> Frankly, I find I’m constantly doing --all because otherwise I have no
>> earthly idea how to find what I’m looking for anymore...
>>
>>
>> > On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet 
>> wrote:
>> >
>> > Ralph,
>> >
>> >
>> > in your environment, pml/monitoring is disabled.
>> >
>> > so instead of displaying "MCA pml monitoring", ompi_info --all displays
>> >
>> > "MCA (disabled) pml monitoring" which is larger than 24 characters.
>> >
>> >
>> > fwiw, you can observe the same behavior with
>> >
>> > OMPI_MCA_sharedfp=^lockedfile ompi_info --all
>> >
>> >
>> > one option is to bump centerpoint (opal/runtime/opal_info_support.c)
>> from 24 to something larger,
>> > an other option is to mark disabled components with a shorter string,
>> for example
>> > "MCA (-) pml monitoring"
>> >
>> >
>> > Cheers,
>> >
>> > Gilles
>> >
>> > On 6/3/2017 5:26 AM, r...@open-mpi.org wrote:
>> >> I keep seeing this when I run ompi_info --all:
>> >>
>> >> 
>> **
>> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
>> >> *** will appear poorly in the prettyprint output.
>> >> ***
>> >> ***   Value:  "MCA (disabled) pml monitoring"
>> >> ***   Max length: 24
>> >> 
>> **
>> >> 
>> **
>> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
>> >> *** will appear poorly in the prettyprint output.
>> >> ***
>> >> ***   Value:  "MCA (disabled) pml monitoring"
>> >> ***   Max length: 24
>> >> 
>> **
>> >>
>> >> Anyone know what this is about???
>> >> Ralph
>> >>
>> >>
>> >>
>> >> ___
>> >> devel mailing list
>> >> devel@lists.open-mpi.org
>> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> >
>> > ___
>> > devel mailing list
>> > devel@lists.open-mpi.org
>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>>
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] ompi_info "developer warning"

[gilles]

George,

it seems today the limit is more something like max 24 + max 56.

we can keep the 80 character limit (i have zero opinion on that) and 
move to

max 32 + max 48 for example.

an other option is to replace "(disabled) " with something more compact

"(-) " or even "- "

Cheers,

Gilles

- Original Message -

So we are finally getting rid of the 80 chars per line limit?

  George.



On Sun, Jun 4, 2017 at 11:23 PM, r...@open-mpi.org  
wrote:

Really? Sigh - frustrating. I’ll change itas it gets irritating 
to keep get this warning.

Frankly, I find I’m constantly doing --all because otherwise I 
have no earthly idea how to find what I’m looking for anymore...


> On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet  wrote:
>
> Ralph,
>
>
> in your environment, pml/monitoring is disabled.
>
> so instead of displaying "MCA pml monitoring", ompi_info --all 
displays
>
> "MCA (disabled) pml monitoring" which is larger than 24 
characters.
>
>
> fwiw, you can observe the same behavior with
>
> OMPI_MCA_sharedfp=^lockedfile ompi_info --all
>
>
> one option is to bump centerpoint (opal/runtime/opal_info_
support.c) from 24 to something larger,
> an other option is to mark disabled components with a shorter 
string, for example
> "MCA (-) pml monitoring"
>
>
> Cheers,
>
> Gilles
>
> On 6/3/2017 5:26 AM, r...@open-mpi.org wrote:
>> I keep seeing this when I run ompi_info --all:
>>
>> *
*
>> *** DEVELOPER WARNING: A field in ompi_info output is too 
long and
>> *** will appear poorly in the prettyprint output.
>> ***
>> ***   Value:  "MCA (disabled) pml monitoring"
>> ***   Max length: 24
>> *
*
>> *
*
>> *** DEVELOPER WARNING: A field in ompi_info output is too 
long and
>> *** will appear poorly in the prettyprint output.
>> ***
>> ***   Value:  "MCA (disabled) pml monitoring"
>> ***   Max length: 24
>> *
*
>>
>> Anyone know what this is about???
>> Ralph
>>
>>
>>
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel




___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] ompi_info "developer warning"

[George Bosilca]

So we are finally getting rid of the 80 chars per line limit?

  George.



On Sun, Jun 4, 2017 at 11:23 PM, r...@open-mpi.org  wrote:

> Really? Sigh - frustrating. I’ll change itas it gets irritating to keep
> get this warning.
>
> Frankly, I find I’m constantly doing --all because otherwise I have no
> earthly idea how to find what I’m looking for anymore...
>
>
> > On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet 
> wrote:
> >
> > Ralph,
> >
> >
> > in your environment, pml/monitoring is disabled.
> >
> > so instead of displaying "MCA pml monitoring", ompi_info --all displays
> >
> > "MCA (disabled) pml monitoring" which is larger than 24 characters.
> >
> >
> > fwiw, you can observe the same behavior with
> >
> > OMPI_MCA_sharedfp=^lockedfile ompi_info --all
> >
> >
> > one option is to bump centerpoint (opal/runtime/opal_info_support.c)
> from 24 to something larger,
> > an other option is to mark disabled components with a shorter string,
> for example
> > "MCA (-) pml monitoring"
> >
> >
> > Cheers,
> >
> > Gilles
> >
> > On 6/3/2017 5:26 AM, r...@open-mpi.org wrote:
> >> I keep seeing this when I run ompi_info --all:
> >>
> >> 
> **
> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
> >> *** will appear poorly in the prettyprint output.
> >> ***
> >> ***   Value:  "MCA (disabled) pml monitoring"
> >> ***   Max length: 24
> >> 
> **
> >> 
> **
> >> *** DEVELOPER WARNING: A field in ompi_info output is too long and
> >> *** will appear poorly in the prettyprint output.
> >> ***
> >> ***   Value:  "MCA (disabled) pml monitoring"
> >> ***   Max length: 24
> >> 
> **
> >>
> >> Anyone know what this is about???
> >> Ralph
> >>
> >>
> >>
> >> ___
> >> devel mailing list
> >> devel@lists.open-mpi.org
> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@lists.open-mpi.org
> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] ompi_info "developer warning"

[r...@open-mpi.org]

Really? Sigh - frustrating. I’ll change itas it gets irritating to keep get 
this warning.

Frankly, I find I’m constantly doing --all because otherwise I have no earthly 
idea how to find what I’m looking for anymore...


> On Jun 4, 2017, at 7:25 PM, Gilles Gouaillardet  wrote:
> 
> Ralph,
> 
> 
> in your environment, pml/monitoring is disabled.
> 
> so instead of displaying "MCA pml monitoring", ompi_info --all displays
> 
> "MCA (disabled) pml monitoring" which is larger than 24 characters.
> 
> 
> fwiw, you can observe the same behavior with
> 
> OMPI_MCA_sharedfp=^lockedfile ompi_info --all
> 
> 
> one option is to bump centerpoint (opal/runtime/opal_info_support.c) from 24 
> to something larger,
> an other option is to mark disabled components with a shorter string, for 
> example
> "MCA (-) pml monitoring"
> 
> 
> Cheers,
> 
> Gilles
> 
> On 6/3/2017 5:26 AM, r...@open-mpi.org wrote:
>> I keep seeing this when I run ompi_info --all:
>> 
>> **
>> *** DEVELOPER WARNING: A field in ompi_info output is too long and
>> *** will appear poorly in the prettyprint output.
>> ***
>> ***   Value:  "MCA (disabled) pml monitoring"
>> ***   Max length: 24
>> **
>> **
>> *** DEVELOPER WARNING: A field in ompi_info output is too long and
>> *** will appear poorly in the prettyprint output.
>> ***
>> ***   Value:  "MCA (disabled) pml monitoring"
>> ***   Max length: 24
>> **
>> 
>> Anyone know what this is about???
>> Ralph
>> 
>> 
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] ompi_info "developer warning"

[Gilles Gouaillardet]

Ralph,


in your environment, pml/monitoring is disabled.

so instead of displaying "MCA pml monitoring", ompi_info --all displays

"MCA (disabled) pml monitoring" which is larger than 24 characters.


fwiw, you can observe the same behavior with

OMPI_MCA_sharedfp=^lockedfile ompi_info --all


one option is to bump centerpoint (opal/runtime/opal_info_support.c) 
from 24 to something larger,
an other option is to mark disabled components with a shorter string, 
for example

"MCA (-) pml monitoring"


Cheers,

Gilles

On 6/3/2017 5:26 AM, r...@open-mpi.org wrote:

I keep seeing this when I run ompi_info --all:

**
*** DEVELOPER WARNING: A field in ompi_info output is too long and
*** will appear poorly in the prettyprint output.
***
***   Value:  "MCA (disabled) pml monitoring"
***   Max length: 24
**
**
*** DEVELOPER WARNING: A field in ompi_info output is too long and
*** will appear poorly in the prettyprint output.
***
***   Value:  "MCA (disabled) pml monitoring"
***   Max length: 24
**

Anyone know what this is about???
Ralph



___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel


___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

[OMPI devel] ompi_info "developer warning"

[r...@open-mpi.org]

I keep seeing this when I run ompi_info --all:

**
*** DEVELOPER WARNING: A field in ompi_info output is too long and
*** will appear poorly in the prettyprint output.
***
***   Value:  "MCA (disabled) pml monitoring"
***   Max length: 24
**
**
*** DEVELOPER WARNING: A field in ompi_info output is too long and
*** will appear poorly in the prettyprint output.
***
***   Value:  "MCA (disabled) pml monitoring"
***   Max length: 24
**

Anyone know what this is about???
Ralph

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] .ompi_info dependency files

[George Bosilca]

It is a vestige from a epoch where our shared library symbols were loaded
in the RTLD_GLOBAL mode. I support your proposal to scrap it out.

  George.


On Tue, Apr 7, 2015 at 1:41 PM, Nathan Hjelm  wrote:

>
> I am working on rewriting some of the MCA component open code to delay
> dlclose until opal_util_finalize () and I ran into something
> interesting. Open MPI supports component dependency files ending in
> .ompi_info. These files can be used to describe dependencies between mca
> components. This feature seems to be a break in the MCA abstration. I
> could, for example, make mca_btl_vader.so "depend" on components in
> ompi (like mca_osc_pt2pt.so).
>
> What is the history of the .ompi_info dependency file format? Can we
> remove support for it? It would greatly simplify the code in
> mca_base_component_find.c.
>
> -Nathan
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/04/17191.php
>

[OMPI devel] .ompi_info dependency files

[Nathan Hjelm]

I am working on rewriting some of the MCA component open code to delay
dlclose until opal_util_finalize () and I ran into something
interesting. Open MPI supports component dependency files ending in
.ompi_info. These files can be used to describe dependencies between mca
components. This feature seems to be a break in the MCA abstration. I
could, for example, make mca_btl_vader.so "depend" on components in
ompi (like mca_osc_pt2pt.so).

What is the history of the .ompi_info dependency file format? Can we
remove support for it? It would greatly simplify the code in
mca_base_component_find.c.

-Nathan


pgpeRCq_mg0MQ.pgp
Description: PGP signature

Re: [OMPI devel] ompi_info not Giving Complete Output

[Kevin Brown]

Ah, I see.
Thanks a lot guys.

Kevin
--
*Kevin A. Brown* *|* Tokyo Institute of Technology *|* *E-mail*:
brown.k...@titech.ac.jp


On Tue, May 27, 2014 at 3:06 AM, Jeff Squyres (jsquyres)  wrote:

> Or use --all.
>
>
> On May 26, 2014, at 10:21 AM, Ralph Castain  wrote:
>
> > Try adding "--level 9" to the cmd line. It's a new "feature" to try and
> reduce the volume of data being thrown at the user as the majority of
> params are frequently of use only to us developers
> >
> > On May 26, 2014, at 7:14 AM, Kevin Brown 
> wrote:
> >
> >> Greetings,
> >>
> >> I've just noticed that ompi_info (Open MPI v. 1.8.1) is not giving a
> complete listing when ran with the following options:
> >>
> >> rc000:~ > ~/opt/openmpi-1.8.1-base/bin/ompi_info --param all all
> >>  MCA btl: parameter "btl_tcp_if_include" (current
> value: "",
> >>   data source: default, level: 1 user/basic,
> type:
> >>   string)
> >>   Comma-delimited list of devices and/or CIDR
> >>   notation of networks to use for MPI
> communication
> >>   (e.g., "eth0,192.168.0.0/16").  Mutually
> exclusive
> >>   with btl_tcp_if_exclude.
> >>  MCA btl: parameter "btl_tcp_if_exclude" (current value:
> >>   "127.0.0.1/8,sppp", data source: default,
> level: 1
> >>   user/basic, type: string)
> >>   Comma-delimited list of devices and/or CIDR
> >>   notation of networks to NOT use for MPI
> >>   communication -- all devices not matching
> these
> >>   specifications will be used (e.g.,
> >>   "eth0,192.168.0.0/16").  If set to a
> non-default
> >>   value, it is mutually exclusive with
> >>   btl_tcp_if_include.
> >> rc000:~ >
> >>
> >> The info shown above is the only output given by the command.
> >>
> >> Configuration info has been attached to this mail.
> >>
> >> Is this correct behavior?
> >>
> >> Thanks,
> >> Kevin
> >>
> >> Kevin A. Brown | Tokyo Institute of Technology  | E-mail:
> brown.k...@titech.ac.jp
> >>
> >>
> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/05/14841.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/05/14842.php
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/05/14843.php
>

Re: [OMPI devel] ompi_info not Giving Complete Output

[Jeff Squyres (jsquyres)]

Or use --all.


On May 26, 2014, at 10:21 AM, Ralph Castain  wrote:

> Try adding "--level 9" to the cmd line. It's a new "feature" to try and 
> reduce the volume of data being thrown at the user as the majority of params 
> are frequently of use only to us developers
> 
> On May 26, 2014, at 7:14 AM, Kevin Brown  wrote:
> 
>> Greetings,
>> 
>> I've just noticed that ompi_info (Open MPI v. 1.8.1) is not giving a 
>> complete listing when ran with the following options:
>> 
>> rc000:~ > ~/opt/openmpi-1.8.1-base/bin/ompi_info --param all all
>>  MCA btl: parameter "btl_tcp_if_include" (current value: "",
>>   data source: default, level: 1 user/basic, type:
>>   string)
>>   Comma-delimited list of devices and/or CIDR
>>   notation of networks to use for MPI communication
>>   (e.g., "eth0,192.168.0.0/16").  Mutually exclusive
>>   with btl_tcp_if_exclude.
>>  MCA btl: parameter "btl_tcp_if_exclude" (current value:
>>   "127.0.0.1/8,sppp", data source: default, level: 1
>>   user/basic, type: string)
>>   Comma-delimited list of devices and/or CIDR
>>   notation of networks to NOT use for MPI
>>   communication -- all devices not matching these
>>   specifications will be used (e.g.,
>>   "eth0,192.168.0.0/16").  If set to a non-default
>>   value, it is mutually exclusive with
>>   btl_tcp_if_include.
>> rc000:~ > 
>> 
>> The info shown above is the only output given by the command. 
>> 
>> Configuration info has been attached to this mail.
>> 
>> Is this correct behavior?
>> 
>> Thanks,
>> Kevin
>> 
>> Kevin A. Brown | Tokyo Institute of Technology  | E-mail: 
>> brown.k...@titech.ac.jp
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/05/14841.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/05/14842.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] ompi_info not Giving Complete Output

[Ralph Castain]

Try adding "--level 9" to the cmd line. It's a new "feature" to try and reduce 
the volume of data being thrown at the user as the majority of params are 
frequently of use only to us developers

On May 26, 2014, at 7:14 AM, Kevin Brown  wrote:

> Greetings,
> 
> I've just noticed that ompi_info (Open MPI v. 1.8.1) is not giving a complete 
> listing when ran with the following options:
> 
> rc000:~ > ~/opt/openmpi-1.8.1-base/bin/ompi_info --param all all
>  MCA btl: parameter "btl_tcp_if_include" (current value: "",
>   data source: default, level: 1 user/basic, type:
>   string)
>   Comma-delimited list of devices and/or CIDR
>   notation of networks to use for MPI communication
>   (e.g., "eth0,192.168.0.0/16").  Mutually exclusive
>   with btl_tcp_if_exclude.
>  MCA btl: parameter "btl_tcp_if_exclude" (current value:
>   "127.0.0.1/8,sppp", data source: default, level: 1
>   user/basic, type: string)
>   Comma-delimited list of devices and/or CIDR
>   notation of networks to NOT use for MPI
>   communication -- all devices not matching these
>   specifications will be used (e.g.,
>   "eth0,192.168.0.0/16").  If set to a non-default
>   value, it is mutually exclusive with
>   btl_tcp_if_include.
> rc000:~ > 
> 
> The info shown above is the only output given by the command. 
> 
> Configuration info has been attached to this mail.
> 
> Is this correct behavior?
> 
> Thanks,
> Kevin
> 
> Kevin A. Brown | Tokyo Institute of Technology  | E-mail: 
> brown.k...@titech.ac.jp
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/05/14841.php

[OMPI devel] ompi_info not Giving Complete Output

[Kevin Brown]

Greetings,

I've just noticed that ompi_info (Open MPI v. 1.8.1) is not giving a
complete listing when ran with the following options:

rc000:~ > ~/opt/openmpi-1.8.1-base/bin/ompi_info --param all all
 MCA btl: parameter "btl_tcp_if_include" (current value: "",
  data source: default, level: 1 user/basic, type:
  string)
  Comma-delimited list of devices and/or CIDR
  notation of networks to use for MPI communication
  (e.g., "eth0,192.168.0.0/16").  Mutually exclusive
  with btl_tcp_if_exclude.
 MCA btl: parameter "btl_tcp_if_exclude" (current value:
  "127.0.0.1/8,sppp", data source: default, level: 1
  user/basic, type: string)
  Comma-delimited list of devices and/or CIDR
  notation of networks to NOT use for MPI
  communication -- all devices not matching these
  specifications will be used (e.g.,
  "eth0,192.168.0.0/16").  If set to a non-default
  value, it is mutually exclusive with
  btl_tcp_if_include.
rc000:~ >

The info shown above is the only output given by the command.

Configuration info has been attached to this mail.

Is this correct behavior?

Thanks,
Kevin

--
*Kevin A. Brown* *|* Tokyo Institute of Technology  *|* *E-mail*:
brown.k...@titech.ac.jp


configs_and_outputs.tar.bz2
Description: BZip2 compressed data

Re: [OMPI devel] ompi_info

[Jeff Squyres (jsquyres)]

Actually, the compromise was listed in my original mail:

  2a. Fair enough.  The long-standing ompi_info behavior precedent alone is 
probably enough to warrant re-thinking the new ompi_info behavior.  Nathan will 
implement a compromise (that George was ok with when I talked on the phone with 
him).  If you have a  parameter somewhere that disables components 
(e.g., $HOME/.openmpi-mca-params.conf contains "btl = tcp,sm,self"), then 
ompi_info will somehow mark those components' parameters as "inactive" in the 
prettyprint and parseable outputs



On Aug 28, 2013, at 2:50 AM, George Bosilca  wrote:

> Jeff is indeed correct, the compromise we reached was to default to the 
> historical behavior of showing only the parameters of selected components and 
> have an option to show everything else.
> 
>  George.
> 
> PS: Shouldn't "ompi_info --param all all" be identical to "ompi_info --all"?
> 
> On Aug 27, 2013, at 22:10 , Jeff Squyres (jsquyres)  
> wrote:
> 
>> On Aug 27, 2013, at 3:13 PM, Nathan Hjelm  wrote:
>> 
> 1a. ompi_info has a *very long-standing precedent* behavior of using 
>  MCA params to exclude the display of components (and their 
> params). Users have come to rely on this behavior to test that OMPI is 
> honoring their $HOME/.openmpi-mca-params.conf file (for example) because 
> -- at least prior to new ompi_info -- there was no other way to verify 
> that.
>>> 
>>> Please take a look @ r29070. I changed the default behavior of ompi_info
>>> -a when --level is not specified to assume level 9. I also added an
>>> option (--selected-only/-s) that limits the output to components that
>>> may be selected. Let me know if this fix is ok.
>> 
>> 
>> I don't think it's going to be enough.
>> 
>> George's point is that the *default behavior* for ompi_info for years has 
>> been to do what --selected-only does.  So adding a non-default option to get 
>> that same behavior... I think George will hate that.  Right, George?  :-)
>> 
>> I think your option 2b) from your previous mail was the compromise:
>> 
>> -
>> To summarize what will be done:
>> 
>> 1) --all without a --level will assume --level 9
>> 2) Either a) add an option to ompi_info to suppress registering all
>> components when a component selection parameter is set (ie. --mca btl
>> self,sm) or b) somehow mark the parameters of unused components as such.
>> -
>> 
>> I.e., show all components, but mark those who are not selected somehow.
>> 
>> Sorry.  :-\
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] ompi_info

[George Bosilca]

Jeff is indeed correct, the compromise we reached was to default to the 
historical behavior of showing only the parameters of selected components and 
have an option to show everything else.

  George.

PS: Shouldn't "ompi_info --param all all" be identical to "ompi_info --all"?

On Aug 27, 2013, at 22:10 , Jeff Squyres (jsquyres)  wrote:

> On Aug 27, 2013, at 3:13 PM, Nathan Hjelm  wrote:
> 
 1a. ompi_info has a *very long-standing precedent* behavior of using 
  MCA params to exclude the display of components (and their 
 params). Users have come to rely on this behavior to test that OMPI is 
 honoring their $HOME/.openmpi-mca-params.conf file (for example) because 
 -- at least prior to new ompi_info -- there was no other way to verify 
 that.
>> 
>> Please take a look @ r29070. I changed the default behavior of ompi_info
>> -a when --level is not specified to assume level 9. I also added an
>> option (--selected-only/-s) that limits the output to components that
>> may be selected. Let me know if this fix is ok.
> 
> 
> I don't think it's going to be enough.
> 
> George's point is that the *default behavior* for ompi_info for years has 
> been to do what --selected-only does.  So adding a non-default option to get 
> that same behavior... I think George will hate that.  Right, George?  :-)
> 
> I think your option 2b) from your previous mail was the compromise:
> 
> -
> To summarize what will be done:
> 
> 1) --all without a --level will assume --level 9
> 2) Either a) add an option to ompi_info to suppress registering all
> components when a component selection parameter is set (ie. --mca btl
> self,sm) or b) somehow mark the parameters of unused components as such.
> -
> 
> I.e., show all components, but mark those who are not selected somehow.
> 
> Sorry.  :-\
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] ompi_info

[Jeff Squyres (jsquyres)]

On Aug 27, 2013, at 3:13 PM, Nathan Hjelm  wrote:

>>>  1a. ompi_info has a *very long-standing precedent* behavior of using 
>>>  MCA params to exclude the display of components (and their 
>>> params). Users have come to rely on this behavior to test that OMPI is 
>>> honoring their $HOME/.openmpi-mca-params.conf file (for example) because -- 
>>> at least prior to new ompi_info -- there was no other way to verify that.
> 
> Please take a look @ r29070. I changed the default behavior of ompi_info
> -a when --level is not specified to assume level 9. I also added an
> option (--selected-only/-s) that limits the output to components that
> may be selected. Let me know if this fix is ok.


I don't think it's going to be enough.

George's point is that the *default behavior* for ompi_info for years has been 
to do what --selected-only does.  So adding a non-default option to get that 
same behavior... I think George will hate that.  Right, George?  :-)

I think your option 2b) from your previous mail was the compromise:

-
To summarize what will be done:

1) --all without a --level will assume --level 9
2) Either a) add an option to ompi_info to suppress registering all
components when a component selection parameter is set (ie. --mca btl
self,sm) or b) somehow mark the parameters of unused components as such.
-

I.e., show all components, but mark those who are not selected somehow.

Sorry.  :-\

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] ompi_info

[Nathan Hjelm]

On Tue, Aug 27, 2013 at 06:57:09PM +0200, George Bosilca wrote:
> 
> On Jul 19, 2013, at 17:57 , Jeff Squyres (jsquyres)  
> wrote:
> 
> > I've now talked to both George and Nathan.  Let me summarize for the web 
> > archives / community:
> > 
> > 1. There are two main points of contention:
> > 
> >   1a. ompi_info has a *very long-standing precedent* behavior of using 
> >  MCA params to exclude the display of components (and their 
> > params). Users have come to rely on this behavior to test that OMPI is 
> > honoring their $HOME/.openmpi-mca-params.conf file (for example) because -- 
> > at least prior to new ompi_info -- there was no other way to verify that.
> > 
> >   1b. It seems meaningless for MPI_T_Init to open *all* components when 
> > we're just going to be exposing a bunch of components/parameters that will 
> > not be used.  Easy example: MPI_T_Init will open all the PMLs, but we'll 
> > only end up using one of them.  Why have all the rest?
> 
> Any progress on this?


Please take a look @ r29070. I changed the default behavior of ompi_info
-a when --level is not specified to assume level 9. I also added an
option (--selected-only/-s) that limits the output to components that
may be selected. Let me know if this fix is ok.

-Nathan

Re: [OMPI devel] ompi_info

[Nathan Hjelm]

On Tue, Aug 27, 2013 at 06:57:09PM +0200, George Bosilca wrote:
> 
> On Jul 19, 2013, at 17:57 , Jeff Squyres (jsquyres)  
> wrote:
> 
> > I've now talked to both George and Nathan.  Let me summarize for the web 
> > archives / community:
> > 
> > 1. There are two main points of contention:
> > 
> >   1a. ompi_info has a *very long-standing precedent* behavior of using 
> >  MCA params to exclude the display of components (and their 
> > params). Users have come to rely on this behavior to test that OMPI is 
> > honoring their $HOME/.openmpi-mca-params.conf file (for example) because -- 
> > at least prior to new ompi_info -- there was no other way to verify that.
> > 
> >   1b. It seems meaningless for MPI_T_Init to open *all* components when 
> > we're just going to be exposing a bunch of components/parameters that will 
> > not be used.  Easy example: MPI_T_Init will open all the PMLs, but we'll 
> > only end up using one of them.  Why have all the rest?
> 
> Any progress on this?

There was until a bad puppet script wiped out all my data on my work
computer. I will work on it today and should have something ready to
push tomorrow.

To summarize what will be done:

1) --all without a --level will assume --level 9
2) Either a) add an option to ompi_info to suppress registering all
components when a component selection parameter is set (ie. --mca btl
self,sm) or b) somehow mark the parameters of unused components as such.

1 and 2a are easy. 2b is a little harder.

-Nathan

Re: [OMPI devel] ompi_info

[George Bosilca]

On Jul 19, 2013, at 17:57 , Jeff Squyres (jsquyres)  wrote:

> I've now talked to both George and Nathan.  Let me summarize for the web 
> archives / community:
> 
> 1. There are two main points of contention:
> 
>   1a. ompi_info has a *very long-standing precedent* behavior of using 
>  MCA params to exclude the display of components (and their 
> params). Users have come to rely on this behavior to test that OMPI is 
> honoring their $HOME/.openmpi-mca-params.conf file (for example) because -- 
> at least prior to new ompi_info -- there was no other way to verify that.
> 
>   1b. It seems meaningless for MPI_T_Init to open *all* components when we're 
> just going to be exposing a bunch of components/parameters that will not be 
> used.  Easy example: MPI_T_Init will open all the PMLs, but we'll only end up 
> using one of them.  Why have all the rest?

Any progress on this?

  George.


> 
> 2. After talking to Nathan, here's our answers:
> 
>   2a. Fair enough.  The long-standing ompi_info behavior precedent alone is 
> probably enough to warrant re-thinking the new ompi_info behavior.  Nathan 
> will implement a compromise (that George was ok with when I talked on the 
> phone with him).  If you have a  parameter somewhere that disables 
> components (e.g., $HOME/.openmpi-mca-params.conf contains "btl = 
> tcp,sm,self"), then ompi_info will somehow mark those components' parameters 
> as "inactive" in the prettyprint and parseable outputs
> 
>   2b. Nathan reminded me why we chose to do this.  It requires a little 
> explanation...
> 
> One thing to remember: MPI_T parameters *are* MCA parameters.  Hence, the 
> btl_tcp_if_include MCA parameter is also the btl_tcp_if_include MPI_T 
> parameter.  Put differently: MPI_T and MCA are two interfaces to the same 
> back-end variables.
> 
> Something to note: if you call MPI_Init and then later call MPI_T_init, the 
> latter is effectively a no-op.
> 
> The interesting case is when you call MPI_T_init before you call MPI_Init.  
> In this case, as has been noted in this thread: we open all components in all 
> frameworks.
> 
> However: what hasn't been noted is that during the subsequent MPI_Init, we do 
> normal selection *and will close unused components* (which also un-registers 
> all their corresponding MPI_T/MCA parameters).  For example:
> 
> 1. During MPI_T_init, we'll open all the PMLs: CM, OB1, etc.
> 
> 2. Subsequent calls to MPI_T functions can *set* MPI_T/MCA params.  For 
> example, you can use MPI_T to pick the ob1 PML.
> 
> 3. When MPI_Init is finally invoked, normal MPI_Init flow is observed; if an 
> MCA param was set to, for example, pick the PML, it will be honored and the 
> non-selected PMLs will be closed.  Consequently, all the MPI_T/MCA params for 
> the closed components will disappear from MPI_T (which is allowed by the 
> spec).  Continuing the example from #2, the CM PML will be closed, and all of 
> its MPI_T/MCA params will disappear.
> 
> Put simply: the point of opening *all* frameworks/components is to find out 
> what all the params are so that the window of time represented by #2 can be 
> utilized to examine/set MCA params as you want before you go into the 
> "normal" MPI process 
> 
> So I think we're ok from this standpoint.
> 
> 
> 
> 
> On Jul 19, 2013, at 10:29 AM, "Jeff Squyres (jsquyres)"  
> wrote:
> 
>> George and I talked about this on the phone; I understand his questions 
>> better now.
>> 
>> Nathan and I will get together and work through his questions and come back 
>> to everyone with some answers / proposals.
>> 
>> 
>> On Jul 19, 2013, at 9:27 AM, George Bosilca  wrote:
>> 
>>> 
>>> My point is the following. I favor consistent behaviors and I'm always in 
>>> favor of respecting the configuration files. ALWAYS like in the word that 
>>> mean all cases without exception. Thus, by default, ompi_info as any other 
>>> component of the Open MPI infrastructure MUST read the configuration files 
>>> and respect all options provided there. And here was another inconsistency 
>>> on the "new" approach. ompi_info reports some of the values (like the eager 
>>> size and friends), while deciding to ignore others (like the list of the 
>>> active PML and BTL).
>>> 
>>> I do concede that there are cases where we need something slightly 
>>> different, maybe as a convenience. If there is a need for a special case 
>>> for ompi_info to ignore the configuration files, let's add it. But do't 
>>> make it the default, instead request a special command line argument for it.
>>> 
>>> There were several mentions about he MPI_T in this discussion. If I 
>>> understand what was said about it, all components are loaded, they register 
>>> their parameters and them based on user selection some the them are 
>>> unloaded. Thus my question is: from the tools perspective what is the 
>>> interest of knowing that a special MPI_T parameter exists but not be able 
>>> 

Re: [OMPI devel] ompi_info

[Jeff Squyres (jsquyres)]

I've now talked to both George and Nathan.  Let me summarize for the web 
archives / community:

1. There are two main points of contention:

   1a. ompi_info has a *very long-standing precedent* behavior of using 
 MCA params to exclude the display of components (and their params). 
Users have come to rely on this behavior to test that OMPI is honoring their 
$HOME/.openmpi-mca-params.conf file (for example) because -- at least prior to 
new ompi_info -- there was no other way to verify that.

   1b. It seems meaningless for MPI_T_Init to open *all* components when we're 
just going to be exposing a bunch of components/parameters that will not be 
used.  Easy example: MPI_T_Init will open all the PMLs, but we'll only end up 
using one of them.  Why have all the rest?

2. After talking to Nathan, here's our answers:

   2a. Fair enough.  The long-standing ompi_info behavior precedent alone is 
probably enough to warrant re-thinking the new ompi_info behavior.  Nathan will 
implement a compromise (that George was ok with when I talked on the phone with 
him).  If you have a  parameter somewhere that disables components 
(e.g., $HOME/.openmpi-mca-params.conf contains "btl = tcp,sm,self"), then 
ompi_info will somehow mark those components' parameters as "inactive" in the 
prettyprint and parseable outputs

   2b. Nathan reminded me why we chose to do this.  It requires a little 
explanation...

One thing to remember: MPI_T parameters *are* MCA parameters.  Hence, the 
btl_tcp_if_include MCA parameter is also the btl_tcp_if_include MPI_T 
parameter.  Put differently: MPI_T and MCA are two interfaces to the same 
back-end variables.

Something to note: if you call MPI_Init and then later call MPI_T_init, the 
latter is effectively a no-op.

The interesting case is when you call MPI_T_init before you call MPI_Init.  In 
this case, as has been noted in this thread: we open all components in all 
frameworks.

However: what hasn't been noted is that during the subsequent MPI_Init, we do 
normal selection *and will close unused components* (which also un-registers 
all their corresponding MPI_T/MCA parameters).  For example:

1. During MPI_T_init, we'll open all the PMLs: CM, OB1, etc.

2. Subsequent calls to MPI_T functions can *set* MPI_T/MCA params.  For 
example, you can use MPI_T to pick the ob1 PML.

3. When MPI_Init is finally invoked, normal MPI_Init flow is observed; if an 
MCA param was set to, for example, pick the PML, it will be honored and the 
non-selected PMLs will be closed.  Consequently, all the MPI_T/MCA params for 
the closed components will disappear from MPI_T (which is allowed by the spec). 
 Continuing the example from #2, the CM PML will be closed, and all of its 
MPI_T/MCA params will disappear.

Put simply: the point of opening *all* frameworks/components is to find out 
what all the params are so that the window of time represented by #2 can be 
utilized to examine/set MCA params as you want before you go into the "normal" 
MPI process 

So I think we're ok from this standpoint.




On Jul 19, 2013, at 10:29 AM, "Jeff Squyres (jsquyres)"  
wrote:

> George and I talked about this on the phone; I understand his questions 
> better now.
> 
> Nathan and I will get together and work through his questions and come back 
> to everyone with some answers / proposals.
> 
> 
> On Jul 19, 2013, at 9:27 AM, George Bosilca  wrote:
> 
>> 
>> My point is the following. I favor consistent behaviors and I'm always in 
>> favor of respecting the configuration files. ALWAYS like in the word that 
>> mean all cases without exception. Thus, by default, ompi_info as any other 
>> component of the Open MPI infrastructure MUST read the configuration files 
>> and respect all options provided there. And here was another inconsistency 
>> on the "new" approach. ompi_info reports some of the values (like the eager 
>> size and friends), while deciding to ignore others (like the list of the 
>> active PML and BTL).
>> 
>> I do concede that there are cases where we need something slightly 
>> different, maybe as a convenience. If there is a need for a special case for 
>> ompi_info to ignore the configuration files, let's add it. But do't make it 
>> the default, instead request a special command line argument for it.
>> 
>> There were several mentions about he MPI_T in this discussion. If I 
>> understand what was said about it, all components are loaded, they register 
>> their parameters and them based on user selection some the them are 
>> unloaded. Thus my question is: from the tools perspective what is the 
>> interest of knowing that a special MPI_T parameter exists but not be able to 
>> use it (because the originator component was meanwhile unloaded)? 
>> 
>> George.
>> 
>> 
>> On Jul 18, 2013, at 18:12 , "Jeff Squyres (jsquyres)"  
>> wrote:
>> 
>>> On Jul 18, 2013, at 11:50 AM, George Bosilca  wrote:
>>> 
 How is this 

Re: [OMPI devel] ompi_info

[George Bosilca]

My point is the following. I favor consistent behaviors and I'm always in favor 
of respecting the configuration files. ALWAYS like in the word that mean all 
cases without exception. Thus, by default, ompi_info as any other component of 
the Open MPI infrastructure MUST read the configuration files and respect all 
options provided there. And here was another inconsistency on the "new" 
approach. ompi_info reports some of the values (like the eager size and 
friends), while deciding to ignore others (like the list of the active PML and 
BTL).

I do concede that there are cases where we need something slightly different, 
maybe as a convenience. If there is a need for a special case for ompi_info to 
ignore the configuration files, let's add it. But do't make it the default, 
instead request a special command line argument for it.

There were several mentions about he MPI_T in this discussion. If I understand 
what was said about it, all components are loaded, they register their 
parameters and them based on user selection some the them are unloaded. Thus my 
question is: from the tools perspective what is the interest of knowing that a 
special MPI_T parameter exists but not be able to use it (because the 
originator component was meanwhile unloaded)? 

  George.


On Jul 18, 2013, at 18:12 , "Jeff Squyres (jsquyres)"  
wrote:

> On Jul 18, 2013, at 11:50 AM, George Bosilca  wrote:
> 
>> How is this part of the code validated? It might capitalize on some type of 
>> "trust". Unfortunately … I have no such notion.
> 
> Not sure what you're asking here.
> 
>> I would rather take the path of the "least astonishment", a __consistent__ 
>> behavior where we always abide to the configuration files (user level as 
>> well as system level). If you want to see every single parameter possibly 
>> available to you (based on your rights of course), temporary remove the 
>> configuration file. Or we can provide a specific ompi_info option to ignore 
>> the configuration files, but not make this the default.
> 
> 
> I think MPI applications and ompi_info are different cases.
> 
> 1. We've definitely had cases of user (and OMPI developer!) confusion over 
> the years where people would run ompi_info and not see their favorite MCA 
> component listed.  After a while, they figured out it was because they had an 
> env variable/file limiting which components were used (e.g., 
> OMPI_MCA_btl=sm,tcp,self would silently disable all other BTLs in ompi_info 
> output).  This actually seems to be fairly counter-intuitive behavior, if you 
> ask me -- it was done this way as an artifact of the old implementation 
> architecture.
> 
> Personally, I think changing ompi_info's behavior to always listing all 
> components is a good idea.  Is there a reason to be concerned about the 
> memory footprint and IO traffic of running ompi_info?
> 
> What might be a useful addition, however, is in the above example (user has 
> OMPI_MCA_btl=sm,tcp,self in their environment) to somehow mark all other BTL 
> params as "inactive because of OMPI_MCA_BTL env variable value", or something 
> like that.
> 
> *** If someone wants this behavior, please propose a specific way to mark 
> prettyprint and parsable ompi_info output.
> 
> 2. MPI application behavior has not changed -- if you call MPI_Init, we open 
> exactly the same frameworks/components that were opened before.  But if 
> you're using a tool (i.e., call the MPI_T init function), then you pay an 
> extra price (potentially more dlopens, more memory usage, etc.).  This is the 
> same as it has always been for tools: tools cost something (memory, 
> performance, whatever).
> 
> That being said, if you want a different behavior, please propose something 
> specific (e.g., specific new MCA param + value(s) for specific behavior(s)).
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] ompi_info

[Jeff Squyres (jsquyres)]

On Jul 18, 2013, at 11:50 AM, George Bosilca  wrote:

> How is this part of the code validated? It might capitalize on some type of 
> "trust". Unfortunately … I have no such notion.

Not sure what you're asking here.

> I would rather take the path of the "least astonishment", a __consistent__ 
> behavior where we always abide to the configuration files (user level as well 
> as system level). If you want to see every single parameter possibly 
> available to you (based on your rights of course), temporary remove the 
> configuration file. Or we can provide a specific ompi_info option to ignore 
> the configuration files, but not make this the default.


I think MPI applications and ompi_info are different cases.

1. We've definitely had cases of user (and OMPI developer!) confusion over the 
years where people would run ompi_info and not see their favorite MCA component 
listed.  After a while, they figured out it was because they had an env 
variable/file limiting which components were used (e.g., 
OMPI_MCA_btl=sm,tcp,self would silently disable all other BTLs in ompi_info 
output).  This actually seems to be fairly counter-intuitive behavior, if you 
ask me -- it was done this way as an artifact of the old implementation 
architecture.

Personally, I think changing ompi_info's behavior to always listing all 
components is a good idea.  Is there a reason to be concerned about the memory 
footprint and IO traffic of running ompi_info?

What might be a useful addition, however, is in the above example (user has 
OMPI_MCA_btl=sm,tcp,self in their environment) to somehow mark all other BTL 
params as "inactive because of OMPI_MCA_BTL env variable value", or something 
like that.

*** If someone wants this behavior, please propose a specific way to mark 
prettyprint and parsable ompi_info output.

2. MPI application behavior has not changed -- if you call MPI_Init, we open 
exactly the same frameworks/components that were opened before.  But if you're 
using a tool (i.e., call the MPI_T init function), then you pay an extra price 
(potentially more dlopens, more memory usage, etc.).  This is the same as it 
has always been for tools: tools cost something (memory, performance, whatever).

That being said, if you want a different behavior, please propose something 
specific (e.g., specific new MCA param + value(s) for specific behavior(s)).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] ompi_info

[Nathan Hjelm]

On Thu, Jul 18, 2013 at 05:50:40PM +0200, George Bosilca wrote:
> On Jul 18, 2013, at 17:07 , Nathan Hjelm  wrote:
> 
> > This was discussed in depth before the MCA rewrite came into the trunk. 
> > There are only two cases where we load and register all the available 
> > components: ompi_info, and MPI_T_init_thread(). The normal MPI case does 
> > not have this behavior and instead loads only the requested components.
> 
> How is this part of the code validated? It might capitalize on some type of 
> "trust". Unfortunately ? I have no such notion.

The fact that ompi_mpi_init never call ompi_info_register_params() which is the 
only path that sets the MCA_BASE_REGISTER_ALL when registering framework 
pameters. The register all behavior has to be explicitly asked for.

> I would rather take the path of the "least astonishment", a __consistent__ 
> behavior where we always abide to the configuration files (user level as well 
> as system level). If you want to see every single parameter possibly 
> available to you (based on your rights of course), temporary remove the 
> configuration file. Or we can provide a specific ompi_info option to ignore 
> the configuration files, but not make this the default.

In some ways this was the default behavior (if no file values were set). The 
current behavior was chosen to be consistent and reflect what I thought was the 
original intent. The old behavior would ignore component selection variables 
set in the environment (ompi_info actually unset them). So, if you set one of 
these variables in the environment (or the ompi_info command line) you would 1) 
still get all components in the framework, and 2) not see the variable as set 
even though it is in an actual run.

So, if I did:

export OMPI_MCA_btl=self,sm

or added --mca btl self,sm to the ompi_info command line

I would still see all the btls + this:

 MCA btl: parameter "btl" (current value: "", data source: 
default, level: 2 user/detail, type: string)
  Default selection set of components for the btl 
framework ( means use all components that can be found)

instead of:

 MCA btl: parameter "btl" (current value: "self,sm", data 
source: environment, level: 2 user/detail, type: string)
  Default selection set of components for the btl 
framework ( means use all components that can be found)

Very annoying!

That said. The register all behavior is easy to control. If there is a 
consensus that we need another ompi_info option I am more than happy to add it. 
But then again, --all should mean all components, all frameworks, all levels. 

-Nathan

Re: [OMPI devel] ompi_info

[Nathan Hjelm]

On Thu, Jul 18, 2013 at 08:33:37AM -0700, Ralph Castain wrote:
> 
> On Jul 18, 2013, at 8:17 AM, "David Goodell (dgoodell)"  
> wrote:
> 
> > On Jul 18, 2013, at 9:53 AM, Ralph Castain  wrote:
> > 
> >> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell)  
> >> wrote:
> >> 
> >>> On Jul 18, 2013, at 8:06 AM, Ralph Castain  wrote:
> >>> 
>  That's a good point, and a bad behavior. IIRC, it results from the MPI 
>  Forum's adoption of the MPI-T requirement that stipulates we must allow 
>  access to all control and performance variables at startup so they can 
>  be externally seen/manipulated.
> >>> 
> >>> Minor nit: MPI_T does not require this.  However, it does recommend that 
> >>> you offer users access to as many variables as possible as early as 
> >>> reasonably possible for the convenience and control of the user.
> >>> 
> >>> If an implementation chooses to offer 5% of the possible 
> >>> control/performance variables to the user just before MPI_Finalize, 
> >>> that's still a valid MPI_T implementation.  But it may not be a very 
> >>> useful one...
> >> 
> >> The problem here is one of use vs startup performance. George is quite 
> >> correct with his concerns - this behavior would have been a serious 
> >> problem for RoadRunner, for example, where we had a small IO channel 
> >> feeding a lot of nodes. It will definitely become an issue at exascale 
> >> where IO bandwidth and memory will be at a premium.
> > 
> > My point was not that the performance concerns were unfounded.  Rather, I 
> > wanted to point out that the "load everything" behavior is not a hard 
> > requirement from the MPI standard, so we have room for different 
> > implementation choices/tradeoffs.
> 
> I understood - I was more just pointing out the potential performance issue 
> of load everything. However, Nathan has addressed it by pointing out that the 
> problem is my aged, fading memory.

So, I think what I can take from this discussion to to make the following 
changes to ompi_info:

 - Make --all without a --level option imply --level 9.

 - Allow the user to modify this behavior by specifying a level: ex --all 
--level 5 would print every variable up to level 5.

I will make these changes today and CMR them into 1.7.3 unless there are any 
objections.

-Nathan

Re: [OMPI devel] ompi_info

[Ralph Castain]

On Jul 18, 2013, at 8:17 AM, "David Goodell (dgoodell)"  
wrote:

> On Jul 18, 2013, at 9:53 AM, Ralph Castain  wrote:
> 
>> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell)  
>> wrote:
>> 
>>> On Jul 18, 2013, at 8:06 AM, Ralph Castain  wrote:
>>> 
 That's a good point, and a bad behavior. IIRC, it results from the MPI 
 Forum's adoption of the MPI-T requirement that stipulates we must allow 
 access to all control and performance variables at startup so they can be 
 externally seen/manipulated.
>>> 
>>> Minor nit: MPI_T does not require this.  However, it does recommend that 
>>> you offer users access to as many variables as possible as early as 
>>> reasonably possible for the convenience and control of the user.
>>> 
>>> If an implementation chooses to offer 5% of the possible 
>>> control/performance variables to the user just before MPI_Finalize, that's 
>>> still a valid MPI_T implementation.  But it may not be a very useful one...
>> 
>> The problem here is one of use vs startup performance. George is quite 
>> correct with his concerns - this behavior would have been a serious problem 
>> for RoadRunner, for example, where we had a small IO channel feeding a lot 
>> of nodes. It will definitely become an issue at exascale where IO bandwidth 
>> and memory will be at a premium.
> 
> My point was not that the performance concerns were unfounded.  Rather, I 
> wanted to point out that the "load everything" behavior is not a hard 
> requirement from the MPI standard, so we have room for different 
> implementation choices/tradeoffs.

I understood - I was more just pointing out the potential performance issue of 
load everything. However, Nathan has addressed it by pointing out that the 
problem is my aged, fading memory.

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

Re: [OMPI devel] ompi_info

[David Goodell (dgoodell)]

On Jul 18, 2013, at 9:53 AM, Ralph Castain  wrote:

> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell)  
> wrote:
> 
>> On Jul 18, 2013, at 8:06 AM, Ralph Castain  wrote:
>> 
>>> That's a good point, and a bad behavior. IIRC, it results from the MPI 
>>> Forum's adoption of the MPI-T requirement that stipulates we must allow 
>>> access to all control and performance variables at startup so they can be 
>>> externally seen/manipulated.
>> 
>> Minor nit: MPI_T does not require this.  However, it does recommend that you 
>> offer users access to as many variables as possible as early as reasonably 
>> possible for the convenience and control of the user.
>> 
>> If an implementation chooses to offer 5% of the possible control/performance 
>> variables to the user just before MPI_Finalize, that's still a valid MPI_T 
>> implementation.  But it may not be a very useful one...
> 
> The problem here is one of use vs startup performance. George is quite 
> correct with his concerns - this behavior would have been a serious problem 
> for RoadRunner, for example, where we had a small IO channel feeding a lot of 
> nodes. It will definitely become an issue at exascale where IO bandwidth and 
> memory will be at a premium.

My point was not that the performance concerns were unfounded.  Rather, I 
wanted to point out that the "load everything" behavior is not a hard 
requirement from the MPI standard, so we have room for different implementation 
choices/tradeoffs.

-Dave

Re: [OMPI devel] ompi_info

[Ralph Castain]

On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell)  
wrote:

> On Jul 18, 2013, at 8:06 AM, Ralph Castain  wrote:
> 
>> That's a good point, and a bad behavior. IIRC, it results from the MPI 
>> Forum's adoption of the MPI-T requirement that stipulates we must allow 
>> access to all control and performance variables at startup so they can be 
>> externally seen/manipulated.
> 
> Minor nit: MPI_T does not require this.  However, it does recommend that you 
> offer users access to as many variables as possible as early as reasonably 
> possible for the convenience and control of the user.
> 
> If an implementation chooses to offer 5% of the possible control/performance 
> variables to the user just before MPI_Finalize, that's still a valid MPI_T 
> implementation.  But it may not be a very useful one...

The problem here is one of use vs startup performance. George is quite correct 
with his concerns - this behavior would have been a serious problem for 
RoadRunner, for example, where we had a small IO channel feeding a lot of 
nodes. It will definitely become an issue at exascale where IO bandwidth and 
memory will be at a premium.

This is especially troubling when you consider how few people will ever use 
this capability. Perhaps we should offer a switch that says "I want access to 
MPI-T" so that the rest of the world isn't hammered by this kind of behavior?


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

Re: [OMPI devel] ompi_info

[George Bosilca]

On Jul 18, 2013, at 15:06 , Ralph Castain  wrote:

 I think ompi_info has always shown all the variables despite what you have 
 the selection variable set (at least in some cases). We now just display 
 everything in all cases. An additional benefit to the updated code is that 
 if you set a selection variable through the environment 
 (OMPI_MCA_btl=self,sm) it no longer appears as unset in ompi_info. The old 
 code unset all selection variables in order to ensure all parameters got 
 printed (very annoying but necessary).
>> 
>> Ralph comment above is not accurate. Prior to this change (well the one from 
>> few weeks ago), explicitly forbidden components did not leave traces in the 
>> MCA parameters list. I validate this with the latest stable.
> 
> FWIW: that wasn't my comment

Sorry Ralph I was wrong, the comment was from Nathan. This discussion grew out 
of hand, it became difficult to follow who said what and when.

  George.

Re: [OMPI devel] ompi_info

[David Goodell (dgoodell)]

On Jul 18, 2013, at 8:06 AM, Ralph Castain  wrote:

> That's a good point, and a bad behavior. IIRC, it results from the MPI 
> Forum's adoption of the MPI-T requirement that stipulates we must allow 
> access to all control and performance variables at startup so they can be 
> externally seen/manipulated.

Minor nit: MPI_T does not require this.  However, it does recommend that you 
offer users access to as many variables as possible as early as reasonably 
possible for the convenience and control of the user.

If an implementation chooses to offer 5% of the possible control/performance 
variables to the user just before MPI_Finalize, that's still a valid MPI_T 
implementation.  But it may not be a very useful one...

-Dave

Re: [OMPI devel] ompi_info

[George Bosilca]

On Jul 17, 2013, at 20:15 , "Jeff Squyres (jsquyres)"  
wrote:

> On Jul 17, 2013, at 12:16 PM, Nathan Hjelm  wrote:
> 
>> As Ralph suggested you need to pass the --level or -l option to see all the 
>> variables. --level 9 will print everything. If you think there are variables 
>> everyday users should see you are welcome to change them to OPAL_INFO_LVL_1. 
>> We are trying to avoid moving too many variables to this info level.
> 
> I think George might have a point here, though.  He was specifically asking 
> about the --all option, right?
> 
> I think it might be reasonable for "ompi_info --all" to actually show *all* 
> MCA params (up through level 9).

Thanks Jeff,

I'm totally puzzled by the divergence in opinion in this community on the word 
ALL. ALL like in "every single one of them", not like in "4 poorly chosen MCA 
arguments that I don't even know how to care about".

> Thoughts?

Give back to the word ALL it's original meaning: "the whole quantity or extent 
of a group". 

> 
>>> Btw, something is wrong i the following output. I have an "btl = sm,self" 
>>> in my .openmpi/mca-params.conf so I should not even see the BTL TCP 
>>> parameters.
>> 
>> I think ompi_info has always shown all the variables despite what you have 
>> the selection variable set (at least in some cases). We now just display 
>> everything in all cases. An additional benefit to the updated code is that 
>> if you set a selection variable through the environment 
>> (OMPI_MCA_btl=self,sm) it no longer appears as unset in ompi_info. The old 
>> code unset all selection variables in order to ensure all parameters got 
>> printed (very annoying but necessary).

Ralph comment above is not accurate. Prior to this change (well the one from 
few weeks ago), explicitly forbidden components did not leave traces in the MCA 
parameters list. I validate this with the latest stable.

> Yes, I think I like this new behavior better, too.
> 
> Does anyone violently disagree?

Yes. This behavior means the every single MPI process out there will 1) load 
all existing .so components, and 2) will give them a chance to leave undesired 
traces in the memory of the application. So first we generate an increased I/O 
traffic, and 2) we use memory that shouldn't be used. We can argue about the 
impact of all this, but from my perspective what I see is that Open MPI is 
doing it when explicit arguments to prevent the usage of these component were 
provided.

  George.

> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] ompi_info

[Nathan Hjelm]

On Wed, Jul 17, 2013 at 03:04:06AM +0200, George Bosilca wrote:
> I would like to question the choice for the new ? spartan ompi_info output? I 
> would not mind restoring the default behavior, aka. have a verbose "--all", 
> instead of some [random] MCA params.

As Ralph suggested you need to pass the --level or -l option to see all the 
variables. --level 9 will print everything. If you think there are variables 
everyday users should see you are welcome to change them to OPAL_INFO_LVL_1. We 
are trying to avoid moving too many variables to this info level.

> Btw, something is wrong i the following output. I have an "btl = sm,self" in 
> my .openmpi/mca-params.conf so I should not even see the BTL TCP parameters.

I think ompi_info has always shown all the variables despite what you have the 
selection variable set (at least in some cases). We now just display everything 
in all cases. An additional benefit to the updated code is that if you set a 
selection variable through the environment (OMPI_MCA_btl=self,sm) it no longer 
appears as unset in ompi_info. The old code unset all selection variables in 
order to ensure all parameters got printed (very annoying but necessary).

-Nathan

Re: [OMPI devel] ompi_info

[Ralph Castain]

On Jul 16, 2013, at 6:04 PM, George Bosilca  wrote:

> I would like to question the choice for the new … spartan ompi_info output?

I won't debate the logic - I'll leave that to Jeff and Nathan

> I would not mind restoring the default behavior, aka. have a verbose "--all", 
> instead of some [random] MCA params.

I believe you need to add -level 9 to your ompi_info cmd and you should see 
everything?

> 
> Btw, something is wrong i the following output. I have an "btl = sm,self" in 
> my .openmpi/mca-params.conf so I should not even see the BTL TCP parameters.

Param registration is now separate from "open", so all components register 
their variables even if they will be later ignored.

> 
> Thanks,
>  George.
> 
> 
> $ompi_info --param all all
> MCA btl: parameter "btl_tcp_if_include" (current value: "",
>  data source: default, level: 1 user/basic, type:
>  string)
>  Comma-delimited list of devices and/or CIDR
>  notation of networks to use for MPI communication
>  (e.g., "eth0,192.168.0.0/16").  Mutually exclusive
>  with btl_tcp_if_exclude.
> MCA btl: parameter "btl_tcp_if_exclude" (current value:
>  "127.0.0.1/8,sppp", data source: default, level: 1
>  user/basic, type: string)
>  Comma-delimited list of devices and/or CIDR
>  notation of networks to NOT use for MPI
>  communication -- all devices not matching these
>  specifications will be used (e.g.,
>  "eth0,192.168.0.0/16").  If set to a non-default
>  value, it is mutually exclusive with
>  btl_tcp_if_include.
> MCA pml: performance "pml_ob1_unexpected_msgq_length" (type:
>  unsigned, class: size)
>  Number of unexpected messages received by each peer
>  in a communicator
> MCA pml: performance "pml_ob1_posted_recvq_length" (type:
>  unsigned, class: size)
>  Number of unmatched receives posted for each peer
>  in a communicator
> 
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] ompi_info

[George Bosilca]

I would like to question the choice for the new … spartan ompi_info output? I 
would not mind restoring the default behavior, aka. have a verbose "--all", 
instead of some [random] MCA params.

Btw, something is wrong i the following output. I have an "btl = sm,self" in my 
.openmpi/mca-params.conf so I should not even see the BTL TCP parameters.

Thanks,
  George.


$ompi_info --param all all
 MCA btl: parameter "btl_tcp_if_include" (current value: "",
  data source: default, level: 1 user/basic, type:
  string)
  Comma-delimited list of devices and/or CIDR
  notation of networks to use for MPI communication
  (e.g., "eth0,192.168.0.0/16").  Mutually exclusive
  with btl_tcp_if_exclude.
 MCA btl: parameter "btl_tcp_if_exclude" (current value:
  "127.0.0.1/8,sppp", data source: default, level: 1
  user/basic, type: string)
  Comma-delimited list of devices and/or CIDR
  notation of networks to NOT use for MPI
  communication -- all devices not matching these
  specifications will be used (e.g.,
  "eth0,192.168.0.0/16").  If set to a non-default
  value, it is mutually exclusive with
  btl_tcp_if_include.
 MCA pml: performance "pml_ob1_unexpected_msgq_length" (type:
  unsigned, class: size)
  Number of unexpected messages received by each peer
  in a communicator
 MCA pml: performance "pml_ob1_posted_recvq_length" (type:
  unsigned, class: size)
  Number of unmatched receives posted for each peer
  in a communicator

Re: [OMPI devel] ompi_info requesting CPUs?

[Eugene Loh]

Ralph Castain wrote:


does it exist in 1.3.4?


Yes, e.g., 22103 and 22104.


if so, it was a trivial change - can't see why  it couldn't be added.

On Oct 20, 2009, at 3:53 AM, Terry Dontje wrote:

Not that I want to delay 1.3.4 anymore than it has been but this  
seems like a possible blocker.  Can this be CMR'd for 1.3.4 or is  
this truly a 1.4 CMR?


Ralph Castain wrote:


Fixed in r22111

On Oct 19, 2009, at 8:13 PM, Eugene Loh wrote:

Somewhere between r22090 and r22109, ompi_info started  
(erroneously) requesting CPUs.


E.g., r22090 is good:

% ompi_info | grep Open MPI:
 Open MPI: 1.7a1r22090

But r22109 is bad:

% ompi_info | grep Open MPI:
-- 


Your job has requested more cpus per process(rank) than there
are cpus in a socket:

Cpus/rank: 1
#cpus/socket: 0

Please correct one or both of these values and try again.
-- 


A component framework failed to open properly.
ompi_info will likely not display all configuration information
 Open MPI: 1.7a1r22109

Re: [OMPI devel] ompi_info requesting CPUs?

[Ralph Castain]

Fixed in r22111

Thanks

On Oct 19, 2009, at 8:13 PM, Eugene Loh wrote:

Somewhere between r22090 and r22109, ompi_info started (erroneously)  
requesting CPUs.


E.g., r22090 is good:

% ompi_info | grep Open MPI:
  Open MPI: 1.7a1r22090

But r22109 is bad:

% ompi_info | grep Open MPI:
--
Your job has requested more cpus per process(rank) than there
are cpus in a socket:

Cpus/rank: 1
#cpus/socket: 0

Please correct one or both of these values and try again.
--
A component framework failed to open properly.
ompi_info will likely not display all configuration information
  Open MPI: 1.7a1r22109

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

[OMPI devel] ompi_info requesting CPUs?

[Eugene Loh]

Somewhere between r22090 and r22109, ompi_info started (erroneously) 
requesting CPUs.


E.g., r22090 is good:

% ompi_info | grep Open MPI:
   Open MPI: 1.7a1r22090

But r22109 is bad:

% ompi_info | grep Open MPI:
--
Your job has requested more cpus per process(rank) than there
are cpus in a socket:

 Cpus/rank: 1
 #cpus/socket: 0

Please correct one or both of these values and try again.
--
A component framework failed to open properly.
ompi_info will likely not display all configuration information
   Open MPI: 1.7a1r22109