To clarify: “usual WiFi speed”; as in “good performance” or “bad performance”?
1 Like
Sorry for the short wording. I've meant I see the usual very good Wi-Fi performance with Ath-10k drivers that I had so far too.
I add that I've never experienced any latency issue (that other people have) prior to latest mac80211 patch.
Edit - the above is no longer valid with latest patches so just ignore it.
1 Like
Are we talking CT firmware or mainline firmware? Does the driver also matter, CT vs mainline?
Trying to build a table of WTF is working and what isn't, is on my mind.
Nailing this set of bugs to the wall and closing it out is proving to be almost as difficult as this one was:
And I DON'T want to spend (our) summer vacation on it.
3 Likes
On master snapshot (on kernel 5.15.38) without without a patches there was a transfer of about 18-20Mbps in 10 meters in a rather crowded environment (two floors, two ceilings, partition wall ...), ping about 30 +/- 5ms. For comparison, I have about 35Mbps on the cable, and with the device itself, the wifi is not much better than at 10 meters in the smartphone. After applying the fix, the speed is similar (maybe a bit higher because sometimes it reaches 24Mbps) but the ping is about 5ms better on average. Except that I applied yet another fix- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=4bcc2ab96fce497ab9c7863dd051bdcf0a5018bf. It seems better than before the corrections, but it takes time for it, and on the LTE connection it is reading tea leaves 
.
Firmware ath10k ver 10.4-3.6-00140 and kmod-10k-ct. Tests in 2.4GHz freq. Linksys EA6350v3 (ipq4019).
Bad news. The patch didn't resolve the high latency issue I'm facing with the new VTBA scheduler. I'm reverting my build back to the round-robin scheduler.
OK... After a cursory test, it appears that the fixes do not fix either bandwidth or access times in any way. After applying the patch, strange messages appeared in the log (i.e.10k_ahb a000000.wifi: received unexpected tx_fetch_ind event: in push mode and ath10k_ahb a000000.wifi: DFS region 0x0 not supported, will trigger radar for every pulse) for both 2.4GHz and 5GHz - I tried with various firmware but it did not help. After the appearance of the messages, the link was degraded and, as a consequence, the lack of normal access after a few hours (even 1/10 of the initial transfers- after restart device- which disqualified the normal use, ping was fairly normal).
After restoring the previous state without corrections, no errors, normal transfers and normal ping (as for the Internet after LTE 
). Also, what I wrote earlier about the corrections could be premature - although it may work on some devices. On the ea6350v3 unfortunately it does not work.
1 Like
I don't know if the WLAN stuck is connected to the new patches but I see the same issue on three different R7800 as I wrote here. I've returned to the previous build.
why use ct firmware/driver anyway?
1 Like
This just went upstream, bypassing ATF.
https://lore.kernel.org/all/20220611200106.34319-3-nbd@nbd.name/
8 Likes
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