I see from various threads on this forum that sqm (sch_cake) has been shown to work at rates of up to 600mbit bidirectional. I hope that the next generation of turris’s work can scale to a full gbit here, bu:t it would be VERY interesting to know a couple things about current scaling problems, as I think further development work is going to be required to the core “cake” code. We tend to use the flent.org tests to get detailed reports on how and where things are going wrong. Web tests are far too weak to drive gbit networks reliabily enough to see what’s going wrong.
Is there anyone(s) out there that can run one or more strings of flent vs SQM test’s on bufferbloat.net’s behalf? flent is commonly available for linux repositories and can be made to work on OSX, and we maintain a fleet of flent servers throughout the globe. Our most current one was built for starlink testing (it has nothing to do with starlink itself), but can be leveraged for this:
What I’m mostly looking for at the moment is “rtt_fair” results at various rates - both at what can actually be achieved via turris, and above where it begins to fail with and without sqm enabled.
I don’t know if turris supports the “flent” package for openwrt or not(?) that has additional tools we can use to collect data more directly, via flent as well.
flent -x --socket-stats --step-size=.05 -H de.starlink.taht.net -H london.starlink.taht.net -H singapore.starlink.taht.net -H fremont.starlink.taht.net -t your_test_options_bandwidth_etc rtt_fair4be
It is also very possible to setup a flent server on your local network, enable sqm
on it, and just test that. It would be great if someones had that also, as the rtt_fair test is also a really good test of the wifi version of fq_codel.