All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 13 Sep 2021 15:40:53 +0200	[thread overview]
Message-ID: <3340507.qp3XP9fiM0@prime> (raw)
In-Reply-To: <20210910175954.1147.78979@diktynna.open-mesh.org>

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

On Friday, September 10, 2021 7:59:54 PM CEST brian.edmisten@viasat.com wrote:
> Simon,
> 
> Thanks for responding.  We are trying out some different solutions for
> bonding these radios.  For scenarios BATMAN seems really well suited for
> the problem but we wanted to test this one and see how much work we need to
> put into it.  I saw the same behavior with IV but I'll switch back and
> check on it.  While its up though here is what I am seeing with V.
> 
> batctl o
> [B.A.T.M.A.N. adv 2019.4, MainIF/MAC: eth0/00:0c:29:c5:d2:da
> (bat0/de:8b:cc:39:d0:69 BATMAN_V)] Originator        last-seen (
> throughput)  Nexthop           [outgoingIF] 00:0c:29:53:f8:c9    0.320s (  
>  10000.0)  00:0c:29:53:f8:dd [      eth2] 00:0c:29:53:f8:c9    0.320s (   
> 10000.0)  00:0c:29:53:f8:d3 [      eth1] * 00:0c:29:53:f8:c9    0.320s (   
> 10000.0)  00:0c:29:53:f8:c9 [      eth0]
> 
> batctl n
> [B.A.T.M.A.N. adv 2019.4, MainIF/MAC: eth0/00:0c:29:c5:d2:da
> (bat0/de:8b:cc:39:d0:69 BATMAN_V)] IF             Neighbor             
> last-seen
> 00:0c:29:53:f8:c9    0.436s (    10000.0) [      eth0]
> 00:0c:29:53:f8:d3    0.340s (    10000.0) [      eth1]
> 00:0c:29:53:f8:dd    0.116s (    10000.0) [      eth2]
> 
> batctl tg
> [B.A.T.M.A.N. adv 2019.4, MainIF/MAC: eth0/00:0c:29:c5:d2:da
> (bat0/de:8b:cc:39:d0:69 BATMAN_V)] Client             VID Flags Last ttvn  
>   Via        ttvn  (CRC       ) * 33:33:00:00:00:02   -1 [....] (  1)
> 00:0c:29:53:f8:c9 (  2) (0x6b62ac80) * 01:00:5e:00:00:01   -1 [....] (  2)
> 00:0c:29:53:f8:c9 (  2) (0x6b62ac80) * 4e:b3:25:58:bd:15   -1 [....] (  1)
> 00:0c:29:53:f8:c9 (  2) (0x6b62ac80) * 33:33:00:00:00:01   -1 [....] (  1)
> 00:0c:29:53:f8:c9 (  2) (0x6b62ac80)
> 
> I do not directly see any of the commands outputting transmit quality  I
> would expect the three ethernet nics to be the same but it is an
> assumption.
> 
> Here is the same info under IV
> batctl o
> [B.A.T.M.A.N. adv 2019.4, MainIF/MAC: eth2/00:0c:29:c5:d2:ee
> (bat0/f2:49:86:e6:ea:aa BATMAN_IV)] Originator        last-seen (#/255)
> Nexthop           [outgoingIF] * 00:0c:29:53:f8:d3    0.976s   (255)
> 00:0c:29:53:f8:d3 [      eth1] * 00:0c:29:53:f8:c9    0.944s   (251)
> 00:0c:29:53:f8:c9 [      eth0] * 00:0c:29:53:f8:dd    0.368s   (255)
> 00:0c:29:53:f8:c9 [      eth0] 00:0c:29:53:f8:dd    0.368s   (255)
> 00:0c:29:53:f8:d3 [      eth1] 00:0c:29:53:f8:dd    0.368s   (252)
> 00:0c:29:53:f8:dd [      eth2]
> 
> batctl n
> [B.A.T.M.A.N. adv 2019.4, MainIF/MAC: eth2/00:0c:29:c5:d2:ee
> (bat0/f2:49:86:e6:ea:aa BATMAN_IV)] IF             Neighbor             
> last-seen
>          eth0     00:0c:29:53:f8:c9    0.032s
>          eth1     00:0c:29:53:f8:d3    0.992s
>          eth2     00:0c:29:53:f8:dd    0.384s
> 
> batctl tg
> [B.A.T.M.A.N. adv 2019.4, MainIF/MAC: eth2/00:0c:29:c5:d2:ee
> (bat0/f2:49:86:e6:ea:aa BATMAN_IV)] Client             VID Flags Last ttvn 
>    Via        ttvn  (CRC       ) * 33:33:00:00:00:02   -1 [....] (  2)
> 00:0c:29:53:f8:dd (  3) (0x9339b660) * 01:00:5e:00:00:01   -1 [....] (  3)
> 00:0c:29:53:f8:dd (  3) (0x9339b660) * 2a:78:9d:5f:f3:f6   -1 [....] (  1)
> 00:0c:29:53:f8:dd (  3) (0x9339b660) * 33:33:00:00:00:01   -1 [....] (  2)
> 00:0c:29:53:f8:dd (  3) (0x9339b660)
> 
> 

Hi Brian,

thank you very much for providing that output. There is only "TQ" (transmit 
quality) in BATMAN IV, BATMAN V uses througput based metric instead (in kbit/
s). For Ethernet, it tries to read the Ethernet speed directl, therefore you 
see those 10000 values.

Anyway, in BATMAN IV the values look close enough (they need to be within 50 
TQ points). Just as sanity check, did you enable bonding? It is disabled by 
default. You can use batctl b 1 to enable it.

Unfortunately there is not really logging code for debugging, so let's try 
checking the settings. If that doesn't work, I could rebuild and verify ...

Cheers, 
      Simon

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

  reply	other threads:[~2021-09-13 13:40 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 [this message]
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=3340507.qp3XP9fiM0@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.