Bug #410
closedProblems with B.A.T.M.A.N. V speed recognition on ath10k
0%
Description
Hi,
I'm not totally sure if this should be a bug request or a feature request since I don't know how the driver output based speed recognition should be working in detail.
I'm trying to setup a B.A.T.M.A.N. V mesh on a TP-Link RE450v1 running on OpenWRT 19.07.3.
It's working but I've got problems with the speed recognition:
[ 37.909038] batman_adv: bat0: Adding interface: wlan0 [ 37.914391] batman_adv: bat0: Interface activated: wlan0 [ 40.476462] batman_adv: bat0: WiFi driver or ethtool info does not provide information about link speeds on interface wlan0, therefore defaulting to hardcoded throughput values of 1.0 Mbps. Consider overriding the throughput manually or checking your driver.
batman_adv version:
root@re450-4:~# batctl -v batctl openwrt-2019.2-4 [batman-adv: openwrt-2019.2-7]
The driver I'm using:
ath10k-firmware-qca988x
kmod-ath10k
What I don't understand is that I can see link speed estimations in iw station dump - so why aren't they recognized by batman_adv?
The link speed is clearly visible from iw station dump:
root@re450-4:~# iw wlan0 station dump Station 88:c3:97:xx:xx:c2 (on wlan0) ... signal: -62 [-73, -65, -67] dBm signal avg: -53 [-64, -57, -60] dBm Toffset: 35108160011 us --> tx bitrate: 975.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 3** --> rx bitrate: 975.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 3** rx duration: 9492580 us last ack signal:-95 dBm mesh llid: 0 mesh plid: 0 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: ACTIVE mesh non-peer PS mode: ACTIVE ...
But batman_adv is not able to use these speed values:
root@re450-4:~# batctl n [B.A.T.M.A.N. adv openwrt-2019.2-7, MainIF/MAC: wlan0/d4:6e:0e:xx:xx:de (bat0/ea:59:0f:xx:xx:d6 BATMAN_V)] IF Neighbor last-seen 78:11:dc:xx:xx:12 0.350s ( 1.0) [ wlan0] 78:11:dc:xx:xx:c2 0.430s ( 1.0) [ wlan0] 88:c3:97:xx:xx:c2 0.250s ( 1.0) [ wlan0]
This results in non optimized routes/hops. In contradiction to the problems with the ath10k driver it is working without any issues on mt76 (mt7615e to be precise).
What I also don't understand is why batman_adv is not falling back to integrated speed measurements. Throughput_override is disabled (set to 0) so it should normally try to estimate the real speed instead of using 1 Mbit/s:
root@re450-4:~# batctl hardif wlan0 throughput_override 0.0 MBit
Do you have any suggestions how to further troubleshoot this to find the root cause?
Updated by Marek Lindner almost 4 years ago
- Status changed from New to Feedback
- Assignee changed from batman-adv developers to Philipp Schuster
Philipp Schuster wrote:
But batman_adv is not able to use these speed values:
This results in non optimized routes/hops. In contradiction to the problems with the ath10k driver it is working without any issues on mt76 (mt7615e to be precise).
Initially B.A.T.M.A.N. V relied on the measured link throughput from the WiFi driver's rate control algorithm. QCA decided to not export this information to the Linux kernel, therefore batman-adv has no method to assess the neighbor throughput on ath10k hardware.
The RX/TX values you are quoting are more marketing values and are not comparable to the measured link throughput in terms of accuracy. Nonetheless, with the 2020.0 release, batman-adv introduced a crude work-around by reading those rx/tx values on ath10k drivers and divide the number by 3. Upgrading to that or a newer release will 'fix' your ath10k devices.
What I also don't understand is why batman_adv is not falling back to integrated speed measurements. Throughput_override is disabled (set to 0) so it should normally try to estimate the real speed instead of using 1 Mbit/s.
Did you read anywhere batman-adv would fallback to automated measurements when throughput_override is set to 0 ? If so, can you please point out where so that we can fix the documentation.
Whether or not to use automated measurements is an ongoing discussion in the project. On our mailing list we have a patchset ready for testing if you are interested.
Updated by Sven Eckelmann almost 4 years ago
- Description updated (diff)
As Marek pointed out, the driver doesn't provide any expected throughput values. This value would look like this (last line):
$ iw dev mesh0 station dump
Station 42:d3:15:28:9b:d9 (on mesh0)
[...]
signal: -85 [-85] dBm
signal avg: -82 [-82] dBm
Toffset: 414793822198 us
tx bitrate: 6.5 MBit/s MCS 0
rx bitrate: 5.5 MBit/s
rx duration: 0 us
last ack signal:10 dBm
expected throughput: 2.197Mbps
[...]
Please close this ticket as rejected after the question about the documentation was answered by Philipp.
But as far as I can see, the documentation is nowhere mentioning "measurements" in connection with "throughput_override". See all occurrences of "throughput_override" at the moment:
The patch series with the automatic measurements needs changes but can be found at:
Updated by Linus Lüssing almost 4 years ago
Just to clarify a bit why they are "marketing values":
It might be that for instance on average the driver needs three tries to successfully transmit at this raw bitrate of 975.0. So the "real" (simplified) throughput would be more like 325 MBit/s. But there might also be a second neighbor for which the driver chooses a raw bitrate of 520.0 MBit/s, but which needs only one transmission. So the "real" throughput would be 520.0 MBit/s. However by only considering the raw bitrates, batman-adv would then wrongly choose the former as the better one.
For ath9k we luckily get the "expected throughput" from the driver, which takes 802.11 retries into account. For ath10k we unfortunately don't. And we can't change that because for ath10k they decided to move the rate control algorithm into a closed source firmware. :-(
But you are right in that that the 1.0 MBit/s to every neighbor does not really help either. So yeah, we teeth-gnashingly accepted the fallback estimation using the raw bitrates divided by three in 2020.0 lately: Batman-adv 2020.0 released
Updated by Philipp Schuster almost 4 years ago
Thank you very much for your quick and well explained answers.
I'll try the "quick and dirty" workaround in 2020.0.
Regarding the documentation it might be my fault. Maybe I just misinterpreted what was meant here:
[[https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking#throughput_override]]
throughput_override
Available since: batman-adv 2019.3Defines the throughput value to be used by B.A.T.M.A.N. V when estimating the link throughput using this interface. If the value is set to 0 then batman-adv will try to estimate the throughput by itself .
Updated by Sven Eckelmann almost 4 years ago
- Status changed from Feedback to Rejected
Ok, I have adjusted it slightly