Yeah, all right, I interpreted incorrectly your post. I'll test rrul_be later. I reckon it was mostly fine. Most of my "toys" are 18,000 km from here too. 
@dtaht, see below a quick rrul_be test with the new topology, as promised in the ath10k thread (this is VHT80).
Any future test will do on HT20. I think it will help with the connection stability, right?
1 Like
really lovely. 4x1 bandwidth disparity. I'm really puzzled as to this in general. I felt after looking over ac and later in 2015 ack-filtering was going to be needed, but never got around to it: https://github.com/dtaht/sch_cake/blob/master/sch_cake.c#L1254
generic rrul, if it blows up, you can fix by quashing the qos_map. I have limited joy in seeing it blow up, but...
Do you mean by this porting it from cake to fq_codel?
I would do it a bit later during lunchtime as my network is under heavy use right now. By the way, I'm using the next qos_map_set in my network, i.e., re-mapping UP 6 and UP 7 to UP 5:
option iw_qos_map_set '1,1,8,1,18,3,20,3,22,3,24,4,26,4,28,4,30,4,32,4,34,4,36,4,38,4,40,5,44,5,46,5,48,5,56,5,0,63,255,255,255,255,255,255,255,255,255,255,255,255,255,255'
cake was in parallel development with fq_codel. The intent was to try out some ideas in cake first, and then compare with fq_codel, and merge the best of them. Over time cake grew to eat wayyyy too much cpu to want to port over to the wifi stack, and fq_codel runs faster on gigE and higher interfaces.
So it may be we go nuts and try to port most of cake over to the wifi stack (which might solve the 802.11e problems), or pieces, but until the last 6 months, most of our efforts were directed at very different stuff, like the L4S vs SCE fight in the ietf. In my case politics, outreach and mikrotik, apple, and now, libreqos, eat most of my time.
the ack-filter port would be so much easier if the fq_codel implementation hadn't grown hairy include files.
Another thing we needed in wifi was the drop-batch facility that's in the main qdisc... or cobalt... and increasingly GSO splitting seems sane. I'd come up with an fq_codel that was saner in a couple respects over here:
https://lists.bufferbloat.net/pipermail/cake/2018-September/004345.html
before getting sucked into the sce thing.
Other wifi factors besides ack-filtering dominate, as we've discussed, dealing with powersave, multicast, rssi, buggy drivers, have been most of the real latency and jitter inducing problems we've faced.
1 Like
Just want to say thank you all for all the effort you guys put into this. Upgraded my access point and router to 22.03 and everything seems to be performing even better than before.
2 Likes
thx!
Me being totally OCD, I sit here and obsess over where the three outliers on the upload come from. P99.99999 would be nice. Not there yet...
do you have an osx netperf binary you could upload somewhere for this person?
In the waveform test I routinely see outliers that I do not see in e.g. flent rrul tests, so I argue that these might be artifacts of using a browser to perform these measurements*, especially after all these side-channel mitigation efforts that decreases temporal resolution of browser time measurements.
*) In support of this I see considerably fewer outliers when using firefox than safari (both under macos) so the browser can add its own delay in this test.
Sidenote: with the relative low number of latency probes P99.99999 will be essentially identical to the reported maximum. And you can download a CSV file of each session, which IIRC contains the individiaal RTTs so one can look at different distribution parameters or generate a CDF/PDF.
2 Likes
Are we like, measuring the TLS exchange? that would cost some time...
Can you share details on your setup? ISP type, router & AP model? SCM settings?
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.