OMG! I hope this is the fix.
This patch seems to be part of a patch set, which includes the re-worked overflow airtime weight calculation. Maybe I'm being too much of a skeptic, but the patch here just removes the airtime adjustment of the first rb-tree node every time the ieee80211_txq_may_transmit API is called. The txq passed into the API is still being evaluated for eligibility to transmit, so it doesn't seem (to me anyway) that it will help the issue any.
1 Like
Quarky can you test this patch set before it goes official. Let's hope it doesn't make other unexpected changes.
Well, I kind of is a little hesitant in this instance as I don't think it'll help.
I'm now thinking along the line that maybe the virtual airtime values (for both the txq and per interface ac queues) are not getting updated properly. It seems that these values are only getting updated when a txq is getting scheduled into the rb-tree, and that it is not already in the tree. It would have made more sense (to me anyway) to update the virtual airtime values when a txq is being used and returned back to the rb-tree. I can't see these value getting updated anywhere else, and these values are used exclusively to determine if a txq is eligible for transmit.
Of course (as is often the case :-P) I could be wrong. Still trying to understand how the airtime scheduler functions.
1 Like
I wish our open-source developers (whose generous volunteer efforts I have always appreciated) would occasionally have some WebEx / Zoom meetings to discuss certain persistent critical issues. Writing emails or posting in forums with thousands of posts may get lost in the insane info-overloading world nowadays.
2 Likes
I think I have to take back what I said about the patch. It may have some effect after all. The part of the code that was removed may update an interface's global airtime value if the first node of the rb-tree of that interface is thought to have missed out on transmit time. Likely this should not have happened. I guess it does not affect other mac80211 driver (e.g. mt76 based ones) because ieee80211_txq_may_transmit() is only called by the ath10k driver.
Back to my analysis a few post back. It appears I was wrong ... again. The airtime values are indeed updated by the ath10k driver when it transmits packets. Without it being updated, no transmission will be allowed, as likely the check to allow transmission will likely fail most of the time.
@sppmaster, I'll try to test just this patch (without the recent weigh adjustment patch) and see if it has a positive effect.
3 Likes
Bad news. I still encounter latency spikes. Very apparent when playing online games. Game play stutters. Reverting back to the round-robin scheduler.
1 Like
Please try the latest version in OpenWrt master to see if it improves ath10k latency
5 Likes
I am all in favor of all us getting together via videoconference if this latest patch doesn't fix it. With beer, yerba mate, and combustibles at hand. If this patch does fix it, I'm alsol in favor of all us getting together to celebrate.
6 Likes
Back-ported the patch to 21.02 for my R7800.
Will report back in a few days if there is any improvement.
1 Like
Thank you vey much Felix and Dave for all your incredible efforts in making OpenWrt a very enjoyable experience for all of us. Much appreciated.
2 Likes
Sooner than I expected, but the patch did not resolve the latency issue I'm facing with my R7800. I have to qualify that it is back-ported to 21.02 and using an older qca9984 firmware compared to master.
Unfortunately I have to revert back to the round-robin scheduler build again.
Let's hope those testing the latest master builds will have better results.
3 Likes
Forgive me if it has already been asked but does this only refer to ath10k or also ath10k-ct?
Your question is to @Quarky, but for any one else following along, the use of "this" in your question is a bit unclear. Also, as I suspect you are aware, the title of this thread is misleading.
Commit 958785508 affects mac80211 and may affect any driver/firmware that utilizes AQL/ATF on the master branch.
This might include ath9k, ath10k, ath10k-ct mt76, etc.
As an example, the r7500v2 with the ath10k-ct driver/firmware by default uses AQL but not ATF. Based on this patch comment in commit 958785508, I expect it will affect the r7500v2.
Perhaps someone knowledgeable can suggest a method such as
r7500v2 # iw list | grep -A 15 "Supported extended features:"
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
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 16
--
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
Note in the output above [ AIRTIME_FAIRNESS ] is missing.
If you see either (or both) [ AQL ] and [ AIRTIME_FAIRNESS ] in the output and your running master (or some other DIY build) with the commit 958785508, then you may be affected.
2 Likes
Please test if this patch helps: https://pastebin.com/LqdrpxCJ
Theoretically it should force scheduling on ath10k (and any driver without explicit ATF support) back to a simple round-robin variant.
If you're using ath10k-ct and it enables airtime fairness, please change the driver like in my patch to disable the airtime fairness flag.
3 Likes
Do I apply this patch over the latest VTAB ATF patches (i.e. with the weight computation change) or should it be applied just over the existing VTAB ATF code?
2 Likes
Applies on top of the latest code from master
3 Likes
Thanks for all of your efforts put to make Wi-Fi fast.
But please read my observations here and here.
Since this commit Wi-Fi 5GHz is completely unusable.
Before it I never had any latency issue with WLANs.
1 Like
Did you try my patch as well?
I haven't tried it yet.