From: "Кирилл Луконин" <klukonin@gmail.com>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [PATCH] batman-adv: Use wifi rx/tx as fallback throughput
Date: Mon, 10 Jun 2019 12:37:08 +0500 [thread overview]
Message-ID: <CALYz8yoqh8X3hZcafrZAauFT4OZtQZ9r92G+9zW9__ir4m5How@mail.gmail.com> (raw)
In-Reply-To: <4907494.lMUJSmCnaO@rousseau>
Hello, colleagues.
I have a working solution for this problem. It is not batman-related,
but I decided to share it with you right here.
Please let me clarify some details.
1) Some ath10k firmwares (10.2) do not export tx bitrate. So we can't
rely on it.
2) Throughput estimation is better to inject from userspace, rather
than make batman estimate it from unreliable sources.
3) Here is the patch for mac80211 We made for ath10k and such drivers
that do not export expected throughput value.
I also think it's a better way because a lot of drivers do not work
with mac80211 (wil6210). And all driver-dependent math can be easily
changed on-the-fly.
Here is simple patch that make possible this expected throughput injection.
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -12,6 +12,7 @@
#include <linux/debugfs.h>
#include <linux/ieee80211.h>
+#include <net/mac80211.h>
#include "ieee80211_i.h"
#include "debugfs.h"
#include "debugfs_sta.h"
@@ -20,6 +21,8 @@
/* sta attributtes */
+#define DEF_THR_BUFF_SIZE sizeof("4294967295")
+
#define STA_READ(name, field, format_string) \
static ssize_t sta_ ##name## _read(struct file *file, \
char __user *userbuf, \
@@ -490,6 +493,60 @@ static ssize_t sta_vht_capa_read(struct
STA_OPS(vht_capa);
+static ssize_t sta_def_thr_read(struct file *file, char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ int ret = 0;
+ char buf[DEF_THR_BUFF_SIZE] = { 0 };
+ struct sta_info *sta = file->private_data;
+
+ rcu_read_lock();
+
+ // Access synchronization to struct sta_info is documented in
net/mac80211/sta_info.c:34
+ ret = snprintf(buf, DEF_THR_BUFF_SIZE - 1, "%u", sta->def_thr);
+
+ rcu_read_unlock();
+
+ if(ret >= DEF_THR_BUFF_SIZE)
+ return -EFAULT;
+
+ buf[DEF_THR_BUFF_SIZE - 1] = '\0';
+
+ return simple_read_from_buffer(userbuf, count, ppos, buf, ret);
+}
+
+static ssize_t sta_def_thr_write(struct file *file, const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ u32 thr = 0;
+ int ret = 0;
+ char buf[DEF_THR_BUFF_SIZE] = { 0 };
+ struct sta_info *sta = file->private_data;
+
+ if(count >= DEF_THR_BUFF_SIZE)
+ return -EINVAL;
+
+ if (copy_from_user(buf, userbuf, count))
+ return -EFAULT;
+
+ buf[DEF_THR_BUFF_SIZE - 1] = '\0';
+
+ ret = sscanf(buf, "%u", &thr);
+ if(ret != 1)
+ return -EINVAL;
+
+ rcu_read_lock();
+
+ // Access synchronization to struct sta_info is documented in
net/mac80211/sta_info.c:34
+ sta->def_thr = thr;
+ ieee80211_sta_set_expected_throughput(&sta->sta, thr);
+
+ rcu_read_unlock();
+
+ return count;
+}
+STA_OPS_RW(def_thr);
+
#define DEBUGFS_ADD(name) \
debugfs_create_file(#name, 0400, \
sta->debugfs_dir, sta, &sta_ ##name## _ops);
@@ -534,6 +591,7 @@ void ieee80211_sta_debugfs_add(struct st
DEBUGFS_ADD(agg_status);
DEBUGFS_ADD(ht_capa);
DEBUGFS_ADD(vht_capa);
+ DEBUGFS_ADD(def_thr);
DEBUGFS_ADD_COUNTER(rx_duplicates, rx_stats.num_duplicates);
DEBUGFS_ADD_COUNTER(rx_fragments, rx_stats.fragments);
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2305,6 +2305,9 @@ u32 sta_get_expected_throughput(struct s
else
thr = drv_get_expected_throughput(local, sta);
+ if(thr == 0 && sta->def_thr != 0)
+ thr = sta->def_thr;
+
return thr;
}
--- b/net/mac80211/sta_info.h
+++ a/net/mac80211/sta_info.h
@@ -509,6 +509,7 @@
struct work_struct drv_deliver_wk;
u16 listen_interval;
+ u32 def_thr;
bool dead;
bool removed;
Best Regards,
Lukonin Kirill
пн, 10 июн. 2019 г. в 08:32, Marek Lindner <mareklindner@neomailbox.ch>:
>
> On Sunday, 9 June 2019 20:45:06 HKT René Treffer wrote:
> > I am testing this on devices with ath9k (2.4GHz) and ath10k (5GHz), so I
> > was looking at the estimates I get from ath9k. Here is a dump from my
> >
> > home network on 2.4GHz/ath9k and what rx/3 would give us:
> > > signal tx rx expect tx/3 min(tx/3,(rx+tx)/2/3)
> > > -77 13.0 43.3 6.682 4.333
> > > -57 130.0 117.0 44.677 43.333 41.166
> > > -53 117.0 130.0 42.388 39.0
> > > -82 43.3 6.5 13.366 14.433 8.3 (!!!)
> > > -63 52.0 86.7 26.733 17.333
> > > -58 130.0 173.3 29.21 43.333 !!!
> > > -82 6.5 43.3 2.197 2.166
> > > -48 104.0 65.0 40.191 34.666 28.166
> > > -69 57.8 13.0 20.49 19.266 11.8
> > > -58 86.7 52.0 33.507 28.9 23.116
> > > -58 52.0 1.0 37.994 17.333 8.833
> > > -56 115.6 144.4 29.21 38.533 !!!
>
>
> To confirm my understanding: What this table shows are raw tx/rx link estimated
> values ? None of these numbers compares to Minstrel HT expected throughput or
> actual throughput ?
>
>
> > Cases where the rx/tx estimate would be higher are marked with !!!.
>
> I also don't quite understand what the '!!!' thing is trying to indicate. What
> is being compared ? But it may be due to my misunderstandings above.
>
> In my small test setup with one ath10k device meshing with ath9k over 2.4GHz,
> your tx / 3 formula seems to be quite accurate (had removed the rx part).
>
> # batctl o (your magic formula)
> * ac:86:74:00:38:06 0.930s ( 45.7) ac:86:74:00:38:06 [ mesh24]
>
> # batctl tp ac:86:74:00:38:06 (actual throughput)
> Test duration 10440ms.
> Sent 58393512 Bytes.
> Throughput: 5.33 MB/s (44.75 Mbps)
>
> What would be interesting is how the numbers produced by 'tx / 3' compare to
> either the actual throughput (can easily be tested with the throughput meter)
> or Minstrel expected throughput.
>
>
> > Why bother and look at rx at all? Asymmetric routing should already
> > work. I was bit concerned about highly asymmetric links, especially
> > those where the path back might not work. It might not be worth it though.
>
> Generally, the return path might be entirely different. Batman-adv does not
> enforce or even endorse symetric paths. If there is better path for the return
> route, batman-adv will choose the better path based on tx from the sender and
> if only one return path exists, we don't care anyway ..
>
> Cheers,
> Marek
next prev parent reply other threads:[~2019-06-10 7:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-09 10:19 [PATCH] batman-adv: Use wifi rx/tx as fallback throughput René Treffer
2019-06-09 10:37 ` Sven Eckelmann
2019-06-09 11:40 ` Marek Lindner
2019-06-09 12:45 ` René Treffer
2019-06-10 3:31 ` Marek Lindner
2019-06-10 7:37 ` Кирилл Луконин [this message]
2019-06-12 6:39 ` Marek Lindner
2019-06-12 20:50 ` Кирилл Луконин
2019-06-25 8:26 ` Marek Lindner
2019-06-27 10:41 ` Кирилл Луконин
2019-06-27 10:57 ` Marek Lindner
2019-06-10 10:06 ` René Treffer
2019-08-11 12:50 ` Marek Lindner
[not found] ` <CALD2-cLnviLCav=Lui9T4Mzz1nnY93kN_0ypd-nhwFUhKNYRQg@mail.gmail.com>
2019-08-11 13:17 ` Marek Lindner
2019-06-09 10:41 ` Sven Eckelmann
2019-06-09 11:09 ` Sven Eckelmann
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=CALYz8yoqh8X3hZcafrZAauFT4OZtQZ9r92G+9zW9__ir4m5How@mail.gmail.com \
--to=klukonin@gmail.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).