[Cake] cake in dd-wrt

Tue Aug 20 19:34:19 EDT 2019

Sebastian Gottschall <s.gottschall at newmedia-net.de> writes:

> Am 20.08.2019 um 18:24 schrieb Dave Taht:
>> On Tue, Aug 20, 2019 at 5:09 AM Sebastian Gottschall
>> <s.gottschall at newmedia-net.de> wrote:
>>> :-) i'm following this list and yes we are working on bringing cake
>>> in :-)
>> Yea! thx for being on the list!
>>
>>> is there any question behind this link from your side?
>> I just wanted to make people here aware that it was happening.
>>
>> Is there a build now?
> the first builds with cake are already out yes, but unfinished. we
> started then to rewrite major parts of the qos code. i expect to push
> out
> a new build tomorrow. it will still not use the full potential of cake
> since we have to bring all together with the priority and ndpi and
> filter based filter together
> with the cake scheduler. but it works so far and will be better in the
> next days and weeks after we have found a solution for it. cake is
> more a all in wonder solution
> so we have to use the features of cake itself to reimplement the
> priorisation classes
>>
>> If I had any one principal request it would be to make sure the
>> dd-wrt
>> gui (if one is made) exposes the link layer parameters. Getting the
>> framing wrong is about the biggest error I see in the deployment:
>> https://www.youtube.com/watch?v=LjJW_s5gQ9Y
> i have seen this already. out plan here is that the user specifies the
> internet connection type like vdsl2, cable, whatever in case of cake
> which then will be used
> as argument

Awesome!

>>
>> Other nifty cake features:
>>
>> "wash" and "besteffort" are important on some cablecos that remark
>> traffic to CS1
>> "nat" is dang useful if you are natting
>> ack-filter helps on really slow asymmetric networks on the slow side
>> only.
>>
>> So, like, my defaults would be
>>
>> in: nat wash besteffort # triple-isolate bandwidth X etc
>> out: nat ack-filter # if > 10x1 down/up ratio
> my finding for damn slow internet < 2000 kbit upstream that we need to
> handle rtt like codel with the formula
>
> rtt = 50 - (uprate / 50)
>
> which gives a rtt of 10 at 2000 kbit. otherwise its not working
> good. for the rest i will consider your defaults for our tests.
>
>> And make sure the link layer settings are exposed in the gui. I
>> really
>> don't know how much
>> "washing" is needed outside the cablecos, taking packet captures of
>> various isps to see how often
>> dscp bits are mangled nowadays would be good. besteffort on inbound
>> saves some on cpu.
> dscp might be problematic for isps like orange in france and other
> fiber isps i have found in spain and netherlands.
> all these isps expect dscp classes to be set for outbound traffic
> depending on the traffic type. (iptv, voice and internet). this
> together is also
> mapped to vlan priorities again internally. so using the dscp bits
> might be problematic for cake since it clears out the dscp flags and
> so internet simply doesnt work anymore
> for these isps (or just with modem 56k speed)

I would love to know more about what dscp's are in more common use and
what isps intend for them to be doing. cake's default mappings are the
result of much reading of RFCs, debate, and headbanging. The "model"
concept is easily extended

>> Are you using the out of tree version or mainline? Out of tree has
>> some experimental SCE work
>> that I'd love to see tested at more scale but not actually shipped
>> at this time.
> out of tree straight from git with modifications to be compatible to
> my kernels since your compatiblity layer is mmh not perfect.
> some compat layer you made doesnt work since they already got
> backported to the latest upstream kernel versions. so just some
> refinement.
> nothing special or much work
>>
>> Due to how cpu intensive cake can be (on inbound) I've been working
>> on
>> a faster, less feature-full fq_codel, it's here:
>>
>> https://github.com/dtaht/fq_codel_fast
> i reviewed it and also tried to compile it with success. problem is,
> that code parts of it are looking unfinished with debug printks etc.
> this is why i stopped at that point since i thought its
> unfinished. but i have added it already to my code tree and added the
> required parts to compile
> it with all of my kernels (compat layer for older kernels or lets say
> #ifdef hell)

Thx! It's unfinished, but functional, as I seemed to be the only one
that had interest in revising fq_codel further, and lack time to
actually build and profile embedded targets.

>>
>> I hate the idea of fq_codel one way, cake the other, but tbf +
>> fq_codel_fast seems to work well at
>> ~1gbit on my apu2 and cake doesn't. I'd originally planned to try
>> and
>> make a multi-core shaper out
>> of it, but sce distracted me....
> multicore would be nice since alot of home routers are coming with up
> to 4 native cpus right now. (ipq8065 has 1.8 ghz and dual
> core. ipq40xx has 4 cores but just 700 mhz and is 4 times slower per
> core and mhz, so it makes sense here)
> i'm using a APU as internet router as well btw

That's my primary target at the moment.

>> Having more folk on board benching stuff on modern non-x86 platforms
>> would be good.
> yeah no problem. we mainly test on a gateworks laguna armv6 platform
> in my company, but most reponse will come from broadcom arm northstar
> and qca ipq platforms from the community
> but i hope i also get feedback from slower platforms like mips ar7240
> etc

I've not heard of "northstar"?

I have to admit I'm mostly interested in benchmarks from the newer
platforms. Have not been keeping up with the state of the art here.

It seemed better to make cake as perfect as could be and wait for the hw
to catchup. At the time.

I keep hoping to find the perfect next-gen wifi 6 with fq_codel derived
tech everywhere box ... and to be able to just buy it off the shelf
this christmas.

>> Another cake feature is that you can get all the benefits on a
>> normal
>> ethernet (with bql) *without turning the shaper on* but we have not
>> benchmarked that either vs a vs fq_codel or fq_codel_fast
> from the response i got from the early experiments is that cake
> performs much better in typical bufferfloat tests than fq_codel. but i
> will see how my latest version now works

> which fully integrated it.

Arguably fq_codel could use a few tweaks from the cake/cobalt effort.
It was great for 2012 though!

>
>
> Sebastian
>
>>
>> Have fun!
>>
>> Here's the first paper: https://arxiv.org/pdf/1804.07617.pdf
>>
>>> Sebastian
>>>
>>> Am 18.08.2019 um 18:33 schrieb Dave Taht:
>>>> https://svn.dd-wrt.com/ticket/5796
>>>>
>>
>>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake