From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (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 5B2523B2A4; Fri, 9 Dec 2016 09:43:09 -0500 (EST) Received: by mail-wj0-x242.google.com with SMTP id j10so2772590wjb.3; Fri, 09 Dec 2016 06:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5wlyvgJP5BUwkWniC9tiSpkr24C/7gD4QRH7IEqTr5U=; b=NysHRAT+oCRjpdMCU+cWvGVzQa35liDgJhYxpSimwjkBWe6X4Kd+qSXaqO79a3Hx+x NTvRxIg+/E5bkMx2cgCmptvR38CStVsk84ot4gYZFzVoevYElruOolGwfgsG9N8Lq9cL Zqrad3bqa2bl9YqcbGVB3YV9HpUOXl3yotSeUjcFzl9vLG3Kn4d6LMCJrRAF+W9u3vKr WylsD9DMmo54hPWSCP6PDVgKL60aUoxoURdImdUYNJopYmr+ywvCo9mVswBuZ14f9zFH DpI6s8n3VjwRU7xi35LFwGX3T9w1BGMEuYiURxIGQ+v1iGYpQdfe8VpxIKJsK8UYS9Iw 4K5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5wlyvgJP5BUwkWniC9tiSpkr24C/7gD4QRH7IEqTr5U=; b=IT9+JnDy6FbiCFq6iq63Nzxe8rc+tR7WmEKy1ret44cOdMhZUfUBcFoWYTTSbjlNUO FFO5L6wEOK42kOABjUWOJ3MqHA9X9xtOVV2VAm6lCJD7x0lix05p1SciGdMJaEXxNmtx mCpTephIp77xUqYX75pgaayiyT5ENZOSmt5bhncoahm9DD3sx9swIfZz5VUW3Q+gqxwh A38EVf+MGFSvbZ6RYYAc5hLG9rev1ctDpV9LU4fBvJ4+o5+sl4Upiv4UXg6+QPChmdCi iWVw5PFpATfTnT9cNyr/0JMDQXnhAYIROKcETP4UZKXjyS+Qf2WzrBw/fzvHN2sKGIrp i44g== X-Gm-Message-State: AKaTC02FjIKYM30MuD08OhnzdorbiQ5LRArGFzcGLHVEOzlUcnDiWzq6ESy/JuslWo6dsg== X-Received: by 10.194.94.166 with SMTP id dd6mr78054155wjb.88.1481294588277; Fri, 09 Dec 2016 06:43:08 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id u18sm20949509wmd.1.2016.12.09.06.43.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Dec 2016 06:43:07 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D3DE77E4-F193-4B05-BCF2-CB20F27A6D8E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phineas Gage In-Reply-To: Date: Fri, 9 Dec 2016 15:43:05 +0100 Cc: codel@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Message-Id: <20EA10A9-73B2-4EAE-B8EE-927AD5DB29F3@gmail.com> References: <9BA0F7D8-5A25-4033-A101-38BF001B74EB@gmail.com> To: David Lang X-Mailer: Apple Mail (2.3124) 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 14:43:09 -0000 --Apple-Mail=_D3DE77E4-F193-4B05-BCF2-CB20F27A6D8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99m calling =E2=80=9Cradios=E2=80=9D 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=E2=80=99s firmware on = kernel 2.6.32.68, and doesn=E2=80=99t come with an fq_codel module. = You=E2=80=99re saying that this is the hardware where I=E2=80=99d really = want to run it, and just add fq_codel as the egress leaf queue without = rate limiting, right? But I don=E2=80=99t think fq_codel can run on this = kernel. Much of the =E2=80=9Cradio=E2=80=9D hardware is similar to this, = and I=E2=80=99m also not sure what throughput the small CPUS they have = (like MIPS 74Kc) could even support with fq_codel. So unless I=E2=80=99m 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=E2=80=99t need = to even configure an fq_codel queue with tc. But I would probably need = to be able to run that on Ubiquiti=E2=80=99s firmware. PowerBeam = M5-400=E2=80=99s 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: >=20 > 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. >=20 > 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) >=20 > you really want to be running fq_codel on the 'radios', that's the = bottleneck point as you shift from ethernet to wifi. >=20 > 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. >=20 > David Lang --Apple-Mail=_D3DE77E4-F193-4B05-BCF2-CB20F27A6D8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99m calling =E2=80=9Cradios=E2=80=9D 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=E2=80=99s firmware = on kernel 2.6.32.68, and doesn=E2=80=99t come with an fq_codel module. = You=E2=80=99re saying that this is the hardware where I=E2=80=99d really = want to run it, and just add fq_codel as the egress leaf queue without = rate limiting, right? But I don=E2=80=99t think fq_codel can run on this = kernel. Much of the =E2=80=9Cradio=E2=80=9D hardware is similar to this, = and I=E2=80=99m also not sure what throughput the small CPUS they have = (like MIPS 74Kc) could even support with fq_codel.

So unless I=E2=80=99m = 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=E2=80=99= t need to even configure an fq_codel queue with tc. But I would probably = need to be able to run that on Ubiquiti=E2=80=99s firmware. PowerBeam = M5-400=E2=80=99s 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

= --Apple-Mail=_D3DE77E4-F193-4B05-BCF2-CB20F27A6D8E--