All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Andi Kleen <ak@suse.de>
Cc: Bernhard Busch <bbusch@biochem.mpg.de>, linux-kernel@vger.kernel.org
Subject: Re: Poor Performance for ethernet bonding
Date: Fri, 24 Aug 2001 08:19:50 -0700	[thread overview]
Message-ID: <3B867096.3A1D7DE@candelatech.com> (raw)
In-Reply-To: <3B865882.24D57941@biochem.mpg.de.suse.lists.linux.kernel> <oupg0ahmv2a.fsf@pigdrop.muc.suse.de>

Andi Kleen wrote:
> 
> Bernhard Busch <bbusch@biochem.mpg.de> writes:
> 
> > Hi
> >
> >
> > I have tried to use ethernet  network interfaces bonding to increase
> > peformance.
> >
> > Bonding is working fine, but the performance is rather poor.
> > FTP between 2 machines ( kernel 2.4.4 and 4 port DLink 100Mbit ethernet
> > card)
> > results in a transfer rate of 3MB/s).
> >
> > Any Hints?
> 
> Bonding reorders packets, which causes frequent retransmits and stalls in TCP.
> One setup that doesn't is multipath routing (ip route .. with multiple
> nexthops over different interfaces). It'll only load balance (srcip, dstip,tos)
> tuples though, not individual flows, but then it has the advantage that
> it actually works.

Couldn't the bonding code be made to distribute pkts to one interface or
another based on a hash of the sending IP port or something?  Seems like that
would fix the reordering problem for IP packets....  It wouldn't help for
a single stream, but I'm guessing the real world problem involves many streams,
which on average should hash such that the load is balanced...

Ben

> 
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

  reply	other threads:[~2001-08-24 15:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3B865882.24D57941@biochem.mpg.de.suse.lists.linux.kernel>
2001-08-24 13:44 ` Poor Performance for ethernet bonding Andi Kleen
2001-08-24 15:19   ` Ben Greear [this message]
2001-08-24 15:22     ` Andi Kleen
2001-08-24 15:45       ` Ben Greear
2001-08-24 16:04         ` Andi Kleen
2001-08-27  7:40           ` Henning P. Schmiedehausen
2001-08-24 18:17     ` Thomas Davis
2001-08-24 20:59       ` Ben Greear
2001-08-25  7:04 Willy Tarreau
2001-08-25 18:23 ` Ben Greear
2001-08-26  7:59   ` willy tarreau
  -- strict thread matches above, loose matches on Subject: below --
2001-08-24 13:37 Bernhard Busch
2001-08-24 14:12 ` Sergey Ostrovsky
2001-08-24 14:33 ` Martin Josefsson
2001-08-24 15:16   ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B867096.3A1D7DE@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ak@suse.de \
    --cc=bbusch@biochem.mpg.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.