Adrian,
For the most part this seems to work for me. But there are a few issues.
I'm not sure which are introduced by this patch, and whether some may be
expected behavior. But for completeness I will point them all out.
First, let me explain I am working on a machine with 3 tcp interfaces,
On Wed, Jan 30, 2008 at 06:48:54PM +0100, Adrian Knoth wrote:
> > What is the real issue behind this whole discussion?
> Hanging connections.
> I'll have a look at it tomorrow.
To everybody who's interested in BTL-TCP, especially George and (to a
minor degree) rhc:
I've integrated something
On Wed, Jan 30, 2008 at 03:38:00PM +0100, Bogdan Costescu wrote:
> The results is that, with the default Linux kernel settings, there is
> no way to tell which way a connection will take in a multi-rail TCP/IP
> setup. Even more, when the ARP cache expires and a new ARP request is
> made, the
On Wed, Jan 30, 2008 at 12:05:50PM -0500, George Bosilca wrote:
> What is the real issue behind this whole discussion?
Hanging connections. See
https://svn.open-mpi.org/trac/ompi/ticket/1206
The multi-address peer tries to connect, but btl_tcp_proc_accept denies
due to not matching
What is the real issue behind this whole discussion ? With one or
multiple IP addresses by interface the connection step will work. Now
I can see a benefit of having multiple socket over the same link (and
it's already implemented in Open MPI), but I don't see the interest of
using
On Wed, 30 Jan 2008, Adrian Knoth wrote:
let me point out that the assumption "One interface, one address"
isn't true.
Strictly speaking when configuring one address to one interface:
For Linux, "one interface, one address" isn't true; for Solaris and
other Unices it is. The standards allow
Is one possible solution to have Open MPI mark in the packet where the
incoming connection is coming from?
On Jan 30, 2008, at 9:20 AM, Tim Mattox wrote:
Hello,
On Jan 30, 2008 3:17 AM, Adrian Knoth
wrote:
[snip]
As mentioned earlier: it's very common to
On Tue, Jan 29, 2008 at 07:37:42PM -0500, George Bosilca wrote:
> The previous code was correct. Each IP address correspond to a
> specific endpoint, and therefore to a specific BTL. This enable us to
> have multiple TCP BTL at the same time, and allow the OB1 PML to
> stripe the data over
The previous code was correct. Each IP address correspond to a
specific endpoint, and therefore to a specific BTL. This enable us to
have multiple TCP BTL at the same time, and allow the OB1 PML to
stripe the data over all of them.
Unfortunately, your commit disable the multi-rail over