[Alpha] 386.2

[brummygit]

The way will be by replacing the qos script with your own. I'm not gonna provide 10 different parameters that will confuse everyone. The only setting available on the webui will be the same as for fq_codel: an overhead selector. Everything else will be set to a sensible default.

Is there any mileage in considering using Diffserv as the default in both directions when the Besteffort tin is the default behaviour unless traffic is classified? No washing would then allow classified traffic into the other tins is applicable. I don't know if there is any significant overhead to running diffserv rather than besteffort for instances where all traffic is hitting besteffort anyway.

 

[dave14305]

If true, that would break things for virtually everyone, not just Cake users.

I read it here in a Reddit post by @dtaht (point #2):

https://www.reddit.com/r/HomeNetworking/comments/fvhr4w

 

[RMerlin]

I read it here in a Reddit post by @dtaht (point #2):

I knew about Comcast (I also saw his post in the past), what I meant is that if Cake is set to a single Tin then it won't matter for Cake what DSCP value is used, and if that DSCP value were to have an impact beyond the router, it would have been problematic for every Comcast customers not using Cake+wash (which would mean 99% of Comcast`s customers).

 

[RMerlin]

Is there any mileage in considering using Diffserv as the default in both directions when the Besteffort tin is the default behaviour unless traffic is classified?

No, because downstream traffic cannot be relied upon to have proper DSCP flags, making the use of diffserv3 quite unreliable there.

 

[Kingp1n]

Wow...I see that baking this kind of cake can be challenging. Best of luck and hope we can get a taste of it soon haha

 

[archiel]

The way will be by replacing the qos script with your own. I'm not gonna provide 10 different parameters that will confuse everyone. The only setting available on the webui will be the same as for fq_codel: an overhead selector. Everything else will be set to a sensible default.

When you refer to 'replacing the qos script with your own' do you mean we would disable Cake in the webui and run something like the present cake-qos, or that we could run something like a 'cake-qos.cfg.add' script to override the web settings?

For instance, I am currently running cake-qos with upload and download options raw diffserv3 rtt 80ms, which I arrived at after a lot of testing and which works for my setup and ISP and gives me a very steady 3x A+ on DSL reports.

 

[Deleted member 22229]

ISP and gives me a very steady 3x A+ on DSL reports.

That speed test BB test is completely inaccurate, Basically the test is borked and should not be relied on. Its also very browser dependent another reason to not trust the results.

 

[Morris]

I wonder however, is there any point in washing ingress if we only use a single tin? Might save a few precious CPU cycles if we didn't wash ingress traffic.

The whole beauty of cake is that one dose not need to tag traffic to get good QOS as best effort works great. I see no harm in passing the DSCP markings upstream as they might be used and provide QOS on at the upstream routers. How many CPU cycles would be saved by not zeroing that field? I think the value of passing the DSCP markings could be big for some applications and it will make no difference for cake when configured best effort.

Morris

 

[Morris]

The way will be by replacing the qos script with your own. I'm not gonna provide 10 different parameters that will confuse everyone. The only setting available on the webui will be the same as for fq_codel: an overhead selector. Everything else will be set to a sensible default.

This is a wise choice. So many over configure cake and then wind up with bad results. Cake works best wen the setup is as simple as cake!

Morris

 

[RMerlin]

When you refer to 'replacing the qos script with your own' do you mean we would disable Cake in the webui and run something like the present cake-qos, or that we could run something like a 'cake-qos.cfg.add' script to override the web settings?

You will enable Cake QoS on the webui, but use the qos-start script to either replace or modify /tmp/qos that gets created by the firmware. Think of qos-start as a "postconf" script for QoS.

The firmware will generate /etc/cake-qos.conf (variables) and /tmp/qos (the script that configures QoS). It will execute /jffs/scripts/qos-start if it exists. After that it will execute /tmp/qos (whether the one the firmware created, or any modified/replaced version).

I see no harm in passing the DSCP markings upstream

I don't wash DSCP markings upstream, only downstream because of silly ISPs like Comcast (see @dave14305 's quote of a David Taht Reddit post). Anyone will still be free to change that by modifying or replacing the /tmp/qos script generated by the firmware.

 

[RMerlin]

Wow...I see that baking this kind of cake can be challenging. Best of luck and hope we can get a taste of it soon haha

Even if something is designed to be "very simple" (like Cake), there will always be people who will try to overtune things, spending days on tweaking something that might only show a visible improvement in a synthetic test. So, my goal with the implementation is not to try to make the most optimal setup possible, but to go with something that is "good enough" for "the majority". Anyone with a special case or in needs of trying to squeeze every once of performance will have to do so on their own. I largely simply used the layer_cake setup from the SQM scripts, applied some of David Taht's recommendations (as he backed them with actual facts, not just "on paper this will do this and that), and called it good. Most of the work was with everything around that, such as adding the kernel modules, trying to either backport stuff to iproute2-4.3 or upgrading it to 5.11, etc...

That means unless a very clear issue is found, I will most likely not make any further change to the current queue setup I decided to settle on.

 

[bluepoint]

Okay cake is now served! See post #1.

 

[Kingp1n]

I'm about to try the latest alpha. If I'm currently using Flex, and I want to try the built ‐in cake, does it automatically turn off A. QoS or I must must manually do this prior to the switch? Thanks.

 

[QuikSilver]

I'm about to try the latest alpha. If I'm currently using Flex, and I want to try the built ‐in cake, does it automatically turn off A. QoS or I must must manually do this prior to the switch? Thanks.

Looks like you can choose it or not.

 

[Make WiFi Great Again]

I cant seem to upgrade from 386.2_alpha1-gc52b410e89 to 386.2_alpha1-ga84fed8777 on an ac68u keep getting that asus firmware protection unsupported firmware error.

I finally had to rename the 777 file with the previous build name of 0e89 and then she took fine.strange.

 

[New2This]

Thanks for this.....Just updated the firmware.

 

[John Fitzgerald]

Is manual better if you can use Speedtest to determine a range?
How are people choosing their range?
Anyone tried automatic? Is that preferred?

 

[Kingp1n]

I'm testing CAKE-QoS now. If I'm testing w/Comcast do I need to set a value inside MPU or leave it at '0' (default)? Thanks!

 

[John Fitzgerald]

I'm testing CAKE-QoS now. If I'm testing w/Comcast do I need to set a value inside MPU or leave it at '0' (default)? Thanks!

Here's mine: use the red dropdown arrow

 

[GHammer]

If you choose cake and disable the Enable GeForce NOW QoS UPnP control, you will get an error asking you to enter a value. What value or where isn't given.
I don't use GEForce, so disabled it. After the error, I enabled it and the cake settings applied.

Besides not using GEForce, I'm a tiny bit concerned about having a UPnP server running.