b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
From: "René Treffer" <treffer@measite.de>
To: Marek Lindner <mareklindner@neomailbox.ch>,
	b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH] batman-adv: Use wifi rx/tx as fallback throughput
Date: Sun, 9 Jun 2019 14:45:06 +0200	[thread overview]
Message-ID: <accc8852-ded3-188b-b72e-313d1b462d18@measite.de> (raw)
In-Reply-To: <3224708.U1DPrJmi8S@rousseau>

On 09.06.19 13:40, Marek Lindner wrote:

> On Sunday, 9 June 2019 18:37:54 HKT Sven Eckelmann wrote:
>> No, we are not interested in rx rate for tx throughput estimations.
> Before ruling rx out, can you explain your thinking behind this magic formula 
> (if smaller compute sum and divide by 6):

Sorry, I should have provided way more context here.... The formula is
min(tx/3,avg(rx,tx)/3), which is tx/3 for rx>tx

My thinking was
1. it should be lower than an expected throughput measurement (play it safe)
2. it should still be roughly in line with expected throughput as
implemented elsewhere

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
> -61     57.8   72.2   29.21   19.266
> -42     65.0   72.2   31.218  21.666
> -58     52.0   1.0    37.994  17.333  8.833
> -56     115.6  144.4  29.21   38.533            !!!
> -65     39.0   72.2   22.338  13.0
> -55     58.5   72.2   29.21   19.5
> -65     65.0   72.2   31.218  21.666
> -59     86.7   117.0  35.705  28.9
> -78     7.2    1.0    4.394   2.4     1.366
> -22     65.0   72.2   31.218  21.666
> -49     72.2   72.2   33.507  24.066
> -68     13.0   21.7   8.879   4.333
> -56     52.0   52.0   24.536  17.333
> -66     43.3   52.0   24.536  14.433
> -63     26.0   39.0   15.563  8.666
> -42     65.0   58.5   31.218  21.666  20.583
> -60     39.0   26.0   20.49   13.0    10.833
> -63     28.9   58.5   17.852  9.633

Cases where the rx/tx estimate would be higher are marked with !!!.

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.

Anyway, there are significant over-simplifications in here:
- Is what I see here even representative / does it apply universally?
- Is 5Ghz and 2.4GHz and their modes even comparable like this? Across
drivers/chips?

Regards,
  René
> +               if (sinfo.filled & BIT(NL80211_STA_INFO_TX_BITRATE)) {
> +                       tx = cfg80211_calculate_bitrate(&sinfo.txrate);
> +                       if (sinfo.filled & BIT(NL80211_STA_INFO_RX_BITRATE)) {
> +                               rx = 
> cfg80211_calculate_bitrate(&sinfo.rxrate);
> +                               if (rx < tx) {
> +                                       return (rx + tx) / 6;
> +                               }
> +                       }
> +                       return tx / 3;
> +               }
>
> Thanks,
> Marek

  reply	other threads:[~2019-06-09 12:45 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 [this message]
2019-06-10  3:31       ` Marek Lindner
2019-06-10  7:37         ` Кирилл Луконин
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=accc8852-ded3-188b-b72e-313d1b462d18@measite.de \
    --to=treffer@measite.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=mareklindner@neomailbox.ch \
    /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).