Endgame Bufferbloat Results: RT-AX86U Pro + CAKE SQM (+0ms Active Latency)".

[Fonpap]

Removing this post to avoid confusion. Please refer to the updated concurrent stress test results posted below.

 

[dave14305]

What are your CAKE settings? What results did you have with QoS disabled? Just curious.

 

[S.claus]

I thought Cake capped out around 300mbps?

 

[Fonpap]

I’m running a custom JFFS script to handle CAKE SQM, fine-tuned for my 1000/500 FTTH line. Settings are optimized with a strict overhead and manual bandwidth caps to ensure that 0ms deviation.

Without QoS, the line is still fast, but the active latency spikes are noticeable (standard bufferbloat). The goal here wasn't just speed, but "Lab Perfect" consistency for competitive gaming.

I’ll share more details once I finalize some more stress tests!

 

[Fonpap]

I thought Cake capped out around 300mbps?

The secret to pushing CAKE past 500Mbps on the RT-AX86U Pro is all about CPU affinity and interrupt handling.

By manually binding the network interface interrupts to specific CPU cores, you prevent a single core from bottlenecking. When you distribute the processing load across all four cores, the router can handle the SQM overhead much more efficiently.

It’s the only way to achieve +0ms active latency and sub-1ms jitter at these speeds.

 

[Fonpap]

I’m running a custom JFFS script to handle CAKE SQM, fine-tuned for my 1000/500 FTTH line. Settings are optimized with a strict overhead and manual bandwidth caps to ensure that 0ms deviation.

Without QoS, the line is still fast, but the active latency spikes are noticeable (standard bufferbloat). The goal here wasn't just speed, but "Lab Perfect" consistency for competitive gaming.

I’ll share more details once I finalize some more stress tests!

 

[Fonpap]

What are your CAKE settings? What results did you have with QoS disabled? Just curious.

With QoS disabled at full line speed (1000/500 Mbps), I was getting a Bufferbloat Grade A, with +13ms on Download Active and +25ms on Upload Active. While those results were decent, they weren't "Lab Perfect" for my standards.

By utilizing CAKE SQM with an aggressive undershoot (550/275 Mbps) and manually balancing the interrupts across all CPU cores, I managed to lock it at +0ms/+0ms with sub-1ms jitter.

The core of the optimization is this command:

tc qdisc replace dev ppp0 root cake bandwidth 275mbit diffserv3 dual-srchost nat nowash no-ack-filter split-gso rtt 100ms noatm overhead 34 && tc qdisc replace dev ifb4ppp0 root cake bandwidth 550mbit besteffort dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100ms noatm overhead 34 && echo "f" > /proc/irq/$(grep -m1 ppp0 /proc/interrupts | cut -d: -f1)/smp_affinity

 

[Fonpap]

What are your CAKE settings? What results did you have with QoS disabled? Just curious.

You're right, sharing is the best way to keep this community great!

My physical line is 1000/500 Mbps FTTH, but for this setup, I have deliberately set CAKE to **550/275 Mbps**. I prefer "statistical perfection" over raw speed for my gaming needs.

**The Setup Details:**
* **Firmware:** Asuswrt-Merlin 3004.388.8_4 (Stable and rock solid).
* **QoS Method:** CAKE SQM via custom JFFS script.
* **CPU Optimization:** I’m using `smp_affinity` to balance the interrupt load across all 4 CPU cores. This is how I manage to push 550 Mbps with CAKE without hitting the typical 300 Mbps CPU bottleneck.
* **Settings:** `bandwidth 275mbit diffserv3 dual-srchost nat nowash no-ack-filter split-gso rtt 100ms noatm overhead 34` (and similar for download).

Without QoS, I get near-gigabit speeds, but the jitter and bufferbloat spikes make the connection feel much less "stable" during heavy use. For me, a flat line at 550 Mbps is better than a jittery one at 1000 Mbps.

 

[Tech9]

Nothing is "jittery" below line saturation. I have multiple fiber ISP lines and they will all show A+ on this test with simple bandwidth limiter below line saturation. Your "lab" test is broken, fixing non-existent issue.

 

[Fonpap]

I hear both points, and sharing these details is what makes this community great!

@dave14305 My physical line is 1000/500 Mbps FTTH, but for this "Endgame" result, I have deliberately set CAKE to 550/275 Mbps. Without QoS, I get full gigabit speeds, but the jitter and bufferbloat spikes are not worth the trade-off for my specific use case (competitive gaming).

@Tech9 I respect your point of view. Most fiber lines get an A+ with a simple limiter, but the "Lab" goal here wasn't just the grade—it was the near-zero variance (0.290ms stddev) under extreme synthetic stress.

While a basic limiter prevents saturation, it doesn't always handle micro-jitter or CPU interrupt distribution as effectively as a tuned CAKE setup with proper CPU core balancing (smp_affinity). It's definitely a "purist" approach to a non-existent issue for most, but for those of us chasing absolute consistency, this stability is the goal.

Firmware: Asuswrt-Merlin 3004.388.8_4
CAKE Settings: bandwidth 275mbit diffserv3 dual-srchost nat nowash no-ack-filter split-gso rtt 100ms noatm overhead 34

 

[dave14305]

What is the irq for your ppp0 interface? The firmware will do some smp_affinity updates on boot, so just curious how it was set before.

CAKE will still only use one core, but if it's now an idle core, that helps.

You say you use a custom jffs script. Is QoS even enabled in the firmware GUI, or do you manage it 100% in your script? Is flow cache disabled so CAKE will still see the unique individual flows?

 

[Fonpap]

Good questions, Dave. I want to be precise here:

1. **QoS Management:** I have QoS **Enabled** in the ASUS GUI, set to "Cake/Bandwidth Limiter" so the system initializes the qdisc correctly. However, my JFFS script (`firewall-start`) runs afterward to apply my specific "aggressive undershoot" values (550/275) and custom Cake arguments.
2. **Flow Cache:** This is the most important part. To make sure CAKE sees the unique individual flows as you mentioned, my script manually runs `fc disable` and `runner disable`. Without disabling hardware acceleration, the bufferbloat results wouldn't be this consistent.
3. **The ppp0 Interface:** I checked the IRQ for the ppp0 interface and used `smp_affinity` to bind it to a specific core. Moving the interrupt handling away from the core that handles the general system overhead was the final piece of the puzzle for the 0.290ms jitter.
4. **Firmware:** Running on 3004.388.8_4, which has been extremely stable for this manual approach.

It's a "hybrid" setup: GUI for the foundation, and the script for the fine-tuning and CPU balancing.