This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Sorry for the delay in reply.
On Aug 27, 2007, at 6:16 PM, Jeff Squyres wrote:
>>> - 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
>>> 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.
So I see 2 solutions to this:
1) Require that everyone specify the collective on the command line.
2) Create a special, hidden MCA parameter that prints the
collective being used only once. Then MTT can extract that and we can
Just an idea.
>>> - It is difficult to search in the reporter for queries like:
>>> * Open MPI run with only tcp,sm,self
>> How about something like this?
> 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
Humm I was having an aweful time getting these results to pair as you
did in the link you gave me (I actually gave up after a while). Maybe
I was using the reporter wrong.
>>> One solution I proposed was using the 'tagging' idea, but there
>>> be some alternative UI features that we can develop to better
>>> these types of queries. Tim P seemed interested/had some ideas on
>>> to do this.