Re: [Cake] cake in dd-wrt

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

can you explain line

524 in 
https://github.com/dtaht/fq_codel_fast/blob/master/sch_fq_codel_fast.c?


Am 20.08.2019 um 18:47 schrieb Sebastian Gottschall:
>
> 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
>>>>
>>
>>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake