From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9E5403B2A4 for ; Tue, 20 Aug 2019 19:43:26 -0400 (EDT) Received: from dancer.taht.net (c-73-162-29-198.hsd1.ca.comcast.net [73.162.29.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 540A021425; Tue, 20 Aug 2019 23:43:25 +0000 (UTC) From: Dave Taht To: Sebastian Gottschall Cc: Dave Taht , "cake\@lists.bufferbloat.net \>\> Cake List" References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> <7f6c008f-e678-badc-5abc-74e95d1fa5bc@newmedia-net.de> Date: Tue, 20 Aug 2019 16:43:22 -0700 In-Reply-To: <7f6c008f-e678-badc-5abc-74e95d1fa5bc@newmedia-net.de> (Sebastian Gottschall's message of "Tue, 20 Aug 2019 20:05:38 +0200") Message-ID: <87o90jflnp.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] cake in dd-wrt X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 23:43:26 -0000 Sebastian Gottschall 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 >>> 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