On 2/6/2014 11:08 AM, Jeff Squyres (jsquyres) wrote:
> In addition to what Ralph said (just install OMPI under your $HOME, at least for testing purposes), here's what we say about version compatibility:
> 1. OMPI started providing ABI guarantees with v1.3.2. The ABI guarantee we provide is that a 1.x and 1.(x+1) series will be ABI compatible, where x is odd. For example, you can compile against 1.5.x and still mpirun with a 1.6.x installation (assuming you built with shared libraries, yadda yadda yadda).
> 2. We have never provided any guarantees about compatibility between different versions of OMPI (even with a 1.x series). Meaning: if you run version a.b.c on one server, you should run a.b.c on *all* servers in your job. Wire line compatibility is NOT guaranteed, and will likely break in either very obnoxious or very subtle ways. Both are bad.
> However, per the just-install-a-copy-in-your-$HOME advice, you can have N different OMPI installations if you really want to. Just ensure that your PATH and LD_LIBRARY_PATH point to the *one* that you want to use -- both on the current server and all servers that you're using in a given job. And that works fine (I do that all the time -- I have something like 20-30 OMPI installs under my $HOME, all in various stages of development/debugging; I just updated my PATH / LD_LIBARY_PATH and I'm good to go).
> Make sense?
Yes. And it seems the recommended one for this purpose is 1.7, not 1.6.
What should happen if I try to transmit something big? At least in my
case it was probably under 4G, which might be some kind of boundary
(though it's a 64 bit system).
> On Feb 6, 2014, at 1:23 PM, Ross Boylan <ross_at_[hidden]> wrote:
>> On 2/6/2014 3:24 AM, Jeff Squyres (jsquyres) wrote:
>>> Have you tried upgrading to a newer version of Open MPI? The 1.4.x series is several generations old. Open MPI 1.7.4 was just released yesterday.
>> It's on a cluster running Debian squeeze, with perhaps some upgrades to wheezy coming. However, even wheezy is at 1.4.5 (the next generation is currently at 1.6.5). I don't administer the cluster, and upgrading basic infrastructure seems somewhat hazardous.
>> I checked for backports of more recent version (at backports.debian.org) but there don't seem to be any for squeeze or wheezy.
>> Can we mix later an earlier versions of MPI? The documentation at http://www.open-mpi.org/software/ompi/versions/ seems to indicate that 1.4, 1.6 and 1.7 would all be binary incompatible, though 1.5 and 1.6, or 1.7 and 1.8 would be compatible. However, point 10 of the FAQ (http://www.open-mpi.org/faq/?category=sysadmin#new-openmpi-version) seems to say compatibility is broader.
>> Also, the documents don't seem to address on-the-wire compatibility; that is, if nodes on are different versions, can they work together reliably?
>>> On Feb 5, 2014, at 9:58 PM, Ross Boylan <ross_at_[hidden]> wrote:
>>>> On 1/31/2014 1:08 PM, Ross Boylan wrote:
>>>>> I am getting the following error, amidst many successful message sends:
>>>>> [n10][[50048,1],1][../../../../../../ompi/mca/btl/tcp/btl_tcp_frag.c:118:mca_btl_tcp_frag_send] mca_btl_tcp_frag_send: writev error (0x7f6155970038, 578659815)
>>>>> Bad address(1)
>>>> I think I've tracked down the immediate cause: I was sending a very large object (from R--I assume serialized into a byte stream) that was over 3G. I'm not sure why it would produce that error, but it doesn't seem that surprising that something would go wrong.
>>>>> Any ideas about what is going on or what I can do to fix it?
>>>>> I am using the openmpi-bin 1.4.2-4 Debian package on a cluster running Debian squeeze.
>>>>> I couldn't find a config.log file; there is /etc/openmpi/openmpi-mca-params.conf, which is completely commented out.
>>>>> Invocation is from R 3.0.1 (debian package) with Rmpi 0.6.3 built by me from source in a local directory. My sends all use mpi.isend.Robj and the receives use mpi.recv.Robj, both from the Rmpi library.
>>>>> The jobs were started with rmpilaunch; it and the hosts file are included in the attachments. TCP connections. rmpilaunch leaves me in an R session on the master. I invoked the code inside the toplevel() function toward the bottom of dbox-master.R.
>>>>> The program source files and other background information is in the attached file. n10 has the output of ompi_info --all, and n1011 has other info for both nodes that were active (n10 was master; n11 had some slaves).
>>>>> users mailing list
>>>> users mailing list
>> users mailing list