|
Posted by anoop on August 1, 2008, 8:13 pm
If you were Registered and logged in, you could reply and use other advanced 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
If you were Registered and logged in, you could reply and use other advanced 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.
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
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
If you were Registered and logged in, you could reply and use other advanced 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?
>
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
If you were Registered and logged in, you could reply and use other advanced thread options
> 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 | | Testing Link aggregation without LACP | January 25, 2007, 3:45 am |
| Port trunking / link aggregation problem | October 8, 2006, 9:11 am |
| VLAN Aggregation | July 4, 2008, 8:21 am |
| Link Up Time | March 14, 2006, 12:24 pm |
| Basic link tester | December 15, 2005, 1:19 pm |
| D-LINK DFE 530TX+ with LINUX | July 10, 2006, 10:50 am |
| trying to bring up a 1000Base-X link | August 21, 2006, 3:42 pm |
| Link connected question | January 30, 2007, 8:05 pm |
| No link detection on copper SFP | May 25, 2007, 5:58 pm |
| "Forcing" gigabit link operation | March 20, 2006, 4:02 pm |
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map