CakeQOS CakeQoS-Merlin v2.1.1

[Lynx]

Surely cake can be updated on Asus Merlin? @dave14305 is this something that can be reasonably expected?

But @privacyguy123, I think the issue here is bigger than cake not distinguishing the individual encrypted flows from each other (yes, separate cars). If you're still seeing bloat at 20Mbit/s something else is going on.

What is your VPN provider? I used to use NordVPN and regularly had to change to a different server reporting low load (using their API) to keep on top of latency and bandwidth. In the end I gave up with using NordVPN and rather than try a different VPN just abandoned use of a VPN altogether.

If you disable VPN altogether do you see no bufferbloat with cake set at 20Mbit/s?

 

[Morris]

In the end I gave up with using NordVPN and rather than try a different VPN just abandoned use of a

Bingo!

 

[privacyguy123]

Surely cake can be updated on Asus Merlin? @dave14305 is this something that can be reasonably expected?

But @privacyguy123, I think the issue here is bigger than cake not distinguishing the individual encrypted flows from each other (yes, separate cars). If you're still seeing bloat at 20Mbit/s something else is going on.

What is your VPN provider? I used to use NordVPN and regularly had to change to a different server reporting low load (using their API) to keep on top of latency and bandwidth. In the end I gave up with using NordVPN and rather than try a different VPN just abandoned use of a VPN altogether.

If you disable VPN altogether do you see no bufferbloat with cake set at 20Mbit/s?

If indeed Cake isn't up to date and not working correctly then the settings set at 2Mb 20Mb or 200Mb would be irrelevant - it isn't working. Hoping for an update - seems to be at kernel level which means a firmware update from @RMerlin right? Because I can't build Cake from the git source because kernel headers are missing on the router and that part of the firmware is read-only anyway ...

Ditching a VPN is not an option, ping to their servers is 20ms - bloat is happening under load locally. E.g. when Sky Boxes kick in streaming downstairs or downloading TV shows on the pre record list ... turning it off is not some magical fix for MY use case. Was hoping for QoS+VPN which is what we should have with the latest Cake, no?

 

[Morris]

If indeed Cake isn't up to date and not working correctly then the settings set at 2Mb 20Mb or 200Mb would be irrelevant - it isn't working. Hoping for an update - seems to be at kernel level which means a firmware update from @RMerlin right? Because I can't build Cake from the git source because kernel headers are missing on the router and that part of the firmware is read-only anyway ...

Ditching a VPN is not an option, ping to their servers is 20ms - bloat is happening under load locally. E.g. when Sky Boxes kick in streaming downstairs or downloading TV shows on the pre record list ... turning it off is not some magical fix for MY use case. Was hoping for QoS+VPN which is what we should have with the latest Cake, no?

I do not believe that Merlin can change the kernel

 

[privacyguy123]

I do not believe that Merlin can change the kernel

It's just a kernel module that needs built and placed into the firmware. It's already there so it can be done, it's just the wrong/old version without the WireGuard patch apparently ...

Right there:

find / | grep cake

/lib/modules/4.1.52/kernel/net/sched/sch_cake
/lib/modules/4.1.52/kernel/net/sched/sch_cake/sch_cake.ko
/sys/module/sch_cake
/sys/module/sch_cake/notes
/sys/module/sch_cake/notes/.note.gnu.build-id
/sys/module/sch_cake/taint
/sys/module/sch_cake/initstate
/sys/module/sch_cake/coresize
/sys/module/sch_cake/sections
/sys/module/sch_cake/sections/.bss
/sys/module/sch_cake/sections/.init.text
/sys/module/sch_cake/sections/.ARM.exidx.exit.text
/sys/module/sch_cake/sections/.text
/sys/module/sch_cake/sections/.ARM.exidx.init.text
/sys/module/sch_cake/sections/.alt.smp.init
/sys/module/sch_cake/sections/.ARM.exidx
/sys/module/sch_cake/sections/.rodata
/sys/module/sch_cake/sections/.strtab
/sys/module/sch_cake/sections/.symtab
/sys/module/sch_cake/sections/.gnu.linkonce.this_module
/sys/module/sch_cake/sections/.rodata.str1.4
/sys/module/sch_cake/sections/.note.gnu.build-id
/sys/module/sch_cake/sections/.exit.text
/sys/module/sch_cake/sections/.data..read_mostly
/sys/module/sch_cake/refcnt
/sys/module/sch_cake/uevent
/sys/module/sch_cake/holders
/sys/module/sch_cake/initsize

 

[dave14305]

Surely cake can be updated on Asus Merlin? @dave14305 is this something that can be reasonably expected?

The enhancement was never backported to 4.19 (used in HND5.04 models), and definitely not backported to the original Dave Taht out-of-tree version used on the earlier HND models running 4.1.27. At a glance, the first LTS kernel I see it show up in is 5.10.

 

[privacyguy123]

@Lynx

Tbh I see more issues here (judging by posts on OpenWRT forum). There's another patch within WireGuard that would need to exist also, as far as I see WireGuard is also out of date.

cat /sys/module/wireguard/version
1.0.20210124

Latest looking like:

1.0.20210914

 

[privacyguy123]

The enhancement was never backported to 4.19 (used in HND5.04 models), and definitely not backported to the original Dave Taht out-of-tree version used on the earlier HND models running 4.1.27. At a glance, the first LTS kernel I see it show up in is 5.10.

RMerlin confirms the code from Github is already in the firmware - why would this patch not be present if that's the case?

 

[Lynx]

If indeed Cake isn't up to date and not working correctly then the settings set at 2Mb 20Mb or 200Mb would be irrelevant - it isn't working. Hoping for an update - seems to be at kernel level which means a firmware update from @RMerlin right? Because I can't build Cake from the git source because kernel headers are missing on the router and that part of the firmware is read-only anyway ...

I think we should take a step back for a second though. Updating cake and/or WireGuard in Asus Merlin would only help allow cake to distinguish between encrypted flows, and I'm dubious that is going to help in your position given what you have reported earlier.

To be clear, if you set cake to 10Mbit/s with the existing cake implementation in Asus Merlin and you are still seeing bufferbloat and/or an unsatisfactory connection, then updating cake and/or WireGuard to help cake distinguish between the encrypted flows is not going to help. That is because the problem is then not related to cake not being able to distinguish between the encrypted flows; the problem is rather something else, e.g. that the VPN server is overloaded and giving inconsistent latency and bandwidth, which is the reason I ultimately decided to abandon use of NordVPN. If you want a more consistent experience, a better option might be to rent a VPS and host your own WireGuard VPN on that.

I really think you should check whether cake at 10Mbit/s provides a satisfactory connection with and without using a VPN, and perhaps you could provide some simple test results using: https://www.waveform.com/tools/bufferbloat to confirm.

 

[privacyguy123]

I think we should take a step back for a second though. Updating cake and/or WireGuard in Asus Merlin would only help allow cake to distinguish between encrypted flows, and I'm dubious that is going to help in your position given what you have reported earlier.

To be clear, if you set cake to 10Mbit/s with the existing cake implementation in Asus Merlin and you are still seeing bufferbloat and/or an unsatisfactory connection, then updating cake and/or WireGuard to help cake distinguish between the encrypted flows is not going to help. That is because the problem is then not related to cake not being able to distinguish between the encrypted flows; the problem is rather something else, e.g. that the VPN server is overloaded and giving inconsistent latency and bandwidth, which is the reason I ultimately decided to abandon use of NordVPN. If you want a more consistent experience, a better option might be to rent a VPS and host your own WireGuard VPN on that.

I really think you should check whether cake at 10Mbit/s provides a satisfactory connection with and without using a VPN, and perhaps you could provide some simple test results using: https://www.waveform.com/tools/bufferbloat to confirm.

I'm not understanding your logic - If Cake was working properly WITH THE VPN it'd shape traffic at any speed cap - it isn't working whatsoever WITH THE VPN. This has to be an error with either Cake or the WireGuard module being out of date, imo. The kernel is hurrendousy behind on these devices, on 4.1.52 - perhaps it's missing some important code that hasn't been backported.

Bufferbloat tests with VPN OFF are sometimes good and sometimes not. Ping sky rockets and times out when speedtest is ran concurrently also - to be honest QoS it seems like it's not working AT ALL. I.e. the tests Im running come up with the same results with Cake on or off ... that says to me: Cake doing nothing.

Is the underlying problem my broadband provider or something? Why is ping skyrocketing and timing out even with VPN OFF if that is what QoS is meant to solve.

 

[dave14305]

RMerlin confirms the code from Github is already in the firmware - why would this patch not be present if that's the case?

It’s not there. Not sure what code you or Merlin are referring to, specifically. The CAKE code adding use_skbhash isn’t in the Merlin code.

 

[privacyguy123]

It’s not there. Not sure what code you or Merlin are referring to, specifically. The CAKE code adding use_skbhash isn’t in the Merlin code.

I'll point @RMerlin towards this post, in PM he seems to think it's fine.

 

[Lynx]

I'm not understanding your logic - If Cake was working properly WITH THE VPN it'd shape traffic at any speed cap - it isn't working whatsoever WITH THE VPN. This has to be an error with either Cake or the WireGuard module being out of date, imo. The kernel is hurrendousy behind on these devices, on 4.1.52 - perhaps it's missing some important code that hasn't been backported.

Bufferbloat tests with VPN OFF are sometimes good and sometimes not. Ping sky rockets and times out when speedtest is ran concurrently also - to be honest QoS it seems like it's not working AT ALL. I.e. the tests Im running come up with the same results with Cake on or off ... that says to me: Cake doing nothing.

Is the underlying problem my broadband provider or something? Why is ping skyrocketing and timing out even with VPN OFF if that is what QoS is meant to solve.

I think the only thing that updating cake and/or WireGuard is going to achieve is to help cake distinguish between the encrypted flows to ensure that individual flows receive their fair share of bandwidth with respect to the overall cake bandwidth. Without this, cake treats all that is encrypted as one flow between your router and the VPN host, and so individual flows do not necessarily get a fair share of the overall bandwidth. But this flow fairness issue is not the cause of latency spikes even when setting the cake bandwidth to something low like 10Mbit/s. Why? Because if treating three flows as a single flow and throttling that to 10Mbit/s does not curtail latency spikes, then there will be latency spikes regardless of the bandwidth share out of 10MBit/s that each of the three flows receives.

You indicate that at present even when setting your bandwidth low, and with or without a VPN, you are seeing latency spikes. I do not think this is a problem with the cake implementation in Asus Merlin, but rather a problem with your internet connection that needs resolving if possible. What sort of connection do you have? It might be that you need to take this issue up with your ISP.

If you have a variable rate connection like Starlink or 4G then that introduces significant additional complexity because cake works with a fixed bandwidth at any given point in time. I maintain a solution for that: cake-autorate, which adjusts the bandwidth on the fly, and that solution is certainly portable to Asus Merlin (someone already set this up at one point), but if you have a fixed rate connection you can forget this.

 

[privacyguy123]

You indicate that at present even when setting your bandwidth low, and with or without a VPN, you are seeing latency spikes. I do not think this is a problem with the cake implementation in Asus Merlin, but rather a problem with your internet connection that needs resolving if possible. What sort of connection do you have? It might be that you need to take this issue up with your ISP.

Unfortunately it's a possibility. I dread reaching out to Virgin Media as they are useless. Using a 3rd party router and their kit in modem mode problem won't help them want to help me. It'll be a case of blame the non Virgin router, IMO.

If you have a variable rate connection like Starlink or 4G then that introduces significant additional complexity because cake works with a fixed bandwidth at any given point in time. I maintain a solution for that: cake-autorate, which adjusts the bandwidth on the fly, and that solution is certainly portable to Asus Merlin (someone already set this up at one point), but if you have a fixed rate connection you can forget this.

My connection shouldn't be variable but it is at the moment lol - I doubt this script will help at all because I cannot see Cake doing ANYTHING at all with any option combination (I've fiddled with them all.) Something further down the line wrong, whether it's something F'd up in the router, Virgin modem or Virgin network. Cake still does not do anything discernable with the VPN ON OR OFF which is strange to me.

 

[Lynx]

Seems to me you need to battle with Virgin Media and have them fix the underlying issues with your connection. Based on my experience with dealing with Vodafone, I recommend you skip customer service and go straight to the complaints procedure, and request back-dated compensation in your complaint since when the trouble began.

 

[privacyguy123]

Seems to me you need to battle with Virgin Media and have them fix the underlying issues with your connection. Based on my experience with dealing with Vodafone, I recommend you skip customer service and go straight to the complaints procedure, and request back-dated compensation in your complaint since when the trouble began.

Good shout haha.

I don't think Cake will ever work with this kernel/environment however so I may just have bought the wrong router. I think OpenWRT is the solution realistically.

 

[Lynx]

I don't think Cake will ever work with this kernel/environment however so I may just have bought the wrong router. I think OpenWRT is the solution realistically.

Based on the foregoing, I respectfully disagree. Whilst Asus Merlin may not be as up-to-date or present as many features as OpenWrt, it benefits from powerful hardware, a more user-friendly interface, and powerful, feature-packed and commercially-backed and tuned WiFi. In your case, the fault very much does not seem to lie with Asus Merlin, but rather with your ISP connection. So I'd fix that before considering switching out to OpenWrt.

 

[privacyguy123]

Based on the foregoing, I respectfully disagree. Whilst Asus Merlin may not be as up-to-date or present as many features as OpenWrt, it benefits from powerful hardware, a more user-friendly interface, and powerful, feature-packed and commercially-backed and tuned WiFi. In your case, the fault very much does not seem to lie with Asus Merlin, but rather with your ISP connection. So I'd fix that before considering switching out to OpenWrt.

The Cake patch doesn't exist and can't exist before kernel 5.10, no amount of tweaking or talking to broadband providers will fix that. The fault with Cake not working with WireGuard does lie in the firmware, respectfully. I would want this functionality faulty BB provider or not ...

 

[Lynx]

The following issues are orthogonal and should not be conflated:

1) your connection with your ISP giving rise to spurious latency spikes - this needs fixing by your ISP and cake or Asus Merlin has nothing to do with this; and

2) cake differentiating between individual, WireGuard-encrypted flows to provide per flow fairness with respect to the overall cake bandwidth - sure, at the moment the implementation of cake in Asus Merlin is not able to leverage the skb->hash preservation changes to help differentiate WireGuard-encrypted flows and thereby enforce flow fairness for multiple encrypted flows, but do not blame this for 1) above.

Such conflation would be unfair to the Asus Merlin community, and makes me think of that quote from Nikolai Gogol: "don't blame the looking glass if your mug is crooked".

 

[privacyguy123]

The following issues are orthogonal and should not be conflated:

1) your connection with your ISP giving rise to spurious latency spikes - this needs fixing by your ISP and cake or Asus Merlin has nothing to do with this; and

2) cake differentiating between individual, WireGuard-encrypted flows to provide per flow fairness with respect to the overall cake bandwidth - sure, at the moment the implementation of cake in Asus Merlin is not set up to differentiate WireGuard-encrypted flows and so will not provide enforce flow fairness for multiple encrypted flows, but do not blame this for 1) above.

Such conflation would be unfair to the Asus Merlin community, and makes me think of that quote from Nikolai Gogol: "don't blame the looking glass if your mug is crooked".

I don't blame the Asus Merlin community for anything, you're looking into it too far.

My BB provider provides patchy services, sure, but I still want the functionality of being able to apply QoS to a VPN connection ... the current implementation can't do that, it's just as simple as that.

EDIT:

2) can actually be circumvented anyway in Asus Merlin by modifying where cake is applied using something like the approach I set out here:

QoS Script for VPN

Here is my QoS script to deal with a VPN and apply QoS with correct overhead depending on whether the VPN is active or not: admin@RT-AX86U-4168:/jffs/scripts# cat /jffs/configs/cake-qos.conf.add DLIF='br0' DLOPTIONS='wash dual-dsthost ingress' ULIF_TUN='tun11' TUN_PACKET_OVERHEAD='53'...

www.snbforums.com

Brother, the Cake patch does not exist in the firmware and can't exist. It can never work with the current firmware confirmed over on Cake GitHub. Case closed as you were!