From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 211743B2A3; Tue, 7 Feb 2017 06:57:38 -0500 (EST) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id F205D67E59; Tue, 7 Feb 2017 12:57:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1486468655; bh=dec0OagOW+BoNyF7RkMvdTkgztQqx6zO5gU8EJN/4Uo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=g6WZXrEZ5JyT834tvOZJxl6Kp9BnLgQaosd6qe+VT1s8kf0I0rPsARXT5ZDtgqXYp YFY3aSrGx+RzR+RvWTxIdftAHJo1EBOUqJcWzy/bNfHMMOqQD2hw9ruT4u8cD9PQB3 bBsB5pcupIvl5NvDY1ABExsVHcpIIMaGMveJw3UlmAoPRGf6TpoXJe5Y8I4ben3lr9 oOjrC8RbYwaEuCyn9eMKufRkkQJoIr7dugtEelo9rP/qmbrzu0IlMj2cK50p5C2DMs c2CmskgHX3iXBUfjlFDrkRiXFtuRfzrvtHutCVnKPcth9R0W6W6bn4ep8dlZGaanOH udK2V1VAD3f2w== Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5D67518A55; Tue, 7 Feb 2017 12:57:35 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Pete Heist Cc: make-wifi-fast@lists.bufferbloat.net, cake@lists.bufferbloat.net References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <878tpqge5g.fsf@toke.dk> Date: Tue, 07 Feb 2017 12:57:35 +0100 In-Reply-To: (Pete Heist's message of "Thu, 2 Feb 2017 09:25:07 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877f52rz68.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 07 Feb 2017 11:57:43 -0000 Pete Heist writes: > On Feb 1, 2017, at 3:48 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Pete Heist 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 a= nd > 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 c= an > 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 so= unds > 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 cou= ld 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 d= one=E2=80=9D > piece of work that doesn=E2=80=99t appeal to the engineer in me. Right, a template might work. But not sure how generic the use case is, or whether another mechanism might be better (such as a separate tool that could keep track of data files; maybe as a web-based database or something). > 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. 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 Cython... > > Hmm. Unless I=E2=80=99m missing something, what I=E2=80=99m seeing is th= at I _can_ add > another qdisc, only that it=E2=80=99s ineffective unless soft rate limit= ing 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. > > 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. Yeah, that would probably be a good idea :) > It=E2=80=99s not critical, but why am I able to see this level of reduct= ion > 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. > 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 prett= y 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_80mbit/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? Netperf has this tendency to stop the UDP flows if there's packet loss. If you're on 2.7+ of netperf it should restart after a while, but if it happens a lot you can still lose quite a few samples... -Toke