From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from webmail.newmedia-net.de (smtps.newmedia-net.de [IPv6:2a05:a1c0:0:de::167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 34AD73B2A4 for ; Tue, 20 Aug 2019 14:06:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=newmedia-net.de; s=mikd; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject; bh=RFSXyeaSSX8Cj2C8A5PAHuTtbPczZKCXLpUiMIEsJZQ=; b=P0TbxSpXqaDHv/7o6HPp27oP7subZHTuT7NrZ++TExTJqiD/bfD47D/3xYQ2qbu93rTHbCiyYCdIrHfYQ8k/0ovmDtkxU07x/RGaA8ajtNfJ0br2AIrFlYXqepB59yQLa16At4iSSYoJz9vnvP44TEtCMv4dGmE2LI/l+1F6gaU=; From: Sebastian Gottschall To: Dave Taht Cc: "cake@lists.bufferbloat.net >> Cake List" References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> Message-ID: <7f6c008f-e678-badc-5abc-74e95d1fa5bc@newmedia-net.de> Date: Tue, 20 Aug 2019 20:05:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Received: from [2003:c9:3f25:1300:e947:ab73:1d88:4792] by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1i08Wt-0006dJ-OG; Tue, 20 Aug 2019 20:06:47 +0200 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 18:06:42 -0000 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 >> 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