Re: [PATCH] batman-adv: Use wifi rx/tx as fallback throughput

René Treffer
2019-06-09T12:45:06Z

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