Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: [OMPI users] 'readv failed: Connection timed out' issue
From: Jonathan Dursi (ljdursi_at_[hidden])
Date: 2010-04-20 08:55:50


We've got OpenMPI 1.4.1 and Intel MPI running on our 3000 node system. We like OpenMPI for large jobs, because the startup time is much faster (and startup is more reliable) than the current defaults with IntelMPI; but we're having some pretty serious problems when the jobs are actually running. When running medium- to large- sized jobs (say, anything over 500 cores) over ethernet using OpenMPI, several of our users, using a variety of very different sorts of codes, report errors like this:

mca_btl_tcp_frag_recv: readv failed: Connection timed out (110)

which sometimes hang the job, or sometimes kill it outright:

mca_btl_tcp_frag_recv: readv failed: Connection timed out (110)
mca_btl_tcp_frag_recv: readv failed: Connection reset by peer (104)
mpirun: killing job...

mpirun noticed that process rank 0 with PID 9513 on node gpc-f123n025
exited on signal 0 (Unknown signal 0).

We don't see this problem when the same users, using the same codes, use IntelMPI.

Unfortunately, this only happens intermittently, and only with large jobs, so it is hard to track down. It seems to happen more reliably with larger numbers of processors, but I don't know if that tells us something real about the issue, or just that larger N -> better statistics. For one users code, it definitely occurs during an MPI_Wait (this particular code has been run on a wide variety of machines with a wide variety of MPIs -- which isn't proof of correctness of course, but everything looks fine), for others it is less clear. I don't know if it's an OpenMPI issue, or just represents a network issue which Intel's MPI happens to be more tolerant of with the default set of parameters. It's also unclear whether or not this issue occurred with earlier OpenMPI versions.

Where should I start looking to find out what is going on? Are there parameters that can be adjusted to play with timeouts to see if the issue can be localized, or worked around?

        - Jonathan

Jonathan Dursi <ljdursi_at_[hidden]>