public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: Ray Gibson <booray@gmail.com>
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] Testing example of interface bonding
Date: Wed, 13 Aug 2014 14:34:20 +0200	[thread overview]
Message-ID: <2752578.H2iNbLeYOX@prime> (raw)
In-Reply-To: <CAA51LVpzYaMEkrsKwo2yXkMg9+zTtBtqGO7=96mB0Pyv+NSB6w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

Ray, 

On Tuesday 12 August 2014 11:21:18 Ray Gibson wrote:
> 
> I've put all the output in a pastebin as to not clog up everyone's inbox:
> 
> http://pastebin.com/6fqUUUYq
> 

Thanks! The output actually looks fine. I've tried a little bit myself in a few 
VMs and noticed two problems which were preventing bonding to work, at least 
for me:

 * There was a trivial (and rather stupid) logic bug in the check whether 
bonding should be considered or not. See "[PATCH] batman-adv: fix and simplify 
condition when bonding should be used"
 * Another not so trivial problem is that bonding with the multi interface 
optimization checks the originator tables for the different interfaces. However 
since you don't use WiFi and all links appear perfect, the same router is 
often chosen for the different interfaces and the bonding has not enough 
candidates to choose and do round robin. I've sent an experimental patch 
"[RFC] batman-adv: experimental sysfs variable to always apply half duplex 
penalty" which allows to turn on the interface / half duplex penalty for all 
interfaces, not just wifi interfaces. That patch will most probably not make it 
upstream, but should be good enough for testing. Enable it with:

echo 1 > /sys/devices/virtual/net/bat0/mesh/always_half_duplex_penalty

Please apply these two patches, set the new option and try again!

> [...]
> 
> Regardless of its potential impact on performance, I think it's worth
> a look and test to see if there may be some potential benefit.
> Currently this setup is working nice in that it's a true case of point
> to point redundant links.  If additional links could be added or
> removed at will to enhance throughput I would see this useful in a
> variety of applications.  Currently, I'd like to just reproduce what
> the function was originally designed to do and then go from there.

OK, sure, it can't hurt to try it out - maybe you can even find ways to 
optimize it. In any case, we would be happy to hear about your test results 
and experiences. :)

Thanks,
    Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

      reply	other threads:[~2014-08-13 12:34 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
2014-08-12 18:21   ` Ray Gibson
2014-08-13 12:34     ` Simon Wunderlich [this message]

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=2752578.H2iNbLeYOX@prime \
    --to=sw@simonwunderlich.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=booray@gmail.com \
    /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