I actually do not know, I guess we/you could invite waveforms maker to another RPM meeting and ask 
I live in a small town in the middle of the UK. My connection is as follows:
Fiber to the cabinet -> VDSL from cabinet to the building -> generic Zyxel VDSL box in bridge mode -> Checkpoint L50 wired router with OpenWrt 22.03 running SQM -> Meraki MR42 access point with OpenWRT 22.03 -> Lenovo X270 laptop running Kubuntu LTS 22.04
I have setup SQM based on the wiki article a few years ago and not done anything special. The AP is in the same room as the laptop so only a few meters away and using a 5GHz channel without any interference from the neighbours.
Just had a more detailed look. I'm using the piece_of_cake.qos for my SQM settings.
Wifi is configured as: mode AC, channel 116, 80MHz width
1 Like
Sure, this will get them there: brew install kris-anderson/netperf/netperf-enable-demo, not sharing the binary because I'm not sure if an arm64 or x86_64 is needed.
Just for the giggles (SQM on WAN 800/47 Mbps), a macOS computer using a wireless connection to WiFi 5 AP (866 Mbit/s), download choking point is my WiFi as you can see:
I will say that achieving 50% of the theoretical speed on a wireless AC link is really good; don't you love OpenWrt?
3 Likes
Wow that is so per’ty!!!!
this was the behavior of a mt79 based AP vs the ax210 pre-august:
near complete lockout of all but EF.
You can find mt7922 on eBay by searching for "MT7922A22M". They're often sold by
disgruntled ASUS users who replace the mt7922 included in their laptops with an
ax210 instead. You can find additional listings sometimes by also searching for
ASUS' model number for the NIC instead, which is "AW-XB530NF".
I found a first-party listing for mt7922 [2], but it's been perpetually out of
stock.
Meanwhile, the 80 MHz brother of mt7922, mt7921, is readily available from
Amazon, and uses the same driver as mt7922.
And buggy.
Part of what led me to mt76 was bugginess in iwlwifi. It turns out that every
iwlwifi NIC that uses RSS (9000 series and newer, so everything from the last 5
years) will occasionally drop bona-fide packets when the RX queues get backed up
with (relatively) too many frames too quickly, which causes a number of
symptoms, one of which is stalls [1].
Another frustration with iwlwifi is that ax200 and newer use RTS/CTS for nearly
every frame, argh. And the logic which decides that is in firmware of course. 
I made a number of changes to mt76 both AP-side and station-side, and currently
on my mt7922 laptop I get 2.10 Gbps RX and 1.90 Gbps TX UDP throughput. This is
with contiguous 160 MHz bandwidth over 5 GHz DFS spectrum and MCS 11 rates.
[2] https://github.com/kerneltoast/kernel_x86_laptop/commit/ca89780690f7492c2d357e0ed2213a1d027341ae
[1] https://bugzilla.kernel.org/show_bug.cgi?id=216044
[2] https://lenovo.encompass.com/item/12936010/Lenovo/5W10V25826/
1 Like
I read the cake code some time ago and learned that "Network Packets" get marked 0x38 (CS7). What about those? Are they kept like EF? Did I correctly understand that everything gets aggregated but EF? Is it what you mean?
cake allocates soft admission control for each of the 3 or 4 classes it supports, alway garunteeing some level of throughput for all. As for why the mt79/ax210 test was so bad, no idea.
Cake does no marking of any kind. However cake will sort CS7, which according to the diffserv fan-fiction (well the IETF originated diffserv, so maybe author-fiction) was traditionally used to mark important network control traffic, into its highest priority tin if it encounters such packets.
CS7 is mapped to AC_VO by OpenWrt's new DSCP-to-WMM mappings.
Yes, I stand corrected. My bad. I had to go back and recheck the code; the last time was a long time ago. I saw that ARP packets get treated and classified in the tins as CS7 (0x38).
1 Like
4 Likes
Oops, I'm such a nerd. That made me laugh. Oh, well, back to business.
I wish I could get closer to that... here's a couple of tests from my lowly ath10 C7/A7 AP's, trying to do better with my laptop's probably lowlier Intel embedded card:
Test setup:
1Gb/35mbit DOCSIS cable - x86 router box w Cake SQM 850Mb/35Mb - C7 or A7 AP's on below OWT versions - Win 10 Laptop with Intel AC 3168
Indicated wifi speed:
433.3Mbit/s, 80MHz, VHT-MCS 9, VHT-Nss 1, short GI, up and down
C7 22.03.0
https://www.waveform.com/tools/bufferbloat?test-id=d8ec0cae-9f04-4a4e-a6c2-84b16f66a351
A7 22.03.0-rc6
https://www.waveform.com/tools/bufferbloat?test-id=1ac8b22f-ff93-4312-8d8a-c48300cf9c67
Sorry, don't know how to insert screenshots.
Complaints/issues:
-I don't seem to see connect rates higher than the above, no matter how close I get. The laptop is 4-5' away from both routers. Probably a limit of the card? I see higher (but almost never 833mbit) on a USB adapter on a farther away desktop, also never see much above 200mbit. Limit of the C7/A7's?
-The latency is higher, as you see. Sometimes the upload approaches 0ms, but the download is usually 15-20ms, when it's good, and never much below that. This is pretty good.
I had also been chasing an apparently consistent speed difference between 22-03.0-rc6 and the release version, with the release version slower, which prompted me to comment here. Annoyingly, it vanished on this new test setup at close range. I thought that would be more interesting/disturbing to you all here, but don't have an example handy.
Typical observed speeds were above 200mbit for -rc6, and about 150mbit for the release version.
Anyway, have been enjoying the serious work getting hammered out, and if I could help from the cheap seats here, I'd be happy to contribute.
Your bandwidth in Waveform is in line with a WiFi connection of 433.3 Mbps, wonder why only that connection speed, even when you get closer to the AP. Did you try upgrading laptop WiFi card drivers?
Upload latency is low because the limit is not your wireless network, but your ISP upload bandwidth. CAKE is doing a fine job keeping your latency low, as expected.
May I ask what drivers you run in your ath10k A7/C7? Are they the -ct ones?
Yep....
Both run the same: ath10k-firmware-qca988x-ct 2020-11-08-1
The board firmware is also the same version between the two releases. I thought there was an update in there, bewteen the -rc6 and final, but it seems not. The other ath10k firmware is the same as well.
You may try the non -ct version; someone else found that -ct version was causing speed issues in his router.
Update: if you plan to run more tests, it looks like the wireless is your bottleneck. Might be good to install netserver and irtt in your x86 box and run flent rrul_be and flent tcp_ndown / tcp_nup tests against it.
Might give that a try at some point. I've seen a lot of people trying a lot of things...
I've been also trying to find optimal settings for the wifi cards, there's always a lot of setting there, and occasionally they seem to influence things. Of course, different cards, different sets of commands...
Best speeds on my C7's has never been above 280mbit or so, with other client adapters, though I have seen people say they have gotten in the 400mbit's.
On the latency side, I used to see down in the single digits on the 2.4ghz radio (ath9k) but not currently. Haven't tried to investigate yet if that's local hardware differences, or something changed in recent OWT versions.
OTGH, on 5ghz and ath10k, I used to see latency in the 30's, so its nice to see it down to 14-15ms on the download...
Update: I would like to "graduate" to some real tests... maybe with a little handholding I could. Kinda been holding back thinking I need to get enough pieces together to have separate test servers and clients off from my router, etc, but maybe with my more powerful x86 box, I could do something useful as is... and learn stuff along the way.
433 at MCS indicates single stream connection with 80MHz, maybe the laptop only has a single antenna, or the spatial arrangement is such that multi stream does not work. So you ether try 160 MHz (only recommended if all sides can do this and you
only have few other APs in your WiFi surround).