All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edmisten, Brian" <Brian.Edmisten@viasat.com>
To: Simon Wunderlich <sw@simonwunderlich.de>,
	"b.a.t.m.a.n@lists.open-mesh.org"
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: RE: Bonding Alternating
Date: Wed, 22 Sep 2021 15:10:01 +0000	[thread overview]
Message-ID: <48ae7df0caa241f196067aba594f3805@viasat.com> (raw)
In-Reply-To: <2193349.8FveGl8YFJ@prime>

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

Simon,

Thanks for clearing up the hop information.

The radios are not exactly the same throughput wise, but are similar at
short distance.  One is about 80% of the other.

Regards,
Brian Edmisten

-----Original Message-----
From: Simon Wunderlich [mailto:sw@simonwunderlich.de] 
Sent: Wednesday, September 22, 2021 12:55 AM
To: b.a.t.m.a.n@lists.open-mesh.org; Edmisten, Brian
<Brian.Edmisten@viasat.com>
Subject: Re: Bonding Alternating

Hi Brian,

please see inline:

On Tuesday, September 21, 2021 5:41:07 PM CEST Edmisten, Brian wrote:
> Simon,
> 
> The current scenario we are working with we have two different radio 
> systems that already provide a layer 2 mesh network each.  To the user 
> they look like two Ethernet interfaces one for one wave form and one for
the other.
> BATMAN so far is making it more stable in that the convergence of the 
> network is much faster.  There is an opportunity for 3 different radio 
> systems, but the third vendor is unconfirmed.  There was an ask to try 
> to increase bandwidth if the nodes were known to be close together.  
> We were trying out BATMAN's bonding features as using it could 
> simplify our setup and reduce some of the overhead we are getting with 
> the layers or software we are currently using.

Thank you for elaborating! Are these radios providing the same throughput?
One thing I noted when doing tests back then is that the slower link will
slow down the combined link, since it is sending packets in a round robin
fashion. 
In other words, with two links, if the slow link has half the throughput of
the fast link, you will not have any benefit.

> 
> When you say one hop, do you mean one BATMAN hop or something else?  If it
> makes a difference my testing was direct but I think the radios will
> actually look like there is a switch between the nodes.

Whether there is a switch or not doesn't matter to BATMAN. By one hop I
meant 
they are directly connected via Layer 2, there is no intermediate BATMAN hop

acting as a relay.

Since you will be using Ethernet links and not WiFi links, BATMAN will not
be 
able to detect that you are actually using radio links, since its only 
checking kernel internal structures (whether the device uses cfg80211 or 
wext). I'm adding a patch to generally treat interfaces like wireless 
interfaces from a routing perspective, this could also make a difference for

your VM tests.

> 
> Thank you for looking in to this for me.  BATMAN is doing great for our
> first use case.

Great to hear :)

Good luck using it and thank you for your feedback!

Cheers,
      Simon

> 
> Thank you,
> Brian Edmisten
> 
> -----Original Message-----
> From: Simon Wunderlich [mailto:sw@simonwunderlich.de]
> Sent: Tuesday, September 21, 2021 7:16 AM
> To: b.a.t.m.a.n@lists.open-mesh.org; Edmisten, Brian
> <Brian.Edmisten@viasat.com>
> Subject: Re: Bonding Alternating
> 
> Hi Brian,
> 
> I've checked it out and can confirm your issues. The bonding code as
> currently implemented is trying to use a different router from each
routing
> table towards the same originator[1]. However, with 1-hop Ethernet links
> those routers are always the same in all the routing tables. With WiFi
that
> would be a bit different (I've commented out the WiFi penalty check), but
> even then it only alternates between two of the three interfaces.
> 
> At this point I don't have a straight forward fix for this. Will you use
> three Ethernet devices in your later deployment, or will those be WiFi
> interfaces?
> Also, would it be useful for you to consider bonding/teams interfaces of
the
> Linux kernel to bond the link, and give that to batman-adv?
> 
> Cheers,
>        Simon
> 
> [1]
>
https://www.open-mesh.org/projects/batman-adv/wiki/Network-wide-multi-link-o
> ptimization
> 
> On Wednesday, September 15, 2021 4:58:58 PM CEST Edmisten, Brian wrote:
> > Simon,
> > 
> > Thank you. I appreciate you looking at this.
> > 
> > Regards,
> > Brian Edmisten
> > 
> > -----Original Message-----
> > From: Simon Wunderlich [mailto:sw@simonwunderlich.de]
> > Sent: Wednesday, September 15, 2021 12:26 AM
> > To: b.a.t.m.a.n@lists.open-mesh.org; Edmisten, Brian
> > <Brian.Edmisten@viasat.com>
> > Subject: Re: Bonding Alternating
> > 
> > Hi Brian,
> > 
> > hmm, I see. I will try to set up this scenario over the next few days
> > and let you know. I haven't used bonding for quite a while now, but I
> > also don't think that we had changes in the code which would break it.
> > 
> > Anyway, will test and let you know.
> > 
> > Cheers,
> > 
> >       Simon
> > 
> > On Tuesday, September 14, 2021 6:57:37 PM CEST Edmisten, Brian wrote:
> > > Simon,
> > > 
> > > I did check again.  batctl bonding responds with enabled.
> > > 
> > > Cheers,
> > > Brian Edmisten


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4956 bytes --]

      reply	other threads:[~2021-09-22 15:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 20:09 Bonding Alternating brian.edmisten
2021-09-10  7:15 ` Simon Wunderlich
2021-09-10 17:59   ` brian.edmisten
2021-09-13 13:40     ` Simon Wunderlich
2021-09-14 16:57       ` Edmisten, Brian
2021-09-15  7:26         ` Simon Wunderlich
2021-09-15 14:58           ` Edmisten, Brian
2021-09-21 14:16             ` Simon Wunderlich
2021-09-21 15:41               ` Edmisten, Brian
2021-09-22  7:55                 ` Simon Wunderlich
2021-09-22 15:10                   ` Edmisten, Brian [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=48ae7df0caa241f196067aba594f3805@viasat.com \
    --to=brian.edmisten@viasat.com \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=sw@simonwunderlich.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.