Re: [OMPI users] Disable network interface selection

> On Jun 22, 2018, at 8:25 PM, r...@open-mpi.org wrote: > > > >> On Jun 22, 2018, at 7:31 PM, Gilles Gouaillardet >> mailto:gilles.gouaillar...@gmail.com>> wrote: >> >> Carlos, >> >> By any chance, could >> >> mpirun—mca oob_tcp_if_exclude 192.168.100.0/24 ... >>

Re: [OMPI users] Disable network interface selection

> On Jun 22, 2018, at 7:31 PM, Gilles Gouaillardet > wrote: > > Carlos, > > By any chance, could > > mpirun—mca oob_tcp_if_exclude 192.168.100.0/24 ... > > work for you ? > > Which Open MPI version are you running ? > > > IIRC, subnets are internally translated

Re: [OMPI users] Disable network interface selection

Carlos, By any chance, could mpirun—mca oob_tcp_if_exclude 192.168.100.0/24 ... work for you ? Which Open MPI version are you running ? IIRC, subnets are internally translated to interfaces, so that might be an issue if the translation if made on the first host, and then the interface name

Re: [OMPI users] Disable network interface selection

On Jun 22, 2018, at 7:36 PM, carlos aguni wrote: > > I'm trying to run a code on 2 machines that has at least 2 network interfaces > in it. > So I have them as described below: > > compute01 > compute02 > ens3 > 192.168.100.104/24 > 10.0.0.227/24 > ens8 > 10.0.0.228/24 > 172.21.1.128/24 > ens9

[OMPI users] Disable network interface selection

Hi all, I'm trying to run a code on 2 machines that has at least 2 network interfaces in it. So I have them as described below: compute01 compute02 ens3 192.168.100.104/24 10.0.0.227/24 ens8 10.0.0.228/24 172.21.1.128/24 ens9 172.21.1.155/24 --- Issue is. When I execute `mpirun -n 2

Re: [OMPI users] Open MPI: undefined reference to pthread_atfork

You already asked this question on the devel list, and I've asked you for more information. Please don't just re-post your question over here on the user list and expect to get a different answer. Thanks! > On Jun 22, 2018, at 4:55 PM, lille stor wrote: > > Hi, > > > When compiling a

[OMPI users] Open MPI: undefined reference to pthread_atfork

Hi,   When compiling a C++ source file named test.cpp that needs a shared library named libUtils.so which in its turn needs Open MPI shared library libmpi.so (hence the parameter -Wl,-rpath-link,/home/dummy/openmpi/build/lib): g++ test.cpp -lUtils

Re: [OMPI users] new core binding issues?

> On Jun 22, 2018, at 2:14 PM, Brice Goglin wrote: > > If psr is the processor where the task is actually running, I guess we'd need > your lstopo output to find out where those processors are in the machine. > Excellent, that’s exactly the sort of thing I was hoping someone on the list

Re: [OMPI users] new core binding issues?

If psr is the processor where the task is actually running, I guess we'd need your lstopo output to find out where those processors are in the machine. Brice Le 22 juin 2018 19:13:42 GMT+02:00, Noam Bernstein a écrit : >> On Jun 22, 2018, at 1:00 PM, r...@open-mpi.org wrote: >> >> I

Re: [OMPI users] new core binding issues?

Afraid I’m not familiar with that option, so I really don’t know :-( > On Jun 22, 2018, at 10:13 AM, Noam Bernstein > wrote: > >> On Jun 22, 2018, at 1:00 PM, r...@open-mpi.org >> wrote: >> >> I suspect it is okay. Keep in mind that OMPI itself is starting multiple

Re: [OMPI users] new core binding issues?

> On Jun 22, 2018, at 1:00 PM, r...@open-mpi.org wrote: > > I suspect it is okay. Keep in mind that OMPI itself is starting multiple > progress threads, so that is likely what you are seeing. The binding patter > in the mpirun output looks correct as the default would be to map-by socket > and

Re: [OMPI users] new core binding issues?

I suspect it is okay. Keep in mind that OMPI itself is starting multiple progress threads, so that is likely what you are seeing. The binding patter in the mpirun output looks correct as the default would be to map-by socket and you asked that we bind-to core. > On Jun 22, 2018, at 9:33 AM,

[OMPI users] new core binding issues?

Hi - for the last couple of weeks, more or less since we did some kernel updates, certain compute intensive MPI jobs have been behaving oddly as far as their speed - bits that should be quite fast sometimes (but not consistently) take a long time, and re-running sometimes fixes the issue,