Re: bonding theory question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Sat, Sep 6, 2008 at 13:11, Mag Gam <magawake@xxxxxxxxx> wrote:
> Actually, would there be a big performance boost when using mode4?

Not necessarily, since balance-rr already gives you load-balancing.
They actually implement it differently. balance-rr can spread packets
of the same TCP connection across the two links, so you may use your
links more, but with the side effect of having your packets delivered
out of order. In 802.3ad all packets of a single TCP connection will
use the same link, this means your links will not be as balanced as
what you get with balance-rr, but it will not require reordering on
the other side of the connection. Check section 12.1.1 in
/usr/share/doc/iputils-*/README.bonding . In any case, you should
evaluate what your needs are and tune for that.

> Currently I am seeing 95% total throughput.

If you have only a few clients doing huge transfers, 802.3ad will
probably not be as good as balance-rr for that. Again, you should tune
it for your needs.

> Which isn't that bad. I am
> peaking at 238MB/sec (each gig/e connections)

I believe you mean 238MB/sec on both interfaces, since 1Gbps = 125MB/s.

> Also, mode0 does fault tolerance, meaning if a switch failure occurs
> we should still be good, but how would the packets then be
> transferred? I suppose rr would be disabled since it won't need to
> alternate, correct?

Actually balance-rr is still there, it is only doing round-robin of
one interface only. Remember, you could have a bonding of 3, 4 or more
interfaces, in that case if you loose one you still have more than one
to balance traffic through.

Filipe
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux