[Make-wifi-fast] Re: [Bloat] [Codel] [Rpm] Re: Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dan,


> On Jun 7, 2026, at 20:30, dan <dandenson@gmail.com> wrote:
> 
> I have to argue these points on wifi saturation.  It's like an argument from 2015, it's true for devices speaking in 2015's language but it's simply false for modern APs and devices.

Well, as I wrote I ran a test yesterday, no "stinkin" OpenWrt around*, and still exactly the same suckage (more than 1 second induced delay in the LibreQoS test in the bidirectional phase, only that phase exceeded the WAN capacity), and I see no reason why OFDMA should change much, this was a test with a single station and a single AP... so the issue I saw was not likely to be massive airtime collisions and retransmission storms, but plain old over-sized and under-managed buffers.


*) somewhat hard to pin down exactly, but according to google, both my m3 macbook-pro and the telekom speedport smart 4r2 support OFDMA, so unlike my previous tests this seems to be comparable to your test, no?

> 
> First, I'll acknowledge that CSMA based wifi does suck in the ways described and there's no way to fix that but to replace it. Also, any AP that routinely handles CSMA clients even in mixed modes will struggle with CSMA mostly from hidden node.
> 
> Also, I don't operate in a niche space, my space is where every non-ethernet connected device operates.  I do home, small business, large event centers, hotels, campgrounds, whole building solutions with hundreds of concurrent users.  My wISP operation is the smallest part of the business, it just happens to have the cheapest clients so needs the cheapest solutions.  I'm the anti-niche.

Accept my apology. I still consider WiFi managed by someone with actual clue a niche, but I mainly wanted to juxtapose what you do with what all the APs in my neighborhood do, likely none of the special care you invest at all. I have no reliablle number, but out of the ~38 Millionen internet subscription in Germany the majority likely uses what ever WiFi came with the ISP's router and so will be anywhere from 802.11n to 802.11be (with be being likely quite rare as it is new and expensive).

> 
> The issues described above are non-OFDMA experiences.  OFDMA, at it's very core, is a bi-directional scheduler that is TDMA which erases the CSMA problems that cause retransmit 'storms'. 

Well, that is part of the problem, but not the only one, as it does not address bufferbloat at all.


> A single OFDMA AP and virtually any number of OFDMA clients before you run out of CPU, will not collapse under saturation on OFDMA because they have strict timeslots.

Yes, I should have been explicit, currently all I can report is suckage, not the root cause.

> 
> Worth noting, most decent WiFi7 access points with 6Ghz can strongly encourage OFDMA in clients if you setup a 6Ghz WPA3 only SSID.  It's not a hard rule, but that combination generally strips out all non-OFDMA speaking devices.

Thanks, will keep in mind, once I get such devices.

> 
> This comes down to quality drivers/software on the AP. 

We discussed that before, and I conceed that OpenWrt radios/drivers might have their own set of issues, but the most recent test was outside of OpenWrt, a macbook and an telekom speedport smart 4r2, these very likely use drivers from the radio manufacturers SDK, not the plain old drivers from mainline Linux and both seem to actually support OFDMA.

> WiFi8 is still a paper tiger practically speaking, but WiFi7 is out in full deployment and showing it's power.  Noise at a client is reported to the AP, the AP won't schedule noisy RUs to that client, and vice versa.  Multiple AP deployments see the other APs and channels and schedule RUs based on the amount of data to deliver.  It'll use noisy RUs at lower modulations and clean ones at higher modulations and it does it bi-directionally so noise at the AP can be used to transmit to clients that don't see that noise and vice versa. 
> 
> We have been deploying a hybrid approach with APs operating with WPA3 and >=80Mhz channels to encourage OFDMA and then separate APs on separate channels for older devices on WPA2.
> 
> So when you guys give these anecdotal answers describing <=wifi5/CSMA, I'd really like to know where and if I can get in contact with the facility management and offer them a real, modern wifi network, because we put a LOT of pressure on wifi and your issues are a thing of the past.  They just do not happen on a well designed wifi system encouraging OFDMA use and accommodating older devices.

A here is a disconnect betwen us, I am testing residential wifi, that typically has no facility management attached.

> 
> This might be the space FiWi wants to be, but FiWi will show up to solve a problem that is years in the past.
> 
> Further, I don't think Dave really cared where the bottleneck was, only that there were full buffers and that was a solvable problem.  Putting fq_codel or cake on the AP's interface was the ideal place to handle lots of things,

It was essentially the only place to handle airtime fairness. But yes the goal was to "simply" fix all the affected devices/interfaces...

> including device-to-device communications, but note that he's a founding member of libreqos that puts the shapers on the internet edge as well,

Yes, and he started sqm-scripts as a sort of wondershaper v2, but we realized that even with a debloated WAN, once WiFi becomes the bottleneck, we were back at square one latency-under-load-wise, as wifi simply sucks, so he started make-wifi-fast because solving variable rate links from the wan is a loosing proposition... occasionally is the best you can do (see sqm-autorate, cake-autorate, purple and similar) but is still is a work around for something that should be ideally fixed somewhere else.

> and we had multiple conversations about fq_codel on every intermediate port you could find, each one improving the links.

Not doubting that at all (it matches my memory as well), actually one place where this is missing ist the upstream of most WiFi-stations (I believe this includes most typical radios used for stations under Linux as well).