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