From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 BD5D03B29E; Wed, 8 Feb 2017 10:26:42 -0500 (EST) Received: by mail-wm0-x22f.google.com with SMTP id t18so51137574wmt.0; Wed, 08 Feb 2017 07:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=OiT/9Yrda3L4G2OR6vnmM5WuiWBhBz7MZ+fu1/lder0=; b=inKOcjHSiNHZQ35yi5Rh+3o7ItHJMBurfaOnN1vuprLOUs1QwVUAD4gCWSBXOtBG3C ozzoMVTPm2Q2GFPCtHeX9W74X7DxAg4FMTRxCyNfPnJ9ut/MbkMaee+61J840IGktZzG 0C538p8aTmE7KjAfdzoOpeOmweSrsU2hn3N1HuN0sma9pHAzqjfdQyz/nffRekxc1ifC yJV+5Hx850FG7+U7AKhk0KY1bgikWJYfSRfqDr66IKT59nkp6ld5EQkmGDhWOm0W29Ve zb8qwYAS1wO6svxjPbmkgFVnUQOyzRHDLjXTd/yHSx7SX4TswGgV33Lr08DgxBRxR6lv 3iKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OiT/9Yrda3L4G2OR6vnmM5WuiWBhBz7MZ+fu1/lder0=; b=Y9m/yrNcpl46ZS02xx/jMPr6FTLehlCwUKEwIbIXXappuEl8DSnFbp3kwIkgadKk4g I9LDFQ4fPYf9qP1VHUnbEEM9c41CYzTnCMoypuxA9NUXvXp3HHxH8TgKLNZxvBg8En/0 j3GyM/c1uPpPiROqgRcjmbnB6rVaRiiS6m610vNdEPvsdQf/WDAZufDOETvOzMX6RVwp +6kXOMYypxbEOP3i3KV/4FhizWSx0cbY1zuvanzai+cFrWsISeoiajPxvxWIChEZyHpw fOGBSFRf6F7p7tdXrzd7J9ULvANGv90bvXIP6QxCHg+x814ZF0edVxc4K1J4h/2Eomvl l+rw== X-Gm-Message-State: AMke39ktB1+4Cbu4vGaG0XasqQMrU8HsYFds1vjSLIDCO4ECLQTu5W1uEPhErSf6eigv8w== X-Received: by 10.28.230.91 with SMTP id d88mr17363347wmh.129.1486567601752; Wed, 08 Feb 2017 07:26:41 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id h3sm13610684wrb.31.2017.02.08.07.26.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Feb 2017 07:26:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BB79B922-3D3F-4AD2-A9A5-3635E062F4F7" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <877f52rz68.fsf@toke.dk> Date: Wed, 8 Feb 2017 16:26:39 +0100 Cc: make-wifi-fast@lists.bufferbloat.net, cake@lists.bufferbloat.net Message-Id: References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <878tpqge5g.fsf@toke.dk> <877f52rz68.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3124) Subject: Re: [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available 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: Wed, 08 Feb 2017 15:26:43 -0000 --Apple-Mail=_BB79B922-3D3F-4AD2-A9A5-3635E062F4F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Yeah, I have recently begun learning Go myself, and like it too. Apart > from the fact that it produces these huge statically linked binaries, > and requires glibc, so you can't run it on embedded systems (such as > LEDE). >=20 > If I were to integrate code that actually shipped packets into Flent, = I > would probably use Python=E2=80=A6 Even after the new SSA back end, they can still be large. I hadn=E2=80=99t= thought to run Flent on embedded hardware, so there isn=E2=80=99t a = performance impact from running the test code itself on the hardware = you=E2=80=99re testing. But that=E2=80=99s true, if it needs to = sometimes, then Go doesn=E2=80=99t work. >> It=E2=80=99s not critical, but why am I able to see this level of = reduction >> when there=E2=80=99s already fq-codel in the driver? 25ms is very = good, I only >> wonder where I=E2=80=99m getting the extra 10-15ms from, out of = interest. :) >>=20 >> The driver queues up two aggregates beneath the queue to keep the >> hardware busy. It may be possible to improve slightly upon this, but = we >> have not gotten around to trying yet. >>=20 >> Ok, if rtt were about half of 25ms there would be almost no argument >> for external rate limiting. Even as it is now, I question what >> difference the user sees between 12ms and 25ms latency for Internet >> traffic. It also makes me more interested to see results for Chaos >> Calmer with fq_codel applied on the Wi-Fi device without limiting. >=20 > Yup, exactly. We want to get to the point where you'll have no reason = to > do any rate limiting. That reminds me, is there any way to disable fq-codel in the ath9k = driver, and revert to being able to use the qdisc layer without = limiting? Then I could do this testing without having to install Chaos = Calmer, and it could avoid some re-flashing in case I need to re-test = something in the new driver code again. I picked up 2x NanoStation M5 and 2x of FreeNet=E2=80=99s older APUs = (https://pcengines.ch/alix2d2.htm ), = and should add more results soon. I also hope to try some of their more = modern hardware, as the APUs in particular are a bit ancient, but I'll = see if it becomes available.= --Apple-Mail=_BB79B922-3D3F-4AD2-A9A5-3635E062F4F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Yeah, I have recently begun learning Go = myself, and like it too. Apart
from the fact that it produces these huge = statically linked binaries,
and requires glibc, so you can't run it = on embedded systems (such as
LEDE).

If I were to integrate code that actually = shipped packets into Flent, I
would probably use Python=E2=80=A6

Even after the new SSA back end, they can still be = large. I hadn=E2=80=99t thought to run Flent on embedded hardware, so = there isn=E2=80=99t a performance impact from running the test code = itself on the hardware you=E2=80=99re testing. But that=E2=80=99s true, = if it needs to sometimes, then Go doesn=E2=80=99t work.

It=E2=80=99s not critical, but why am I able to see this = level of reduction
when there=E2=80=99s already fq-codel = in the driver? 25ms is very good, I only
wonder where = I=E2=80=99m getting the extra 10-15ms from, out of interest. :)

The driver queues up two aggregates beneath = the queue to keep the
hardware busy. It may be possible to = improve slightly upon this, but we
have not gotten around = to trying yet.

Ok, if rtt were about half = of 25ms there would be almost no argument
for external = rate limiting. Even as it is now, I question what
difference= the user sees between 12ms and 25ms latency for Internet
traffic. It also makes me more interested to see results for = Chaos
Calmer with fq_codel applied on the Wi-Fi device = without limiting.

Yup, exactly. We want to get to the point = where you'll have no reason to
do any rate limiting.

That reminds me, = is there any way to disable fq-codel in the ath9k driver, and revert to = being able to use the qdisc layer without limiting? Then I could do this = testing without having to install Chaos Calmer, and it could avoid some = re-flashing in case I need to re-test something in the new driver code = again.

I picked up 2x NanoStation M5 = and 2x of FreeNet=E2=80=99s older APUs (https://pcengines.ch/alix2d2.htm), and should add more = results soon. I also hope to try some of their more modern hardware, as = the APUs in particular are a bit ancient, but I'll see if it becomes = available.
= --Apple-Mail=_BB79B922-3D3F-4AD2-A9A5-3635E062F4F7--