Hi all,
I use openmpi-1.3b3r2 and blcr-0.7.3 to run my application on 2 nodes. I
configure openmpi to run on 2 nodes for default.
I want to use checkpoint/restart functionalities, so I use this command to
configure openmpi:
# .configure --with-devel-headers --with-ft=cr --with-blcr=
First:
Thanks George (and Brian :)).
The MPI_Put error is gone. Did you take a look at the problem
that with the block_indexed type the PUT doesn't work? I'm
still getting the following output (V1 corresponds to the datatype
created with MPI_Type_create_indexed_block while the V2 type
is created with MPI
On Dec 11, 2008, at 7:01 PM, Marcus G. Daniels wrote:
I've heard some experimental work has been done to run OpenMPI over
the Axon driver as found in IBM triblades. Seems like that should
work fine, as it's just another RDMA interface, no?
I personally don't know anything about Axon; perh
Hi again.
I adapted my testing program by overwriting the window buffer
complete with 1. This allows me to see at which places OpenMPI writes.
The result is:
*** -DO1=1 -DV1=1 *** (displ 3,2,1,0 , MPI_Type_create_indexed_block)
mem[0] = { 0., 0., 0.}
mem[1] = { 0., 0., 0
FWIW, Open MPI does have on its long-term roadmap to have "blocking"
progress -- meaning that it'll (probably) spin aggressively for a
while and if nothing "interesting" is happening, it'll go into a
blocking mode and let the process block in some kind of OS call.
Although we have some inte
Just to clarify: are you talking about using this on RoadRunner to
move data from the Opteron to the Cell blades? Or are you talking
about using OpenMPI on some other machine?
If you are interested in RR, we should probably continue the
discussion off-list. The short answer is that we have
Hi Jeff,
I'd like to use MPI for features like derived types, and moving
around non-flat data.
You should be able to do that today.
The Axon PCIe-to-PCIe RDMA interface has a raw device and an ethernet
device in the Linux kernel, and I can indeed using the latter as a
workaround. It's mor
Hello,
I am having problems with OMPI-1.3beta with an interactive job where rank 0
reads stdin from a terminal. The problem does not show up when stdin
is redirected from a file. The problem also does not exist with OMPI 1.2.[5-9].
Has there been any change in OMPI between 1.2 and 1.3 that I sho
Jeff Squyres wrote:
FWIW, Open MPI does have on its long-term roadmap to have "blocking"
progress -- meaning that it'll (probably) spin aggressively for a
while and if nothing "interesting" is happening, it'll go into a
blocking mode and let the process block in some kind of OS call.
Alth
Hi Harald
There is a patch for the IOF in 1.3 "soaking" in the trunk right now.
I'll check to ensure it fixes this issue too. Hopefully, it will come
over to the 1.3 branch early next week.
Ralph
On Dec 12, 2008, at 8:21 AM, Harald Anlauf wrote:
Hello,
I am having problems with OMPI-1.
Hello Eugene:
On Mon, Dec 08, 2008 at 11:14:10AM -0800, Eugene Loh wrote:
..
>> Proceeding from that, it seems that "mpi_recv" is implemented as
>> "poll forever until the message comes"
>> and NOT as
>>"sleep until the message comes"
>>
>> I had assumed, until now, that mpi_recv w
Hello Jeff:
On Fri, Dec 12, 2008 at 08:37:14AM -0500, Jeff Squyres wrote:
> FWIW, Open MPI does have on its long-term roadmap to have "blocking"
> progress -- meaning that it'll (probably) spin aggressively for a
> while and if nothing "interesting" is happening, it'll go into a
> blocking
On Dec 12, 2008, at 11:46 AM, Eugene Loh wrote:
FWIW, I've run into the need for this a few times due to HPCC tests
on large (>100 MPI procs) nodes or multicore systems. HPCC (among
other things) looks at the performance of a single process while all
other np-1 processes spinwait -- or of
On Dec 12, 2008, at 3:22 PM, douglas.gupt...@dal.ca wrote:
I could imagine another alternative. Construct a wrapper
function that
intercepts MPI_Recv and turn it into something like
PMPI_Irecv
while ( ! done ) {
nanosleep(short);
PMPI_Test(&done);
}
I don't know how useful this woul
On Dec 12, 2008, at 3:46 PM, douglas.gupt...@dal.ca wrote:
This is probably because most users running MPI jobs tend to devote
the entire core/CPU/server to the MPI job and don't try to run other
jobs concurrently on the same resources.
Our situation is different. While our number-cruncher ap
Jeff Squyres wrote:
On Dec 12, 2008, at 11:46 AM, Eugene Loh wrote:
FWIW, I've run into the need for this a few times due to HPCC tests
on large (>100 MPI procs) nodes or multicore systems. HPCC (among
other things) looks at the performance of a single process while all
other np-1 proces
Dorian,
I looked into this again. So far I can confirm that the datatype is
correctly created, and always contain the correct values (internally).
If instead of one sided you use send/recv then the output is exactly
what you expect. With the one sided there are several strange things.
Wha
17 matches
Mail list logo
