On Mon, Aug/27/2007 06:16:14PM, Jeff Squyres wrote:
> 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)
> >> - Calling the y-axis 'latency' is a bit misleading, maybe 'time'
> >> would be better. Minor issue.
> Easy to fix (and we should).
> >> - 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
> >> - 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
> >> * 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
> >> 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.
> 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?
Every time reporter.php is visited, graphs and CSV dumps
that are more than 1 hour old are cleaned out from the MTT
tmp/ area. The HTML dumps live as long as the browser window
is kept open since they're downloaded with the report (which
I thought was preferable).
I made the HTML raw data dumps go to their own windows.
> <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
> mtt-devel mailing list