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

[Dave Taht <dave.taht@gmail.com>]

On Wed, Feb 8, 2017 at 8:11 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Pete Heist <peteheist@gmail.com> writes:
>
>>  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…
>>
>> Even after the new SSA back end, they can still be large. I hadn’t
>> thought to run Flent on embedded hardware, so there isn’t a
>> performance impact from running the test code itself on the hardware
>> you’re testing. But that’s true, if it needs to sometimes, then Go
>> doesn’t work.
>
> It's not so much running the test *from* the router, as it is having the
> server component (netserver) run on a router to test. To do that it'll
> have to be C, basically...

I note that I usually run tests *through* the router rather than *to*
the router, and most of my targets for this have evolved to be arm
(odroid c2), and x86 platforms, so I could get past a gbit.

Long ago I started writing a spec for the things that we couldn't
quite do sanely using netperf as a substrate (twd in my github repo),
but I gave up as getting to netperf equivalence was too hard.

Of note I've always regarded exposing d-itg and some sort of monotonic
voip-like test to the internet as too dangerous without a solid 3 way
handshake, and leveraging existing voip and webrtc/videoconferencing
servers (like freeswitch) way too hard to setup and measure. (there
are plenty of tools to generate rtp-like packets).

I am unfond of the current ping and udp tests in the rrul component
because they don't look like these traffic types, and drawing
conclusions from their behavior as if they were is wrong. Also, with
very low RTTs, the measurement flows tend to skew the tests - you'll
consistently see "lower bandwidth" measured when you cut an RTT from
100 to 1ms via active queue management, when what is really happening
is 100x more measurement traffic.

Of the choices today for writing network servers, go appears to be the
leading candidate, and certain things that might affect timings (for
example, stop the world garbage collection) can be turned off during a
test.

Being lazy about writing protocols and wanting to (eventually) also
have a C version, I'd looked over both protobufs, and
https://capnproto.org/ as means to abstract enough of that out to
handle both test negotiation and simulation...

and then I went back to just using trusty old netperf 'cause when you
are getting orders of magnitude improvements throughout the stack it
really didn't matter.

We're now at the point with both cake and fq_codel at the wifi mac
layer, where getting precision timings with variances below a ms is
becoming needed. (I basically ignore anything less than 3ms as noise
presently)...

and for example, I'm anal enough (now) to see this tiny latency spikes
on tests like this on 60 second intervals and wonder where they are
coming from...

http://www.taht.net/~d/worldwide_fairness.png


>>  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.
>>
>>  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.
>
> Nope, no way to turn it off.
>
> -Toke
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org