CAKE w/ Adaptive Bandwidth [October 2021 to September 2022]

I am sorry this all looks interesting and I want to give it a shot. But I'm having a slight error while script is running.

ul_if=pppoe-wan # upload interface
dl_if=br-lan # download interface

My wan connection is pppoe and Is this what supposed to be? Options are br-lan, eth0, eth1, ifb4eth0, ifb4pppoe-wan, lo, pppoe-wan, teql0, wlan0 in /sys/class/net
I'm getting error:

root@OpenWrt:~# ./autorate.sh
rx_bytes_path: /sys/class/net/br-lan/statistics/rx_bytes
tx_bytes_path: /sys/class/net/pppoe-wan/statistics/tx_bytes
ping: ping: socketsocket: Address family not supported by protocol
: Address family not supported by protocol
                 log_time;       rx_load;       tx_load;  baseline_RTT;           RTT;     delta_RTT;   cur_dl_rate;   cur_ul_rate;
ping: ping: socketsocket: Address family not supported by protocol
: Address family not supported by protocol
20211229T001038.552218451;          0.00;          0.01;          1.94;          1.94;         -0.01;      11500.00;      11500.00;
RTNETLINK answers: No such file or directory
ping: ping: socketsocket: Address family not supported by protocol
: Address family not supported by protocol
20211229T001039.046409316;          0.00;          0.00;          1.94;          2.00;          0.06;      11500.00;      11500.00;
ping: ping: socketsocket: Address family not supported by protocol
: Address family not supported by protocol
20211229T001039.553800463;          0.00;          0.00;          1.94;          2.01;          0.07;      11500.00;      11500.00;

Three mentioned packages are installed. Didn't add ipv6 in my firmware since my ISP supports only ipv4. So what's this error "ping: socketsocket: Address family not supported by protocol"?

Could you confirm which version you are using?

Likely ifb4-pppoe-wan is the dl_if you want

This is imho a mistake. Ipv6 is here now and needs to be a thing people get used to. The future of openwrt imho is that the easiest and most supported administration method will be ipv6 ULA.

In any case in your specific case I believe In the lua version that we are listening for replies on :: which is an ipv6 address that represents all addresses BOTH ipv6 and ipv4. So I suspect that's causing your problem. Thanks for the report!

2 Likes

@richb-hanover-priv, I should mention that the branches are now cleaned up courtesy of @_FailSafe, so the experimental branch should now be replaced with testing/lua-threads

It's not quite ready yet, but @_FailSafe is hard at work getting it to a testable state.


I just updated & compiled the master version

Here we go!

Thanks to some quick development work by @Lochnair and @dlakelan over the past few days, the "official" Lua test branch (w/preemptive threading) is ready now. It is the testing/lua-threads branch and here is the README:

There are wget based installation instructions for those who want to try it out without pulling the project repo. It can be installed via:
sh -c "$(wget -q -O- https://raw.githubusercontent.com/Fail-Safe/sqm-autorate/testing/lua-threads/sqm-autorate-setup.sh)"

If you do choose to pull the project repo, you can still run the sqm-autorate-setup.sh file within the project and it will install the necessary pieces from the local files. This is useful for testing and tuning purposes.

Within the README are instructions for use, as well as descriptions for the available options and their purposes. Many thanks to @CharlesJC for his work to integrate a native OpenWrt config into this project.

Please refer to this evolving post by @richb-hanover-priv for testing expectations:

When issues are discovered, please open a bug report in the repo here: https://github.com/Fail-Safe/sqm-autorate/issues/new/choose

Feature/enhancement requests can be submitted via the same URL.

For anyone browsing my repo, please know that the develop/... branches are in no way expected to be stable. Please do not use them if you are not willing to help fix the issues you will uncover. Do NOT open bug reports for develop/... branch code.

The testing/... branches come with a reasonable expectation that obvious runtime bugs have already been squashed. Issues uncovered within testing/... branch code are fair game for bug reports.

Thanks to all who continue to contribute to the discussion and progressions here!

2 Likes

Thanks to @_FailSafe for the final push and cleaning up the repo to make it usable by others. Please do read the readme which has some caveats and expectations. Once this seems to run for people I do think it's fair game for people to fork the repo and try out different ratecontrol functions/algorithms.

3 Likes

If people are getting more speed on few sites like google drive, youtube etc. will the script manage individual ingress bandwidth while maintaining bufferbloat to minimum?

The script has a single speed and will raise the speed so long as buffer bloat remains low, but it won't give you "multiple lanes"

1 Like

I got this error then i tried to start script.

root@RaspberryCM4:~# lua /usr/lib/sqm-autorate/sqm-autorate.lua
lua: error loading module 'lanes.core' from file '/usr/lib/lua/lanes/core.so':
        Error relocating /usr/lib/lua/lanes/core.so: pthread_yield: symbol not found
stack traceback:
        [C]: ?
        [C]: in function 'require'
        /usr/lib/lua/lanes.lua:38: in main chunk
        [C]: in function 'require'
        /usr/lib/sqm-autorate/sqm-autorate.lua:9: in main chunk
        [C]: ?
root@RaspberryCM4:~#

@aGentti86 You on a snapshot build? @_FailSafe wrote a patch to address this as he ran into the same thing: https://github.com/Fail-Safe/sqm-autorate/blob/testing/lua-threads/patch/300-fix-gnu-c-pthread_yield-error.patch

If you're building yourself, please apply that patch, rebuild and see if that helps. Otherwise I can do a build of Lanes for you if let me know which platform your on (ath79/nand etc.)

1 Like

Can someone please elaborate on how capacity estimate is calculated from cake?
Is it updated realtime?
In my adsl line, it seems that's the max attainable rate for both incoming/outgoing.
Maybe we can use it in some calculations as well.

Not sure I get your question correctly, but n the shell script we simply multiply the current cake limits with the duration of the last sampling period to get the maximum volume that could have transferred throough cake and compare that to the volume actually transmitted. But that is only a veridical capacity estimate for the bottleneck introduced by cake itself, if the variable link rate dropped below the cake setting in the sampling interval this estimate will be larger than the true bottleneck capacity, and if the bottleneck rate soared above the cake setting that estimate will be too small.

I meant the cake's capacity estimate:

qdisc cake 1: root refcnt 2 bandwidth 5924Kbit diffserv8 triple-isolate nat wash no-ack-filter split-gso rtt 100.0ms atm overhead 32 fwmark 0xf
Sent 9003127968 bytes 15100369 pkt (dropped 730393, overlimits 15766281 requeues 0)
backlog 0b 0p requeues 0
memory used: 797888b of 4Mb
** capacity estimate: 6409Kbit**

What's the full tc command you're running to get that output?

tc -s qdisc

Here's a bug for the issue, as well as the location in which the patch must be located if building from snapshot: https://github.com/Fail-Safe/sqm-autorate/issues/32#issue-1090505291

Is that value not just reflecting what is being set via options upload and download in /etc/config/sqm file?

Nope... it's not the same value. cake rate is "bandwidth 6138Kbit" but capacity estimate is: 6409Kbit

tc -s qdisc show dev ifb4pppoe-wan
qdisc cake 1: root refcnt 2 bandwidth 6138Kbit diffserv8 triple-isolate nat wash no-ack-filter split-gso rtt 100.0ms atm overhead 32 fwmark 0xf
Sent 9472170257 bytes 15778997 pkt (dropped 819975, overlimits 16819552 requeues 0)
backlog 38527b 31p requeues 0
memory used: 797888b of 4Mb
capacity estimate: 6409Kbit
min/max network layer size: 35 / 1492
min/max overhead-adjusted size: 106 / 1696
average network hdr offset: 0

What are the upload and download values in your SQM config?

FWIW, this is what I see:

root@OpenWrt:~# tc -s qdisc | grep bandwidth
qdisc cake 8018: dev eth0 root refcnt 9 bandwidth 29902Kbit diffserv4 dual-srchost nat nowash ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64
qdisc cake 8019: dev ifb4eth0 root refcnt 2 bandwidth 577939Kbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64
root@OpenWrt:~# tc -s qdisc | grep capacity
 capacity estimate: 24500Kbit
 capacity estimate: 462500Kbit
root@OpenWrt:~# cat /etc/config/sqm | grep load
	option upload '24500'
	option download '462500'
1 Like