On 10:51 Tue 18 Mar , Jeff Squyres wrote:
> The upcoming v1.3 series doesn't suffer from this issue; we revamped
> our transport system to distinguish between early and normal
> completions. The pml_ob1_use_eager_completion MCA param was added to
> v1.2.6 to allow correct MPI apps to avo
On Mar 18, 2008, at 10:32 AM, George Bosilca wrote:
Jeff hinted the real problem in his email. Even if the program use
the correct MPI functions, it is not 100% correct.
I think we disagree here -- the sample program is correct according to
the MPI spec. It's an implementation artifact tha
As indicated in the FAQ you should add the directory where Open MPI
was installed to the LD_LIBRARY_PATH.
george.
On Mar 18, 2008, at 8:57 AM, Giovani Faccin wrote:
Ok, I uninstalled the previous version. Then downloaded the pre-
release version. Unpacked it, configure, make, make install.
Jeff hinted the real problem in his email. Even if the program use the
correct MPI functions, it is not 100% correct. It might pass in some
situations, but can lead to fake "deadlocks" in others. The problem
come from the flow control. If the messages are small (which is the
case in the tes
Ok, I uninstalled the previous version. Then downloaded the pre-release
version. Unpacked it, configure, make, make install
When running MPICC I get this:
mpiCC: error while loading shared libraries: libopen-pal.so.0: cannot open
shared object file: No such file or directory
$whereis libope
On Mar 18, 2008, at 8:38 AM, Giovani Faccin wrote:
Yep, setting the card manually did not solve it.
I would not think that it would. Generally, if OMPI can't figure out
your network configuration, it'll be an "all or nothing" kind of
failure. The fact that your program runs for a long wh
Yep, setting the card manually did not solve it.
I'm compiling the pre-release version now. Let's see if it works.
Giovani
Giovani Faccin escreveu: Hi Mark
Compiler and flags:
sys-devel/gcc-4.1.2 USE="doc* fortran gtk mudflap nls (-altivec) -bootstrap
-build -d -gcj (-hardened) -ip28 -ip32r
Hi Mark
Compiler and flags:
sys-devel/gcc-4.1.2 USE="doc* fortran gtk mudflap nls (-altivec) -bootstrap
-build -d -gcj (-hardened) -ip28 -ip32r10k -libffi% (-multilib) -multislot
(-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla"
Network stuff:
sonja gfaccin # ifconfig
loLin
Giovani:
Which compiler are you using?
Also, you didn't mention this, but does "mpirun hostname" give the
expected response? I (also new) had a hang similar to what you are
describing due to ompi getting confused as to which of two network
interfaces to use - "mpirun hostname" would hang when st
OK, this is strange. I've rerun the test and got it to block,
too. Although repeated tests show that those are rare (sometimes the
program runs smoothly without blocking, but in about 30% of the cases
it hangs just like you said).
On 08:11 Tue 18 Mar , Giovani Faccin wrote:
> I'm using openmpi
Two notes for you:
1. Your program does necessarily guarantee what you might expect:
since you use ANY_SOURCE/ANY_TAG in both the receives, you might
actually get two receives from the same sender in a given iteration.
The fact that you're effectively using yield_when_idle (which OMPI
wi
Hi Andreas, thanks for the reply!
I'm using openmpi-1.2.5. It was installed using my distro's (Gentoo) default
package:
sys-cluster/openmpi-1.2.5 USE="fortran ipv6 -debug -heterogeneous -nocxx -pbs
-romio -smp -threads"
I've tried setting the mpi_yield_when_idle parameter as you asked. Howev
Hmm, strange. It doesn't hang for me and AFAICS it shouldn't hang at
all. I'm using 1.2.5. Which version of Open MPI are you using?
Hanging with 100% CPU utilization often means that your processes are
caught in a busy wait. You could try to set mpi_yield_when_idle:
> gentryx@hex ~ $ cat .openmp
Hi there!
I'm learning MPI, and got really puzzled... Please take a look at this very
short code:
#include
#include "mpicxx.h"
using namespace std;
int main(int argc, char *argv[])
{
MPI::Init();
for (unsigned long t = 0; t < 1000; t++)
{
//If we are process 0:
14 matches
Mail list logo
