AQL and the ath10k is *lovely*

Thank you. Now, is the wifi performance better with these patches than it was in 21.02.1 or am I asking for too much? :slight_smile:

Yes, WIFI in 22.03.0-RC6 and current Master work as well as 21.02.1 and maybe even better.

2 Likes

Depends for who... I didn't notice any major differences in speed or access times - I'd even be inclined to say that speeds were better on 21.02 - especially on longer distances (on ipq4018).

One of the things we've been doing semi-successfully is adding more rigor to the tests, and retaining historical data, so we can better compare "improvements" going forward. Right now I see too much latency compared to the original (2016) ath9k effort, and don't have any good data on multi-station performance with the fixes we've landed to date. I think the

tx_queue_data2_burst=2.0

(and 3) AP changes need to be tested on more hw in particular, which will improve throughput from the AP in contended scenarios. Two patches starting at: Reducing multiplexing latencies still further in wifi - #10 by amteza have not made it into rc6, but are just scripts....

So my hope would be for all of us, to somehow, going forward, to not be "inclined" to think things have got worse or better, but to actually know. :slight_smile:

5 Likes

We were not talking about lagging that could only be observed when running tests with tools like flent etc. The lagging problem in 21.02.2, 21.02.3, 22.03.0-RC5 (and earlier) was so severe that online meetings (WebEx, Zoom etc.) or online games appeared to be frozen for a few minutes (yes minutes!) when the lagging condition surfaced, to the point of having an unusable network. There were several different culprits that might trigger such condition, but one of the well-known culprits (as reported by many people, including me) was due to some WIFI client (e.g. phone etc.) leaving the home when these online activities were happening.

1 Like

so far as I understand the walkaway bug was resolved by this: AQL and the ath10k is *lovely* - #780 by Lynx

we weren't so much talking about "lagging" but "halting" in that case.

The very first fix that cured that lagging/halting issue was this one:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=aab535d2bbc414aecde5770152e7da6690462b9a

"mac80211: add airtime fairness improvements

This reverts the airtime scheduler back from the virtual-time based schedulerto the deficit round robin scheduler implementation.
This reduces burstiness and improves fairness by improving interaction with AQL."
1 Like

I am under the impression that was un-reverted with the true fix being the multicast fix. ?

Also, I am pedantic - "lag" to me means events measured in ms. "halting" means events measured in 100s of ms.

1 Like

That fix was only for people using multicast (e.g. enabling uPnP) in their WIFI network. The horrible walkaway bug had nothing to do with multicast.

@nbd pretty please ...

@nbd

This is the original bug filed for this issue:

1 Like