What level of control does openwrt have (running locally on an AP) over the wireless hardware?
Is the physical wireless hardware a ‘black box’ from openwrt’s perspective?
Thank you @Lynx !
I hope to do exactly that 
I LOVE to get involved with the developers of products/ projects I actually use, nothing comes close to the open source community in this regard; allowing the developers to work directly, hand in hand with the downstream users of their work.
It is truly amazing what can be achieved, and HOW FAST IT CAN BE DEPLOYED when one leverages this idea.
Thank you for the guidance, I will tune these paramaters a bit in my trusty old n66u, see if I can shave a bit of load off the cpu and gain a bit more shaping performance for my efforts.
on the list 
Absolutely am;
At this point my upgrade path is probably going to be an upgrade to something x86 based for my HOME router, and then I will transfer the Mikrotik hEX into service for the mobile event network deployment.
Although I am hearing really good things about the cake performance of the 64bit belkin rt3200/linksys e8450.
At ~$50 US on eBay I am getting tempted to take one for a spin.
The RPi4 is still on my list though; I have an old OG RPi1B that sits in my network cabinet running PiHole and a few other fun things.
And if @dtaht wants to drop a link, or perhaps a few lines of text on what he has been working on out on that boat with LTE/5G cellular network "improvements" ...
Well, as a person who will likely be using cellular networks as the backhaul for "live event wifi networks" in the years ahead, consider me instered!
A big thank you to everyone here for welcoming me with open arms
Very happy I found this place.
Mostly, yes;
But in the case of a few different WiFi chipsets, you are "in luck"
Look for a WiFi AP/ router that runs one of the above chipsets, flash it with OpenWRT and your all set.
By the way, it may be of interest to you that I found it is easy to collect arbitrary streams from anywhere and combine them into IFBs on which cake is applied. I wrote an nftables and tc filter based cake solution for this here:
The idea is that you fwmark using nftables and then use tc to filter on that / conntrack and use conntrack restore to restore DSCPs to set up an ifb-dl and ifb-ul pair that you can apply cake instances on, and so you can:
A) combine all download and upload flows from different interfaces into the global ifb-dl and ifb-ul interfaces and apply cake on those; and
B) have client devices and/or router set DSCPs on upload and automatically apply the same DSCPs on download per connection based on conntrack in order to work with the diffserv4 tiers in cake.
Example use for VPN and br-guest use here:
this is pretty epic
I have been brainstorming on this all morning, and I think this is how I get all my barking dog (ruckus) AP's to bark in the right order.
You see, I can create DSCP markup rules and apply them per-SSID in the ruckus unleashed management interface;
I will be playing around with this...
Yes I think this approach is really powerful. The template there can be adjusted for your needs.
I like being able to collect the flows from arbitrary places and combine for cake.
Nftables is pretty flexible. I use it to apply DSCP's based on MAC address and port. All of it can be changed as needed.
You can use 'tcpdump -i ifb-ul -v' to verify correct flows and DSCPs, albeit take care that I've applied wash on cake upload which will scrub things (so ISP only sees cs0) so for testing probably 'nowash' would be better.
Just wondering @moeller0 if you did test going beyond saturation on your link and if so if you learnt anything that we could feed in? I guess this project has got to a stage where it just works for many now so it's mostly a case of optimisation now.
No, I even stopped autorate this week, since my router just got a major update (from an OpenWrt 19 base up to an OpenWrt 21 base) and I first want to confirm everything works as expected before starting more autorate experiments, making it easier to assign cause and effect.
3 Likes
Yes!
I have a stacked watchlist of LTE routers on eBay right now;
Looking to upgrade my Teltonika RUT240 (Cat 4) to something with a higher category so I can get more upload potential.
Even with "perfect" signal on a nice 20mhz wide LTE channel, I have a feeling ~14Mbps (current consistent upload average with "perfect" signal on a 20mhz channel) is going to start choking out (even with the benefits of cake) as I start crossing the 70-100 concurrent active clients zone.
Right now I have 30-50 "potential" users at these events, and we just turned on this wifi/internet based app funtionality, so only a small percentage of people are actually connecting and using it.
But, I am hoping to have closer to 100+ at the next one; and well...
Growth is the strategy
So, yes, I would love to take it off your hands, and it -will- get used.
I just listed this earlier today on eBay UK:
but we're based in the UK and they're rather more expensive here so probably better for you to look into US listings like maybe this one:
It's a great device, albeit I've just switched to a Zyxel NR7101 with integrated antenna and one can run OpenWrt on that.
Ohh yes, forgot to consider that
I have been curiously considering running OpenWRT on the LTE modem itself...
Are there some well supported LTE chipsets...?
I have been looking at Peplink LTE units myself;
Peplink Pepwave Transit Duo looks fairly tempting with its dual LTE modems, the second modem can either be a failover or load balanced with the first.
A lot of people in the RV community seem to 'rave about them; and external antenna's are a must for my use case.
And from my current googling, its looks like peplink is in the process of adding fq_cdoel to their linux based firmware, good times!
https://forum.peplink.com/t/queue-management-fq-codel-implementation-mitigate-bufferbloat/33107/
I think you are being too optimistic. I filed my response to that link back in 2021, with no response. Feel free to add your voice to the plea there...
You'd filled me with hope for a sec....
One of the many burdens of youth...
I will definetly leave a few words on my opinion over there; one would think, 2-3 years after a beta release that seemed to be working well for the upload leg they turned it on for it would have made it into stable release....
Unfortunately this is one of the most recent postings I can find on their forums using their keyword for the feature "mitigate bufferbloat":
The fix for Mitigate Bufferbloat is not in Firmware 8.2.0 Beta 1. Currently Mitigate Bufferbloat is operational for upload, but not for download. Download was discovered to be quite CPU intensive in the 8.0.0 beta, so was disabled for 8.0.0 GA.
Peplink has stated that this has a “target firmware of 8.2.0”. Will it be in a forthcoming 8.2.0 Beta?
...posted Jan. 9 2022... no reply.
Perhaps on a more positive note...
After reading Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi...
The SmartCast™ "feature" from Ruckus Wireless ...reads... like a rather faithful implementation of the above paper.
At some point here I am going to fire up Flent and figure out how to use it; should be interesting to put SmartCast to the test.
If even for but a moment...
I am putting together a packet of information on bufferbloat in a kind of problem > solution > implementation format.
It keeps the explaination very basic at the top level, but I have it HEAVILY linked with every IETF rfc I could find related to this stuff, white papers, good blog posts, podcasts, youtube presentations, links to Leonard Kleinrock's work, etc.
Something simple enough to skim through without getting TOO bogged down into technicals, but linked deeply enough that if you want to actually use this stuff "its all there".
Feel free to let me know if I got anything terribly wrong:
I am going to be passing this off to a "major technology company" who do... a lot of things where this would apply.
They sit on a major standards board and are currently developing new standards for fiber... hopefully a nudge can be made in the right direction for the future of the internet.
If the seed proves fruitful, I'll let you know what I am able.
1 Like
I keep going back to this...
I have been reading that rate limiting clients on the wifi, or even rate limiting a whole SSID is going to cause more harm than good when looked at from the airtime perspecive.
Rate limiting a client essentially means you are arbitrarily causing it to transfer at a lower rate than it otherwise could. The "lower" you rate limit a client, the more airtime that client needs to transfer the same amount of data.
It seems to me, from an airtime perspective, you -always- want a client to transfer as fast as it is capable; using the smallest amount of airtime possible for the 'x' units of data that client needs to transfer.
This follows the principle behind lifting the bss-minrate for an SSID; if you dont allow clients to even connect at "very low" data rates, you eliminate the possibility of a "slow client" using the airtime inefficiently.
Rate limiting clients forces them to the lower (rate limit) data rate, when they could be using LESS of your airtime if they were allowed to transfer at whatever peak rate they could achieve at that moment.
Same thing for rate limiting an SSID group; the whole SSID group would use less of an AP's total airtime if you "allowed" it to transfer at the highest data rate possible.
Now, I have heard it said that the above is totally true and valid as long as your WiFi airtime is the current network bottleneck.
If the WAN link is the bottleneck, I find many people recommending using rate limits for the WiFi clients in order to avoid saturating the WAN link;
This seems like flawed logic to me in the first place; I am not sure how wasting airtime on the WiFi (via rate limiting the clients) and engaging its less efficient buffers is "better" than saturating an ethernet WAN link.
Then, consider that this WAN link is actively (smartly...?) managed by sch_cake with shaper rates that are just under the actual link throughput;
-IF- that is the case, then I dont see -ANY- problem with the WAN link getting saturated from time to time.
It seems -everyone- on the network would actually BENEFIT from the "guest" network (for example) being allowed to run "just as fast" as everyone else on the same WiFi network. Let them use whatever airtime they are going to use as fast as possible, and if it does end up saturating the WAN link, cake will save everyone on the network from dropping their VoIP call or buffering their livestream/ videoconference at that moment. In the worst case, some dynamic rate streaming services seamlessly lower their bitrate for a few frames and no one even notices the saturation.
One "cool" thing Ruckus Wireless configuration management lets me do (providing it works as intended) is -exactly- something Toke was brainstorming about here: Bufferbloat mitigation in the WiFi stack - status and next steps
Namely, allowing "userspace" to have some (configuration) control over the "fairness" of the scheduler.
In Ruckus config every SSID gets a "Priority" flag.
By defualt, every SSID created is "high" priority.
The user has the option to set this to either "high" or "low".
Setting an SSID as "low" priority gives it 1/4 the 'airtime priority' of "high" priority SSID's
I will be curiosly playing with this feature, but I have this feeling that it could tend towards the same problem as rate limiting... maybe.
Like, I give the "guest" network 1/4 airtime priority;
So, when the airtime is free, and there is no "high priority" traffic, "low priority" clients can use all if it, and that satisfies the "get on the airtime fast, transfer fast, and get off the airtime fast" philosophy.
When the airtime is "occupied" by high priority SSID traffic, the "low" priority guest SSID traffic is going to "hang on the air" for a longer period of time, because they have to wait for their 1/4 chunks of airtime to come around;
...but this shouldn't be a problem for the high priority SSID traffic, though; in theory, no matter how much bandwidth the guest network is asking for, it wont be possible for it to "unfairly" dominate the airtime.
...brainstorming...
So, the 1/4 airtime priority is actually "effectively" creating a throughput limit for the "guest SSID" (in this example) that only comes into effect when there is high priority traffic on the air, and it will limit throughput via airtime alotment.
If a guest SSID user does a speed test with zero other users on the air, they will get 100% available throughput.
And then, in "theory", if the same guest SSID user does a speed test when the link is ALREADY 100% saturated with "high priority" traffic; the guest SSID user should see %25 of available throughput, while the "high priority" users see an aggregate reduction to %75 available throughput going to them (during the duration of the speedtest). All of this "should" happen without any single client seeing a significant increase in latency.
Am I making any glaring mistakes here, does this follow?
If you instantiate cake on a WiFi interface you will not actually affect which MCS/coding scheme will ne used. Just like when you use cake to shape 1Gbps ethernet to 100Mbps, each packet will be sent at 1Gbps speed there just will be larger gaps between those packets, that is it affects the duty cycle. For WiFi you might forego some potential for aggegation which has some throughput cost. The weigted scheduler still seems like a decent solution.
2 Likes
Hmm. Maybe this horrific meeting with the (now ex) CEO of ruckus 2+ years ago didn't actually go as badly as I thought: https://www.youtube.com/watch?v=vExojh82p-k
But there's a lot of people making claims without backing them up with benchmarks, still.
2 Likes
light bulb
I had not considered this advantage of the cake shaper when applied to WiFi clients...
And now I am seriously curious as to how the ruckus AP firmware is accomplishing its rate limiting function. I havent actually tested the rate limiting yet...
I like the simplicity of it.
I dont have to calculate throughput budgets as some percentage of my available WAN link capacity.
(which, I am LTE backhaul -hence cake-autorate- so even if I DID do this calculation, it would need constant adjustment.... not really feasable)
It seem like it scales nicely; if I increase my airtime budget with more/faster AP's, if I upgrade my WAN link's throughput, I dont need to adjust any values, it "just works" -allegedly.
(I am going to test it before I feel confident that it actually works as intended)
I dont (think) I have to worry as much about client density distribution as I would if I were calculating per client rate limits. Even if I have something like a 1:2, or even 1:3 high:low priority client ratio (more clients on the low priority SSID's than high priority); when high priority clients ask for some airtime, they will take priority, and the low priority clients will share an aggregate reduction in duty cycle on the airtime.
True news.
Like I said, I want to fire up Flent so I can make some 'real' rrul plots with these ruckus AP's I have; but...
As I recall from recent testing on my home network (1gig sysmetric fiber to the house, GPON box from Frontier).
GPON box >Cat 6 Ethernet> Mikrotik hEX (OpenWRT -cake OFF/ no QoS) >Cat 6 Ethernet> Laptop
I was seeing 150-200ms (sometimes up to 300ms, sometimes as little as 60-90ms) of induced latency under load running the waveform bufferbloat/ ookla speedtest test's within a browser on the laptop.
Not exactly hitting 1gbit in the tests, more like ~900mbps.
Interstingly, I unplugged the laptop from the ethernet, connected to one of my ruckus AP's (5ghz radio) in the same room, and did the same tests to see "how much worse" it would be on the WiFi, and was surprised to see that it got consistently better.
The AP's I have are 3x3:3 802.11ac wave 1 AP's, so the bottleneck moved from the WAN link to the access point, hitting 400-600mbps in the browser tests.
Still not great, between 30-60ms induced latency under load for the download leg, consistently ~20ms of induced latency on the upload leg. Upload leg was consistently better than download, and I even saw quite a few tests where the upload leg was getting sub 10ms induced under load.
Will be interesting to dig deeper with some more testing.
I was out and about a few days ago and ended up in a Dunkin Donuts with free guest WiFi.
The captive portal said it was 'powered by Cisco Meraki'
Waveform bufferbloat test reported ~20ms induced latency on the download, and a hugely impressive 0ms induced latency on the upload
~24 down/ ~4 up
Slowly, but surely, the wheel of progress grinds its way along.
1 Like
Meraki adopted sfq + codel in 2013.
2 Likes