could really be that the firmware doesn't declare support for it.
Try adding to your wireless config:
In the config wifi-device section
option airtime_mode '2'
In the config wifi-iface section:
option airtime_bss_weight '1'
1 Like
I'm currently running ath10k with https://github.com/kvalo/ath10k-firmware/blob/master/QCA9984/hw1.0/3.9.0.2/firmware-5.bin_10.4-3.9.0.2-00152 on my nbg6817/ ipq8065/ qca9984:
ath10k-firmware-qca9984-kvalo - 2021-06-21-91e35569-1
kmod-ath10k - 5.10.78+5.15-rc6-1-1
[ 83.117693] ath10k_pci 0001:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[ 83.743945] ath10k_pci 0001:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[ 83.744021] ath10k_pci 0001:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 83.759710] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.9.0.2-00152 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 723f9771
[ 86.031495] ath10k_pci 0001:01:00.0: board_file api 2 bmi_id 0:2 crc32 85498734
[ 89.813922] ath10k_pci 0001:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 512 raw 0 hwcrypto 1
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ ACK_SIGNAL_SUPPORT ]: ack signal level support
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ ENABLE_FTM_RESPONDER ]: enable FTM (Fine Time Measurement) responder
* [ STA_TX_PWR ]: TX power control per station
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
I am using ath10k-ct on g10/ ipq8064/ qca9980:
ath10k-board-qca99x0 - 20210511-1
ath10k-firmware-qca99x0-ct-htt - 2020-11-08-1
kmod-ath10k-ct - 5.10.78+2021-09-22-e6a7d5b5-1
[ 64.309446] ath10k_pci 0001:01:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x10000000
[ 65.763530] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
[ 65.763599] ath10k_pci 0000:01:00.0: msdu-desc: 2500 skid: 32
[ 65.840505] ath10k_pci 0000:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
[ 65.840547] ath10k_pci 0000:01:00.0: wmi print 'free: 48560 iram: 21380 sram: 30852'
[ 66.206942] ath10k_pci 0000:01:00.0: rts threshold -1
[ 66.212627] ath10k_pci 0000:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AQL ]: Airtime Queue Limits (AQL)
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
1 Like
Thanks for that. I've suspected for some time now that air time fairness is not (currently) supported by the firmware. I have a few more things to try before asking @greearb.
It is possible that it might have been enabled in the past as I recall good wifi using 4.19. I have an old image from that time I plan on loading to check. It'd be nice if this turns out to be something that just needs to be re-enabled for the 99x0 firmware.
I disabled at least part of the ATF logic in the firmware, I think it should be done up in driver or mac80211 stacks. Since ath10k-ct reports proper tx status (including tx-rate) on per frame basis, the driver/stack has all knowledge needed to influence ATF I think.
1 Like
Based on greearb's comment above, I'll keep looking into how openwrt detects if a device is ATF capable and see if i can change something so that the output from iw list indicates ATF is available (i am conscious of the fact that iw's output may be unrelated to whether or not ATF is actually functioning).
Since i see nothing relevant to change in hostapd.sh (and qca9984 devices apparently have no ATF related settings in their hostapd conf files but iw list does indicate ATF capability) I'll try changing the ath10k-ct driver's mac.c file from
if (ath10k_peer_stats_enabled(ar) || test_bit(WMI_SERVICE_REPORT_AIRTIME, ar->wmi.svc_map))
wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_AIRTIME_FAIRNESS);
to something like
wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_AIRTIME_FAIRNESS);
(i.e. remove the if statement test or just use a printf to see what the driver is doing here) and see where that takes me.
k that works. iw list now outputs
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
Tomorrow i'll try some testing with netperf as i had done above and see if there is a change.
@ansuel I suspect your initial suggestion to turn on ATF via hostapd configuration is likely necessary (airtime_mode=2 and airtime_bss_weight=1).
@Gingernut's suggestion to configure ATF settings for hostapd via /etc/config/wireless works and this is what I'm currently doing (including a wifi down && wifi up after making any changes).
I'll still need to to convince myself i can turn ATF off and on (via hostapd) and if ATF is having an affect. Assuming I've got in on, some initial playing around seems that it might be doing something.
I have yet to convince myself changing the ath10k-ct driver as described above so that iw list indicates ATF capability does anything more than provide an indication of ATF capability from the driver. I don't know if this indication might be used elsewhere by openwrt.
I'm under the impression the test_bit(WMI_SERVICE_REPORT_AIRTIME, ... component of the if test related to the firmware and i don't recall much about ath10k_peer_stats_enabled(ar)
In short, I'm confused as to why the if statement apparently evaluates true for qca9984 but false for qca9980. For now, I'm assuming this behavior doesn't affect ATF's functioning.
1 Like
if it has to be enabled that means it's disabled from ages and iw just report supported BUT NOT USED.
again could really be that it's not supported by the firmware.... i would create an issue on the ath10k-ct github just to make sure it's not a limitation of the card.
from my recent as well as prior observations, it seems ATF is always enabled.
So far, I can always get an output from
cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/*/airtime
It doesn't matter if:
iw listindicates ATF capability or not, and/orairtime_mode=0is in /var/run/hostapd-phy0.conf followed bykill -HUP $(pidof hostapd)(Settingoption airtime_mode '0'in /etc/config/wireless does nothing - i.e.airtime_mode=0does not show up in /var/run/hostapd-phy0.conf)
This seems consistent with Toke's comment (from you link above) "The config is all for setting policy; if you don't configure anything you'll just get per-station fairness..."
as well as greearb's comment that implies to me ATF is not implemented by the ath10k-ct driver/firmware (but it does depend on tx status and tx-rate from the driver/firmware).
Not yet. The purpose of this thread is to understand the origin of my "undesirable" wifi behavior with multiple clients (as demonstrated by the netperf results described above). I was hoping to eliminate ATF as the source of it by disabling ATF and reproducing the netperf results.
When I noticed that iw list indicated ATF support for qca9984 and not for qca9980, I thought perhaps ATF was not enabled at all for qca9980 - which might explain my observations. That is looking less likely now.
It's still possible ATF is not functioning properly (for me) and that this is related to the apparent inconsistency between qca9984 and qca9980 ath10k-ct drivers but I don't think I can demonstrate it yet.
It's also possible my observations are due to wifi interfance, hardware malfunctions, or my own inexperience.
I do plan on tweeking ATF via hostapd (per BSS wieghts) and seeing what that does.
thing is that the fact that iw doesn't report atf is still a problem and should be checked... if also other user have this on 9980 than i would create an issue on ath10k-ct anyway...
Should it? Perhaps ath10k-ct for qca9984 should not report ATF since apparently it really does not have much to do with it. Which reminds me, i wonder if ATF implementation differs for qca9984 between the ct and non ct versions?
well an explanation wouldn't hurt. Could really be that the option was wrongly never enabled for 9980
1 Like
The other reason I don't want to do it yet is that the discussion is going faster than my ability to evaluate the recent change of getting "ATF" to show up from iw list. My comment to you about adding AFT configs to hostapd came from an netperf observation which indicates things might be different now.
Is my speculation that ATF does not have much to do with the ath10k-ct driver (as opposed to the firmware) really true? I need to do my home work.
I am grateful that greearb took a few seconds to comment here and I don't want to abuse that attention with bug reports of little value - besides, he seen it.
could someone with a qca9984 device running ath10k-ct post the output from:
cat /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services | grep -E '(AIRTIME|PEER_STATS)'
Obviously mine are not enabled:
r7500v2 # cat /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services | grep -E '(AIRTIME|PEER_STATS)'
WMI_SERVICE_PEER_STATS -
WMI_SERVICE_REPORT_AIRTIME -
and before i do something rash like forcing ath10k_peer_stats_enabled(ar) to always return true, I like to know what your WMI_SERVICE_REPORT_AIRTIME state is.
EDIT: also it looks like /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats might be returning peer stats for one less than the number of connected peers for me. I don't think this is related but it did get me thinking how i would know if the tx_rate and other stats data used by ATF is correctly reported from the driver.
Thank you.
This is ath10k, not ath10k-ct:
root@nbg6817:~# cat /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services | grep -E '(AIRTIME|PEER_STATS)'
WMI_SERVICE_PEER_STATS enabled
WMI_SERVICE_REPORT_AIRTIME enabled
1 Like
I submitted a bug report here.
I'll follow this one through, but I think I'm almost done.
Openwrt is a fun project and I've enjoyed spending time on it but using a device with a small user base and that is essentially unsupported is difficult. Certainly, I don't see many other users that would be willing to spend the effort described in this thread trying to figure out why their wifi sucks.
The r7500v2 is still a good switch and it is fortunate there is wireless support via ath10k-ct.
However, I think the developers such as yourself and @greearb are probably better served by simply stating this device is unsupported and spending time on devices with a larger user base. While existing r7500v2 users might complain, in the end they will also be better off not ending up here.
This is r7800 with ath10k-ct and ct-firmware, master build as of 3 days ago.
WMI_SERVICE_PEER_STATS enabled
WMI_SERVICE_REPORT_AIRTIME -
But reading the bug report on github doesn't seem like it will be added back in.
1 Like
I know and thankyou. After a small patch to ath10k-ct mac.c, I can now get iw list to show ATF and i can change ATF weights; however changing ATF weights does not seem to change my netperf observations - at least like I expect it should.
EDIT I closed the bug report as, IMHO, this bug should be fixed in openwrt and not by @greearb. It seems to me that openwrt is "repurposing" the meaning of "NL80211_EXT_FEATURE_AIRTIME_FAIRNESS" in a way that is potentially confusing for ath10k-ct users outside of the openwrt project. The ath10k-ct 9980 firmware does not support ATF. Openwrt does support ATF (outside of the ath10k-ct driver/firmware) and the ath10k-ct driver facilitates ATF.
Are some peers still missing for you in /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats ?
They are all there for me...