On Oct 2, 2010, at 10:54 , Gijsbert Wiesenekker wrote:
>
> On Oct 1, 2010, at 23:24 , Gijsbert Wiesenekker wrote:
>
>> I have a large array that is shared between two processes. One process
>> updates array elements randomly, the other process reads array elements
>
On Oct 1, 2010, at 23:24 , Gijsbert Wiesenekker wrote:
> I have a large array that is shared between two processes. One process
> updates array elements randomly, the other process reads array elements
> randomly. Most of the time these writes and reads do not overlap.
> The curren
I have a large array that is shared between two processes. One process updates
array elements randomly, the other process reads array elements randomly. Most
of the time these writes and reads do not overlap.
The current version of the code uses Linux shared memory with NSEMS semaphores.
When ar
On Aug 17, 2010, at 11:29 , Gijsbert Wiesenekker wrote:
> I have a four-node quad core cluster. I am running OpenMPI (version 1.4.2)
> jobs with Torque (version 2.4.8). I can submit jobs using
> #PBS -lnodes=4:ppn=4
> And 16 processes are launched. However if I use
> #PBS -lnode
I have a four-node quad core cluster. I am running OpenMPI (version 1.4.2) jobs
with Torque (version 2.4.8). I can submit jobs using
#PBS -lnodes=4:ppn=4
And 16 processes are launched. However if I use
#PBS -lnodes=4:ppn=1
or
#PBS -lnodes=4
The call to MPI_Init is succesful, but the call to
MPI_
The following code tries to send a message, but if it takes too long the
message is cancelled:
#define DEADLOCK_ABORT (30.0)
MPI_Isend(message, count, MPI_BYTE, comm_id,
MPI_MESSAGE_TAG, MPI_COMM_WORLD, &request);
t0 = time(NULL);
cancelled = FALSE;
while(TRUE)
{
//do som
On May 24, 2010, at 20:27 , Eugene Loh wrote:
> Gijsbert Wiesenekker wrote:
>
>> My MPI program consists of a number of processes that send 0 or more
>> messages (using MPI_Isend) to 0 or more other processes. The processes check
>> periodically if messages are avail
On May 24, 2010, at 19:42 , Gijsbert Wiesenekker wrote:
> My MPI program consists of a number of processes that send 0 or more messages
> (using MPI_Isend) to 0 or more other processes. The processes check
> periodically if messages are available to be processed. It was running fine
My MPI program consists of a number of processes that send 0 or more messages
(using MPI_Isend) to 0 or more other processes. The processes check
periodically if messages are available to be processed. It was running fine
until I increased the message size, and I got deadlock problems. Googling
On May 11, 2010, at 9:18 , Gijsbert Wiesenekker wrote:
> An OpenMPI program of mine that uses MPI_Isend and MPI_Irecv crashes after
> some non-reproducible time my Fedora Linux kernel (invalid opcode), which
> makes it hard to debug (there is no trace, even with the debug kernel, an
a way to do this?
>
>
> you can check number of message pending simply using MPI_Test function. It
> return false if the request of message is in pending status. The difference
> with MPI_Wait is in the behaviour of these two routines: MPI_Wait is
> blocking, MPi_Test, check and
An OpenMPI program of mine that uses MPI_Isend and MPI_Irecv crashes after some
non-reproducible time my Fedora Linux kernel (invalid opcode), which makes it
hard to debug (there is no trace, even with the debug kernel, and if I run it
under valgrind it does not crash).
My guess is that the kern
ction is actually working properly -- removing the
>> nanosleep() shouldn't affect the correctness of your barrier.
>>
> I read Gijsbert's e-mail differently. Apparently, the issue is not MPI/OMPI
> at all, but a hang inside nanosleep.
>
>> On Dec 31, 2009, at 1:1
I was having non-reproducible hangs in an OpenMPI program. While
troubleshooting this problem I found that there were many temporary directories
in my /tmp/openmpi-sessions-userid directory (probably the result of MPI_Abort
aborted OpenMPI programs). I cleaned those directories up and it looks l
nks for all the help.
Gijsbert
On Mon, Dec 14, 2009 at 8:22 PM, Ashley Pittman wrote:
> On Sun, 2009-12-13 at 19:04 +0100, Gijsbert Wiesenekker wrote:
> > The following routine gives a problem after some (not reproducible)
> > time on Fedora Core 12. The routine is a CPU usage
The following routine gives a problem after some (not reproducible) time on
Fedora Core 12. The routine is a CPU usage friendly version of MPI_Barrier.
The verbose output shows that if the problem occurs one of the (not
reproducible) nodes does not receive a message from one of the other (not
re
Maybe this question is not entirely appropriate to this forum, but maybe
someone reading this forum has already tried this and knows which method
is faster.
I am about to hook up a NAS node to my Centos based Linux cluster. NAS
storage will be shared amongst the nodes using GFS2. My OpenMPI
jody wrote:
Hi
I have a small cluster consisting of 9 computers (8x2 CPUs, 1x4 CPUs).
I would like to be able to observe the output of the processes
separately during an mpirun.
What i currently do is to apply the mpirun to a shell script which
opens a xterm for each process,
which then starts t
I am running OpenMPI on Fedora Core 10. MPI_Abort does not seem to abort
the processes on FC10. I found out that when you send a signal all
processes seem to abort as expected, so I am now using raise(SIGTERM)
instead of MPI_Abort(). Are there any consequences to not using MPI_Abort?
Regards,
gaurav gupta wrote:
Hello,
I want to know that which task is running on which node. Is there any
way to know this.
Is there any profiling tool provided along with openmpi to calculate
time taken in various steps.
--
GAURAV GUPTA
B.Tech III Yr. , Department of Computer Science & Engineering
I
I am running mpiexec on Fedora Core 10. Where can I find the list of
ports that I have to open if I want to run mpiexec with iptables enabled?
Running mpiexec with debug shows that it uses ports around 5. strace
does not show a call to getenv, so I am not sure if mpiexec on Fedora
supports M
21 matches
Mail list logo
