I'm still reading and love data & testing 
Keep posting!
Is it iperf3 that gives you the latency stats?
Since you're running a Mac I believe you're using iperf3-darwin that has RTT displayed.
And I also found out that my Macbook Air M2 have some issues with 5g wifi and lagging in SSH etc every second. This is because of awdl0. This might have an impact too on your testing.
I actually was monitoring RTT in a separate window running gping whilst iperf3 was humming along. I'll have to check out iperf3-darwin--did not know of it!
Excellent callout and I have run into the same. I'm happy to say that I have been running with awdl0 disabled for quite some time now and it should have no bearing in the test results I posted.
FWIW, I came across this a while back when I was chasing the MacOS latency spikes on WiFi.
I opted to install it with the "Run it automatically after a restart" method and it's been keeping awdl0 inactive for me on the regular
Ah, interesting. That was a different solution. I did something different and it's working for me. I read that awdl0 is using a fixed channel 44 in Europe and 149 in the US. So my issue was that I was using channel 36. I just changed to channel 44 and that solved it.
But everyone can't change to channel 44 or 149 because of noisy neighbors. So your solution might be better...
I did not have this issue with my older Macbook Pro 13" 2016.
Just gave iperf3-darwin a spin! I didn't realize it was built-in to MacOS. The bummer is that it seems to only provide RTT when it is the sender. The test I was performing was to have my router as sender so that the TXQ on my RT3200s was exercised for the aql_txq_limit effects.
If there are any notable flaws in my testing methods, feel free to call them out and I'll be happy to re-run the exercise.
Update...
FWIW, it does seem that running in --bidir mode does show RTT on each sending interval.
I keep hoping more folk will try testing with crusader? Particularly the staggered start test of a mere two flows. See https://github.com/Zoxc/crusader/releases/tag/v0.0.9-testing - unlike flent, it runs on everything.
Hey Dave, I'm always up for testing out a new tool. I don't want to take this OpenWrt thread sideways with app-specific troubleshooting, but I did hit an error upon trying it out. I added to this existing issue, and while Rust isn't a language I know well, I will see if I can make any headway with it:
I'm looking forward to seeing the data once it's working on my Mac!
cool, on this thread (the whole thread is delicious) I finally got someone to try crusader + fq_codel on gpon. https://www.reddit.com/r/HomeNetworking/comments/18tdqcc/
He´d written a very nice article! But I got grouchy about engineering to the test!
@dtaht In cake I see a lot of overlimits. I've been able to reduce the amount of dropped packets by qosify. However... how do you handle overlimits? I'm trying to find more information on that topic, but I'm not able to get "hands on" information, from others that are solving high amount of overlimits.
dropped - the number of times a packet is dropped because all queues are full
overlimits - the number of times the configured link capacity is filled
What are the relations between configured link capacity and cake, or something else that is configured
Thanks in advance.
It has been so long since I looked at the codebase that i no longer know what overlimits means in cake. I outlined stuff we can do to cake over here, which included instrumenting it for drop_reason
and a few other useful things. https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit#heading=h.vbbnfu73wlpp
I am planning on looking harder at some point soon, but not just now, yet, sorry.
That's alright. Thanks for sharing the doc.
I think that overlimits really just means that our qdsc is accumulating packets, that is packets arrived while our traffic shaper was not transmitting them further, which is exactly what the traffic shaper is intended to do. So overlimits are not an error counter, but in our case more a proof of functionality.
Crusader run to test my MT6000 AP from my 2021 MacBook Pro M1:
I kicked off a thread specific to the MT6000 here, should other MT6000 owners want to follow along, or better yet, join in!
Quite interesting! Maybe worth emphasising that this is over WiFi (the non duplex nature of WiFi explains nicely why the total bidirectional load tops out at around the same total as the two individual uni-directional load tests...)
