From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 66F133B2A4 for ; Fri, 9 Dec 2016 10:47:01 -0500 (EST) Received: by mail-io0-x229.google.com with SMTP id h30so62971554iod.2 for ; Fri, 09 Dec 2016 07:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to; bh=eY8g1mQa1MtkWDtOvQm1Jo1eXeDgOaeFUC6xK9S6TmE=; b=yeWnkCss4PJ5aiVVOWy3+NiN9J1aDQczIcNTd/xarat6PluxOHYr9Xq5oAoxAoHioJ e3aDKbTvQD2dXbq5B6V4ts+FkhPzvZ88hXh9qLMeChJ3eBDTQvqHyEGhHp7mDfbXIbKN wmkdi9AH0lDZuJcWuck2ITZUY3IVdUY6r1I69/KiCt2kKzpSEIfCnHetBo2ydx5dAeiw SgCulNpcj/WW8DoBwwV9Uv3ihaqawjqZzwkwsotvvQC/ngRQqaEoNETnnkbZ7rSCB445 VnfldJ6L26ToIAVOJBZN3TAKfdPJifKhkhQzMjA7LQ20GgZkFSTmglbKaASdZ9VSi8AR gmOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to; bh=eY8g1mQa1MtkWDtOvQm1Jo1eXeDgOaeFUC6xK9S6TmE=; b=DLWwUKddJO8L51qn/XtMUox3ws1gaE6e6iyLKGgfXTmsGFITJxH//aWIpR8G0jpYbT 9ewwPLdp1EST+e7fCQcX2xOgKG6l0o1m7aNaLmmHWjynoy3vDRw93B2PU5+QhsbAmxfz AwHN3q+fJalCLCIPmO22S146BR2RNyHUMuVEQB2XSkhccXPCc4pH+l+w66gORuQL6TlQ zpu0Uy5dMXXraxQX1CNoY4KaNgvT5lXCwZjypX7geET/GwH3aWf/hJGcA8UXuwx2OQkW YxFD6aqXcjezsF/IyapMoMZo+l2YyUL+Gsh6rWRsoAFrxrPyBJV9OSrl8+a6cBBkNY1+ 3d8Q== X-Gm-Message-State: AKaTC01ykMB+5++Z6NJ1zTe3CfzthAQajvwm5p66XWidSci9mtGsKRznS1Paa0MvblezVA== X-Received: by 10.36.76.85 with SMTP id a82mr7201591itb.67.1481298416677; Fri, 09 Dec 2016 07:46:56 -0800 (PST) Received: from [172.21.63.50] (hades.kettering.edu. [192.138.137.97]) by smtp.gmail.com with ESMTPSA id v75sm7273376ita.12.2016.12.09.07.46.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 07:46:56 -0800 (PST) From: Noah Causin To: make-wifi-fast@lists.bufferbloat.net References: <9BA0F7D8-5A25-4033-A101-38BF001B74EB@gmail.com> <20EA10A9-73B2-4EAE-B8EE-927AD5DB29F3@gmail.com> Message-ID: <0a270455-c48d-812a-1e8b-8a9f70a9ad78@gmail.com> Date: Fri, 9 Dec 2016 10:47:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20EA10A9-73B2-4EAE-B8EE-927AD5DB29F3@gmail.com> Content-Type: multipart/alternative; boundary="------------08608850EBF4FCC0581B2C98" Subject: Re: [Make-wifi-fast] Software rate limiting with fq_codel for point-to-point WiFi backhaul links X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:47:01 -0000 This is a multi-part message in MIME format. --------------08608850EBF4FCC0581B2C98 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 > > 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 --------------08608850EBF4FCC0581B2C98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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@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

--------------08608850EBF4FCC0581B2C98--