hi everybody
my starlink is currently only connected to a netgear switch which is distributed throughout the house only by cable, when I add my router under OpenWrt will the internet be directly operational? Or should I do this?
thanks
starlink is amazing now effectly
no sqm
sqm just a test like this
I realize that I need to incorporate cake-autorate into my How OpenWrt Vanquishes Bufferbloat post. I've put a first draft of a cake-autorate description there.
Comments welcome on any part of the article. Thanks.
Newbie here, need help configuring cake-autorate-config.sh please. Already installed autorate as a service but other than that im clueless. Thanks already.
@Mehdi1607 concerning your post:
(I am responding in this thread because the thread that you originally posted on was a historical thread).
I think we will need more information to go on to give meaningful advice here.
My topic was left a little hanging last time I checked in here so I'll give my concluding 2 cents.
I figured out the issue on my end.
For some reason, not exactly sure why, it seems that it's necessary that the FD 1 and 2 are redirected properly. Otherwise the runtime operation of the scripts get finnicky.
This way, it start working properly immediately upon boot, and still works as it should the next day.
I had the problem that one direction got seemingly "stuck" earlier.
This is your latest release tag from git, using tsping for the pinger binary, running on gentoo linux.
Doesn’t ’cake-autorate.sh &’ work?
Out of curiosity, what’s the total CPU usage? I’ve been trying to see how low I can get that. It’s now around 6-8% on my router with default settings.
Also fancy exporting some data? We can verify all is running well. Typically some degree of tuning will help maximise performance.
Sure, I enabled it as of now. Did a reboot to confirm, and it seems that yes, still good, functionality is there and logging is now enabled.
I'm staying at home for the next 2 days so I can provide some graphs tomorrow perhaps?
This machine is so overkill, the CPU usage is so low that even with all the offloads disabled on the NICs it's not really affecting anything.
This is a custom kernel though, I've turned off a couple of things for performance purposes. The kernel runs in PREEMPT none, fully dynticks, 300hz and a couple other things. Compiled for the architecture with machine optimizations in place for ivybridge processors.
The CPU is a i7-3770K, C-states fixed max. 1 and frequency locked at stock 3.5Ghz with performance governor.
The load average is 0.01 and during speedtests, a core jumps to 9-10% momentarily, mostly idleish.
The device is acting as a L2 bridge topologically, with 2 physical interfaces, logically bridged for cake to work on either end.
Wow. Sounds like an impressive setup!
To stop the process, just send a kill signal to the main process (check ps or the proc_ids file created in /var/run/cake-autorate/primary) and cake-autorate will cleanly terminate and all processes will be torn down.
DL: maximum 95.000%-ile delta delay over all 2 reflectors: 4.865 ms.
DL: maximum 99.000%-ile delta delay over all 2 reflectors: 10.855 ms.
DL: maximum 99.500%-ile delta delay over all 2 reflectors: 17.195 ms.
DL: maximum 99.900%-ile delta delay over all 2 reflectors: 185.735 ms.
DL: maximum 99.950%-ile delta delay over all 2 reflectors: 252.745 ms.
DL: maximum 99.990%-ile delta delay over all 2 reflectors: 355.345 ms.
DL: maximum 99.999%-ile delta delay over all 2 reflectors: 355.345 ms.
UL: maximum 95.000%-ile delta delay over all 2 reflectors: 22.700 ms.
UL: maximum 99.000%-ile delta delay over all 2 reflectors: 25.065 ms.
UL: maximum 99.500%-ile delta delay over all 2 reflectors: 25.675 ms.
UL: maximum 99.900%-ile delta delay over all 2 reflectors: 30.600 ms.
UL: maximum 99.950%-ile delta delay over all 2 reflectors: 103.310 ms.
UL: maximum 99.990%-ile delta delay over all 2 reflectors: 103.325 ms.
UL: maximum 99.999%-ile delta delay over all 2 reflectors: 103.325 ms.
The reflector charts look a bit odd. Maybe @moeller0 can decipher those.
The only time cake-autorate reduced the download rate was about 3/4 of the way through at just over 800s from the start of the log. I suppose your connection was mostly inactive throughout this logging period.
You might or might not want to consider reducing the delay thresholds:
# owd delta threshold in ms is the extent of OWD increase to classify as a delay
# these are automatically adjusted based on maximum on the wire packet size
# (adjustment significant at sub 12Mbit/s rates, else negligible)
dl_owd_delta_thr_ms=30.0 # (milliseconds)
ul_owd_delta_thr_ms=30.0 # (milliseconds)
# average owd delta threshold in ms at which maximum adjust_down_bufferbloat is applied
dl_avg_owd_delta_thr_ms=60.0 # (milliseconds)
ul_avg_owd_delta_thr_ms=60.0 # (milliseconds)
because your overall latency is significantly lower than the red lines as shown above.
This is simply because tsping has millisecond granularity and this link has low baselines..., assuming that is what you mean. I note when I export these the axis look less distorted...
Otherwise I agree, showing a phase of little activity is good practice to familiarise oneself with how no activity looks like on the link, but it is also not really much to discuss by itself...
This is a network behind a business plan on 4G. ISP being Telia.
They are relatively stable. Rarely does it show signs of problems. The outdoor unit supports 5G but I noticed that 4G frequencies are actually better so it's forcefully configured to stay on these.
This is our countryside house with normal usage over the course of a day, 2-3 users average, 1 young one watching youtube constantly and me and another occasionally news, youtubes ourselves.
Here's the current config:
#!/bin/bash
# *** STANDARD CONFIGURATION OPTIONS ***
### For multihomed setups, it is the responsibility of the user to ensure that the probes
### sent by this instance of cake-autorate actually travel through these interfaces.
### See ping_extra_args and ping_prefix_string
dl_if=enp1s0 # download interface
ul_if=enp2s0 # upload interface
# Set either of the below to 0 to adjust one direction only
# or alternatively set both to 0 to simply use cake-autorate to monitor a connection
adjust_dl_shaper_rate=1 # enable (1) or disable (0) actually changing the dl shaper rate
adjust_ul_shaper_rate=1 # enable (1) or disable (0) actually changing the ul shaper rate
min_dl_shaper_rate_kbps=7000 # minimum bandwidth for download (Kbit/s)
base_dl_shaper_rate_kbps=50000 # steady state bandwidth for download (Kbit/s)
max_dl_shaper_rate_kbps=100000 # maximum bandwidth for download (Kbit/s)
min_ul_shaper_rate_kbps=5000 # minimum bandwidth for upload (Kbit/s)
base_ul_shaper_rate_kbps=12500 # steady state bandwidth for upload (KBit/s)
max_ul_shaper_rate_kbps=25000 # maximum bandwidth for upload (Kbit/s)
# *** OVERRIDES ***
### See defaults.sh for additional configuration options
### that can be set in this configuration file to override the defaults.
### Place any such overrides below this line.
pinger_binary=tsping
no_pingers=2
reflectors=("213.168.18.146" "195.50.193.163")
output_processing_stats=1 # enable (1) or disable (0) output monitoring lines showing processing stats
output_load_stats=1 # enable (1) or disable (0) output monitoring lines showing achieved loads
output_reflector_stats=1 # enable (1) or disable (0) output monitoring lines showing reflector stats
output_summary_stats=1 # enable (1) or disable (0) output monitoring lines showing summary stats
output_cake_changes=1 # enable (1) or disable (0) output monitoring lines showing cake bandwidth changes
debug=1
log_DEBUG_messages_to_syslog=1
The service is rated 100/25M
I run my personal mini-DC behind this connection. Hosting my own e-mail and a few others services.
I'll try out the suggestions but yeah, for the capacity, it's not problematic. It's just me chasing the last inch out of a rather good 4G link 
Maybe you could post data showing a couple of speed tests or constant download?
Okay I didn't fully focus on those logs, I assumed it would include the entire 24h window within which we had plenty of speedtests, downloads etc.
I'll try and see that I can get some true load in there today.
Great. And maybe you could reset the log file:
/var/run/cake-autorate/primary/log_file_reset
and then run 2x speed tests, and then export:
/var/run/cake-autorate/primary/log_file_export.
By the way, you can adjust the log file settings as per:
# ** Take care with these settings to ensure you won't run into OOM issues on your router ***
# every write the cumulative write time and bytes associated with each log line are checked
# and if either exceeds the configured values below, the log file is rotated
log_to_file=1 # enable (1) or disable (0) output logging to file (/tmp/cake-autorate.log)
log_file_max_time_mins=10 # maximum time between log file rotations
log_file_max_size_KB=2000 # maximum KB (i.e. bytes/1024) worth of log lines between log file rotations
These are set conservatively given that most users will be running on a router with limited free memory space in /tmp.
And with a beefy router with sufficient non-NOR storage setting the log to 24 hours would work. However I am not sure that the octave code would gracefully deal with large logfiles (it might or it might not), but you can specify segments for plot generation...
Would you be able to summarize how? I'll also put that into the documentation.
% symbolically: octave -qf --eval 'fn_parse_autorate_log("path/to/the/log.file", "path/to/the/output/plot.format", [starttime endtime], {selected_reflector_subset})'
starttime and endtime are seconds since start of the log...
The log starts at time 0, and the code will clamp the end to min(reqiested_ endtime, real_ endtime).
Not sure where the error is coming from.
Uploaded a new log, this one under load.
Password is the same: qwerty123
EDIT: Nevermind, let me try and sort this out, that log is also weird.
Okay, this log contains the dl_high loglines, previous one didnt.
Had to use the USR1 and USR2 signals to get it to do what was needed.
Password: qwerty123
