Easy CAKE rule for Home/Soho for an A+ on Bufferbloat test

Hello
I would like to implement a ‘simple’ CAKE rule at home to get an A+ on ‘https://www.waveform.com/tools/bufferbloat’. I have a 500/50 connection. Unfortunately, there are so many different approaches here, maybe someone has a simple configuration for home use :wink:
Best regards, Richard
PS: ROS 7.19.4

This one does that, and it also now explains why you might not be getting the “A+” you’re expecting, then gives alternatives. (Scroll to the end if you’ve read it before.)

Thank you! I'll try that.
Do I have to reboot after creating the queue (as mentioned in some examples)?

No, it takes effect immediately, presuming it’s correctly targeted.

@tangent

thx, Worked great :slight_smile:
However, now the entire traffic is no longer displayed under the Fasttrack rule. The Queue Simple Total counter also remains at 0, for whatever reason. Is there a possibility of a dummy rule that counts the entire traffic for me?

Then your simple queue is maybe not working?

I think so, the queue is “green”:

And here is traffic also:

But here is everything “0”:

The result of the waveform test is now perfect, so something is “happening” :wink:

Here the config:

/queue type
add kind=cake \
    name=cake-rx \
    cake-diffserv=besteffort \
    cake-flowmode=dual-dsthost \
    cake-rtt-scheme=regional \
    cake-nat=yes \
    cake-overhead-scheme=docsis
add kind=cake \
    name=cake-tx \
    cake-ack-filter=filter \
    cake-diffserv=besteffort \
    cake-flowmode=dual-srchost \
    cake-rtt-scheme=regional \
    cake-nat=yes \
    cake-overhead-scheme=docsis
    
/queue simple
add name=cake-queue \
    max-limit=490M/49M \
    queue=cake-rx/cake-tx \
    target=ether1-WAN \
    comment="CAKE SQM Magenta"

/ip/firewall/filter
add action=fasttrack-connection chain=forward \
connection-state=established,related \
comment="fasttrack LAN traffic only" \
out-interface=!ether1-WAN \
in-interface-list=LAN \
hw-offload=yes

a found it, had to set

/queue simple set “cake-queue” total-queue=default

value was “default-small”

Back to my question, can I now see the total traffic with a dummy rule somewhere?

You can see it already at the "Statistics" Tab. I don't know what else you are looking for

You should see the total, I have a simple fq_codel setup on ax2 some of the stats will only show when the queue is busy, first graph no load second loaded.

Of course, now I can see everything in the stats, sorry, I was on the line just now :wink::see_no_evil_monkey:

/queue simple set “cake-queue” total-queue=default

That's weird, but I have added a note regarding this to the article.

I thank you for diagnosing it!

I don't think a total (sum of IN and OUT) queue is necessary at all if you set only a total-queue and nothing else from the total-* namespace. But if you like the statistics - fine.

I'd want a solid reason to not do this before I'd be willing to remove that from the article. Why wouldn't the "Total Statistics" tab show a summary including what shows on "Statistics"? If that last is S and the difference between the values reported on these tabs sums to X, then the only ways we can arrive at S+X=0 are if both S=X=0 or at least one of the two is negative, neither of which is the case.

Ultimately, this feels like a workaround for an implementation bug. The default should be "default", and no fiddling should be needed to get the "Total" to be ≥ the other statistics. Elementary math, that.

@tangent

With “default” for total-queue-type, I have a lot of drops. When I create and use my own cake-default type (as shown here: some quick comments on configuring cake - #281 by kenyloveg), I no longer have any drops. How does this all work together? In particular, in the default type, the flow mode (since it is not defined) is set to triple isolate, and in the rx/tx types, it is set to dualdsthost/dualsrchost.

I'm not certain what you mean by that, but if I am interpreting it correctly, these "drops" under load are intended and desirable. They are how the algorithm shortens the feedback loop in signaling buffer exhaustion to the remote peer. A less derisive term than "bufferbloat" is "excessive feedback loop delay".

Ah OK, i understand :+1:

fwiw, there is a typo: place=before=0 instead of place-before=0

One more question about the CAKE queue. The graph clearly shows when CAKE was activated. I measure at regular intervals with Speedtest CLI. Before and after that, I have consistent measurements. During the test phase when CAKE was active, the values fluctuated extremely. Is that normal?

green: download, yellow: upload, blue: ping

Please add a legend for green, blue and yellow line. thx.