That worked! Thanks. Which version should I test?
There is a copy icon/button if you hover over the top right corner of the preformatted test, that on click will copy the whole enchilada into the clipboard buffer:
Here I clicked that on your post and just pasted it in with command-C (giving away the OS I am currently using).
export LUA_CPATH='/root/.luarocks/lib/lua/5.1/?.so;/usr/lib/lua/5.1/?.so;./?.so;/usr/lib/lua/?.so;/usr/lib/lua/loadall.so'
export LUA_PATH='/root/.luarocks/share/lua/5.1/?.lua;/root/.luarocks/share/lua/5.1/?/init.lua;/usr/share/lua/5.1/?.lua;/usr/share/lua/5.1/?/init.lua;./?.lua;/usr/share/lua/?.lua;/usr/share/lua/?/init.lua;/usr/lib/lua/?.lua;/usr/lib/lua/?/init.lua'
I just updated the feature/process-bandwidth-files branch with the working updates from @dlakelan just now. Go ahead and grab it from there 
I did that too. How do we make this permanent? I tried putting in .profile didn't work.
Add it to /etc/profile instead, note no leading .
Yeah, you can toggle the verbose or debug (if you want a LOT of noise) options to get a little more data. Otherwise at the moment only speed change updates will start popping up in stdout.
1 Like
Wow - the output is too much - could we maybe output lines as in shell script:
printf "${RED} %s;%14.2f;%14.2f;%14.2f;%14.2f;%14.2f;%14.2f;${NC}\n" $( date "+%Y%m%dT%H%M%S.%N" ) $rx_load $tx_load $min_downlink_delta $min_uplink_delta $cur_dl_rate $cur_ul_rate
That is rx load, tx load, the present minimum downlink delta, the present minimum uplink delta, the current download rate and the current upload rate.
Because that can be graphed in Excel to measure script efficacy.
Eventually. we're still really in development and debug mode. No one has ever seen this thing actually work yet. so running it while your wife is on zoom is like asking to get sent to the dogs 
Indeed! 
Happy wife is a happy life.
Just watching the speed rise to see where it stops. First issue I see is that both download and upload is rising despite only download active. Second issue is that download is rising and rising and rising. I don't think the baseline stuff has been properly ported yet because the baselines fluctuate like crazy.
Please can we just port the script as much as possible without any clever stuff. Because that is going to make this so much harder.
By the way didn't you have the rx and tx path generation in at one point?
And any chance we can mirror the output of the shell script? It's not easy to read this output and not amenable to plotting in excel at the moment.
So actually yes, download rates never stopped increasing - download and upload just rises ad in finitum on only download active:
SPEED CHANGE PARTY!
rx_load: 0.33395638617609 | tx_load: 0.015954652502073
mindown: 71.611206075722 | minup: 0.34836657197208
cur_dl_rate: 92096 | cur_ul_rate: 34536
I presume that speed change party was scaling back the load because of the high mindown (is that min delta downlink?). I really am hoping we stick with the shell script logic that has been developed, because otherwise this is all much harder.
root@OpenWrt:~# tc qdisc ls
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
qdisc noqueue 0: dev lan1 root refcnt 2
qdisc noqueue 0: dev lan2 root refcnt 2
qdisc noqueue 0: dev lan3 root refcnt 2
qdisc noqueue 0: dev lan4 root refcnt 2
qdisc cake 8047: dev wan root refcnt 2 bandwidth 32620Kbit besteffort flows nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 92
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc cake 8041: dev veth-lan root refcnt 2 bandwidth 84405Kbit besteffort triple-isolate nonat wash ingress no-ack-filter split-gso rtt 100ms noatm overhead 92
qdisc noqueue 0: dev veth-br root refcnt 2
qdisc noqueue 0: dev wlan0 root refcnt 2
qdisc noqueue 0: dev wlan1 root refcnt 2
qdisc noqueue 0: dev wlan1.sta1 root refcnt 2
qdisc noqueue 0: dev wlan1.sta2 root refcnt 2
qdisc noqueue 0: dev vpn root refcnt 2
I beg thee - no clever stuff! We know that the logic in the shell script actually works and it will be much easier to work from there without trying out some wacky new ideas. Though I did anticipate spreading out the requests. I was expecting deviation from the script logic to account for that.
All that being said amazing work guys in getting this far. @_FailSafe you have obviously put in a lot of time into this.
It's still just buggy as heck, we're working on finding the bugs, for example it had the reduce due to latency condition accidentally missing from the code due to late night coding session. The goal is to get something that works like the shell script, and then stick it on its own branch where it can be preserved, and then work on whatever "funny stuff" people want to do in separate experimental branches.
1 Like
LOL! Thanks for your response. This evening I've been Mr Moody! Sorry about that.
Yeah, let's just put the Lua testing on hold in this thread for the moment until @dlakelan, @Lochnair, and I get a few more things reviewed and ironed out from the port. I probably was a little too hasty putting out the signal for testers.
No need to keep reporting issues at this point as we have a laundry list of things to revisit and tidy up. I'll work with @dlakelan to confirm the Lua behavior matches the shell behavior and then let this thread know again when there's a more ready version.
To be clear, I just wanted to urge that a true port is implemented first to avoid the added complexity of testing out changes to logic that's been ages in the making. @dlakelan's post above hugely reassured me:
So hoping we can hold off on the Bayesian background model employing realtime independent component analysis, stochastic reverse rollover Hidden Markov Models with decompositions, transformations, etc., until we've got our nice and simple owd/baseline approach up and running.
I'm just super hopeful to keep everyone working together as much as possible on common project. It seems lua is the way forward so I'm putting shell development on hold in the hope once port is handled we can then all work on that in terms of optimising to get solution for all OpenWrt users.
I personally don't mind this thread being used for incremental development. It's just very pleasing to see it all ticking along. So please keep providing updates as I'll bet I'm not the only one who enjoys catching up on the progress.
And @_FailSafe, @dlakelan, @CharlesJC and @Lochnair thank you so much for your amazing combined efforts on this. There are so many who will benefit from CAKE with autorate.
@Lochnair don't suppose you tried sprout any more? Don't kill me for asking. I'm just dead curious.
@Lynx I'm afraid I haven't had time to do much bufferbloat related stuff the past few days, but I did start working on a openwrt package for sprout to more easily get it installed.
However it turns out it needs to compile some protobuf things I don't know how to fix yet, I've no experience with that, so might need help from someone who does to get it rolling.
I should mention I'm out of town this week for school, so I'm not following these efforts much at the moment.
If you tag me I'll likely show up, but otherwise I'll keep my focus elsewhere.
1 Like
I submitted a PR to factor out some redundant objects / arrays in the lua script. I hope that these are of use
1 Like
Here is an updated version of the Lua script that, for me, is behaving much closer to the OWD shell script. I am making no claims it is perfect yet. Just ready to be compared against the shell script behavior and determine what tuning is needed.
1 Like
Thanks for the input you've been providing. I would say take a look at the branch I posted here and feel free to recommend updates to it once a consensus is reached around how well it is performing against the shell version.
I like a lot of the suggestions in your PRs, and I was going to do some of the same cleanups. But I didn't want to cause any suspicion that big changes were happening to the underlying functionality (in relation to the shell version).
1 Like
A request for all of us who haven't been paying strict attention in class
It looks as if you've linked to the port-from-shell branch on github.com.
- Does the README for that branch contain up-to-date installation instructions?
- Are there any specific experiments that you would like us to perform?
- What reports and results would be useful?
Thanks for all this work!
1 Like