February 2017 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] MPI Tools WG cancelled 2/23
by rhc＠open-mpi.org 22 Feb '17

22 Feb '17

AHHHH...SHUCKS!! I really wanted to have our meeting...sniff. > On Feb 22, 2017, at 2:29 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > > HI all, <> > > Since the forum is next week, I am going to cancel tomorrow’s meeting and save our energy and time for the face to face. > > The Tools WG meetings at the forum will follow the normal pattern: debugger discussions Monday afternoon (Pacific time) and tools discussions Tuesday morning (Pacific). The exact times and webex information are on the Forum agenda page: http://mpi-forum.org/meetings/2017/02/agenda <http://mpi-forum.org/meetings/2017/02/agenda> > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov <mailto:[email protected]>, http://scalability.llnl.gov/ <http://scalability.llnl.gov/> > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools>

1 0

Re: [mpiwg-tools] MPI Tools WG cancelled 2/23
by Mohror, Kathryn 22 Feb '17

22 Feb '17

HI all, Since the forum is next week, I am going to cancel tomorrow's meeting and save our energy and time for the face to face. The Tools WG meetings at the forum will follow the normal pattern: debugger discussions Monday afternoon (Pacific time) and tools discussions Tuesday morning (Pacific). The exact times and webex information are on the Forum agenda page: http://mpi-forum.org/meetings/2017/02/agenda Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

No call tomorrow: Feb 16, 2017
by Marc-Andre Hermanns 15 Feb '17

15 Feb '17

Dear all, Unfortunately, I have to cancel tomorrows meeting. We'll continue the discussion on MPI_T events in two week during the face-to-face meeting. By then I hope to have updated the wiki page and uploaded the missing minutes. Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

notes from meetings
by Mohror, Kathryn 14 Feb '17

14 Feb '17

Hi all, In the spirit of 'better late than never' I have updated meeting notes pages for the last two meetings. - https://github.com/mpiwg-tools/tools-issues/wiki/Notes-2017-01-12 : Now has the slides John presented - https://github.com/mpiwg-tools/tools-issues/wiki/Notes-2017-01-26 : Now has notes! And the build/test outline for PMIx that John wrote Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

MPI Tools WG cancelled 2/9
by Mohror, Kathryn 04 Feb '17

04 Feb '17

Hi all, This is a reminder that the regular debugger meeting for this week 2/9 is cancelled. We plan to pick it back up on 2/23. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Jeff Squyres (jsquyres) 03 Feb '17

03 Feb '17

On Feb 3, 2017, at 9:19 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: > > If implemented, I would recommend that the MPI Forum would get a CID > as well. This would enable us to define specific variables and events > across implementations (if they choose to provide them). > > Then, we can start thinking about standardizing some variable and > events that are available in multiple implementations anyway. Hmm. Interesting concept. That will either lead to a giant "WIN!" or madness. I'm not sure which. :-) -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Marc-Andre Hermanns 03 Feb '17

03 Feb '17

Hi Jeff, yes, that is good news. If implemented, I would recommend that the MPI Forum would get a CID as well. This would enable us to define specific variables and events across implementations (if they choose to provide them). Then, we can start thinking about standardizing some variable and events that are available in multiple implementations anyway. Cheers, Marc-Andre On 03.02.2017 15:05, Jeff Squyres (jsquyres) wrote: > I have confirmed with the IEEE Registration authority that an open source software project can purchase a CID. > > Hence, the scheme listed below would seem to work well -- our (logical) vendor ID can be an IEEE OUI or CID, because they hold the desired properties: > > - they are both 24 bits long > - OUIs and CIDs are guaranteed to be unique (both within their respective classes and from each other) > - hence, a single 24-bit parameter is suitable for holding either value > - IEEE maintains a world-wide registry of both OUIs and CIDs > - purchasing a CID is not cost-prohibitive > - purchasing a CID for use in this case is appropriate for software vendors (including open source projects) > > > >> On Feb 2, 2017, at 10:59 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> The more I look into this, the more it looks like we should use a CID and/or an OUI. >> >> The CID and OUI are both 24-bit IEEE-maintained numbers. >> >> CID = Company ID. Used for no particular purpose. >> OUI = Organization Unique ID. Used for Ethernet MAC address space reservation. >> >> While all networking vendors in the HPC space have OUIs, researchers and software tool vendors probably do not. We do not want researchers/software vendors to buy an OUI -- that would be a mis-use of global MAC address space. >> >> It looks like the CID was created for exactly this purpose: you need a globally unique number, but you do not need to reserve a range in in the MAC address space. >> >> The IEEE was clever enough to reserve 1 bit to tell the difference between an OUI and a CID. Hence: >> >> - all OUIs are distinct from all CIDs, and vice versa >> - if you care, you can tell if a given 24 bit value is a CID or OUI >> >> It looks like the purchase of a CID is $685 USD: http://standards.ieee.org/develop/regauth/cid/index.html >> >> http://standards.ieee.org/develop/regauth/tut/eui.pdf >> >> What I don't know yet is whether an open source software project can buy a CID or not. I have an email in to IEEE asking this question. >> >> >> >>> On Feb 2, 2017, at 8:21 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>> >>> On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >>>> >>>> I did not want to mandate a specific length. The way I understand it >>>> is that the ID is an integer of some length, where parts can be masked >>>> and queried for information. >>> >>> I think what I was trying to say (poorly) was that I am proposing a *logical* tuple. How long each item is in the tuple, and how we map that to C types are different questions. >>> >>> Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value. >>> >>>> In my last mail, yes, but I do acknowledge that additional fields are >>>> necessary. I just asked about the vendor ID, as that is the one mostly >>>> regulated, right? The vendors are free to use the remaining bits as >>>> they see fit, right? >>> >>> I would think so. >>> >>>> Yes, I read about the OUI. As far as I know, these are _bought_ from >>>> and controlled by IEEE. How would an MPI vendor obtain one of those to >>>> use for software events from inside the MPI? >>> >>> Buy one. >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools > > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Wilhelm-Johnen-Str. 52425 Jülich Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Jeff Squyres (jsquyres) 03 Feb '17

03 Feb '17

I have confirmed with the IEEE Registration authority that an open source software project can purchase a CID. Hence, the scheme listed below would seem to work well -- our (logical) vendor ID can be an IEEE OUI or CID, because they hold the desired properties: - they are both 24 bits long - OUIs and CIDs are guaranteed to be unique (both within their respective classes and from each other) - hence, a single 24-bit parameter is suitable for holding either value - IEEE maintains a world-wide registry of both OUIs and CIDs - purchasing a CID is not cost-prohibitive - purchasing a CID for use in this case is appropriate for software vendors (including open source projects) > On Feb 2, 2017, at 10:59 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > The more I look into this, the more it looks like we should use a CID and/or an OUI. > > The CID and OUI are both 24-bit IEEE-maintained numbers. > > CID = Company ID. Used for no particular purpose. > OUI = Organization Unique ID. Used for Ethernet MAC address space reservation. > > While all networking vendors in the HPC space have OUIs, researchers and software tool vendors probably do not. We do not want researchers/software vendors to buy an OUI -- that would be a mis-use of global MAC address space. > > It looks like the CID was created for exactly this purpose: you need a globally unique number, but you do not need to reserve a range in in the MAC address space. > > The IEEE was clever enough to reserve 1 bit to tell the difference between an OUI and a CID. Hence: > > - all OUIs are distinct from all CIDs, and vice versa > - if you care, you can tell if a given 24 bit value is a CID or OUI > > It looks like the purchase of a CID is $685 USD: http://standards.ieee.org/develop/regauth/cid/index.html > > http://standards.ieee.org/develop/regauth/tut/eui.pdf > > What I don't know yet is whether an open source software project can buy a CID or not. I have an email in to IEEE asking this question. > > > >> On Feb 2, 2017, at 8:21 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >>> >>> I did not want to mandate a specific length. The way I understand it >>> is that the ID is an integer of some length, where parts can be masked >>> and queried for information. >> >> I think what I was trying to say (poorly) was that I am proposing a *logical* tuple. How long each item is in the tuple, and how we map that to C types are different questions. >> >> Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value. >> >>> In my last mail, yes, but I do acknowledge that additional fields are >>> necessary. I just asked about the vendor ID, as that is the one mostly >>> regulated, right? The vendors are free to use the remaining bits as >>> they see fit, right? >> >> I would think so. >> >>> Yes, I read about the OUI. As far as I know, these are _bought_ from >>> and controlled by IEEE. How would an MPI vendor obtain one of those to >>> use for software events from inside the MPI? >> >> Buy one. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> > > > -- > Jeff Squyres > jsquyres(a)cisco.com > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Jeff Squyres (jsquyres) 02 Feb '17

02 Feb '17

The more I look into this, the more it looks like we should use a CID and/or an OUI. The CID and OUI are both 24-bit IEEE-maintained numbers. CID = Company ID. Used for no particular purpose. OUI = Organization Unique ID. Used for Ethernet MAC address space reservation. While all networking vendors in the HPC space have OUIs, researchers and software tool vendors probably do not. We do not want researchers/software vendors to buy an OUI -- that would be a mis-use of global MAC address space. It looks like the CID was created for exactly this purpose: you need a globally unique number, but you do not need to reserve a range in in the MAC address space. The IEEE was clever enough to reserve 1 bit to tell the difference between an OUI and a CID. Hence: - all OUIs are distinct from all CIDs, and vice versa - if you care, you can tell if a given 24 bit value is a CID or OUI It looks like the purchase of a CID is $685 USD: http://standards.ieee.org/develop/regauth/cid/index.html http://standards.ieee.org/develop/regauth/tut/eui.pdf What I don't know yet is whether an open source software project can buy a CID or not. I have an email in to IEEE asking this question. > On Feb 2, 2017, at 8:21 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >> >> I did not want to mandate a specific length. The way I understand it >> is that the ID is an integer of some length, where parts can be masked >> and queried for information. > > I think what I was trying to say (poorly) was that I am proposing a *logical* tuple. How long each item is in the tuple, and how we map that to C types are different questions. > > Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value. > >> In my last mail, yes, but I do acknowledge that additional fields are >> necessary. I just asked about the vendor ID, as that is the one mostly >> regulated, right? The vendors are free to use the remaining bits as >> they see fit, right? > > I would think so. > >> Yes, I read about the OUI. As far as I know, these are _bought_ from >> and controlled by IEEE. How would an MPI vendor obtain one of those to >> use for software events from inside the MPI? > > Buy one. > > -- > Jeff Squyres > jsquyres(a)cisco.com > -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017
by Jeff Squyres (jsquyres) 02 Feb '17

02 Feb '17

On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: > > I did not want to mandate a specific length. The way I understand it > is that the ID is an integer of some length, where parts can be masked > and queried for information. I think what I was trying to say (poorly) was that I am proposing a *logical* tuple. How long each item is in the tuple, and how we map that to C types are different questions. Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value. > In my last mail, yes, but I do acknowledge that additional fields are > necessary. I just asked about the vendor ID, as that is the one mostly > regulated, right? The vendors are free to use the remaining bits as > they see fit, right? I would think so. > Yes, I read about the OUI. As far as I know, these are _bought_ from > and controlled by IEEE. How would an MPI vendor obtain one of those to > use for software events from inside the MPI? Buy one. -- Jeff Squyres jsquyres(a)cisco.com

1 0