[BUG Report] CAKE QoS - Upload shaping not working on RT-BE88U

[bgf]

Hello everyone, and a huge thank you to RMerlin for the incredible work on this firmware.

I'm writing to report a potential bug related to the CAKE QoS implementation on my new ASUS RT-BE88U router.

My Setup:

• Router: ASUS RT-BE88U
• Firmware: Asuswrt-Merlin 3006.102.5
• Connection: FTTH (Fiber to the Home)
• Protocol: PPPoE with VLAN ID 100
• Tested Speeds: ~2086 Mbps Download / ~1027 Mbps Upload

The Issue:

My goal was to eliminate bufferbloat for competitive gaming. I configured QoS with the following settings:

• QoS Type: CAKE
• Preset: piece_of_cake.qos
• Download Bandwidth: 1980 Mbps (approx. 95% of tested speed)
• Upload Bandwidth: Started at 970 Mbps and progressively lowered.
• Link Layer Adaptation: Ethernet with VLAN
• Overhead: 44
• MPU: 64
• Mode: normal

The download shaping works perfectly. With the limit set to 1980 Mbps, the Waveform Bufferbloat test consistently shows an "active download" latency of just +1ms to +4ms.

However, the upload shaping does not seem to work at all.No matter what value I set for the upload bandwidth limit, the "active upload" latency remains high, consistently between +20ms and +24ms.

Troubleshooting Steps Taken:

To diagnose the issue, I performed the following steps, all of which failed to resolve the upload bufferbloat:

1. Drastic Bandwidth Reduction: I lowered the upload bandwidth limit to an extremely low value of 500 Mbps. Even with this drastic limit, the active upload latency remained at +23ms, proving that the shaper was not engaging.
2. Disabled Hardware Acceleration: Suspecting a conflict, I connected via SSH and manually disabled all forms of hardware acceleration using the following commands, followed by a full reboot:
   
   nvram set ctf_disable=1
3. nvram set runner_disable=1
4. nvram commit reboot
   Even with CTF and Flow Acceleration disabled, the test result for upload latency was identical (+23ms). This suggests the issue is not a conflict with hardware offloading.

Successful Workaround & Conclusion:

As a final test, I disabled CAKE and enabled ASUS's native Adaptive QoS in "automatic" mode. With this configuration, the bufferbloat is completely eliminated. The Waveform test reports a perfect result of +1ms active download and +2ms active upload.

This confirms two things:

1. The FTTH line itself can be shaped correctly.
2. The underlying hardware of the BE88U is capable of managing the traffic.

The evidence strongly suggests that there is a bug specifically within the CAKE implementation (or its interaction with the network drivers/kernel) for the RT-BE88U platform in the current version of the firmware, which prevents it from correctly shaping upload traffic.

I hope this detailed report is helpful for diagnostics. I'm happy to provide any further information or run additional tests if needed.

Thank you again for all your hard work!

Best regards.

 

[dave14305]

This sounds like AI trolling. There are references to SQM-Scripts terms (piece_of_cake.qos). It's not likely any Asus router will shape traffic at 970 Mbps using CAKE, let alone 1980 Mbps. The CPU cannot handle it.

Turn CAKE back on and reboot. It should automatically disable hardware acceleration (confirm with fc status command). Then post the results of:

tc -s qdisc

EDIT: run this command before AND after a speedtest. Post both output results.

 

[RMerlin]

Cake cannot handle above ~400 Mbps on even the fastest Asus router currently available.

Also, Adaptive QoS currently doesn't do anything on any Wifi 7 device, it's still broken with no fix in sight from TrendMicro/Asus.

 

[bgf]

Hi,

Thank you for the direct and incredibly helpful clarification!

That explains everything perfectly. I was not aware of the 400 Mbps CPU limitation for CAKE on this hardware, nor that Adaptive QoS is currently non-functional on the Wi-Fi 7 platform.

This information is invaluable, as it saves me from any further attempts to debug what is essentially a hardware limitation. I will stop trying to get CAKE to work at gigabit speeds.

Based on this, I will now experiment with Traditional QoS using FQ CODEL, which seems like the most realistic and appropriate approach for my goal.

Thanks again for clearing this up and for all your work on the firmware.

Best regards.

 

[dave14305]

Based on this, I will now experiment with Traditional QoS using FQ CODEL, which seems like the most realistic and appropriate approach for my goal

Sadly, it has the same limitations as CAKE being cpu-bound.