Re: [OMPI devel] Fix for XLC + libtool issue

Good to hear that upgrading fixes this problem. We actually already have an outstanding ticket to upgrade to 2.2.2 (https://svn.open-mpi.org/trac/ompi/ticket/1265 ). We were following the Libtool development process closely and waiting for at least 2.2.2 (get past 2.2.0). This will

Re: [OMPI devel] Fix for XLC + libtool issue

On Apr 25, 2008, at 7:40 AM, Ralf Wildenhues wrote: We actually already have an outstanding ticket to upgrade to 2.2.2 (https://svn.open-mpi.org/trac/ompi/ticket/1265 ). We were following the Libtool development process closely and waiting for at least 2.2.2 (get past 2.2.0). 2.2.2 is out

Re: [OMPI devel] Fix for XLC + libtool issue

* Jeff Squyres wrote on Fri, Apr 25, 2008 at 01:54:39PM CEST: > On Apr 25, 2008, at 7:40 AM, Ralf Wildenhues wrote: > > > > Wow -- those timings are impressive! Quoting that URL (OMPI is [1]): > > - > For example[1], in a

Re: [OMPI devel] Loadbalancing

Kewl! I added ticket 1277 so that we are sure to document this for v1.3. On Apr 23, 2008, at 11:09 AM, Ralph H Castain wrote: I added a new "loadbalance" feature to OMPI today in r18252. Brief summary: adding --loadbalance to the mpirun cmd line will cause the round-robin mapper to

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18252

This commit causes mpirun to segfault when running the IBM spawn tests on our slurm platforms (it may affect others as well). The failures only happen when mpirun is run in a batch script. The backtrace I get is: Program terminated with signal 11, Segmentation fault. #0 0x002a969b9dbe in

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18303

As I said, it makes no difference to me. I just want to ensure that everyone agrees on the interpretation of the MPI standard. We have had these discussion in the past, with differing views. My guess here is that the port was left open mostly because the person who wrote the C-binding forgot to

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18303

To bounce on last George remark, currently when a job dies without unsubscribing a port with Unpublish(due to poor user programming, failure or abort), ompi-server keeps the reference forever and a new application can therefore not publish under the same name again. So I guess this is a

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18303

That sounds fine with me, George. Just to clarify: My comment about differing interpretations didn't pertain to this specific question, but was more an observation of some discussions we have had about such issues in other areas. I didn't talk to anyone about this particular question, just noted

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18303

On 4/25/08 5:38 PM, "Aurélien Bouteiller" wrote: > To bounce on last George remark, currently when a job dies without > unsubscribing a port with Unpublish(due to poor user programming, > failure or abort), ompi-server keeps the reference forever and a new > application

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18303

We always have the possibility to fail the MPI_Comm_connect. There is a specific error for this MPI_ERR_PORT. We can detect that the port is not available anymore (whatever the reason is), by simply using the TCP timeout on the connection. It's the best we can, and this will give us a

Re: [OMPI devel] [OMPI svn] svn:open-mpi r18303

True - and I'm all for simple! Unless someone objects, let's just leave it that way for now. I'll put on my list to look at this later - maybe count how many publishes we do vs unpublishes, and if there is a residual at finalize, then send the "unpublish all" message. Still leaves a race