September 2013 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] reset a stopped pvar
by Junchao Zhang 19 Sep '13

19 Sep '13

[please ignore a duplicate email sent from my gmail] Also, for a stopped pvar, after reset and before restarting, what does a pvar_read return? Returning zero sounds good for counters? What about watermarks? Old value, garbage value or MPI_T_ERROR_XXX? I would choose ERROR. The side-effect is that it makes resetting pvars not beautiful. --Junchao Zhang On Thu, Sep 19, 2013 at 12:32 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: > Hmm, that is a good catch. I agree with Kathryn's interpretation - in > particular the use case she is laying out. If one does: > > Reset > Start > Stop > > You want the watermark from that interval, i.e., the starting value as of > the start call should be the right thing. This is something we definitely > should clarify. > > Thanks, > > Martin > > > > On Sep 18, 2013, at 8:33 PM, Kathryn Mohror <kathryn(a)llnl.gov> > wrote: > > Hi Junchao, > > What is the right behavior when resetting a stopped pvar? The standard > says setting to its starting value. > For counters, timers etc, setting them to zero sounds reasonable. > But for a watermark, setting it to "the current utilization level" looks > weird. It implies that a value caught during the stopped period can affect > its future value when the pvar is re-started. > Probably, we should reset a stopped watermark to a state as if it has > never been started. > Any comments? Thanks > > > Hmm. It makes sense to me, but I'll let others chime in if they disagree. > I think that the moment you start the watermark variable, you want to know > what the "mark" is, so it would be the value of current utilization. So > even if a higher (or lower) value is caught during the stopped period > (which it shouldn't be, because variables aren't supposed to be updated > when stopped), it will be set to the current utilization value when > started. I interpret this as being able to measure the watermark during > different epochs of the program execution. Every time you start the > variable, it's a fresh epoch and you want to know what the watermark was > during that epoch. > > However, I can see how this isn't clear as it could be -- I'll try to see > what we can do to clarify it in the text. > > Thanks again for taking the time to give us this feedback. > > Kathryn > > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] reset a stopped pvar
by Junchao Zhang 19 Sep '13

19 Sep '13

Also, for a stopped pvar, after reset and before restarting, what does a pvar_read return? Returning zero sounds good for counters? What about watermarks? Old value, garbage value or MPI_T_ERROR_XXX? I would choose ERROR. The side-effect is that it makes resetting pvars not beautiful. --Junchao Zhang On Thu, Sep 19, 2013 at 12:32 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: > Hmm, that is a good catch. I agree with Kathryn's interpretation - in > particular the use case she is laying out. If one does: > > Reset > Start > Stop > > You want the watermark from that interval, i.e., the starting value as of > the start call should be the right thing. This is something we definitely > should clarify. > > Thanks, > > Martin > > > > On Sep 18, 2013, at 8:33 PM, Kathryn Mohror <kathryn(a)llnl.gov> > wrote: > > Hi Junchao, > > What is the right behavior when resetting a stopped pvar? The standard > says setting to its starting value. > For counters, timers etc, setting them to zero sounds reasonable. > But for a watermark, setting it to "the current utilization level" looks > weird. It implies that a value caught during the stopped period can affect > its future value when the pvar is re-started. > Probably, we should reset a stopped watermark to a state as if it has > never been started. > Any comments? Thanks > > > Hmm. It makes sense to me, but I'll let others chime in if they disagree. > I think that the moment you start the watermark variable, you want to know > what the "mark" is, so it would be the value of current utilization. So > even if a higher (or lower) value is caught during the stopped period > (which it shouldn't be, because variables aren't supposed to be updated > when stopped), it will be set to the current utilization value when > started. I interpret this as being able to measure the watermark during > different epochs of the program execution. Every time you start the > variable, it's a fresh epoch and you want to know what the watermark was > during that epoch. > > However, I can see how this isn't clear as it could be -- I'll try to see > what we can do to clarify it in the text. > > Thanks again for taking the time to give us this feedback. > > Kathryn > > > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] reset a stopped pvar
by Martin Schulz 19 Sep '13

19 Sep '13

Hmm, that is a good catch. I agree with Kathryn's interpretation - in particular the use case she is laying out. If one does: Reset Start Stop You want the watermark from that interval, i.e., the starting value as of the start call should be the right thing. This is something we definitely should clarify. Thanks, Martin On Sep 18, 2013, at 8:33 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi Junchao, > >> What is the right behavior when resetting a stopped pvar? The standard says setting to its starting value. >> For counters, timers etc, setting them to zero sounds reasonable. >> But for a watermark, setting it to "the current utilization level" looks weird. It implies that a value caught during the stopped period can affect its future value when the pvar is re-started. >> Probably, we should reset a stopped watermark to a state as if it has never been started. >> Any comments? Thanks > > Hmm. It makes sense to me, but I'll let others chime in if they disagree. I think that the moment you start the watermark variable, you want to know what the "mark" is, so it would be the value of current utilization. So even if a higher (or lower) value is caught during the stopped period (which it shouldn't be, because variables aren't supposed to be updated when stopped), it will be set to the current utilization value when started. I interpret this as being able to measure the watermark during different epochs of the program execution. Every time you start the variable, it's a fresh epoch and you want to know what the watermark was during that epoch. > > However, I can see how this isn't clear as it could be -- I'll try to see what we can do to clarify it in the text. > > Thanks again for taking the time to give us this feedback. > > Kathryn > > >> --Junchao Zhang >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [mpiwg-tools] reset a stopped pvar
by Kathryn Mohror 18 Sep '13

18 Sep '13

Hi Junchao, > What is the right behavior when resetting a stopped pvar? The standard says setting to its starting value. > For counters, timers etc, setting them to zero sounds reasonable. > But for a watermark, setting it to "the current utilization level" looks weird. It implies that a value caught during the stopped period can affect its future value when the pvar is re-started. > Probably, we should reset a stopped watermark to a state as if it has never been started. > Any comments? Thanks Hmm. It makes sense to me, but I'll let others chime in if they disagree. I think that the moment you start the watermark variable, you want to know what the "mark" is, so it would be the value of current utilization. So even if a higher (or lower) value is caught during the stopped period (which it shouldn't be, because variables aren't supposed to be updated when stopped), it will be set to the current utilization value when started. I interpret this as being able to measure the watermark during different epochs of the program execution. Every time you start the variable, it's a fresh epoch and you want to know what the watermark was during that epoch. However, I can see how this isn't clear as it could be -- I'll try to see what we can do to clarify it in the text. Thanks again for taking the time to give us this feedback. Kathryn > --Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

reset a stopped pvar
by Junchao Zhang 18 Sep '13

18 Sep '13

Hello, What is the right behavior when resetting a stopped pvar? The standard says setting to its starting value. For counters, timers etc, setting them to zero sounds reasonable. But for a watermark, setting it to "the current utilization level" looks weird. It implies that a value caught during the stopped period can affect its future value when the pvar is re-started. Probably, we should reset a stopped watermark to a state as if it has never been started. Any comments? Thanks --Junchao Zhang

1 0

Re: [mpiwg-tools] pvar attribute questions
by Junchao Zhang 18 Sep '13

18 Sep '13

Yes, you are right. Thank you, Kathryn. --Junchao Zhang On Wed, Sep 18, 2013 at 1:10 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > This looks like Junchao's mail from a while back was released by a > moderator. I believe we already satisfied him on this point. > > Junchao, please let me know if I am incorrect. > > Kathryn > > On Aug 30, 2013, at 3:13 PM, Junchao Zhang <junchao.zhang(a)gmail.com> > wrote: > > If the pvar is restarted by the first session, what will be read into > this pvar? > I think it is 90. But this value of high watermark did not happen in the > live period of the pvar in the first session. So the value 90 doesn't make > sense. > > I don't know how to let a watermark pvar show different values in > different sessions. For COUNTER, TIMER, AGGREGATE pvars, I know we can > compute delta between current value and start value. But for watermark > pvars, the approach does not apply. > > > > On Fri, Aug 30, 2013 at 4:48 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > >> Hi Junchao, >> >> I'm trying to understand MPI3 MPI_T performance variables (pvar). >> The standard defines pvar sessions, pvar classes (e.g.,COUNTER, >> HIGHWATERMARK etc), and continuous pvars, readonly pvars.I was wondering if >> there is any relevance between these concepts. The standard doesn't say >> that. >> >> For instance, for a highwatermark pvar, I guess it should be >> continuous. Otherwise, suppose a pvar session starts this pvar, then stops >> it, and then restarts it. How can I keep track of this pvar? Let's say >> during the live period of the pvar, the high watermark is 50. After the >> pvar is stopped, it went up to as high as 90 (since it may be alive in >> other pvar sessions). So, when I restart the pvar, what value should I read? >> >> >> If a variable is not continuous then its value is not updated when it >> is stopped. So in your example the value would be 50 in the session that >> stopped the variable and 90 in any sessions that still had the variable >> live at the time it reached that value. There's a bit more explanation on >> page 579 starting at line 21. Does that help? >> >> Kathryn >> >> >> Thanks >> --Junchao Zhang >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 >> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> > > > > -- > Junchao Zhang > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Re: [mpiwg-tools] pvar attribute questions
by Mohror, Kathryn 18 Sep '13

18 Sep '13

This looks like Junchao's mail from a while back was released by a moderator. I believe we already satisfied him on this point. Junchao, please let me know if I am incorrect. Kathryn On Aug 30, 2013, at 3:13 PM, Junchao Zhang <junchao.zhang(a)gmail.com<mailto:[email protected]>> wrote: If the pvar is restarted by the first session, what will be read into this pvar? I think it is 90. But this value of high watermark did not happen in the live period of the pvar in the first session. So the value 90 doesn't make sense. I don't know how to let a watermark pvar show different values in different sessions. For COUNTER, TIMER, AGGREGATE pvars, I know we can compute delta between current value and start value. But for watermark pvars, the approach does not apply. On Fri, Aug 30, 2013 at 4:48 PM, Mohror, Kathryn <mohror1(a)llnl.gov<mailto:[email protected]>> wrote: Hi Junchao, I'm trying to understand MPI3 MPI_T performance variables (pvar). The standard defines pvar sessions, pvar classes (e.g.,COUNTER, HIGHWATERMARK etc), and continuous pvars, readonly pvars.I was wondering if there is any relevance between these concepts. The standard doesn't say that. For instance, for a highwatermark pvar, I guess it should be continuous. Otherwise, suppose a pvar session starts this pvar, then stops it, and then restarts it. How can I keep track of this pvar? Let's say during the live period of the pvar, the high watermark is 50. After the pvar is stopped, it went up to as high as 90 (since it may be alive in other pvar sessions). So, when I restart the pvar, what value should I read? If a variable is not continuous then its value is not updated when it is stopped. So in your example the value would be 50 in the session that stopped the variable and 90 in any sessions that still had the variable live at the time it reached that value. There's a bit more explanation on page 579 starting at line 21. Does that help? Kathryn Thanks --Junchao Zhang _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Junchao Zhang _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Active / inactive pvars
by Mohror, Kathryn 18 Sep '13

18 Sep '13

Hi Junchao, The MPI standard says "However, MPI implementations are not allowed to change the index of a performance variable or to delete a variable once it has been added to the set. When a variable becomes inactive, e.g., through dynamic unloading, accessing its value should return a corresponding error code." Does it imply, 1) MPI_T_pvar_get_num() will return a N that counts both active and inactive pvars Yes. 2) MPI_T_pvar_get_info(par_index, ...,) may return MPI_T_ERR_INVALID_INDEX even for a par_index < N Yes. 3) When a pvar is re-activated, it keeps its old index? Yes. These are not obvious in the standard. Thanks for your feedback. We have updated the example for control variables (Example 14.4) to illustrate your first point (will be part of the next released standard). However, I realize now that we should do the same for other examples in the chapter. We possibly need to add some text to address this as well, maybe as errata since it seems clarification could help avoid confusion. I'll bring this up in the working group. Kathryn Thanks. --Junchao Zhang _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Active / inactive pvars
by Junchao Zhang 17 Sep '13

17 Sep '13

Hello, The MPI standard says "However, MPI implementations are not allowed to change the index of a performance variable or to delete a variable once it has been added to the set. When a variable becomes inactive, e.g., through dynamic unloading, accessing its value should return a corresponding error code." Does it imply, 1) MPI_T_pvar_get_num() will return a N that counts both active and inactive pvars 2) MPI_T_pvar_get_info(par_index, ...,) may return MPI_T_ERR_INVALID_INDEX even for a par_index < N 3) When a pvar is re-activated, it keeps its old index? These are not obvious in the standard. Thanks. --Junchao Zhang

1 0

Canceling telecon
by Kathryn Mohror 13 Sep '13

13 Sep '13

Hi all, Due to quite a few people not being able to make the call next Thursday, we will cancel it. We'll resume regular calls October 3. Kathryn ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0