netdev - Re: Bonding gigabit and fast?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200812170751.42387.tvrtko@ursulin.net>
Date:	Wed, 17 Dec 2008 07:51:42 +0000
From:	"Tvrtko A. Ursulin" <tvrtko@...ulin.net>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	Chris Snook <csnook@...hat.com>, netdev@...r.kernel.org
Subject: Re: Bonding gigabit and fast?

On Wednesday 17 December 2008 04:48:55 Jay Vosburgh wrote:
> Tvrtko A. Ursulin <tvrtko@...ulin.net> wrote:
> [...]
>
> >I was using balance-rr, alb flavour does not seem to like 8139too.
>
> 	The choice of balance-rr may be half of your problem.  Try
> balance-xor with xmit_hash_policy=layer3+4, it may behave better.  That
> mode doesn't know about dissimilar speed slaves, so it simply balances
> by math, but that still may behave better than balance-rr because it
> won't stripe single connections across slaves.
>
> 	The balance-alb mode would likely be better (it's smarter about
> balancing across slaves of differing speeds), but requires that the
> slaves be able to change MAC address while up, which not every device is
> capable of doing.
>
> 	To elaborate a bit on balance-rr, it will usually cause out of
> order delivery to varying degrees, which in turn causes TCP's congestion
> control and/or fast retransmits to kick in.  The effect can be mitigated
> to some degree (but not eliminated) by raising the value of the
> net.ipv4.tcp_reordering sysctl.  If memory serves, values more than
> about 125 don't make much additional difference.

Yes, makes sense and is in line from what is written in the bonding HOWTO. My 
problem is that I actually wanted to stripe single connections in order to 
work around really slow gigabit (slower than fast ethernet) performance. 
There is a single GbE link on the receiver side so maybe there shouldn't be 
that much out of order traffic, although something is causing aggregated 
bandwith to be around 50% less than hypothetical sum of two (9+9 alone vs 12 
bonded). And without stripping I couldn't measure aggregated bandwith with a 
single client.

Subject I put for this thread is actually misleading..

Thanks,

Tvrtko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html