yea!
I'd really like more folk to try one tiny tweak for 5ghz: Reducing the codel target to 6ms. IMHO Really should "just work". requires a one line patch.
Also aql_threshold can be fiddled with in sysfs.
1 Like
What is the last snapshot? Or did they compile themselves?
Does this apply to all ath10k devices and do you need to explicitly install the -ct variant?
I've not really been paying attention to the new drivers so have no idea what its all about, but I have a C7 and a Fritzbox 7530, both of which could benefit from this.
AFAIK all ath10k devices should be using by default the -ct variant.
I too am seeing that kind of improvement, on my C7 v3 (US v3, has no 2.4ghz int antennas) on v2 April 4 snapshot.
Prior performance on 5ghz was 20-30ms only with very strong signal and highest data rates, but with a bit of signal drop 100-200ms was the normal. As opposed to the ath9k 2.4ghz being in the 20's almost till loss of connection.
Now, am happily seeing 20-40ms on the ath10k 5ghz radio, far across the house... that is, inbetween times of my cable provider ISP itself falling apart under heavy stay at home Netflix binge primetime loading.... was seeing 10% packet loss to 8.8.8.8 the other day!
Dave... could you or someone publish a dummies tweeking guide, so this dummy and others could more easily try different settings?
There's very very little to set or twiddle with. It mostly just works (in combination with other really complicated things) I've long recommend folk make other mods to their wifi on top of this for years, however those are generic enough to apply to any fq_codeled chip, not just this one, and are subject to my biases for extremely low latency vs bulk throughput. (use a qos_map to just use BE, reduce txop size to 3ms or less, in both the beacon and driver, reduce hw retries, disable b rates) and I keep hoping someone will believe me when I say this makes wifi massively better for gaming, web traffic, in the face of multiple devices, interference, and bad links.
Specific to aql on the ath10k, for this thread.
If you are running at low rates (HT20 in my case, 28Mbits typica; throughput), reducing the aql_threshold to 6k is helping. I'd actually like this to autoconfigure.... but need field data.
If you are low on cpu and operating at high rates, you can twiddle the aqm quantum. 300 is a good number below 200mbit.
5 Likes
package / kernel / mac80211 / patches / subsys / 310-mac80211-Implement-Airtime-based-Queue-Limit-AQL.patch
You mean to edit the values at build time here?
1 Like
I get better much throughput with the non-ct variant on my C7v2.
1 Like
Have you tested latest snapshots since airtime fairness patches were ported to ath10k-ct also?
That's kind of a confusing statement. I found the ath10k essentially unusable at low speeds, but I have not got around to trying for more lab-like high speed results as yet...
I got scared by the 5.4 kernel upgrade that happened mere days after this wonderful first test. I have limited time in life to debug general kernel issues (has anyone tried the 5.4 kernel on the ubnt and archer platforms yet?).
No, the aql_threshhold I mentioned is a sysfs value in /sys/debug/kernel/iee*/phy*/
The only kernel patch I've been fiddling with is fiddling with the codel target.
2 Likes
@SteveNewcomb - dyin to hear of a new batman result with aql on....
Does the advice to disable WMM apply to regular access point networks as well, or should it be kept on?
I need to be clear in hostapd.conf that wmm=off is not the right thing, but in general I recommend fq_codel'd APs disable the extra queues via the qos_map_set, or really limit them. That said, experimentation in our new videoconferencing centered universe is probably in order.... webrtc supports diffserv markings, but few enable them.
I'm like, really afraid to ever post for example, what I announce in beacons, for fear people will endlessly copy/paste what I said rather that understand it in the first place.
2 Likes
Ok, WMM will say on.
And you would be right, as that's exactly what I was planing on doing =) However, after a bit of searching around it doesn't seem like changing qos_map_set is a trivial thing in OpenWrt, so I'll leave this be for now.
Sorry for the delay, Dave, and very psyched up to try it. Working on it now.
Yeah, in fact, we've had discussions on this here in the forum, and it never seemed to me that the feature had actually made it into OpenWrt's version of hostapd. People were trying it, and then the result is no change in behavior.
1 Like
Yeah, it does not build easily, this is still on my perpetual TODO list, after shephering RTX stats into the lantiq vrx200 dsl driver...
With more people/applications playing games with dscps and WMM it becomes IMHO essential for OpenWrt to allow a measured response....
Agreed. The ability to adjust the qos map is an important missing feature for OpenWrt APs.
Bah. Still working on it. Test didn't work because I accidentally built the trunk with ath10k-ct instead of ath10k, which would require a different /etc/config/network and /etc/config/wireless. I haven't yet made such a known-working config for ath10k-ct. Anyway, I want a test that compares apples to apples. (Configuration management is annoying.) Maybe later today... unless I make another silly mistake.