Thank you for, finally, TL;DRing this thread.
Ah yes, I suppose we do already. Not sure what I was thinking there.
Any thoughts on:
This is problematic, we got indication that our shaper rate is too high, so just reducing the amount of further rate increase is not going to help...
If at all consider conceptually something where we have an addition threshold (lower than xl_owd_delta_thr_ms) from which on we reduce the shaper_rate_adjust_up_load_high so that at we have a graceful cut over.
Now, implementation wise we could use your proposal, all that is needed is adjusting the xl_owd_delta_thr_ms values down somewhat (or not it really depends on how well this works and it is not that we had any principled method to deduce the xl_owd_delta_thr_ms values to begin with).
Whether that works better than the current approach is to be seen, I see no real reason why this should not work at least 'good enough' so just try
Sidenote: the scaling seems off in the second graph, the cross over point(0) will be more on the left if ramping from 1.04 to 0.75... but that is besides the point the plot clearly conveys.
1 Like
long story short: I figured out that I in fact did not set up cake-autorate correctly. Therefore I run log and got this error message:
Warning: The configured download interface: 'ifb-wan' does not appear to be present. Waiting 10.0 seconds for the interface to come up.
by running tc qdisc ls this is what I get:\
> root@OpenWrt:~# tc qdisc ls
> qdisc noqueue 0: dev lo root refcnt 2
> qdisc mq 0: dev eth0 root
> qdisc fq_codel 0: dev eth0 parent :10 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :f limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :e limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :d limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :c limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :b limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :a limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :9 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :8 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :7 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :6 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :5 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :4 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :3 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
> qdisc cake 800d: dev wan root refcnt 17 bandwidth 40Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 44
> qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
> qdisc noqueue 0: dev lan3 root refcnt 2
> qdisc noqueue 0: dev lan2 root refcnt 2
> qdisc noqueue 0: dev lan1 root refcnt 2
> qdisc noqueue 0: dev br-lan root refcnt 2
> qdisc cake 800e: dev ifb4wan root refcnt 2 bandwidth 37Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms noatm overhead 44
> root@OpenWrt:~#
Maybe try ifb4wan in the cake-autorate config?
1 Like
And maybe use ingress keyword?
1 Like
Maybe just add it to the description on the cake-autorate github page as part of the introduction or as a separate section, what to expect?
1 Like
I have some questions regarding this script, I have fixed bandwidth FTTH connection, but 99% of my household’s usage is through wifi and there are spots where the WiFi speed drops due to interference and bufferbloat increases.
Can I use this script to get bufferbloat free connectivity across my home?
i had a play with it and it seems to work quite well but I'm wondering if we can add the option to have alternate upper and lower limits.
Mobile Internet speed is based on load and " 4 PM – 10 PM", if I could cap the upper limit during this time just for better fine tuning.
1 Like
Usteer or dawn might be a better idea for this.
How about using cron to modify the bandwidth cap and then restarting? Could flash wear be of a concern?
Could you elaborate how these are supposed to help with low signal and interference?
This project won’t help you. The best solution is to improve your wifi signal by switching to less congested parts of spectrum or adding dumb APs (ideally wired) in problematic places. Also moving as many as possible devices to 5 GHz usually helps a lot with bufferbloat.
1 Like
Not really well, as you would need to run active probes against each individual station and then restrict the rate for all to the worst link... that will not be much fun...
Try to get an OpenWrt AP/router that offers AQL (e.g. mediatek mt76 based devices) which should solve the AP to station direction of the problem (that still leaves the station to AP upload direction, but often there is mnore data being down- than uploaded).
1 Like
Adjusting config and service restart as suggested by @qunvureze is an option.
I wonder if I should add the option in cake-autorate to reload the config file whilst cake-autorate is running. That would facilitate dynamic adjustments. But I’d need to take great care over all the various initialisations to ensure they get run where needed as well.
@moeller0 any thoughts on this? Presumably baselines would stay the same?
They should... my thought however is that the maximum rate really is mostly an optimisation to not waste time searching something unachievable... say on a gigabit ethernet link to the modem, setting the gross shaper rate to anything > 1000 Mbps will at best be useless at best and might actually be actively bad if that results in overfilling an upstream buffer...
But that aside I can envision simpler scenarios that really do not need the full autorate machinery but really just would like to adjust a mostly static shaper for different times of the day, say prime-time versus rest... in cake-autorate you could then set baserate and maxrate to the desired value to mostly get that rate with autorate still acting as a backstop if congestion does arise unexpectedly.... IMHO that means that likely all 3 rates per direction might want some fiddling...
Maybe split the rate config into a different file, or allow a new addition current_autorate_rate_settings.conf that the code will read in and apply on receiving say a HUP signal (I seem to recall that is occasionally used to request a read of changes configuration). That would leave the whole messy question of when to do this as somebody else's problem (looking at you here, cron). But I do not know the whole thing sounds a bit over-complicated, given that autrorate should be able to deal with such situations organically already?
@professor_jonny did you try to restart cake-autorate with changed values manually and does this noticeably perform better?
Great points. All makes sense.
Actually yes!
Would you suggest we scale from the shaper increase rate (1.04) at this new threshold down to the minimum shaper reduction rate (0.99)? Or scrap the minimum shaper rate and scale from the 1.04 to the maximum shaper reduction rate (0.75)?
As a reminder, graphs here:
Band steering will disassociate on low SNR causing reconnection on a better band or ap.
I wonder that we are not mostly interested in the zero point of that transition and the point from where the maximum rate decrease step is in effect... so maybe we calculate the threshold from which to decrease the rate increase steps internally (based on the numbers we already have, the zero and the max decrease step threshold as well as the max rate increase and max rate decrease steps, and just issue a debug message to exposed that calculated number to the user for debugging?*) based on the the other two thresholds?
That would change things a bit, as currently we do not start with zero decrement steps I believe, but with a somewhat larger value, no?
*) I wonder whether with these variable steps it might not make sense to actually put the signed change value (both increase or decrease) into the normal data records for the log? Sure these can be deduced by comparing the shaper settings for two consecutive data records, but maybe it is more convenient to expose them explicitly?