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