That branch incorporates a significant restructuring of cake-autorate to, amongst other things, improve inter process communication by employing FIFOs for passing not only data, but also commands, between the major processes, obviating the previous costly reliance on temporary files. This should give a significant performance increase (and indeed I see significantly reduced CPU load on my RT3200, albeit that is far more powerful than I need with my sub 100Mbit/s connection).
To test, and assuming you are already running the code from the 'master' branch, just replace:
'cake-autorate.sh';
'cake-autorate_lib.sh'; and
'cake-autorate_defaults.sh',
(leaving everything else the same).
There could be minor glitches still needing ironed out (this code now has more than 2000 lines after all, and the correctness options are set aggressively, e.g. to exit just on an attempt to access an unset variable). In any case, this new code will eventually get pushed to 'master' sometime soon anyway.
By the way, having worked with Japanese clients a lot from my time in Munich, I find it very difficult or impossible to believe any infrastructure in the UK can compare favourably. Many parts of the UK feel terribly worn out and tired nowadays. Great Britain lost its way and needs to find its feet again.
new log, with the new .sh files from the restructure branch password: dong
The modem... if i can call it that is a GE-ONU im unsure of the thumbtac? inside it but aside from that you are required to have another router to get an ipv6 that doesn't work properly even if you have purchased the ipv6 additional line atttached to your ppoe connection.... japan is going through an ipv6 restructuring so im unsure if its related to that, either way my connection when i was in the US was not fast but way more consistent and stable with almost no ping spikes near 100ms and packet loss was unheard of (i think its because of the lack of ipv4 in asia)
I'll take a look tomorrow as it's late now. You can also try plotting using the octave plotter to upload timecourse (most important). That works for me using windows virtual machine for Ubuntu but I'm just had to increase the virtual memory page file since that is super memory hungry.
@moeller0 while using octave v 8.1.0 i have been getting errors (im using the recommended windows version according to octave, i had to remove the .- and .+ and switch it to regular old - and + to remove some errors i was getting earlier but im completely stumped as idk what im doing)
>> fn_parse_autorate_log
INFO: C:\Users
INFO: Parsing log file: C:\Users\cake-autorate.primary_2023_04_10_22_48_51.log
INFO: might take a while...
INFO: Processed line: 1000
INFO: Processed line: 2000
INFO: Processed line: 3000
INFO: Processed line: 4000
INFO: Processed line: 5000
INFO: Processed line: 6000
INFO: Processed line: 7000
INFO: Processed line: 8000
INFO: Processed line: 9000
INFO: Processed line: 10000
INFO: Saving parsed data fie as: C:\Users\cake-autorate.primary_2023_04_10_22_48_51.log.mat
INFO: Empty x_range_sec specified, plotting the whole sample timestamp range (0 - 425.309).
Selected DATA sample indices: 1 8410
Selected LOAD sample indices: 1 2095
INFO: Adjusted y-limits based on ADJ_DELAY_THR_factor: -50046 50046
INFO: Grand adjusted y-limits based on OWD_DELTA_QUANTILE_factor and ADJ_DELAY_THR_factor: -50046 50046
INFO: Writing plot as: C:\Users\cake-autorate.primary_2023_04_10_22_48_51.log.rawCDFs.pdf
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(invalid width=19863 or height=14825 or depth=1)
Mesa: User error: GL_INVALID_VALUE in glRenderbufferStorage(invalid width 19863)
INFO: Writing plot as: C:\Users\cake-autorate.primary_2023_04_10_22_48_51.log.deltaCDFs.pdf
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(invalid width=19863 or height=14825 or depth=1)
Mesa: User error: GL_INVALID_VALUE in glRenderbufferStorage(invalid width 19863)
Samples per reflector:
ReflectorID: 1.0.0.1; N: 1060
ReflectorID: 156.154.71.3; N: 1061
ReflectorID: 156.154.71.4; N: 1060
ReflectorID: 185.228.168.9; N: 1062
ReflectorID: 208.67.222.2; N: 1062
ReflectorID: 94.140.14.15; N: 1060
DL: maximum 95.000%-ile delta delay over all 6 reflectors: 3.195 ms.
DL: maximum 99.000%-ile delta delay over all 6 reflectors: 3.425 ms.
DL: maximum 99.500%-ile delta delay over all 6 reflectors: 3.495 ms.
DL: maximum 99.900%-ile delta delay over all 6 reflectors: 6.005 ms.
DL: maximum 99.950%-ile delta delay over all 6 reflectors: 10.510 ms.
DL: maximum 99.990%-ile delta delay over all 6 reflectors: 10.510 ms.
DL: maximum 99.999%-ile delta delay over all 6 reflectors: 10.510 ms.
UL: maximum 95.000%-ile delta delay over all 6 reflectors: 3.195 ms.
UL: maximum 99.000%-ile delta delay over all 6 reflectors: 3.425 ms.
UL: maximum 99.500%-ile delta delay over all 6 reflectors: 3.495 ms.
UL: maximum 99.900%-ile delta delay over all 6 reflectors: 6.005 ms.
UL: maximum 99.950%-ile delta delay over all 6 reflectors: 10.510 ms.
UL: maximum 99.990%-ile delta delay over all 6 reflectors: 10.510 ms.
UL: maximum 99.999%-ile delta delay over all 6 reflectors: 10.510 ms.
INFO: Writing plot as: C:\Users\cake-autorate.primary_2023_04_10_22_48_51.log.timecourse.pdf
Failed to parse XML contents
letter is expected
Error: /undefinedfilename in (C:\\Users\\i\\AppData\\Local\\Temp\\oct-BRd23M)
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
--nostringval-- --nostringval-- false 1 %stopped_push
Dictionary stack:
--dict:733/1123(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.50: Unrecoverable error, exit code 1
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(invalid width=19863 or height=14825 or depth=1)
Mesa: User error: GL_INVALID_VALUE in glRenderbufferStorage(invalid width 19863)
warning: print: No such file or directory, 'C:\Users\i\AppData\Local\Temp\oct-BRd23M'
warning: called from
print at line 814 column 9
fn_parse_autorate_log>write_out_figure at line 1346 column 3
fn_parse_autorate_log at line 705 column 4
INFO: fn_parse_autorate_log took: 43.144 seconds.
>> error: gl2ps_renderer::draw: internal pipe error
error: called from
__opengl_print__ at line 207 column 7
print at line 786 column 16
fn_parse_autorate_log>write_out_figure at line 1346 column 3
fn_parse_autorate_log at line 705 column 4
>> error: gl2ps_renderer::draw: internal pipe error
error: called from
__opengl_print__ at line 207 column 7
print at line 786 column 16
fn_parse_autorate_log>write_out_figure at line 1346 column 3
fn_parse_autorate_log at line 705 column 4
>>
@Clap I'll upload the graphics on this post today. The plotting tool is a little fickle but @moeller0's the author so hopefully he can help. I run octave from Ubuntu 22.02 on Windows (which can be installed via the store). That seems to work just fine, but I had to increase the page file.
I do not have windows available so this is hard for me to test/debug...
However, this looks like something you might be able to change?
Yes, that is a change that octave7 already announces, thanks for testing that!
That is going to be tricky, as this is both an OS and an octave version I do not have available
EDIT: I will update octave to 8.1.0 soon and see what I will get in regards to the plotting code
Side-note: octave is really not a platform that is all that enjoyable... yes, it is mostly compatible with matlab, but boy does it still have rough edges...
P.S.: Regarding the timecourse, there were no latency-triggered rate reductions, so at least for that test period the delay thresholds appear a bit on the high side, but I guess these would need to be tailored to the low-rate/high delay epochs
Oh that's @Clap's timecourse? You beat me to it. Looks OK actually? That's cool. I'm not sure if we've seen cake-autorate deal with such high bandwidths before.
But I'm curious what you are using to apply cake and run cake-autorate?
I used to use Matlab as part of a signal processing group during a work placement as an engineering student including separating signals using a form of independent component analysis. I wrote some C programs to run using its mex functionality for it to speed up computation for certain signal processing routines. Have you ever played with that?
Looks like it got pretty close though - I can see why cake-autorate is needed here because we see a latency spike associated with the bandwidth increase not dissimilar to what I'm familiar with on 4G connection:
I'm going to need to get a log over the weekends as thats when latency goes out the door but im pretty sure this is due to the isp not able to handle as many customers as it has.
The cake-autorate instance is running on a pi4 oc to 1800~
yes that GE-ONU is what the "fiber" line is connected to, but it has to be connected to a router(Aterm WX3600HP which is then providing connection to a pi) the router doesn't allow any type of functional bridging even when its in bridge mode, it also has no DMZ so i cant actually....... "properly shape" the connection.
it would also appear that I didn't properly use the new restructure branch until now, and the log file appears to not exist anymore.
@moeller0 octave 7.3.0 seems to work perfectly fine, the issue appears to be with the new 8.1.0
Yes, I am now facing exactly the same issue with my updated octave 8.1; not sure how to tackle this...
WORK-AROUND: this seems to affect saving as vector formats like pdf and .ps, .eps, .svg, saving as bitmap format like .png or .tif seems to work... this is something octave will need to fix.
Do you mean you are using the new restructure code and not seeing a log file? I see both and exports work OK.
I believe this should be fast enough, right @moeller0? The processing of cake-autorate will be similar for a faster connection with the same settings. The shaper requirements will be greater, but I thought RPi4 could handle 1Gbit/s shaping.
A raspberry pi4B should be good for traffic shaping up to 1 Gbps (more is hard to test as it is limited to gigabit ethernet). However one needs a second ethernet interface, either via dfrobot's nifty router board or via a usb3 dongle, as router-on-a-stick will not allow the aggregate rates required for that fiber link.
Thanks. Well @Clap I'm super interested in your use case because it's not often that we see cake-autorate in use for such high bandwidths. With your testing we can help optimize and I can also work further on this new restructure branch to make sure all is well. I've run it myself for a few days without issue, but there could well be one or two minor bugs - it was a huge rewrite of major parts.
So far i've been using the cake autorate to mitigate packet loss as it appears to help with that somehow.
I'm also attempting to see if there is any physical noticeable difference in latency.
(as far as im currently aware with cake autorate when I get it to function as intended has lowered packet loss and seems to make some inputs delayed in some games.... but what you see is what you get. without cake autorate, what you see isn't sync'd with server, and can cause micro jitters and weird deltas.)
normal sqm w/cake seem to make input delays and sync wack even if its barely noticeable the input delays are usually a tell compared to relative angle your model appears to be looking at in a client vs in a server im assuming due to the buffering.
I have managed to get the refactored code to work as intended by overwriting the file again openwrt is..... odd and im highly incompetent, so it doesn't mix well...
So i'm not entirely sure if cake-autorate is actually functioning but here are my recent results.
dl_if=ifb4eth1 # download interface
ul_if=eth1 # 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=8000 # minimum bandwidth for download (Kbit/s)
base_dl_shaper_rate_kbps=12000 # steady state bandwidth for download (Kbit/s)
max_dl_shaper_rate_kbps=1200000 # maximum bandwidth for download (Kbit/s)
min_ul_shaper_rate_kbps=8000 # minimum bandwidth for upload (Kbit/s)
base_ul_shaper_rate_kbps=12000 # steady state bandwidth for upload (KBit/s)
max_ul_shaper_rate_kbps=1200000 # maximum bandwidth for upload (Kbit/s)
with both the download and upload delay set to 25ms ~
The real challenge is during peak load times as.... it will slow down to 128kbps especially on my Saturdays.
Could you please share the log file for that run? It doesn't look right because you set base to 12Mbit/s but the rates there are cruising along at 1200Mbit/s. Also it is more meaningful to share logs involving heavy download and/or upload. You can use this script here:
Which requires netperf package, to give say 120s download and then upload. Not sure which netperf test server is best for JP.
Something went wrong with ping. My recommendation, do not run the throuput/bufferbloat test from the router but from a computer on your internal LAN....
So your latency thresholds are way too high for the link condition you are testing (25ms per direction).
But also the *_OWD_DELTA_EWMA_US probably should be dropped from the plots, as far as I can tell we are not using them? @Lynx, if we are not using them at all (like there is no option to use them) maybe we should stop actually calculating and log them? (Changing the plotting is easy, but if you see value in these it would feel awkward for me to remove them from the plots unilaterally).
We are using these - reflectors are dropped from the active list if the delta ewma exceeds the minimum by a default delta of 10ms or if the baseline exceeds the minimum by 10ms.
.
