UPDATE: one outcome of this thread has been the development of an experimental shell script for automatically adjusting bandwidth for use in CAKE, which is available here:
Testing to facilitate further improvement welcome. Albeit it seems to work pretty well at the moment for both LTE type links and WiFi.
Original post is below (and the figure above demonstrates the issue). Happy reading!
So from browsing these forums it is evident that CAKE's autorate-ingress is a feature that is highly sought after. It promises automatic bandwidth determination for the many of us who have connections with a fluctuating bandwidth. From the man page:
Automatic capacity estimation based on traffic arriving at this qdisc. This is most likely to be useful with cellular links, which tend to change quality randomly. A bandwidth parameter can be used in conjunction to specify an initial estimate. The shaper will periodically be set to a bandwidth slightly below the estimated rate. This estimator cannot estimate the bandwidth of links downstream of itself.
Sadly it is also evident from these forums that it doesn't work. I have tested this on my own 4G connection without success. It ramps up slowly to a point where I see a lot of bufferbloat. Happy to test further if I should be trying it in conjunction with different settings (could my packet overhead be set too low - presently 70 to cover 60 for WireGuard and 10 for LTE overhead?), but I do not think I have come across even just one positive experience with this feature.
Overall CAKE seems to work very well, but the issue of bandwidth determination remains highly problematic, and for some individuals is even a reason to forego CAKE altogether.
Might the developers be convinced to make it work for those of us on such connections?
As for presumably any LTE connection, my own 4G connection heavily fluctuates. Mostly there is a 30Mbit/s stable component and then anything between 0-40Mbit/s on top of that. Setting bandwidth to 30Mbit/s is mostly OK, but in the evenings I still see some bufferbloat, presumably because of congestion at my ISP / cell tower.
In summary I sacrifice a huge amount of otherwise perfectly usable bandwidth for a solution that works only most of the time. This is obviously not very satisfactory. Anyone on a variable rate connection will face the same issue.
Otherwise I see various DIY attempts have been made to address this interesting issue.
These can be divided into two categories.
Firstly, bandwidth is tweaked by monitoring latency. For example ping tests are carried out and used to increase bandwidth until the ping increases. @dlakelan wrote a script for this:
Secondly, an attempt is made to determine the maximum bandwidth by saturating the connection.
A crude implementation is to disable CAKE and then run a bandwidth test and take the output from that bandwidth test to inform CAKE.
A better approach is however excellently summarised in this post by @richb-hanover-priv here:
The idea is that you disable SQM and then just run a speed test to saturate the connection. You don't care about the output from the speed test; it is just to ensure that the connection is totally saturated. You then compare packets transferred before and after to determine the max bandwidth on the line. The nice thing about this is that it helps reduce interference with normal traffic since you are just filling in the gaps around ordinary traffic. I suppose a downside with this approach however is that it will still result in temporary bufferbloat. So it would presumably interfere with a zoom call.
@Bndwdthseekr wrote a script based on this approach - see here:
My question is: what is the best approach between the above two? I think I favour the former on a theoretical level because it presumably offers reduced interference with normal traffic. But personally I think I would favour a simple and elegant bash script whereas the erlang script looks a bit complicated.
I'd like to try such a simple and elegant script even if it means writing my own.
@Bndwdthseekr what did you settle on in the end?
@moeller0 I'd love to have your thoughts on the above.