Efficiency of link aggregation
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||||||||
|
Posted by anoop on August 1, 2008, 8:13 pm
Please log in for more thread options Is anyone aware of any studies on the efficiency of 802.3ad link aggregation. Since a hash is used to determine which member of an aggregate to put packets on in order to maintain ordering within a flow, we probably cannot get 2x throughput from a 2-member LAG or 3x throughput from a 3-member LAG. Are there any studies on this to show what kind of throughput is practically achievable? Anoop | ||||||||||||||||||||||
|
Posted by Patrick Schaaf on August 2, 2008, 2:59 am
Please log in for more thread options As the differently hashed data flows probably won't have common congestion control, I don't see why you wouldn't get 2x/3x the throughput - with packet loss for 1/2 or 1/3 of the individual flows - when you have enough flows flowing. >Are there any studies on this to show what kind of throughput is
>practically achievable? I've seen 1.8gbit/s on two gbit links with pure IP traffic. Unknown packet loss, but nobody complained. Unscientific, of course, just a memory of having seen RRD graphs some time ago. I'd be interested in studies about TCP behaviour when link aggregation is run without the hashing, with roundrobin or better scheduling, without maintaining ordering. Given the same number of probing TCP flows, will throughput be better or worse than with order maintainance, provided the links do _not_ saturate. best regards Patrick | ||||||||||||||||||||||
|
Posted by Rich Seifert on August 2, 2008, 12:41 pm
Please log in for more thread options mailer-daemon@bof.de (Patrick Schaaf) wrote:
> I'd be interested in studies about TCP behaviour when link aggregation
> is run without the hashing, with roundrobin or better scheduling, without > maintaining ordering. Given the same number of probing TCP flows, will > throughput be better or worse than with order maintainance, provided the > links do _not_ saturate. > There is no question that misordering will kill performance in most TCP implementations. Buffers cannot be delivered to the TCP client until later (out of order) segments are delivered; thus there may be problems with buffer overruns, and *possibly* additional copy operations. In any case, re-ordering is out of the "fast path" of the code; I suspect that any hardware TCP implementations take misordering and relegate it to software exception handling, which will kill performance. -- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX Send replies to: usenet at richseifert dot com | ||||||||||||||||||||||
|
Posted by Rich Seifert on August 2, 2008, 12:38 pm
Please log in for more thread options In article
> Is anyone aware of any studies on the efficiency of 802.3ad link
> aggregation. > Since a hash is used to determine which member of an aggregate to put > packets on in order to maintain ordering within a flow, we probably > cannot > get 2x throughput from a 2-member LAG or 3x throughput from a 3-member > LAG. Are there any studies on this to show what kind of throughput is > practically achievable? > First, there is no requirement that a hash be used to select a link for any particular flow. More important, the performance is more dependent on applications, and not the aggregation method. If two flows are assigned to separate links, and they can saturate their respective links, you will get double the throughput of a single link. How you choose the links is up to the designer, and not mandated by the standard (other than the fact that a given conversation must map to a single link). -- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX Send replies to: usenet at richseifert dot com | ||||||||||||||||||||||
|
Posted by anoop on August 3, 2008, 2:07 pm
Please log in for more thread options wrote:
> First, there is no requirement that a hash be used to select a link for
> any particular flow. More important, the performance is more dependent > on applications, and not the aggregation method. If two flows are > assigned to separate links, and they can saturate their respective > links, you will get double the throughput of a single link. That's correct. However the most common, cost effective implementation is that of using a hash...other mechanisms would need flow tables and possibly need to maintain state, which make things more expensive. Anoop | ||||||||||||||||||||||
| Similar Threads | Posted |
| Efficiency of link aggregation | August 1, 2008, 8:13 pm |
| question about link aggregation between switches. | September 29, 2004, 9:43 pm |
| Testing Link aggregation without LACP | January 25, 2007, 3:45 am |
| 802.3ad Link Aggregation between two hosts using crossover cables | January 24, 2005, 11:23 am |
| Port trunking / link aggregation problem | October 8, 2006, 9:11 am |
| VLAN Aggregation | July 4, 2008, 8:21 am |
| D-link dsl 300T | January 23, 2005, 11:17 pm |
| Link Up Time | March 14, 2006, 12:24 pm |
| Problem with DFE-855 link locking up | July 9, 2004, 12:50 am |
| D-Link DGE-550SX tuning. | July 20, 2004, 9:20 pm |
| Problem with Gig Link not coming up | October 8, 2004, 10:38 am |
| D-Link DSL-500 Console Cable | October 25, 2004, 2:19 am |
| About link test pulse | October 29, 2004, 4:31 pm |
| Basic link tester | December 15, 2005, 10:19 am |
| D-LINK DFE 530TX+ with LINUX | July 10, 2006, 10:50 am |
>aggregation.
>Since a hash is used to determine which member of an aggregate to put
>packets on in order to maintain ordering within a flow, we probably
>cannot
>get 2x throughput from a 2-member LAG or 3x throughput from a 3-member
>LAG.