From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Cc: brian.edmisten@viasat.com
Subject: Re: Bonding Alternating
Date: Fri, 10 Sep 2021 09:15:18 +0200 [thread overview]
Message-ID: <8679334.VDzE56WMh6@prime> (raw)
In-Reply-To: <20210909200939.1153.2026@diktynna.open-mesh.org>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
On Thursday, September 9, 2021 10:09:39 PM CEST brian.edmisten@viasat.com
wrote:
> Before Adding radios to my setup I connected to computers with three NICs
> each. I added all three interfaces to the mesh interface bat0 on each. I
> then run iperf across it and all the traffic seems to go on one interface.
> I run iperf3 with -p 4 so there are multiple streams. Changing it to
> bonding does not seem to change the behavior. batctl o - shows all three
> interfaces
> batctl n - shows three interfaces -This I thought seemed odd as its one
> neighbor across three links batctl tg - shows all clients Via one address
>
> If anyone can point me at what to look at next or what might be wrong would
> help.
>
> I am using BATMAN_V version 2019.4 in kernel 5.4.68.
Hi Brian,
can you perhaps post the output of those commands?
If bonding works, it would even spread one iperf stream among the multiple
links. For bonding to work, the TQ values must be on a similar level,
otherwise it will not be activated.
I haven't really tried bonding with BATMAN V, you may want to try with BATMAN
IV instead.
Please note that bonding will schedule the packets over the available
interfaces, but will not perform any reordering on the receiver side. This can
upset TCP which handles reordering as losses. In experiments with WiFi links,
I often actually got degraded performance because the queue depths of the WiFi
links were growing differently, therefore causing reodering ...
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-09-10 7:15 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 [this message]
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
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=8679334.VDzE56WMh6@prime \
--to=sw@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=brian.edmisten@viasat.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 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.