Having fq_codel built-into the mac80211 layer allows you to use
the max rate of the device with low latency.
The Ubiquiti Powerbeam M5-400 is 5Ghz and most likely has an
ath10k, since the 300 has one. You could probably just use a LEDE
build with the ath10k fq_codel patch.
The only alternative I can think of is to have a passive router
with Cake's autorate_ingress feature.
It automatically estimates the bandwidth of incoming traffic and
sets its rate-limiter to slightly below that to control the queue.
If you like, I can build you an x86 virtual machine with that
setup. You can run that on your PC1 and have it sitting in front
of the Voyage Linux VM to test Flent over WiFi.
The limitation is that it only estimates incoming traffic, so you
would have to deploy it at points you receive traffic.
Noah Causin
Thanks David, I do see your point. That would be great if I could run fq_codel on the outgoing queue of the device that has the WiFi radio.
But what I’m calling “radios” in this case can be a Ubiquiti PowerBeam M5-400, for example. This is a dish with integrated CPU and WiFi radio. It runs Ubiquiti’s firmware on kernel 2.6.32.68, and doesn’t come with an fq_codel module. You’re saying that this is the hardware where I’d really want to run it, and just add fq_codel as the egress leaf queue without rate limiting, right? But I don’t think fq_codel can run on this kernel. Much of the “radio” hardware is similar to this, and I’m also not sure what throughput the small CPUS they have (like MIPS 74Kc) could even support with fq_codel.
So unless I’m missing something, the only option I see in this case is to run it on the routers that are connected to these radio devices via Ethernet and do rate limiting.
As for the Make WiFi Fast project, in addition to the airtime fairness work, part of the plan is to add AQM/FQ at the 802.11 layer, right? In that case, if I were able to run this, I suppose I wouldn’t need to even configure an fq_codel queue with tc. But I would probably need to be able to run that on Ubiquiti’s firmware. PowerBeam M5-400’s do use ath9k, which the code targets, but I think so far the WISP would be reluctant to run OpenWRT or LEDE, though I can ask...
On Dec 9, 2016, at 2:41 PM, David Lang <david@lang.hm> wrote:
If you are able to make the settings on the outgoing side of both the ends of the link, the need to estimate bandwidth should pretty much go away.
The whole mess of estimating bandwidth and throttling to keep below that estimate is only needed when the device(s) that you have control over are not the ones directly adjacent to the bottleneck. If you are directly adjacent to the bottleneck, then you don't need to guess how much data is too much, you see it directly by watching the queues build up (at which point, fq_codel kicks in and forces things to back off)
you really want to be running fq_codel on the 'radios', that's the bottleneck point as you shift from ethernet to wifi.
I would guess that the airtime fairness work probably won't make a huge difference in your case as the backhaul networks are all operating at or near the same speeds, but it may be that it will help by better grouping traffic into transmission bursts.
David Lang
_______________________________________________ Make-wifi-fast mailing list Make-wifi-fast@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/make-wifi-fast