Hi,
Joshua Ladd writes:
> This is an ancient version of HCOLL. Please upgrade to the latest
> version (you can do this by installing HPC-X
> https://www.mellanox.com/products/hpc-x-toolkit)
Just to close the circle and inform that all seems OK now.
I don't have root permission in this machine
This is an ancient version of HCOLL. Please upgrade to the latest version
(you can do this by installing HPC-X
https://www.mellanox.com/products/hpc-x-toolkit)
Josh
On Wed, Feb 5, 2020 at 4:35 AM Angel de Vicente
wrote:
> Hi,
>
> Joshua Ladd writes:
>
> > We cannot reproduce this. On four node
Hi,
Joshua Ladd writes:
> We cannot reproduce this. On four nodes 20 PPN with and w/o hcoll it
> takes exactly the same 19 secs (80 ranks).
>
> What version of HCOLL are you using? Command line?
Thanks for having a look at this.
According to ompi_info, our OpenMPI (version 3.0.1) was config
We cannot reproduce this. On four nodes 20 PPN with and w/o hcoll it takes
exactly the same 19 secs (80 ranks).
What version of HCOLL are you using? Command line?
Josh
On Tue, Feb 4, 2020 at 8:44 AM George Bosilca via users <
users@lists.open-mpi.org> wrote:
> Hcoll will be present in many case
Hcoll will be present in many cases, you don’t really want to skip them
all. I foresee 2 problem with the approach you propose:
- collective components are selected per communicator, so even if they will
not be used they are still loaded.
- from outside the MPI library you have little access to int
Hi,
George Bosilca writes:
> If I'm not mistaken, hcoll is playing with the opal_progress in a way
> that conflicts with the blessed usage of progress in OMPI and prevents
> other components from advancing and timely completing requests. The
> impact is minimal for sequential applications using
If I'm not mistaken, hcoll is playing with the opal_progress in a way that
conflicts with the blessed usage of progress in OMPI and prevents other
components from advancing and timely completing requests. The impact is
minimal for sequential applications using only blocking calls, but is
jeopardizi
Hi,
in one of our codes, we want to create a log of events that happen in
the MPI processes, where the number of these events and their timing is
unpredictable.
So I implemented a simple test code, where process 0
creates a thread that is just busy-waiting for messages from any
process, and which
