But the difference in throughput about 470 vs about 600 between down and up could be any of a number of things - inefficient txop packing, beamforming, retries, signal strength (rssi), minstrel bandwidth probes, but not (probably) the phase of the moon.
This (2016) set of benchmarks was between an osx and linux station vs the ap -> server, and in general the scheduler should force less latency than a single station test.
Honestly, I don't know what it can be. It's been like this for ever. I'm starting to think it has to do with the APs. If I connect my laptop using an USB dongle to another AP which connects to the main AP as a client, I can see the same difference between up and down. It's like AP favors downloading to itself vs uploading to a client. Some more configuration params, hope it helps.
Yes, no more lag/stall issue for R7800 in 22.03.0-rc6.
Now give yourself the challenge to persuade @nbd to commit the same fixes to 21.02.x so the next 21.02.4 release will be golden again.
That would also be a great consolation prize for people running NSS image with PPPoE WAN. PPPoE/NSS is completely broken in 22.03 and Master (both on kernel 5.10 for R7800), so the only way to get NSS acceleration for PPPoE WAN is to revert back to 21.02 (kernel 5.4). But there you are with laggy WIFI issues. It's like being a little kitten trapped from both ends by 2 raccoon comrades-in-crime.
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
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.
The very first fix that cured that lagging/halting issue was this one:
"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."