From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Testing example of interface bonding
Date: Mon, 11 Aug 2014 23:38:20 +0200 [thread overview]
Message-ID: <1463029.4iWUHdE7x7@prime> (raw)
In-Reply-To: <CAA51LVr2ogEGnJNCepYRm2eAZvE_TpPFTeLf6BXkVpjyFfHSFg@mail.gmail.com>
Hello Ray,
thanks a lot for your mail.
On Sunday 10 August 2014 15:00:51 Ray Gibson wrote:
> Hello,
>
> Are there any documented cases (aside from the aging graph on the
> wiki) on batman-adv bonding setups?
Not as far as I know. The bonding feature does not seem to be the most popular
one. :) (If there is anyone, please tell us!)
>
> I'm testing batman-adv 2014.3.0 in an effort to experiment and test
> with multi-link optimizations. There is no wifi in the picture at the
> moment, this is being done with tap interfaces right now.
>
> My two nodes have this network config:
> lan0: bridge of eth0 and bat0, 192.168.100.1 on node1, 192.168.100.2 on
> node2 bat0: includes tap0 and tap1 active, no IP.
> eth1: "wan" link, 10.10.10.1 on node1, 10.10.10.2 on node2
> tap0/1: openvpn bridge links over eth1, no IPs assigned to these interfaces.
>
> This is a VMware environment for testing. With the above setup, I can
> ping/iperf/whatever back and forth on the 192.168.100.x network. It
> works great just extending a lan transparently on a wan link. This
> was the original idea, with redundant connections (hence the multi tap
> interfaces).
>
> Now, I'm trying to isolate the test down to bonding. However,
> enabling bonding in batctl on both nodes has no apparent effect
> whatsoever. Watching an iperf session in ifstat, I will see constant
> traffic on bat0, and then either tap0 or tap1 depending on how it's
> feeling at the time. Sometimes it will shift all the traffic to the
> other tap interface. Sometimes the incoming traffic will be on one
> interface and the outgoing traffic will be on the other.
>
> Note: I'm running iperf/etc on the nodes themselves, not on separate
> devices on the lan bridge.
Hmm. What you should see after enabling bonding would be a similar usage of
both interfaces. I guess each tap interfaces of node1 is "directly connected"
to the other tap interface of node2, right? Could you please share your
outputs of:
batctl originators
batctl originators -i tap0
batctl originators -i tap1
>
> Ultimately I am looking to try bonding several 3G or 4G devices
> together with batman-adv to achieve higher throughput to a single
> destination.
Please note that the bonding will only benefit under some circumstances, as far
as my experiments have shown:
* since its round robin, you'll only see a benefit if the worst link does not
have less than 50% throughput of the best one - otherwise it will slow the
other links down.
* different latencies or buffering delays in the links may lead to out of order
packets, and not every payload traffic likes that.
I could see some improvement when having two equal wifi links though. In any
case, please thoroughly test it before applying that to your 3g/4g
application, there may be some pitfalls. I'd be also very interested in your
findings. :)
Thanks,
Simon
next prev parent reply other threads:[~2014-08-11 21:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-10 22:00 [B.A.T.M.A.N.] Testing example of interface bonding Ray Gibson
2014-08-11 21:38 ` Simon Wunderlich [this message]
2014-08-12 18:21 ` Ray Gibson
2014-08-13 12:34 ` Simon Wunderlich
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=1463029.4iWUHdE7x7@prime \
--to=sw@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox