Hi all,
Firstly, hello to the mailing list for the first time! Secondly, sorry for the
non-descript subject line, but I couldn't really think how to be more specific!
Anyway, I am currently having a problem getting OpenMPI to work within my
installation of SGE 6.2u5. I compiled OpenMPI 1.4
It looks to me like your remote nodes aren't finding the orted executable. I
suspect the problem is that you need to forward the path and ld_library_path
tot he remove nodes. Use the mpirun -x option to do so.
On Oct 4, 2010, at 5:08 AM, Chris Jewell wrote:
> Hi all,
>
> Firstly, hello to the
I'm not sure why the group communicator would make a difference - the code area
in question knows nothing about the mpi aspects of the job. It looks like you
are hitting a race condition that causes a particular internal recv to not
exist when we subsequently try to cancel it, which generates th
On Oct 1, 2010, at 3:24 PM, 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 current version of
On Oct 2, 2010, at 2:54 AM, 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
>> randomly. Most of the time t
I would like to give Open MPI a test drive on some machines I have in my lab
and I have a few questions...
The machines are RHEL 5.4 machines and an older version of Open MPI was already
installed. I understand from the faq that I should not simply over write the
old installation, but would i
Does OMPI have shared memory capabilities (as it is mentioned in MPI-2)?
How can I use them?
Andrei
On Sat, Sep 25, 2010 at 23:19, Andrei Fokau wrote:
> Here are some more details about our problem. We use a dozen of 4-processor
> nodes with 8 GB memory on each node. The code we run needs about
Ed Peddycoart wrote:
The machines are RHEL 5.4 machines and an older version of Open MPI was
already installed. I understand from the faq that I should not simply
over write the old installation, but would it be better if I remove the
old version or install the new to a different location. I
> "Ralph" == Ralph Castain writes:
Ralph> I'm not sure why the group communicator would make a
Ralph> difference - the code area in question knows nothing about
Ralph> the mpi aspects of the job. It looks like you are hitting a
Ralph> race condition that causes a particular in
We have 64 compute nodes which are dual qual-core and hyperthreaded CPUs. So
we have 1024 compute units shown in the ROCKS 5.3 system. I'm trying to
scatter an array from the master node to the compute nodes using mpiCC and
mpirun using C++.
Here is my test:
The array size is 18KB * Number of com
On Oct 4, 2010, at 10:36 AM, Milan Hodoscek wrote:
>> "Ralph" == Ralph Castain writes:
>
>Ralph> I'm not sure why the group communicator would make a
>Ralph> difference - the code area in question knows nothing about
>Ralph> the mpi aspects of the job. It looks like you are hitt
In my experience hyperthreading can't really deliver two cores worth of
processing simultaneously for processes expecting sole use of a core. Since you
really have 512 cores I'm not surprised that you see a performance hit when
requesting > 512 compute units. We should really get input from a
h
Thanks a lot for your reply, Doug.
There is one more thing I forgot to mention. For 500 nodes test, I observe
if I use SGE, it runs only almost half of our cluster, like 35-38 nodes, not
uniformly distributed on the whole cluster but the running time is still
good. So I guess it is not a hyperthr
Some of what you are seeing is the natural result of context switchingsome
thoughts regarding the results:
1. You didn't bind your procs to cores when running with #procs < #cores, so
you're performance in those scenarios will also be less than max.
2. Once the number of procs exceeds the
> "Ralph" == Ralph Castain writes:
Ralph> On Oct 4, 2010, at 10:36 AM, Milan Hodoscek wrote:
>>> "Ralph" == Ralph Castain writes:
>>
Ralph> I'm not sure why the group communicator would make a
Ralph> difference - the code area in question knows nothing about
Ral
Thanks a lot, Ralgh. As I said, I also tried to use SGE(also showing 1024
available for parallel tasks) which only assign 34-38 compute nodes which
only has 272-304 real cores for 500 procs running. The running time is
consistent with 100 procs and not a lot fluctuations due to the number of
machin
On Oct 4, 2010, at 1:48 PM, Storm Zhang wrote:
> Thanks a lot, Ralgh. As I said, I also tried to use SGE(also showing 1024
> available for parallel tasks) which only assign 34-38 compute nodes which
> only has 272-304 real cores for 500 procs running. The running time is
> consistent with 100
Hi,
In Open MPI 1.4.1, the directory lib/openmpi contains about 130
entries, including such things as mca_btl_openib.so. In my
build of Open MPI 1.4.2, lib/openmpi contains exactly three
items:
libompi_dbg_msgq.a libompi_dbg_msgq.la libompi_dbg_msgq.so
I have searched my 1.4.2 installation fo
Here is what I meant: the results of 500 procs in fact shows it with
272-304(<500) real cores, the program's running time is good, which is
almost five times 100 procs' time. So it can be handled very well. Therefore
I guess OpenMPI or Rocks OS does make use of hyperthreading to do the job.
But wit
Storm Zhang wrote:
Here is what I meant: the results of 500 procs in fact shows it with
272-304(<500) real cores, the program's running time is good, which is
almost five times 100 procs' time. So it can be handled very well.
Therefore I guess OpenMPI or Rocks OS does make use of hyperthread
20 matches
Mail list logo
