Hi,
I am evaluating the performance of a clustering program written in Java
with MPI+threads and would like to get some insight in solving a peculiar
case. I've attached a performance graph to explain this.
In essence the tests were carried out as TxPxN, where T is threads per
process, P is proce
Waitall was not returning for the mundane reason that not all messages
sent were received. I'm not sure why the dump command seemed to say
there was nothing waiting. Ironically, the bug would never appear in
production, only in testing.
I fixed up my shutdown logic and all seems well now.
R
It works!! Thanks a lot for the help!!
--
Just add "-mca rmaps seq" to your command line, then. The mapper will take your
hostfile (no rankfile) and map each proc sequentially to the listed nodes. You
ne
On 4/10/2014 11:48 AM, Ross Boylan wrote:
On 4/9/2014 5:26 PM, Ross Boylan wrote:
On Fri, 2014-04-04 at 22:40 -0400, George Bosilca wrote:
Ross,
I’m not familiar with the R implementation you are using, but bear
with me and I will explain how you can all Open MPI about the list
of all pendin
On 4/9/2014 5:26 PM, Ross Boylan wrote:
On Fri, 2014-04-04 at 22:40 -0400, George Bosilca wrote:
Ross,
I’m not familiar with the R implementation you are using, but bear with me and
I will explain how you can all Open MPI about the list of all pending requests
on a process. Disclosure: This i
Hi again,
> Okay, I'll try to do a little poking around. Meantime, please send along the
> output from >"ompi_info" so we can see how this was configured and what built.
enclosed please find the requested information. It would be great to have an
workaround for 1.8 because with 1.8 our verific
Thanks Ralph! In future, I'll try and remember to follow up on these things
:)
Cheers,
Richard
On 10 April 2014 11:16, Ralph Castain wrote:
> Not really - it's the responsibility of the developer to file the CMR.
> Some folks are good about it, and some aren't. In this case, however, I
> suspe
On Apr 10, 2014, at 7:58 AM, Victor Vysotskiy
wrote:
> Dear Ralph,
>
>> it appears that 1.8 is much faster than 1.6.5 with the default settings, but
>> slower when you set btl=tcp,self?
>
> Precisely. However, with the default settings both versions are much slower
> compared to other MPI
Not really - it's the responsibility of the developer to file the CMR. Some
folks are good about it, and some aren't. In this case, however, I suspect it
didn't happen because we didn't hear back that the patch fixed the problem and
was therefore correct :-/
On Apr 10, 2014, at 8:02 AM, Richa
Okay. Thanks for having a look Ralph!
For future reference, is there a better process I can go through if I find
bugs like this that makes sure they don't get forgotten?
Thanks,
Richard
On 10 April 2014 00:39, Ralph Castain wrote:
> Wow - that's an ancient one. I'll see if it can be applied t
Dear Ralph,
> it appears that 1.8 is much faster than 1.6.5 with the default settings, but
> slower when you set btl=tcp,self?
Precisely. However, with the default settings both versions are much slower
compared to other MPI distributions such as MPICH, MVAPICH, and proprietary
ones. The 'b
Just add "-mca rmaps seq" to your command line, then. The mapper will take your
hostfile (no rankfile) and map each proc sequentially to the listed nodes. You
need to list each node once for each proc - something like this:
nodeA
nodeB
nodeB
nodeC
nodeA
nodeC
...
would produce your described pa
We have OMPI 1.4.0, 1.4.5 and 1.6.5 installed on our system.
>>What version of OMPI are you using? We have a "seq" mapper that does what you
>>want, but the precise cmd line option for directing to use it depends a bit
>>on the version.
>>On Apr 9, 2014, at 9:22 AM, Gan, Qi PW wrote:
> Hi,
>
Going on the assumption that it was a copy/paste error, the next question is:
how many nodes were in your allocation?
I ask because there is a change in the way we launch between 1.8 and 1.6.5.
Starting in the 1.7 series, mpirun launches daemons across your allocation at
startup so it can colle
Just to ensure I understand what you are saying: it appears that 1.8 is much
faster than 1.6.5 with the default settings, but slower when you set
btl=tcp,self?
This seems rather strange. I note that the 1.8 value is identical in the two
cases, but somehow 1.6.5 went much faster in the latter ca
Dear Developers,
I have faced a performance degradation on multi-core single processor machine.
Specifically, in the most recent Open MPI v1.8 the initialization and process
startup stage became ~10x slower compared to v1.6.5. In order to measure
timings I have used the following code snippet
Wow - that's an ancient one. I'll see if it can be applied to 1.8.1. These
things don't automatically go across - it requires that someone file a request
to move it - and I think this commit came into the trunk after we branched for
the 1.7 series.
On Apr 9, 2014, at 12:05 PM, Richard Shaw wr
17 matches
Mail list logo
