What's new

CakeQOS CakeQOS-Merlin

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Too complicated!


Your ISP may be DOCSIS yet your router is ethernet. Ethernet always works...

Morris
@Morris....this is interesting....I have the same setup, comcast (docsis) and router is ethernet. You recommend using ethernet over docsis? I haven't tested at all using ethernet yet but I'm interested in trying now. Thanks!
 
@Morris....this is interesting....I have the same setup, comcast (docsis) and router is ethernet. You recommend using ethernet over docsis? I haven't tested at all using ethernet yet but I'm interested in trying now. Thanks!

I'm on FIOS which is ethernet like. When you specify docsis rather than ethernet, a few milliseconds are added to the packet transport time due to the extra bytes used for encapsulation. The transport time for a packet is just a math formula that include packet size, framing overhead, interpacket gap and speed. If you remove docsis and default to ethernet you may need to specify different speeds yet when tuned the results will be the same.

What everyone forgets is we are all dealing with hybrid networks where the ISP backbone may be different than there distribution and our networks are all ethernet, wireless and in some cases moca. What cake is dong is preventing an overloaded queue at the interfaces of our router an also can be used to prevent that upstream till our traffic merges with that of others. Cake dose the same as the teacher telling us to line up for a fire drill and walk in an orderly manner rather than everyone running for the door and some getting pushed out of the way. It is an incredibly cleaver solution.
 
I fully agree with @Morris above. In my network the pinch point is my ISP router and the xDSL link. My RT-AX88U is running cake and whilst it has gigabit connectivity to the ISP router, cake is configured at the pinch point bandwidth so that queues never build in the ISP router causing bufferbloat.

EDIT: I suspect that those posters who report good results with unlimited bandwidth are running cake on their actual pinch point device and therefore Cake is directly managing the queues which would cause the bufferbloat.

I also agree that my actual throughput with cake never quite hits the configured maximums when running tests, but I suspect it's they way it distributes the available capacity and that I never actually achieve a single connection through my router for the speed test - there's always something else chattering even if it's other connections from the PC running the test. What is clear however is that net result provides a great experience on my network.

I read this paper last night and they have a good explanation of the bandwidth shaping options with graphs.

Yes this is where I read that you can configure safely within 0.1% of actuals and get great performance. I can't measure my actuals this accurately anyway.
1) Overhead and Framing Compensation: As mentioned in Section II-A above, the shaper accounts for the actual size of a packet on the wire, including any encapsulation and overhead, which allows the rate to be set closer to the actual bottleneck bandwidth, thus eliminating waste. We believe it is safe to set a rate within 0.1% of the actual link rate when the overhead compensation is configured correctly, with a margin mainly required to accommodate slight variations in the actual bottleneck link bandwidth, caused by, e.g., clock drift in the hardware.
 
Can anyone confirm if GT-AC2900 using kernel 4.x? Cake compatibility future for GT-AC2900 as 386.1 beta is already supported by eric
 
Can anyone confirm if GT-AC2900 using kernel 4.x? Cake compatibility future for GT-AC2900 as 386.1 beta is already supported by eric

Same kernel as the RT-AC86U (4.1.27). Same kernel options as well, so any generic Linux module compiled for the RT-AC86U should work on a GT-AC2900.
 
Installed CakeQoS today on my AX-58U and I noticed the following error if I Start/Stop/Uninstall CakeQoS.

Code:
CakeQOS-Merlin: Stopping
/opt/bin/cake-qos: line 745: runner: not found
Broadcom Packet Flow Cache learning via BLOG enabled.
CakeQOS-Merlin: Starting - ( 69Mbit | 29Mbit | besteffort | docsis nowash regional | docsis ack-filter regional )
Broadcom Packet Flow Cache learning via BLOG disabled.
Broadcom Packet Flow Cache flushing the flows

#########################################################


[*] Press Enter To Continue...
This should be solved in beta2.
 
@dave14305 I have been following the reboot/crash issue with the 58U in the 386 beta thread that merlin has traced to a missing userspace tool in the 58U build.

The issue with cake-qos / runner on 58U is with the 384.19 FW so does this mean that the user space tool for runner is also missing from 384.19?
 
@dave14305 I have been following the reboot/crash issue with the 58U in the 386 beta thread that merlin has traced to a missing userspace tool in the 58U build.

The issue with cake-qos / runner on 58U is with the 384.19 FW so does this mean that the user space tool for runner is also missing from 384.19?
I may have jumped the gun. The latest commit fixes fc missing, not runner. /bin/runner is a small shell script. Does it exist on your router?
 
i'm not sure. I have this issue logged on on the cake-qos github site.

Latest is the following: RMerlin: The bcm675x does not use runner, that's for the bcm490x.
 
but this quote is a copy/paste so not sure what merlin/eric has actually said.

I know that runner shows in the 58U GUI (in the tools page)
 
I also agree that my actual throughput with cake never quite hits the configured maximums when running tests, but I suspect it's they way it distributes the available capacity and that I never actually achieve a single connection through my router for the speed test - there's always something else chattering even if it's other connections from the PC running the test. What is clear however is that net result provides a great experience on my network.
That's why you never use the value that is reported by the speed test. Watch the traffic graph in your router and look for the flat maximum point that is achieved during the speed test and use that value instead. The router's traffic graph will include all traffic from all devices using the router.
 
I may have jumped the gun. The latest commit fixes fc missing, not runner. /bin/runner is a small shell script. Does it exist on your router?

No runner in /bin, but there is /bin/fcctl with this output if it helps.

Code:
Flow Cache Control Utility:

Proc FileSystem: /proc/fcache

::: Usage:

:::::: Flow Cache SW System :
       fc status
       fc enable
       fc disable
       fc flush
                      [ --hw ]
              - Flush all flows matching any combination of:
                      [ --if   <interface> ]
                    | [ --flow <flowid>    ]
                    | [ <--mac | --dstmac | --srcmac> <macaddr> ]
       fc resetstats
       fc flwstats <cmd>
           fc flwstats n <field> <value> [<field> <value> ]
              - Create new query where <field> is one of the following:
                 srcv4, rxdstv4, dstv4, srcv6, dstv6, srcport, dstport,
                 srcipver, dstipver, proto, invid, outvid,
                 dstmac, srcmac, inrxdstmac(l2gre), inrxsrcmac(l2gre),
                 intxdstmac(l2gre), intxsrcmac(l2gre), srcphy, dstphy
           fc flwstats g <id>  - Get results for query <id>.
           fc flwstats d <id>  - Delete query <id>.
           fc flwstats c <id>  - Clear counters on query <id>.
           fc flwstats p       - Print out all active queries.
       fc config
                      [ --defer          <rate>      ]
                    | [ --sw-defer       <pkts>      ]
                    | [ --low-pkt-rate   <rate>      ]
                    | [ --monitor        <0|1>       ]
                    | [ --accel-mode     <0|1>       ]
                    | [ --hw-accel       <0|1>       ]
                    | [ --tcp-ack-mflows <0|1>       ]
                    | [ --timer          <ms>        ]
                    | [ --mcast          <0|1|2|3>   ]
                    | [ --mcast-learn    <0|1|2> 0-disabled,1-enabled,2-enabled only for 1st flow ]
                    | [ --ipv6           <0|1>       ]
                    | [ --4o6-frag       <0|1>       ]
                    | [ --gre            <0|1>       ]
                    | [ --l2tp           <0|1>       ]
       fc dump [ --flow <flowid> ]
 
No runner in /bin, but there is /bin/fcctl with this output if it helps.

Code:
Flow Cache Control Utility:

Proc FileSystem: /proc/fcache

::: Usage:

:::::: Flow Cache SW System :
       fc status
       fc enable
       fc disable
       fc flush
                      [ --hw ]
              - Flush all flows matching any combination of:
                      [ --if   <interface> ]
                    | [ --flow <flowid>    ]
                    | [ <--mac | --dstmac | --srcmac> <macaddr> ]
       fc resetstats
       fc flwstats <cmd>
           fc flwstats n <field> <value> [<field> <value> ]
              - Create new query where <field> is one of the following:
                 srcv4, rxdstv4, dstv4, srcv6, dstv6, srcport, dstport,
                 srcipver, dstipver, proto, invid, outvid,
                 dstmac, srcmac, inrxdstmac(l2gre), inrxsrcmac(l2gre),
                 intxdstmac(l2gre), intxsrcmac(l2gre), srcphy, dstphy
           fc flwstats g <id>  - Get results for query <id>.
           fc flwstats d <id>  - Delete query <id>.
           fc flwstats c <id>  - Clear counters on query <id>.
           fc flwstats p       - Print out all active queries.
       fc config
                      [ --defer          <rate>      ]
                    | [ --sw-defer       <pkts>      ]
                    | [ --low-pkt-rate   <rate>      ]
                    | [ --monitor        <0|1>       ]
                    | [ --accel-mode     <0|1>       ]
                    | [ --hw-accel       <0|1>       ]
                    | [ --tcp-ack-mflows <0|1>       ]
                    | [ --timer          <ms>        ]
                    | [ --mcast          <0|1|2|3>   ]
                    | [ --mcast-learn    <0|1|2> 0-disabled,1-enabled,2-enabled only for 1st flow ]
                    | [ --ipv6           <0|1>       ]
                    | [ --4o6-frag       <0|1>       ]
                    | [ --gre            <0|1>       ]
                    | [ --l2tp           <0|1>       ]
       fc dump [ --flow <flowid> ]
thanks for the help. The cake script is working fine to enable/disable flow cache HW acceleration.

I think the issue is that the script also tried to disable runner (but there is no runner HW acceleration on the AX58U
 


Might be a good idea to have this pinned in the OP somewhere, or even linked in github.
 
What makes the aarch64 build for AX86U different from the other aarch64 builds? Is it because they are kernel modules they must be compiled individually? Wanting to learn more...

EDIT: It looks like there are minor differences in the kernel versions (4.1.27, 4.1.51, 4.1.52).
 
Last edited:
What makes the aarch64 build for AX86U different from the other aarch64 builds? Is it because they are kernel modules they must be compiled individually? Wanting to learn more...

EDIT: It looks like there are minor differences in the kernel versions (4.1.27, 4.1.51, 4.1.52).

Right now on my firmware there are three separate kernels:

RT-AC86U, GT-AC2900 (BCM4906)
RT-AX88U, RT-AX86U (BCM4908)
RT-AX56U, RT-AX58U (BCM675x)

These are all compiled from separate source trees, with different options, so modules are unlikely to be compatible between the three (at best you will get magic symbol mismatches).
 
What is the relationship between the RTT commands and buffer bloat? I've experimented with different values and setting the RTT to a lower value negatively impacts the bandwidth.

Somebody suggested the RTT should be set to match the first hop ping to my ISP:

traceroute to virginmedia.com (213.105.9.24), 30 hops max, 38 byte packets
1 10.53.35.89 (10.53.35.89) 8.958 ms 11.531 ms 10.845 ms
2 croy-core-2a-xe-700-0.network.virginmedia.net (62.252.14.33) 9.940 ms 12.8

This reduces my download speed from 380Mbps to 216Mbps. This online test claims that my result is A+, but the buffer bloat is 280ms?

image_2020-12-08_131627.png

image_2020-12-08_132206.png

Are there any benefits to reducing the RTT in Cake QoS?

No matter what settings I'm trying, I still seem to be suffering from some buffer bloat and some quite large spikes in buffer bloat - e.g. jumps from 6ms to 300 ms during the test.

My main reason for wanting a working QoS solution is online gaming. I'm after a low and stable ping with no discernible spikes - i.e. I see on my screen, what is actually happening in the game. It is also important that when I click fire, the other person dies. I'm willing to sacrifice a bit of bandwidth to achieve this, but I'm struggling to see any improvements.
 

Attachments

  • image_2020-12-08_131851.png
    image_2020-12-08_131851.png
    16.6 KB · Views: 139
Are there any benefits to reducing the RTT in Cake QoS?
I might be off the mark, but from what I understand, setting the RTT lower will mean that Cake can clamp down on packets faster when you are hitting your bandwidth limit. It allows it to act faster as it is expecting the packet acks much sooner.

I also believe that you need to set the RTT to a value that is somewhere around the average ping to the Internet services you are accessing, not the first hop. The packet round trip is measured out to the destination, not your first hop, so in order to guesstimate when to expect replies for your traffic, the round total round trip must be accounted for.

Reading the docs seems to suggest that cake self tunes the RTT pretty well, so getting it in the balllpark is good enough. The default value of 100ms should be fine for most cases. You may consider "Regional" (30ms) if you are mostly accessing local game or streaming servers or something like that. I wouldn't go any lower unless you had very good reason to though.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top