From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 8594F3B2A4; Thu, 2 Feb 2017 03:25:05 -0500 (EST) Received: by mail-wm0-x243.google.com with SMTP id c85so2505918wmi.1; Thu, 02 Feb 2017 00:25:05 -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=ujnlvAKnWKe5VhT0tFaHUe0OvC5Py/90ohGJQr1GJYo=; b=pb5eW8UAE6A3LVPMIZf/8ChYCR5cMuReKeCgtda8JkvxCEwnNJRCmvkGspqFzI7Hk+ AnqiCGLJFGKv/fLOlr8v1Tuip/zifGMCfCygah8cKfEe+c/EMSdoXSTZChcaxila3dne HbqMxnMUCPp1lQzuBebg2t1nhXnMSD7foklcabnFz8yyv/+sm1kzlKeWpWH/j4w9BBl5 1tp20bNGIwoYbX6WIZ1JGrRwpJ+mZDsBacDQJNsw9QaJ0CjKGVFhNN/0us9WHHl+8ZSd 9/kyTs+gwPxBaNiU1IGvPQh89jI1zU3AKznxjLbRJir4+qq8hBBZeHHPl6S2YDItoRB2 m92Q== 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=ujnlvAKnWKe5VhT0tFaHUe0OvC5Py/90ohGJQr1GJYo=; b=PJt/k2W4/IpxlOOfOv3gTO3KCLdyGpFD3NciR+Z/pgp0o9jzNu5wvGoesCKyTMl46O I5ry6Fx9GygF/AZlWRi0bHK4+4zGgisVrbLZ0wKejuJTB3eV+i3uGRjpku6cZQulxV5R Oj1nwkUPG6mdCfRczybp8nA/RTJjvXKcMjfGkSVlhzIAZlEoQJa8JP1x0+efQScff+pn irwtpK/t1zh0/OftNX9Cmihf9WeK99oDtIhYFTEVN6JLfXrNquTGKPMdsm6V5SI12Buz DabYCrYeHCHuHUdMHuW8nmDN63xPYfYxj8Lt0O/LQCkVZCHG1Haza39ZZ+JefQfaprWs +pPQ== X-Gm-Message-State: AIkVDXLUSsbwm69n/itgs6Ca1jcI8OaACE+W2DKdhRw/nFYM1y4iHDMW4msZweio94FE+A== X-Received: by 10.28.63.15 with SMTP id m15mr28737895wma.119.1486023904344; Thu, 02 Feb 2017 00:25:04 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id i189sm34223739wmg.7.2017.02.02.00.25.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 00:25:03 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_720AF57A-C0E4-4249-A297-5829C4B8EBC8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <878tpqge5g.fsf@toke.dk> Date: Thu, 2 Feb 2017 09:25:07 +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> 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: Thu, 02 Feb 2017 08:25:05 -0000 --Apple-Mail=_720AF57A-C0E4-4249-A297-5829C4B8EBC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 1, 2017, at 3:48 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Pete Heist > writes: >=20 >> Few general points on running tests: >>=20 >> - Yeah, as you note Flent has a batch facility. Did you not use this >> simply because you couldn't find it, or was there some other reason? >> Would love some feedback on what I can do to make that more useful = to >> people... While I have no doubt that your 'flenter.py' works, = wrapping >> a wrapper in this sense makes me cringe a little bit ;) >>=20 >> I actually didn=E2=80=99t notice it existed until I was about 85% = done and >> scanning the Flent man page for some other reason. I cringed, but at >> that point I just stuck with what I had. I don=E2=80=99t know if = Flent can >> also make some basic html report with the graphs and setup output, = but >> that was useful to write for myself. Flent=E2=80=99s metadata feature = sounds >> useful and I=E2=80=99ll try that. >=20 > Right, so first thing is advertising it better. I'll look into that; > really do need to freshen up the web site some... >=20 > I will look over your automation script in more detail and see if > there's anything that might be worth adding to Flent's capabilities. = Not > sure if HTML report generation can be generalised sufficiently to be > useful outside your specific scenario, but I'll think it over :) I=E2=80=99m not particularly fond of anything in flenter.py, as it=E2=80=99= s not very generic. If there=E2=80=99s ever HTML generation support in = flent, it could be by processing a user supplied template and offering = tags that are replaced with various things. I used templates in = flenter.py, but I was also hardcoding HTML in my script, so it was just = a =E2=80=9Cget it done=E2=80=9D piece of work that doesn=E2=80=99t = appeal to the engineer in me. I=E2=80=99m more familiar with Go these days, which has a robust = template package. Earlier I wondered if a combined netperf / flent tool = could be written in golang (not volunteering though at this point :). It = could be nice to have native binaries for different platforms, and = goroutines might come in handy for the actually testing of multiple = flows, but if there are low-level calls happening in netperf, you=E2=80=99= d end up using cgo, which of course makes portability harder. >> Hmm. Unless I=E2=80=99m missing something, what I=E2=80=99m seeing is = that I _can_ add >> another qdisc, only that it=E2=80=99s ineffective unless soft rate = limiting is >> used. As evidence, here's my nolimit test of fq_codel: >>=20 >> http://www.drhleny.cz/bufferbloat/fq_codel_nolimit/index.html = >=20 > Ah, totally missed that the qdisc information was available on those > pages as well; guess my scroll bar must have been broken. ;) >=20 > And yeah, just verified that you can indeed install a qdisc on a = noqueue > device; how odd. I should test Chaos Calmer and make clearer in the paper the separation = of when I=E2=80=99m testing the new ath9k driver changes, and when I=E2=80= =99m testing the qdisc layer. It will need quite a re-org. >> 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. 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. >> Ok, so far, I was doing `cat file.flent.gz | grep null | wc -l`, = which >> is a very crude count of the nulls recorded, which seem to happen for >> the udp and icmp flows with packet loss. There are always some nulls >> from before the test starts and after it ends, but if the count jumps >> up I speculate that there=E2=80=99s more packet loss. It=E2=80=99s = pretty weak but >> it=E2=80=99s a hint. >=20 > This is very unlikely to get you anything resembling a right answer. = The > null values recorded by Flent are simply *sampling periods* without = any > output from netperf. There will be a bunch of those at the start or = end > of each test, and there can be other reasons apart from packet loss = that > will give null values. >=20 > You can get packet loss for ICMP by looking at the sequence numbers in > the raw_values object in the data file (you can get that as a Python > object by doing 'from flent import resultset; r =3D > resultset.load(filename)' and poking around in that object). Don't = think > there's currently a way to export that as a loss measure... Understood. :) Somehow though the losses look higher for the UDP flows = than ICMP, if I take this test as an example (pfifo limit 32): = http://www.drhleny.cz/bufferbloat/pfifo_hd-wifi-ap_limit_32_80mbit/index.h= tml The UDP lines end sooner than the ICMP line. I take that to mean there = wasn=E2=80=99t as much loss of ICMP? --Apple-Mail=_720AF57A-C0E4-4249-A297-5829C4B8EBC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 1, 2017, at 3:48 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

Pete Heist <peteheist@gmail.com> writes:

Few = general points on running tests:

- Yeah, as = you note Flent has a batch facility. Did you not use this
 simply because you couldn't find it, or was there some = other reason?
 Would love some feedback on what I can = do to make that more useful to
 people... While I = have no doubt that your 'flenter.py' works, wrapping
 a= wrapper in this sense makes me cringe a little bit ;)

I actually didn=E2=80=99t notice it existed until I was about = 85% done and
scanning the Flent man page for some other = reason. I cringed, but at
that point I just stuck with = what I had. I don=E2=80=99t know if Flent can
also make = some basic html report with the graphs and setup output, but
that was useful to write for myself. Flent=E2=80=99s metadata = feature sounds
useful and I=E2=80=99ll try that.

Right, so first thing is advertising it better. = I'll look into that;
really do need to freshen up the web site = some...

I will look over = your automation script in more detail and see if
there's anything = that might be worth adding to Flent's capabilities. Not
sure if HTML report = generation can be generalised sufficiently to be
useful outside your = specific scenario, but I'll think it over :)

I=E2=80=99m not particularly fond of anything in = flenter.py, as it=E2=80=99s not very generic. If there=E2=80=99s ever = HTML generation support in flent, it could be by processing a user = supplied template and offering tags that are replaced with various = things. I used templates in flenter.py, but I was also hardcoding HTML = in my script, so it was just a =E2=80=9Cget it done=E2=80=9D piece of = work that doesn=E2=80=99t appeal to the engineer in me.

I=E2=80=99m more familiar with Go these days, = which has a robust template package. Earlier I wondered if a combined = netperf / flent tool could be written in golang (not volunteering though = at this point :). It could be nice to have native binaries for different = platforms, and goroutines might come in handy for the actually testing = of multiple flows, but if there are low-level calls happening in = netperf, you=E2=80=99d end up using cgo, which of course makes = portability harder.

Hmm. Unless I=E2=80=99m missing something, what I=E2=80=99= m seeing is that I _can_ add
another qdisc, only that = it=E2=80=99s ineffective unless soft rate limiting is
used. = As evidence, here's my nolimit test of fq_codel:

http://www.drhleny.cz/bufferbloat/fq_codel_nolimit/index.html

Ah, totally missed that the qdisc = information was available on those
pages as well; guess my scroll bar must = have been broken. ;)

And yeah, just verified that you can indeed = install a qdisc on a noqueue
device; how odd.


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.

Ok, so far, I was doing `cat = file.flent.gz | grep null | wc -l`, which
is a very crude = count of the nulls recorded, which seem to happen for
the = udp and icmp flows with packet loss. There are always some nulls
from before the test starts and after it ends, but if the = count jumps
up I speculate that there=E2=80=99s more = packet loss. It=E2=80=99s pretty weak but
it=E2=80=99s a = hint.

This is very unlikely to get you anything = resembling a right answer. The
null values recorded by Flent are simply = *sampling periods* without any
output from netperf. There will be a = bunch of those at the start or end
of each test, and there can be other = reasons apart from packet loss that
will give null values.

You can get packet loss for ICMP by = looking at the sequence numbers in
the raw_values object in the data file = (you can get that as a Python
object by doing 'from flent import = resultset; r =3D
resultset.load(filename)' and poking around in = that object). Don't think
there's currently a way to export that as = a loss measure...

Understood. :) Somehow though the losses look higher for the = UDP flows than ICMP, if I take this test as an example (pfifo limit = 32):

http://www.drhleny.cz/bufferbloat/pfifo_hd-wifi-ap_limit_32_80m= bit/index.html

The UDP lines end sooner than the ICMP line. I take that to = mean there wasn=E2=80=99t as much loss of ICMP?

= --Apple-Mail=_720AF57A-C0E4-4249-A297-5829C4B8EBC8--