b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
From: berkay.demirci@protonmail.com
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: About Throughput in BATMAN_V
Date: Fri, 05 Apr 2024 08:06:56 -0000	[thread overview]
Message-ID: <171230441622.1066.17238774576163032219@diktynna.open-mesh.org> (raw)
In-Reply-To: <3327582.AxlXzFCzgd@rousseau>

I mean batman is getting the right calculation from ethtool but the problem is the value from ethtool is not preferable as throughput can drop as two nodes move away from each other. After checking the batman code, I have a better understanding. Batman's throughput calculation for wifi interfaces is probably desirable because it is using cfg80211's expected_throughput. But we are connecting custom modems to ethernet interfaces so they aren't wlan interfaces so it is using the speed value from ethtool, which isn't always accurate. 

We also did tests in virtual environment and according to this commit https://git.open-mesh.org/batman-adv.git/commit/6e860b3d5e4147bafcda32bf9b3e769926f232c5, ethtool link speed detection used to be disabled for such cases but got reverted since automatic measurements aren't implemented. So, is throughput_meter fallback method that is being worked on right now supposed to be the automatic measurement for cases like this? Whatever the method is, dynamically calculating throughput is a must because like I said, one of our modems have a shorter distance range so it is faster when two nodes are close but as nodes move away, there is lots of packet loss so the real throughput drops as well, but with overriden throughput value stays the same.

BATMAN_IV doesn't have that problem due to considering packet loss but it is worse due to not taking throughput into account so we can't use that neither. If there is any way to take packet loss into account on BATMAN_V that I'm not aware of I would like to learn that, but I'm guessing probably not.

I see that the last patch for tp fallback was written in 2018, has there been no more progress since then? And what are the problems with it?

  reply	other threads:[~2024-04-05  8:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 12:56 About Throughput in BATMAN_V berkay.demirci
2024-04-03 13:16 ` Marek Lindner
2024-04-04  7:00   ` berkay.demirci
2024-04-04 10:00     ` Marek Lindner
2024-04-05  8:06       ` berkay.demirci [this message]
2024-04-08  8:28         ` Marek Lindner
     [not found]           ` <livakUAT6XSpa0RoYB-m2_tK2wjUm-5ZdcvIBa2G1Hw53hhh_tlHIwr2B5nOomayXajuotSI5NGl956q_aZjZG5yVRu5C-uth6lNJcUNCtw=@protonmail.com>
2024-04-15  9:13             ` Marek Lindner
2024-04-15 18:27               ` Berkay Demirci

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=171230441622.1066.17238774576163032219@diktynna.open-mesh.org \
    --to=berkay.demirci@protonmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).