Performance

[lynxthecat]

Hello there! I only just noticed this port. Does it work well?

I have since been working on a new bash implementation:

https://github.com/lynxthecat/sqm-autorate/tree/CAKE-autorate

Pings are ideally interleaved across reflectors to give higher resolution. So rather than just ping every 0.1s to 8.8.8.8, we can ping every 0.1s to 8.8.8.8, and ping every 0.1s to 1.1.1.1 and with time delays between the sends we get a slightly higher resolution, if this makes sense?

I'd be curious about your thoughts in terms of your implementation as compared to this new bash implementation.

[notsure2]

Hello, I wrote this port because your bash script makes too much use of subshells and awk and causes very high CPU usage especially on older or lower end routers.

My go version is basically the same as the script on your master branch except it uses only 1 reflector. I have got its CPU usage down enough (by using direct netlink calls from go without spawning processes) so that I can run the ping every 100ms using a background goroutine. It runs well for me, but at a high tick rate (100ms), I had to reduce the adjustment factor in case of spike down since it was overcompensating.

It works surprisingly well on my old Netgear R7000 running FreshTomato (with backported cake), and rides close to the max bandwidth available. However, it does not incorporate the advancements made in your CAKE-autorate branch.

I posted binaries, the ARM binary works on most routers. You can try it and let me know. I am currently using it with the following settings on my personal home router:

cake-autorate -uploadInterface $UL_IF -downloadInterface $DL_IF \
    -tickDuration 100ms \
    -loadThreshold 50 \
    -maxUploadRate $(nvram get wan${WANSUFFIX}_qos_obw) \
    -minUploadRate $(($(nvram get wan${WANSUFFIX}_qos_obw) * 80/100)) \
    -maxDownloadRate $(nvram get wan${WANSUFFIX}_qos_ibw) \
    -reflectorHost $(nvram get wan${WANSUFFIX}_reflector) \
    -ignoreLoss \
    -rateAdjustOnRttSpikeFactor 0.02 \
    -rateLoadIncreaseFactor 0.01 \
    -rateLoadDecreaseFactor 0.00125 \
    -rttIncreaseFactor 0.001 \
    -rttSpikeThresholdMs $(nvram get wan${WANSUFFIX}_rtt_spike) &

I set the spike threshold to 15ms for my DSL connection and 50ms for my 4G backup.

[notsure2]

Pings are ideally interleaved across reflectors to give higher resolution. So rather than just ping every 0.1s to 8.8.8.8, we can ping every 0.1s to 8.8.8.8, and ping every 0.1s to 1.1.1.1 and with time delays between the sends we get a slightly higher resolution, if this makes sense?

• For me the I have not faced a problem in detecting when bufferbloat happens even with just 1 reflector, but rather how much precisely to adjust the cake rate and factors.

[notsure2]

If the math behind your new implementation is better, I will definitely seek to understand and port it.

[lynxthecat]

Thanks for your responses. Sounds good. Have you set a hard minDownloadRate by the way?

I like your approach of trying to keep it super efficient and super simple.

Have you considered trying to implement a one way delay approach using ICMP type 13 and timestamps? That offers the potential to react to bufferbloat in the direction actually suffering from bufferbloat,. But it adds a lot of complexity.

Hard to say about the logic and whether the new approach in my CAKE-autorate branch is better. There are various approaches out there now (there is a LUA approach, the shell / bash approaches, and also a perl approach) and what we need is to test and see which performs better.

I presume you follow the developments on:

https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848

[notsure2]

I tried to make the LUA approach work on my Tomato router but compiling lua and the needed libs and making it work on the ancient kernel firmware gave an unstable result.

I haven't read the whole thread it's simply too long and I didn't get the time, I've been reading your code instead :-D

Have you considered trying to implement a one way delay approach using ICMP type 13 and timestamps? That offers the potential to react to bufferbloat in the direction actually suffering from bufferbloat,. But it adds a lot of complexity.

First time I hear of this, I guess I will have to research it.

I've found that most of the time I don't have issues with upload, it's much easily manageable and not as fluctuating, the normal approach I use is sufficient for it. The big difficulty is in the highly fluctuating downstream direction.

I guess I will have to devote some time to reading the thread, then.

[notsure2]

Have I set a minimum down rate ? I set the min downrate to 20 percent of the max and it's working well.

-------- Original Message -------- On 2 Mar 2022, 2:43 pm, lynxthecat wrote:

Thanks for your responses. Sounds good. Have you set a hard minDownloadRate by the way?

I like your approach of trying to keep it super efficient and super simple.

Have you considered trying to implement a one way delay approach using ICMP type 13 and timestamps? That offers the potential to react to bufferbloat in the direction actually suffering from bufferbloat,. But it adds a lot of complexity.

Hard to say about the logic and whether the new approach in my CAKE-autorate branch is better. There are various approaches out there now (there is a LUA approach, the shell / bash approaches, and also a perl approach) and what we need is to test and see which performs better.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>

[lynxthecat]

The OWD stuff may be of little benefit. I just mention it because it has received a lot of interest in that thread and it is considered a preferred way forward. But I am not sure about this because it adds a lot of complexity and my connection is like yours in that I don't care about upload variation so much. The hack to just use RTT's and punish both upload and download on bufferbloat seems to work well.

Regarding download bandwidth I would strongly urge offering an absolute setting. Percentages have caused huge frustration in different solutions (including the LUA approach).

Would you be willing to try my new bash approach in the CAKE-autorate branch? I'd be curious how it performs on your router. You can just put the .sh files inside /root/CAKE-autorate, chmod +x them, edit 'defaults.sh' as appropriate, and then run using the service file or by launching directly with ./CAKE-autorate. It does need a few packages like bash though.

[notsure2]

Regarding download bandwidth I would strongly urge offering an absolute setting. Percentages have caused huge frustration in different solutions (including the LUA approach).

I already allow that, I just said what I am using for myself personally, I calculate 20% of my line max and set that as the absolute minimum :-)

OWD approach sounds interesting and more accurate, I will follow the thread and understand how it works.

Trying your new bash script ? It's spikes the CPU on my router to 100% and it's unusable on it. I have to port it.

[lynxthecat]

I'm keen to try your port on my router. It's an RT3200. How would I do that and how do I set download bandwidth since there seems to be no argument for it?

I'm so sorry to hear that the bash script eats too many cpu cycles on your router. On mine it only uses about 2%. That's a huge difference. To me something doesn't seem right . Do you have irqbalance installed?

Could the issue be something peculiar like this:

https://unix.stackexchange.com/questions/655284/script-with-read-in-bash-while-loop-causing-high-cpu-usage-when-run-as-a-syste

So maybe the tail -f is not blocking on your router?

Would the bash implementation port well? It's my main solution at the moment and what I use on my own connection.

[notsure2]

-maxDownloadRate will set the max download rate specify it in Kbits, you can get a full help by running with -help

FreshTomato uses an extremely old 2.6.x kernel due to being encumbered by binary broadcom drivers. There's likely to be inefficiencies there. My netgear r7000 is also extremely old from 2010 and uses a poky dual core arm processor.

I will port your new script when I get some time.