[Make-wifi-fast] Software rate limiting with fq_codel for point-to-point WiFi backhaul links

[Noah Causin]

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


On 12/9/2016 9:43 AM, Phineas Gage wrote:
> 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 at lang.hm 
>> <mailto:david at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20161209/5c080f93/attachment-0001.html>