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 E91B43CB35 for ; Thu, 22 Aug 2019 05:19:59 -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:From:References:Cc:To:Subject; bh=ULedxFMsQ3x8w8m3hyFsp798j6eOURfeE17oNtX7vN8=; b=jjmHAH4SZJY99PeZxNyzXIDEQcgNw4QOyN9IeSaqzyPrnlNKRp5tl/XpkZUeszxsUCLYyKC5YQ+hVslQ+mlzw+UDnOtEq1ImBPv3laqP1zO4eE8H7DCUwfzE1UNAu3q7zkt6vJq+SOuorfIrVW/JgJim/i/9TTUDugZx0Fmsiz4=; To: Dave Taht , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vu?= =?UTF-8?Q?sen?= Cc: Dave Taht , Cake List References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> <87wof7sriw.fsf@toke.dk> <6782ec15-30eb-63b0-f54f-376c5e6b840b@newmedia-net.de> <87tvabsp99.fsf@toke.dk> <74bccc2b-b805-255f-b6a7-83ade9af6765@newmedia-net.de> <87r25fsn70.fsf@toke.dk> <54438C64-C613-438E-9CB9-6C6D0C5EAFA0@gmail.com> <87sgpvflo4.fsf@taht.net> <87wof6rf7t.fsf@toke.dk> <7656FCDE-C590-4B0C-B191-B9FAC928A762@gmail.com> <5eb4c395-c718-2d28-65a7-9762cf8d5bea@newmedia-net.de> <47AD5102-B66F-44A5-AADE-D167ECB94A61@gmx.de> <1d772664-b6cc-a528-9725-96a431032875@newmedia-net.de> <87v9uqea3x.fsf@taht.net> <87tvaap57q.fsf@toke.dk> From: Sebastian Gottschall Message-ID: <5bbd2b81-9846-3a7a-130c-0f59e04fd2d1@newmedia-net.de> Date: Thu, 22 Aug 2019 11:18:55 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Received: from [212.111.244.1] (helo=[172.29.0.186]) by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1i0jGI-0003nL-CB; Thu, 22 Aug 2019 11:20:06 +0200 Subject: Re: [Cake] pie 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: Thu, 22 Aug 2019 09:20:00 -0000 Am 21.08.2019 um 23:53 schrieb Dave Taht: > On Wed, Aug 21, 2019 at 2:40 PM Toke Høiland-Jørgensen wrote: >> Dave Taht writes: >> >>> Sebastian Gottschall writes: >>> >>>> Am 21.08.2019 um 18:21 schrieb Sebastian Moeller: >>>>> On August 21, 2019 6:12:03 PM GMT+02:00, Sebastian Gottschall wrote: >>>>>> thats rather old. i rewrote all the qos code in the last 4 or 5 days. >>>>>> so >>>>>> things might be changed. next phase is bringing all the link level >>>>>> detail configuration stuff into the gui which will be done >>>>>> tomorrow or at least still within this week. >>>>>> i also added now cake to some smaller low budged routers with limited >>>>>> resources, so see how it runs. i had bad experiences with fq_codel in >>>>>> the past due some high memory usage. >>>>>> especially since its hard coded somewhat into the wireless ath9k >>>>>> driver. >>>>>> so i already modded it for more efficient handling. 4 mb max per queue >>>>>> is simply too much for a 32 mb ram based router. >>>>> This is why I'm sqm we reduced the queued packet maximum m to around 1000, and also why cake has an explicit memlimit keyword. >>>> yeah but does this help if fq_codel is hardcoded into mac80211? >>>> fq_codel has a memlimit keyword too btw. its fixed to 4MB. i reduced >>>> it to 256kb on low memory architectures. no other way to get around >>>> OOM problems >>>> mac80211 does always make use of fq_codel. it has a own build in >>>> implementation >>> Certainly memory limits are a huge problem throughout complex qdiscs, >>> especially when stacked up (eg hfsc 1 -> qdiscx hfsc 2 -> qdisc x), >>> and >>> >>> OOMs suck. Particularly as few test packet flooding their devices >>> after setting up a complex qdisc system. >>> >>> Bytes = time. It doesn't matter how many queues you have. This >>> to me has always been one of the biggest flaws of the tc subsystem >>> in general is that the total amount of memory in use on >>> a given physical interface should be managed by the topmost layer. >>> >>> Same problem for wifi in multiple SSIDs... it's still just one device. >>> >>> However we do need enough bytes to keep the device busy and there >>> are other problems with per packet limits leading me to prefer >>> using just memory limits. One is, that your typical ack packet >>> coming off the rx ring is actually 2k in size, not 64 bytes. >>> I had at one point (in openwrt) something that took small packets >>> and copied them to a smaller allocation which took pressure off the >>> memory allocator. >>> >>> I've kind of lost track, did the ath9k wifi stuff use 1 allocation for >>> all 4 hw queues? I'm afraid to look this morning... (and I'm not big >>> on the 4 hw queues either) >> The memory limit in mac80211 is global per phy. > yea! win! So much better than four instances per ssid. bad of some devices have 2 phys and still just 32 mb ram. i mean the 4 mb limit i was talking about is just a mod by openwrt. the original default is 32 mb for fq_codel in mac80211. > >> -Toke >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > >