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

[Phineas Gage]

Thanks for the hint Jonathon. In general, this appears to be effective, at least for the flent rrul test.

Below are flent rrul_noclassification run graphs (flent.gz files available) and the script I used to set up fq_codel. I see close to link rate with iperf3 tests, which test throughput in only one direction, yet can still control the queue reasonably well when there’s bidirectional traffic. For example, I’ve got the total rate limited to 90 Mbit, and each average flow in a flent rrul test runs around 10 Mbit. There are four in each direction, eight total, so I see around 80 Mbit of TCP throughput along with the low rate traffic at around 6 ms latency, which is not bad.

If you set up fq_codel like this on both ends of the link, it doesn’t perform quite as well- latency goes up and throughput down a bit. There are probably some "unwanted interactions" when you do this. So it’s best to set it up on only end end of the link, probably the end whose egress heads towards the Internet if applicable, but I’m still thinking that through.

Again, for those reading this later, it would be best to just run fq_codel (or Cake but I’ll get to that next) on the egress right on the hardware with the WiFi interface attached. The interface will rate limit the queue automatically when there’s bidirectional traffic, and account for variable speed, so that should be a superior configuration. But this is a solution for when that isn’t possible, and the AQM has to be run on separate hardware, connected via Ethernet.

I still want to do more testing for my WISP, both with Cake and the new LEDE builds as well, in various configurations, so I hope to do that next and will start a new thread when there are results. For now, this “half duplex rate limiting” by running AQM on a common IFB interface may help people in some situations!

https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit.png <https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit.png>

https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit_both.png <https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit_both.png>

https://dl.dropboxusercontent.com/u/71551878/bufferbloat/qos.sh <https://dl.dropboxusercontent.com/u/71551878/bufferbloat/qos.sh>

> On Dec 9, 2016, at 1:37 PM, Phineas Gage <phineas919 at gmail.com> wrote:
> 
> Ok, I had not realized that, thanks. :)
> 
> I’ve not seen this done anywhere, has anyone tried it? Otherwise I’ll give it a try and write back what I find.
> 
> In this case, the throughput for the backhaul links “should” be mostly stable, and we’ll just accept any variation as “no worse than before”.
> 
> It's true, I also want to try Cake (anywhere I wrote fq_codel that could be substituted with Cake), and I see from here (https://www.bufferbloat.net/projects/codel/wiki/Cake/#installing-cake-out-of-tree-on-linux <https://www.bufferbloat.net/projects/codel/wiki/Cake/#installing-cake-out-of-tree-on-linux>) that it should work on the 3.16.7 kernel I need to target. Voyage Linux doesn’t install with kernel sources, but I should be able to get that compiled with their SDK.
> 
>> On Dec 9, 2016, at 12:39 PM, Jonathan Morton <chromatix99 at gmail.com <mailto:chromatix99 at gmail.com>> wrote:
>> 
>>> On 9 Dec, 2016, at 12:12, Phineas Gage <phineas919 at gmail.com <mailto:phineas919 at gmail.com>> wrote:
>>> 
>>> Given the half-duplex nature of 802.11 WiFi, is it possible to use fq_codel with software rate limiting on separate hardware from the WiFi radio, while still allowing at or near the full WiFi link rate?
>> 
>> Given that you can’t reliably predict the actual wifi throughput from userspace, and that it will vary over time due to external interference and path attenuation, that would be difficult.
>> 
>> However, you *can* loop both the ingress and egress traffic through a common IFB interface, and shape that - using Cake, even.  That sounds like what you’re trying to experiment with.
>> 
>> - Jonathan Morton
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20161211/13420eee/attachment.html>