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

[Toke Høiland-Jørgensen]

Pete Heist <peteheist at 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...

>  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