CakeQOS CakeQOS-Merlin

[kernol]

Personally that's how I believe the feature should also be, but this wasn't my decision.



Good catch, that is most definitely the issue. I've pushed a hotfix which should hopefully differentiate the system and user calling the stop command and only remove system file entries for the latter. If you wouldn't mind testing it that would be appreciated, otherwise I will revert the feature to my original implementation where it is only a temporary stop.

Sorted ... MANY thanks. Cake survives reboot happily.
I would also vote for a cake "disable" feature - which would retain the nat-start cake-qos start line on reboot .

 

[Treadler]

Personally that's how I believe the feature should also be, but this wasn't my decision.



Good catch, that is most definitely the issue. I've pushed a hotfix which should hopefully differentiate the system and user calling the stop command and only remove system file entries for the latter. If you wouldn't mind testing it that would be appreciated, otherwise I will revert the feature to my original implementation where it is only a temporary stop.

Many thanks!

 

[rgnldo]

implement support bandwidth autodetect.

Needs testing.

SHAPER PARAMETERS
autorate-ingress

[3] --> Queue Priority | [diffserv4]
[4] --> Extra Options | [ack-filter-aggressive]

 

[Torson]

Personally that's how I believe the feature should also be, but this wasn't my decision.
Good catch, that is most definitely the issue. I've pushed a hotfix which should hopefully differentiate the system and user calling the stop command and only remove system file entries for the latter. If you wouldn't mind testing it that would be appreciated, otherwise I will revert the feature to my original implementation where it is only a temporary stop.

I can now confirm that with the last hot-fix cake-qos is running after a reboot without manual intervention.

 

[Torson]

Would you consider a backup / restore configuration menu item? It would be helpful to experiment with different options/settings.

 

[kernol]

Heartfelt Appeal ...to all the builders and contributors to cake-qos ... Please KISS ... Keep It Stupid Simple ... !

I know there are properly clever coders in this group ... and I'm sure many like to tinker a LOT ... but for me [and I'm sure MANY other adopters of cake-qos over time] the biggest appeal is the apparent simplicity of cake-qos [for the end-user] and the fact that it just works straight out of the cake "tin"!

Flexqos is the place for the control experts who have the need to do plenty of bandwidth shaping and in depth customisations.

There is a danger that too many contributors to this project will result in over-complication and end unhappily [seen it before ... don't want a repeat here] ... be .

 

[Wade Coxon]

Would you consider a backup / restore configuration menu item? It would be helpful to experiment with different options/settings.

I don't know that there is enough "configuration" to warrant that.

 

[brummygit]

Heartfelt Appeal ...to all the builders and contributors to cake-qos ... Please KISS ... Keep It Stupid Simple ... !

I know there are properly clever coders in this group ... and I'm sure many like to tinker a LOT ... but for me [and I'm sure MANY other adopters of cake-qos over time] the biggest appeal is the apparent simplicity of cake-qos [for the end-user] and the fact that its just works straight out of the cake "tin"!

Flexqos is the place for the control experts who have the need to do plenty of bandwidth shaping and in depth customisations.

There is a danger that too many contributors to this project will result in over-complication and end unhappily [seen it before ... don't want a repeat here] ... be .

Whilst I agree that there is a good argument for a for a simple implementation, cakeQoS-Merlin and FlexQoS do different things:

• Cake (using besteffort) is currently providing excellent (almost magic ) queue management with all traffic having equal priority
• FlexQoS is adding better traffic shaping / prioritisation to the built-in (to Asuswrt-Merlin) algorithms

Cake already supports multiple configuration options including diffserv3, diffserv4 & diffserv8 which are designed to support shaping / traffic priority based on DSCP marking directing traffic to different tins, but very little of my traffic seems to be DSCP marked and therefore most traffic is processed in the besteffort tin. This means that when demand for my bandwidth is seriously over subscribed, I still suffer problems with large downloads getting a fair share of the bandwidth when competing realtime traffic such as voice calls and video streaming don't have enough to run successfully.

What would be amazing would be to have cakeQoS-Merlin offer a simple install and forget implementation for those that don't need any more, but for people who want to have shaping available too, make advanced options available which allow multiple tins to be implemented and use the built-in Asus / Trend traffic identification functionality (and maybe with some of the extras offered by FlexQoS) apply the DSCP marking to traffic.

I think there is still much work to do on the initial implementation, but I would love to see this continue towards looking at something similar when time permits.

 

[kernol]

Whilst I agree that there is a good argument for a for a simple implementation, cakeQoS-Merlin and FlexQoS do different things:

• Cake (using besteffort) is currently providing excellent (almost magic ) queue management with all traffic having equal priority
• FlexQoS is adding better traffic shaping / prioritisation to the built-in (to Asuswrt-Merlin) algorithms

Cake already supports multiple configuration options including diffserv3, diffserv4 & diffserv8 which are designed to support shaping / traffic priority based on DSCP marking directing traffic to different tins, but very little of my traffic seems to be DSCP marked and therefore most traffic is processed in the besteffort tin. This means that when demand for my bandwidth is seriously over subscribed, I still suffer problems with large downloads getting a fair share of the bandwidth when competing realtime traffic such as voice calls and video streaming don't have enough to run successfully.

What would be amazing would be to have cakeQoS-Merlin offer a simple install and forget implementation for those that don't need any more, but for people who want to have shaping available too, make advanced options available which allow multiple tins to be implemented and use the built-in Asus / Trend traffic identification functionality (and maybe with some of the extras offered by FlexQoS) apply the DSCP marking to traffic.

I think there is still much work to do on the initial implementation, but I would love to see this continue towards looking at something similar when time permits.

I hear you - but genuinely believe that Flexqos, once it matures, will be the best way to handle shaping as it is incredibly capable of being customised. Its predecessor worked really well for me - despite the fact that I don't have a need for multi-level shaping or granular configuration into 8+ categories of traffic.

 

[brummygit]

It really does depend. I have tested all the diffservs, probably not long enough, and hopefully I'll have time to do 24 hours of testing on each, but I have fallen back to best effort for my connection/load.

The key in my mind is the right ATM based on your connection type and the %s for up/down, then you can start playing with the Queue Discipline.

Hope that helps....or apologies if it blurs it more.

I've also been trying the different options.

• BestEffort works well but obviously does no shaping so in my case where I am unfortunately constrained by not having enough bandwidth to meet demand a lot of the time, therefore I get low bufferbloat but video streaming for example can get interrupted due to lack of throughput
• Diffserv8 is seems to be too many tins and (if I'm reading it right) is pre-configured with Best Effort traffic having less than the max configured bandwidth, therefore as most of my traffic is still in Best Effort this is wasting available bandwidth
• Diffserv4 feels optimal - Best Effort is configured to have the full bandwidth available and I see a very small amount of traffic hitting Voice and Video. No traffic has been through the Bulk tin in my case.

BestEffort is a great starting point, especially if people are not particularly bandwidth constrained who can live without traffic shaping, but for me Diffserv4 would seem to be a good target as it means you can have time critical (eg Voice calls), priority (eg Video Streams which drop out if not serviced quickly enough), Normal Best Efforts, and Bulk for stuff that must wait at the back of the queue until there's capacity to service it. The challenge is of course getting the traffic marked correctly.

I plan to stay on Diffserv4 for a while, but initially it seems to work well as most traffic hits the Best Effort tin which seems to be the same as running the BestEffort option itself.

 

[brummygit]

I hear you - but genuinely believe the Flexqos, once it matures, will be the best way to handle shaping as it is incredibly capable of being customised. Its predecessor worked really well for me - despite the fact that I don't have a need for multi-level shaping or granular configuration into 8+ categories of traffic.

I understand the desire for simplicity, and cake works so well for some users that I also hope that Best Effort is the easy starting point for most cases.

The challenge with FlexQoS is that it relies on FQ_Codel which isn't the best, and its known limitations were one of the reasons that cake was developed. Cake is really a replacement for FQ_Codel as implemented in the base (Merlin) firmware. FlexQoS is simply enhancing the traffic marking and tweaking some of the FQ_Codel / Asus Adaptive QoS settings.

I have run FreshJR and then FlexQoS for a long time and it does a great job of shaping but can still suffer some buffer bloat and latency under high load. I was blown away by how good cake was.

 

[Pak Kriss]

I understand the desire for simplicity, and cake works so well for some users that I also hope that Best Effort is the easy starting point for most cases.

The challenge with FlexQoS is that it relies on FQ_Codel which isn't the best, and its known limitations were one of the reasons that cake was developed. Cake is really a replacement for FQ_Codel as implemented in the base (Merlin) firmware. FlexQoS is simply enhancing the traffic marking and tweaking some of the FQ_Codel / Asus Adaptive QoS settings.

I have run FreshJR and then FlexQoS for a long time and it does a great job of shaping but can still suffer some buffer bloat and latency under high load. I was blown away by how good cake was.

Yes, cake works perfect out of the box.

Nothing more what I need at a symmetric 200MBps fiber optic line.

Anything else is an overkill for my usecase.

Sent from my SM-T805 using Tapatalk

 

[ttgapers]

Personally that's how I believe the feature should also be, but this wasn't my decision.



Good catch, that is most definitely the issue. I've pushed a hotfix which should hopefully differentiate the system and user calling the stop command and only remove system file entries for the latter. If you wouldn't mind testing it that would be appreciated, otherwise I will revert the feature to my original implementation where it is only a temporary stop.

So my two cents on this @Adamm would be to keep key functionality inline with previous modules/addons. So, if "disable" functionality "disables" until "next reboot" and/or "enable", then I am ok to open the issue and get this parked.

On the reboot item, I am also open to whether this is an issue, to log it to github/issue tracker so a dev(s) can track it.

Hope that helps.

 

[ttgapers]

implement support bandwidth autodetect.

Needs testing.

SHAPER PARAMETERS
autorate-ingress

[3] --> Queue Priority | [diffserv4]
[4] --> Extra Options | [ack-filter-aggressive]

Thanks @rgnldo

Tracking here: https://github.com/ttgapers/cakeqos-merlin/issues/42

 

[Wade Coxon]

So my two cents on this @Adamm would be to keep key functionality inline with previous modules/addons. So, if "disable" functionality "disables" until "next reboot" and/or "enable", then I am ok to open the issue and get this parked.

Is that the terminology used by other modules?

The more intuitive terminology (well at least to me), is for disable to turn off the feature and have it be persistent across reboots. A stop should simply be to stop it from operating until the next reboot.

Maybe I am just too used to MS Windows services?

 

[Adamm]

As for the whole disable/stop debate, seems like unnecessary feature creep to me. I am very much a supporter of KISS as @kernol spoke about.

How often to users actually plan on disabling and re-enabling cake to the extent it requires a (second) dedicated function? Is there any real world use case someone can provide for this?

 

[ttgapers]

As for the whole disable/stop debate, seems like unnecessary feature creep to me. I am very much a supporter of KISS as @kernol spoke about.

How often to users actually plan on disabling and re-enabling cake to the extent it requires a (second) dedicated function? Is there any real world use case someone can provide for this?

I agree with all - as I am "happy" with where we are at. This might be getting into Poll territory

If stop/start provides the same functionality then I'm ok as well.

cake-qos start (read config if there and start, else defaults and prompt)
cake-qos stop (stop the services/addon, can be started via "start", or user reboots router)

I do believe, support and prefer KISS!

 

[Wade Coxon]

cake-qos start (read config if there and start, else defaults and prompt)
cake-qos stop (stop the services/addon, can be started via "start", or user reboots router)

Yep, agreed. All I care about it making sure that start and stop are not adding and removing entries from nat-start

 

[ttgapers]

Yep, agreed. All I care about it making sure that start and stop are not adding and removing entries from nat-start

Looks like your wish is in...

cake_stop(){
    if cake_check; then
        Print_Output "true" "Stopping" "$PASS"
        cru d "$SCRIPT_NAME_FANCY"
        /opt/sbin/tc qdisc del dev eth0 ingress 2>/dev/null
        /opt/sbin/tc qdisc del dev ifb9eth0 root 2>/dev/null
        /opt/sbin/tc qdisc del dev eth0 root 2>/dev/null
        ip link del ifb9eth0
        rmmod sch_cake 2>/dev/null
        fc enable
        runner enable
        nvram set runner_disable="0"
        nvram commit
    fi
}

cake_start is a bit longer, but at a cursory glance think it adheres.

 

[ugandy]

implement support bandwidth autodetect.

Needs testing.

SHAPER PARAMETERS
autorate-ingress

[3] --> Queue Priority | [diffserv4]
[4] --> Extra Options | [ack-filter-aggressive]

I tried autorate-ingress in a quick test before. maybe i set it up incorrectly, but in my test, the speed limits kept swinging wildly and way below the bandwidth available for both DL and UL. i'll try again. my comcast UL swings between 20Mbps to 3Mbps during the day, so autorate sounds like something that would be needed in my config. i'll do another test