Open MPI logo

MTT Devel Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all MTT Devel mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-08-27 18:16:14


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