[Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

[Pete Heist]

> On Feb 1, 2017, at 3:48 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> Pete Heist <peteheist at gmail.com <mailto:peteheist at 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’t 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’t 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’s metadata feature sounds
>> useful and I’ll 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’m not particularly fond of anything in flenter.py, as it’s not very generic. If there’s 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 “get it done” piece of work that doesn’t appeal to the engineer in me.

I’m 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’d end up using cgo, which of course makes portability harder.

>> Hmm. Unless I’m missing something, what I’m seeing is that I _can_ add
>> another qdisc, only that it’s 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 <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’m testing the new ath9k driver changes, and when I’m testing the qdisc layer. It will need quite a re-org.

>> It’s not critical, but why am I able to see this level of reduction
>> when there’s already fq-codel in the driver? 25ms is very good, I only
>> wonder where I’m 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’s more packet loss. It’s pretty weak but
>> it’s 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 =
> 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’t as much loss of ICMP?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20170202/5d82b673/attachment-0001.html>