A few more notes I forgot:
- 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.
- They lamented the lack of the cherry picking feature since it is
known to be broken in the new reporter.
- 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.
I think that's really it this time. :)
On Aug 27, 2007, at 10:33 AM, Josh Hursey wrote:
> Jeff asked me if I would talk to Rich and folks at IU on Friday about
> the performance graphs. Below are my notes from that meeting:
> - 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.
> - 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 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.
> - 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.
> - It is difficult to search in the reporter for queries like:
> Open MPI run with only tcp,sm,self ; 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.
> 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.
> That was about it. They thought it was good over all, but the above
> were suggestions on ways to make the representation more useful.
> -- Josh
> mtt-devel mailing list