On Feb 1, 2017, at 3:48 PM, Toke Høiland-Jørgensen <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’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

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...