Re: [Cake] cake in dd-wrt

[Dave Taht <dave@taht.net>]

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

> can you explain line
>
> 524 in
> https://github.com/dtaht/fq_codel_fast/blob/master/sch_fq_codel_fast.c?

typo!!!!!

>
>
> 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
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake