On Aug 27, 2007, at 12:06 PM, Ethan Mallove wrote:
- It would be really useful to 'zoom' into sections of the graph.
Primarily restricting the x-axis (Message Size), but also having the
ability to restrict the y-axis (time)
K.
https://svn.open-mpi.org/trac/mtt/ticket/153
- Calling the y-axis 'latency' is a bit misleading, maybe 'time'
would be better. Minor issue.
Easy to fix (and we should).
https://svn.open-mpi.org/trac/mtt/ticket/285
- Torsten mentioned that he was interested in seeing the other skampi
data that we are throwing away. Namely the time-per-rank. And if
available communicator size.
Torsten should be able to click the Detail button from
Performance view, and see everything that went to
stdout in the test. Would that show time-per-rank?
Not ATM; the skampi build is currently configured to not show that
info. Darn that Torsten...
If we want, we can resume the discussion of how to save that info
(since Jelena told us "no", I honestly dumped all that info from my
brain...).
- Torsten mentioned that he wants to add some non-blocking collective
test that he is work on. I told him to contact Jeff on how to do
this.
Shouldn't be hard. I'll wait for him to contact me.
- We need a well defined way to see what collective implementation
was used. Meaning that there are N AlltoAll collective
implementations in the 'tuned' component we need to know when looking
at the graph which one of the N we are looking at for Open MPI. For
other implementations we don't have so much control.
I don't know if MTT can. In order for MTT to do this, OMPI needs to
export that data somehow.
- It is difficult to search in the reporter for queries like:
----------
* Open MPI run with only tcp,sm,self
How about something like this?
http://www.open-mpi.org/mtt/reporter.php?do_redir=288
I did some skampi runs to see verbs results across 2 MPIs (Intel MPI
uses udapl, not tcp). I don't really think that this is hard:
- network: verbs (or TCP in Josh's case)
- test suite: skampi
- command: bcast (granted, per #281, you have to fill in "bcast" on
the "command" field on the advanced window, not the normal window)
It should show all the MPI's. You probably want to limit it down to
a specific platform, though, in order to get apples-to-apples
comparisons.
http://www.open-mpi.org/mtt/reporter.php?do_redir=290
* Intel MPI (which is only tcp I believe)
* MPICH2 with tcp results from running the skampi Bcast benchmark.
----------
The reporter is designed to track a single MPI well for regression
tracking. However when we need to compare multiple MPIs and each may
need to be selected with a different type of query it is impossible/
hard to do.
I don't see why this is hard...? I disagree with the statement
"Reporter is design to track a single MPI well..." See the permalink
above.
One solution I proposed was using the 'tagging' idea, but there might
be some alternative UI features that we can develop to better support
these types of queries. Tim P seemed interested/had some ideas on how
to do this.
- They really liked the ability to look at the HTML version of the
raw data. They seemed frustrated that the popup window is reused when
looking at multiple HTML versions of the raw data. They wanted this
to be a static window that they could keep open so they could look at
multiple variants of this data in small screens.
IIRC, that was some javascript trick that Ethan did in order to
download everything once. It could probably be changed if someone
really wanted to (e.g., the CSV doesn't display this way).
Ethan, can you explain further?
<from Josh's 2nd e-mail>
- The performance graphs are sometimes placed side-by-side instead of
stacked on top of one another. This shinks the x-axis, and is
undesirable. They would prefer that the graphs be always stacked on
top of one another.
That shouldn't be too hard, right Ethan?
- They lamented the lack of the cherry picking feature since it is
known to be broken in the new reporter.
To be fixed...
- They noticed that sometimes there is 'wasted space' in the graphs
in both the x and y axis. They want the graph to be pushed to the
edges of the graph so they can see the most detail in the results.
This might be a function of our PHP graphing package. We seem to
have jpgraph 1.20.5; the most recent seems to be 1.21b. I doubt this
issue has been fixed, but we might check / ask...?
--
Jeff Squyres
Cisco Systems
