# 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
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
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. 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?
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.
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...
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.
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
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.
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:
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.