I will do test with original adapter rpi4 tomorrow
Well i bought mini ups as backup since it's often blank out in my area. I think the setup seem wrong output seller didn't have rpi4 or similar devices to test the electric output. It's been 2 month i used it and only having problem while upgrading openwrt version two times failed(firstboot).
The other one i saw something good in your commit -12) sqm-autorate via config/sqm autorate='1' (for lte/variable-bw-links)
Is there any tips for the those update in openwrt 21.02? I'm using router 4G cat 19(lte) as internet
Glad you noticed that... it's kind of experimental but it will be in the
next 21.02.x build that I push...
(there is also a zip file that can be installed to test with)
It's pretty much just the code from the guys mentioned in that thread at this stage
i can't really test it properly as I don't have LTE...
on my system it keeps SQM settings at the bare minimum
(I think it requires load to make it start working or something)
So likely won't be perfect right now... but in situations where
you really need SQM... and have LTE... it still may
offer benefits... ( sacrifice some 'learning/scaling' speed loss to have low latency in general )
I only have 3 new lines in my sqm section to make it work/enable it;
i assumed if this working speed gonna over 29,7Mbps since my speed download 30-64Mbps up 18-25Mbps. i did a few speedtest and wavebloat for bufferbloat test but the speed not hit above min_dl_rate bufferbloat
everytime changes in /etc/config/sqm need to stop/restart sqm-autorate-init.sh to take effect
In this case you should probably try the original script... (I've not tested from luci so will look into this > actually it looks like it has some bugs so will have to temporarily remove it... the whole reason to create it was for multiple interfaces... but for a single interface the original script below should be fine)
You can comment out the lines you added to /etc/config/sqm, then rm /bin/sqm-autorate-init.sh then reboot
I don't know how well @moeller0's fork works. I think he has been experimenting with various changes. Whatever change is of benefit will get pulled into the main code I am developing.
The code here:
Certainly works at the moment on my LTE connection but it is still experimental. The service file works to enable service but needs to be restarted with any SQM change. Perhaps a call to this service script should be placed inside the main SQM script so that when the SQM script is restarted the autorate service script is also restarted. Also take care to disable logging as otherwise one log line per tick. That said we'd love a day's worth of data output to the memory card on RPi to test over a day's usage.
The readme in the link above gives some help about how the script works.
The script is designed to stay at the minimum set download and upload on zero load. Because without load the capacity of the connection is unknown. When there is a load it then increases the bandwidth until any RTT spike is detected, at which point it eases back.
So the idea is that it recovers otherwise lost bandwidth associated with having to set a compromise bandwidth which won't even work all of the time.
thanks for the info... I will definitely test both...
and suspected/read about this ramping up behavior on load only... (although couldn't see it happen with the first script on my connection will test yours to see if different and will retest the first script in it's vanilla form in case I messed something up)
hopefully after some feedback from those with LTE links will work again on the sqm restart lock up thing...
The original concept is based on @moeller0's ideas by the way. He came up with a simple routine and has been instrumental in getting a viable solution to work. I wrote the initial shell script and that has been tweaked by @moeller0 and others. Otherwise the script has drawn in a lot of ideas from others in the adaptive thread you linked above so it is a team effort.
Anyway the shell script is more or less working now but still a work in progress and will benefit from further testing and improvement.
A consideration is that the script issues tc qdisc change calls. So if qdisc goes away because SQM is stopped and started again the script will try to call tc qdisc change but the corresponding qdisc had been removed.
@moeller0 would it be enough to just have SQM restart the autorate service script when SQM service is started?
Or maybe we should check relevant qdisc exists before calling tc qdisc change?
# only fire up tc if there are rates to change...
if [ "$last_dl_rate" -ne "$cur_dl_rate" ] ; then
#echo "tc qdisc change root dev ${dl_if} cake bandwidth ${cur_dl_rate}Kbit"
tc qdisc change root dev ${dl_if} cake bandwidth ${cur_dl_rate}Kbit
fi
if [ "$last_ul_rate" -ne "$cur_ul_rate" ] ; then
#echo "tc qdisc change root dev ${ul_if} cake bandwidth ${cur_ul_rate}Kbit"
tc qdisc change root dev ${ul_if} cake bandwidth ${cur_ul_rate}Kbit
fi
Also @moeller0 am I right that your fork is just for testing changes to get pulled into my repository? If so @wulfy23 may want to incorporate the code from my repository rather than the fork I think.
I second the "team effort" description, but I disagree about who designed/drove this, this is mostly your work.
I think that might be the right thing to do, that way we will piggy-back on sqm's hotplug scripts, not sure however how to do that elegantly.
Also an option, but potentially a costly one.
Yes, I just forked to be able to play around/explore. On my fixed rate link the script at best does not hurt, so I can not really test anything diligently and hence all my changes are dubious until cleared by testing...
procd_lock problem starting background script from sqm itself
i've spent the last few hours on it and thought it was fixed but have not nailed it yet...
maybe someone else knows what's going on... basically when the autorate script is spawned via sqm itself... (child process or something?) it hangs procd_lock() (so no subsequent stop/start/restart actions will run) maybe because it never exits or something...
starting it manually is ok... so i'll probably give up trying to start/restart from sqm soon unless someone knows a way around the lock problem...
and create a separate 'service' that spawns the autorate.sh scripts themselves... (and associated hotplug / other background detection of sqm service state change / reload sort of thing)
edit: updated the tar file to include a service 'autorate'
if you unzip the tar from '/' and enable and start the service;
you can test it out... but it's very rough still in how it logs things etc. etc. ( it just runs sqm-autorate-init.sh start and sqm-auto-rate-init.sh stop but in silent mode... if you don't see something in ps wwww | grep autorate then just try those commands to start it yourself and see whats going on... it also has 'status' )
will likely take a week or so to properly iron out all the bugs...
I am curious how you managed this. Did you put in restart call within the sqm service script? I wondered about that to address changes in sqm caused by interface going down and hotplug even restarting sqm, which should then restart the autorate service.
@Nomid are you presently using this community build for your funky RPi4 LTE setup? And how are you managing SQM for that? I am wondering about getting RPi4 myself like you have done. To replace my B818-263. Thing is the B818-263 works pretty well - with location optimisation (on its side next to window), I get these amazing stats:
yeah, i've seen this too (r18161)... thought it was due to some things i've been working on maybe... (nothing major really mostly the autorate stuff)... will run some test builds today with 'stable(edit:done r18086 is working ok)'+'next(edit: done r18217 worked ok)' and the current file mods to try to pin down where it's coming from...
edit: re-testing with r18161 first worked and then didn't which could mean the above tests are now void and need to be repeated more thoroughly... (bugger)
for a workaround you can ssh in and run /etc/init.d/rpcd restart
or
use an incognito/private-browsing window
or
just revert back to the stable version...
possibly related (tentative: i'm having a bad run so don't quote me on that)