If mine only varies ~100mbps or so on a 1gbit plan, would you recommend using this? Also, how do we figure out the minimum and baseline dl/up rates?
That is a policy question only you can answer. Personally, I would try setting the shaper to 900 Mbps statically, if that solves the issue reliably you are set, however if you still encounter noticeable latency spikes maybe cake-autorate is for you 
There are no hard rules for these, I would recommend the following:
a) minimum: that is the throughput at or below which you value higher throughput over lower latency. I note that at 12 Mbps a single full sized packet already has a transmission duration of 1 ms, if you have a 10 in your queues that will already add up to 10 ms.
b) baseline: this is the rate that cake autorate converges on when it has no data... so I would set this to the rate that I typically expect to be able to use reliably. If you are very pessimistic set this to the same as minimum, if you are very optimistic set this same as maximum, otherwise pick a value between maximum and minimum that you are comfortable with.
It might take a few iterations to get these right for your taste.
1 Like
I have now set up a ZTE MF287 with 4 cores and cake-autorate seems to work just fine. At 100 MBit/s (my maximum) I do get around 80% usage on cores 1 and 2, but no slow downs at all.
2 Likes
Nice - and how’s the performance in terms of bandwidth adjustment to avoid latency spikes? Is it working well?
Not really. When I download a large file, some websites won't even load. 
Yes that’s not ideal.
But the default settings are pretty aggressive in terms of managing latency. Probably too aggressive for your connection.
Sounds like it’s flooring the bandwidth to your set minimums because there is too much latency increase. So you’d need to increase the tolerated latency and accept that for retaining higher bandwidth.
I’d suggest firstly trying:
dl_avg_owd_delta_max_adjust_up_thr_ms=30.0 # (milliseconds)
ul_avg_owd_delta_max_adjust_up_thr_ms=30.0 # (milliseconds)
dl_owd_delta_delay_thr_ms=80.0 # (milliseconds)
ul_owd_delta_delay_thr_ms=80.0 # (milliseconds)
dl_avg_owd_delta_max_adjust_down_thr_ms=130.0 # (milliseconds)
ul_avg_owd_delta_max_adjust_down_thr_ms=130.0 # (milliseconds)
If with this you’re still seeing floored bandwidth then you’re connection might be beyond saving!
And don’t forget that the minimum bandwidths are hard minimums. I have mine set to 5Mbit/s - easily enough to load websites.
1 Like
@Lynx I have been away for a while, but recently saw this presentation for Purple, that purports to offer "Dynamic control of CAKE". https://www.youtube.com/live/uIcMjPeRT5M?t=647s Interesting?
3 Likes
I watched the presentation, I like it. Also nice I believe that he acknoledges cake-autorate and even used (and credited) @Lynx's schematic graph.
BTW there seems to be some indian university groups that consider/already tackle making a variant of cake-autorate in rust. @Lynx, any interest in getting in contact with them?
2 Likes
Hi Rich, PURPLE came out of discussions at APNIC 58 in Wellington last year about LibreQoS, and what happens if you're a wireless ISP and link capacities vary. I didn't have a good answer on how to deal with this at the time (other than mentioning cake-autorate could also be used), but it got me thinking there must be a way to manage this issue passively.
My first iteration of PURPLE used the (undocumented?) Ubiquiti airOS web API to retrieve capacity stats on a point to point link for tracking, and then continuously updated the CAKE bandwidth parameter on the device directly behind the bottleneck radio to be this rate, less some safety margin (e.g., 15%). I also retrieved the packet backlog from the radio, and would decay the bandwidth further when detecting consecutive backlog or drop measurements (making the assumption that the underlying hardware buffer was full, and packets were then building in backlog at the qdisc layer).
This did actually work quite well, but only on the Ubiquiti radios I used. The capacity estimation on some other radios I had was not anywhere near consistent enough to trust. Polling the backlog was also quite a lagging indicator of congestion. The next iteration of PURPLE simply used the AIMD algorithm (and either unidirectional latency or RTT measurements) with a given target latency for control (still requires some intuition of the link) and sane minimum/maximum bandwidth values to be set. I also sidestepped my own objective of doing things passively.
The proof of concept code and information about measurements has been uploaded to GitHub: https://github.com/wine-group/purple
Disclaimer: unlike cake-autorate, PURPLE is nowhere near production ready, just a research journey exploring the problem space.
Appreciate the work you, @moeller0, @Lynx, and others have done on cake-autorate. Convincing people (even within the field) that this is a real-problem has been surprisingly difficult at times, and having cake-autorate to discuss (and @Lynx's great diagrams) has made it much easier.
5 Likes
Welcome, @twominutesalad 
1 Like
Hello Duncan - thanks for the additional information about PURPLE.
2 Likes
Maybe it is Ysurac/openmptcprouter-feeds
1 Like
This is one huge commit(!):
1 Like
yes. It’s based on sqm-autorate lua though? U made many changes on the bash og script
Edit: my bad, it’s just based on the old 3.1 stable release
1 Like
I have been trying cake-autorate on an mt7621 device (e7350). I have an LTE connection that tops out between 50-60mbps DL, but can drop as low as 18-20mbps. SQM with piece of cake works fine at 35-45 mbps with .2-.3 CPU usage. Cake autorate seems to function well enough, but saturates the CPU usage above 1 when DL speeds exceed around 40-45 mbps. HW/SW offloading is disabled. Are there known cake-autorate config settings to adjust on this low-spec router that might help? Maybe polling frequency? I’m sure filogic would solve all my problems, but was thinking <100mbps would be fine on mt76.
Yes you can reduce ping frequency from the default 20 Hz to 10 Hz. Also disable all logging.
2 Likes
Thank you - leaving the default number of pingers at 6 and setting the ping interval to .6 to achieve 10hz did reduce CPU usage somewhat. I’m going to try 5hz (if my math is right) with these settings in the override section:
log_to_file=0
debug=0
reflector_ping_interval_s=.8
no_pingers=4
My internet is on the slower side today but so far this config reduces CPU usage considerably and still seems to stabilize the connection. For my needs, I’m OK with some brief spikes in latency.
Assuming 5hz is the right target for my CPU, would setting the no_pingers to 3 and ping interval to .6 be advantageous? Appreciate your work and support on this script!