Sebastian Gottschall <[email protected]> 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 >>> <[email protected]> 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 >> [email protected] >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
