Re: [Cake] cake in dd-wrt

[Sebastian Gottschall <s.gottschall@newmedia-net.de>]

Am 20.08.2019 um 18:24 schrieb Dave Taht:
> On Tue, Aug 20, 2019 at 5:09 AM Sebastian Gottschall
> <s.gottschall@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
>
> 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)
>
> 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)
>
> 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
>
> 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
> 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.


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
>>>
>
>