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

["René Treffer" <treffer@measite.de>]

On 10.06.19 05:31, Marek Lindner wrote:
> 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 ?

Ah sorry, _expect_ is the current ath9k expected throughput and that
should be minstrel, right? I pulled data from my ath9k devices, e.g.

> # iw dev wlan1 station dump
> Station e8:de:27:70:0e:bd (on wlan1)
>         [...]
>         signal:         -56 [-59, -59, -80] dBm
>         tx bitrate:     117.0 MBit/s MCS 20
>         rx bitrate:     144.4 MBit/s MCS 15 short GI
>         expected throughput:    42.388Mbps
>         [...]
Those are the potential inputs (-56, 117, 144.4) and a desired output
(42.388), or as a table

> signal  tx     rx     expect
> -56     117.0  144.4  42.388
I then computed manually the tx/3 (39.0) which is lower than
(rx+tx)/2/3. The full line would be

> signal  tx     rx     expect  tx/3    min(tx/3,(rx+tx)/2/3)
> -56     117.0  144.4  42.388  39.0
I hope this makes sense now. I wanted to get close to the current
throughput estimation with worse inputs.
I would be happy to check more inputs, but the tx/3 turned out to be
pretty close and usually slightly lower.

>
>
>> 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. 

I haven't done an actual throughput test, and I would expect the outputs
of my heuristic to be worse.
So I wanted to give slightly lower values than the expected throughput.

The other way to think about it: if you were to replace the
expected_throughput input where would you over-estimate the link quality
now?

>
> 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. 

Comparing with actual throughput sounds like a good idea, I'll do that next.
Right now I don't know how well estimates on both radios hold and how
well they are comparable.

>
>
>> 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