> 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. I picked up 2x NanoStation M5 and 2x of FreeNet’s older APUs (https://pcengines.ch/alix2d2.htm ), and should add more results soon. I also hope to try some of their more modern hardware, as the APUs in particular are a bit ancient, but I'll see if it becomes available.