An immediate one is that the RMA tests should fail.
 
Rajeev


From: owner-mpich2-core@mcs.anl.gov [mailto:owner-mpich2-core@mcs.anl.gov] On Behalf Of William Gropp
Sent: Monday, July 28, 2008 5:58 PM
To: mpich2-core@mcs.anl.gov
Subject: Re: [mpich2-core] Question about tests

Is there a way to test that setting MPICH_NO_LOCAL=1 works? For example, are there DBG hooks so that I can use the debug features to print out the choice of method for vc's?

Bill

On Jul 28, 2008, at 12:46 PM, Darius Buntinas wrote:


Sure, MPICH_NO_LOCAL or MPICH_ODD_EVEN_CLIQUES environment variables.

-d

On 07/28/2008 11:42 AM, William Gropp wrote:
Ergh, is there a way to do this at runtime? Could there be?

Bill

On Jul 28, 2008, at 11:37 AM, Darius Buntinas wrote:

--enable-nemesis-dbg-nolocal
-d

On 07/28/2008 11:32 AM, William Gropp wrote:
Sure, though it will be a hack.

Is there some way to force nemesis to use TCP instead of shared memory
for all connections?

Bill

On Jul 25, 2008, at 12:02 PM, Rajeev Thakur wrote:

Bill,
Would it be possible to enable this local odd-even option for
Nemesis in the old nightly tests? The configure option is
--enable-nemesis-dbg-localoddeven.

Rajeev


------------------------------------------------------------------------
[mailto:owner-mpich2-core@mcs.anl.gov] *On Behalf Of *William Gropp
*Sent:* Friday, July 25, 2008 11:31 AM
*To:* mpich2-core@mcs.anl.gov <mailto:mpich2-core@mcs.anl.gov>
*Subject:* Re: [mpich2-core] Question about tests

Thanks for the info. I'll still stand by the "if its not tested it
doesn't work" position, so it would be good to do at least a basic
test (by hand if that's easier) before shipping.

Bill

On Jul 25, 2008, at 9:37 AM, Dave Goodell wrote:

The local-oddeven option should cover most of these concerns.
However it is worth noting that if there were certain kinds of bugs
in the new(ish) MPIDI_GetIPInterfaces function that they might
not be
detected on only one node. We might need to set up a nightly joint
test between two of the non-breadboard machines if we do want to be
sure to cover this. OTOH, I'm not too concerned about it, so I
wouldn't make it a high priority.

-Dave

On Jul 25, 2008, at 9:24 AM, Pavan Balaji wrote:

Hi Bill,

We are running nemesis with the local-oddeven option which means
that all odd ranks form a shared-memory sub-cluster all even ranks
do the same. Communication between an odd and an even rank process
happens through the network. So, both should be getting tested.
Real two-node testing is better, but we were trying to
optimize for
high-throughput computing given that we have too few machines and
too many tests (takes 3-4 days for each round of all tests).

Truly, we should use the old tests and new tests in conjunction so
that we can maximize the number of tests that are run.

-- Pavan

On 07/25/2008 09:12 AM, William Gropp wrote:
The old new testing system that I had started included some tests
between different machines to ensure that node-to-node worked.
The normal tests usually run on a single machine. Are we
regularly running any cross-node tests, and if so, where are
they? The tests were those that the wiki page calls "Results from
the MPICH2 test suite". (My concern is that Nemesis is detecting
that it can used shared memory and we're not testing TCP;
alternately, we're always testing TCP and never shared memory).
Bill
William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign

--
Pavan Balaji



William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign



William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign




William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign




William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign