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

Experimenting with just working from single rate.

  # in case of supra-threshold RTT spikes decrease the rate unconditionally
        if awk "BEGIN {exit !($cur_delta_RTT >= $cur_max_delta_RTT)}"; then
            next_rate=$( call_awk "int( ${cur_rate}*(1-${cur_rate_adjust_RTT_spike}) )" )
        else
            # ... otherwise take the current load into account
            # high load, so we would like to increase the rate
            if awk "BEGIN {exit !($cur_load >= $cur_load_thresh)}"; then
                next_rate=$( call_awk "int( ${cur_rate}*(1+${cur_rate_adjust_load_high}) )" )
            fi
            # low load, so determine whether to decay down, decay up, or set as base rate
            cur_rate_decayed_down=$( call_awk "int( ${cur_rate}*(1-${cur_rate_adjust_load_low}) )" )
            cur_rate_decayed_up=$( call_awk "int( ${cur_rate}*(1+${cur_rate_adjust_load_low}) )" )

            if awk "BEGIN {exit !($cur_rate_decayed_down > $cur_base_rate)}"; then
                # low load gently decrease to steady state rate
                next_rate=$cur_rate_decayed_down
            elif awk "BEGIN {exit !($cur_rate_decayed_up < $cur_base_rate)}"; then
                # low load gently increase to steady state rate
                next_rate=$cur_rate_decayed_up
            else
                next_rate=$cur_base_rate
        fi
        fi
1 Like

Working well here, so far!

1 Like

The new single rate experimental version? For me it scales down too quickly and too much.

I would concur with that assessment, for sure. But it maintains a much flatter RTT/delta_RTT for me as compared to the "main" version I was testing.

What kind of connection do you have? @richb-hanover-priv suggested getting the script to work from a single rate to simplify everything. So I am trying to experiment to see if I can make that happen. But a drawback is that it will KEEP lowering and KEEP raising. That may be fine, but just not sure yet.

Alright, so don't boot me from this virtual room, please :wink:

I am actually a US cable (DOCSIS 3.1) user with 400/20 mbps on the carrier rate card. But as is common for cable, I actually pull around 480/24 mbps with SQM disabled. That said, my go-to SQM settings have been 462500 kbps for ingress and 24500 for egress. This works well about 70-80% of the time, but since COVID increased WFH and school-from-home populations around me, I have been seeing some significant swings in bandwidth/latency depending on time of day.

Hence, my interest in this script. :slight_smile: I realize the main intent of the script was for potentially lower-speed connection types, but I figured why not give it a shot. If my feedback will skew your testing, let me know and I'll happily convert to "observer" mode from a forum perspective.

Right now, as it's the weekend, I am setting at the 462500/24500 kbps values. But under load (running a speed test) I do see both values get adjusted downward and fluctuate quite a bit before returning to the configured settings. But honestly, given the much flatter RTT/delta_RTT, I would say that's a good thing in my case. Your thoughts?

1 Like

Please can you show some output lines from the script? Can you start script with no load then start ISO's running? Just need a minute or so to plot in excel.

Also can you wait for update I am about to push. 2 secs..

... OK done, please can you post in pastebin output from:

Okay, ran this with the updated script, though I will go ahead and say it had a significant [poor] impact on my upload speed under load. Here's the results from two speed tests: https://pastebin.com/fPYcnASx

Corresponding speed tests:

Speedtest by Ookla

     Server: Spectrum - Durham, NC (id = 16970)
        ISP: Spectrum
    Latency:    20.61 ms   (3.99 ms jitter)
   Download:   429.02 Mbps (data used: 587.0 MB )
     Upload:    10.61 Mbps (data used: 15.9 MB )
Packet Loss: Not available.
   Speedtest by Ookla

     Server: Spectrum - Durham, NC (id = 16970)
        ISP: Spectrum
    Latency:    24.45 ms   (5.13 ms jitter)
   Download:   436.42 Mbps (data used: 539.7 MB )
     Upload:    14.16 Mbps (data used: 23.1 MB )
Packet Loss: Not available.
1 Like

Yikes that ping spike is terrifying.

Please can you try same test except start 2x simultaneous ISO downloads to saturate connection and maintain in saturated state?

Agreed, let me try some different Speedtest servers and see if it's due to that particular server or the updated script. I wasn't seeing those spikes once I moved to your first experimental script...

UPDATE:

Sure thing--I'll do this first!

I'm testing a feature. Namely I only decrease bandwidth upon RTT spike in either direction if there is load in that direction. Not sure if that actually makes sense yet. @moeller0?

This safeguards against reducing upload bandwidth upon only a download load that causes RTT spike and vice versa. So now only RTT spike + load in the direction in question will result in rate reduction.

1 Like

Yikes--this was an interesting test! Here we go: https://pastebin.com/dH3E2Qhf

That brought TC to its knees. Once I hit rock-bottom, I literally had to restart the SQM service to restore connectivity.

For that test, I began two simultaneous downloads of this large test file from a mirror that is geographically near to me:
curl -o test.bin https://mirror.wdc1.us.leaseweb.net/speedtest/10000mb.bin

LOL it went down to 10kbps !

I started seeing 14.4kbps US Robotics modem lights and hamster dance flashing before my eyes. Scary stuff. I think there may have been some flashing red text-on-black background going on too.

1 Like

squeeee---crrrr--beyongabongeee---psshhh

2 Likes

Here is what I see on mine. Seems to work.

@_FailSafe are you using delta RTT = 15? 10 is too low I suppose.

@_FailSafe please can you re-run with recent commit?

Didn't come crashing down as hard that time and both downloads actually ran to completion: https://pastebin.com/0PtTGQqA

From your data @_FailSafe something isn't working right as your RX load goes significantly > 1.0. Hmm. I don't understand that. Are your rx_bytes and tx_bytes paths set correctly:

rx_bytes_path: /sys/class/net/eth0/statistics/rx_bytes
tx_bytes_path: /sys/class/net/eth0/statistics/tx_bytes

@dlakelan any idea why his rx and tx goes > 1.0? Up to even > 9.0?

This doesn't happen to me at all.

root@OpenWrt:~# ./sqm-autorate.sh
rx_bytes_path: /sys/class/net/veth-lan/statistics/tx_bytes
tx_bytes_path: /sys/class/net/wan/statistics/tx_bytes
                 log_time;       rx_load;       tx_load;  baseline_RTT;           RTT;     delta_RTT;   cur_dl_rate;   cur_ul_rate;
20211204T203115.087246452;          0.42;          0.01;         49.09;         56.02;          6.94;      30000.00;      30000.00;
20211204T203115.591589572;          0.23;          0.01;         49.10;         53.15;          4.05;      30000.00;      30000.00;

@_FailSafe have you installed:

# requires packages: iputils-ping, coreutils-date and coreutils-sleep

root@OpenWrt:~# ./sqm-autorate.sh
rx_bytes_path: /sys/class/net/eth0/statistics/rx_bytes
tx_bytes_path: /sys/class/net/eth0/statistics/tx_bytes

Indeed I have installed them:

root@OpenWrt:~# opkg install iputils-ping coreutils-date coreutils-sleep
Package iputils-ping (20210202-1) installed in root is up to date.
Package coreutils-date (8.32-6) installed in root is up to date.
Package coreutils-sleep (8.32-6) installed in root is up to date.