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

[Phineas Gage <phineas919@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 7661 bytes --]