From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4F2383B29E; Thu, 22 Aug 2019 16:10:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566504637; bh=gvycOY4ujgIfEli4NjzzjGknUy1fzQg+MFQSWHrm9fU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=hohs1sgf7lb6Bc7kiMZ/G4c1mzMjaNdKds5xpLABWaEUn7n+7MszEmoiKFliv2x49 2/2yQiCUBzT0iRtP17xrXNGha28YFkvGR2RhaUgWWNlUO0bQb+ICH7OQ8QdWXdG2pc 1XELFUSzft2VoKb8vZkYfBJzYRRaooiB8jdE0MBA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.179.218.79]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MUZKF-1hriLm2suB-00RLae; Thu, 22 Aug 2019 22:10:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: <87ef1dng8s.fsf@toke.dk> Date: Thu, 22 Aug 2019 22:10:36 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Cake List , Battle of the Mesh Mailing List , Make-Wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: <8332CC60-CE58-49EC-AE55-568913D476CE@gmx.de> References: <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> <5bbd2b81-9846-3a7a-130c-0f59e04fd2d1@newmedia-net.de> <87ftltdter.fsf@taht.net> <87pnkxnjo4.fsf@toke.dk> <87ef1dng8s.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:3ebux5Q1aNKsH9jFbXLMc5sUzzSssROc3eg52fWeAESIQBJ4WQj 2yqsooHsGti7y9wH3I3KF0tzEz5ilv9YHEaoOonT+ia38C9ryekcTplm8LsghAZckoPXpTr VARPrlgWzVDHfT7bNyH7C0HGnru9K3bJVfZIgzwmGwl6E8AW2OU6rLdAuA9ApRR/4X0YTj7 GezybnXQPVhA3wq2sjSfg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:KamZIAoPFgo=:crWA05Uobe2y8O/xEmJCxU JAynxMGMkqegjrfx7ErYkK1QjyRDx4NXCySm53libcKl3CajoDTbF+YBK32u76HFx++pwjQyL WI2zTGTnFKUJ4W+2gzKFQBk8/D793xHGSQSSG+MRUL5UYUIyNf9FPj0jho2cZ1RdtxqvSFC1m SNHoXnjr22oDzsnbc2J0iimoT+zhedsg9szpDmYRiCOvwJ1daESAdBbsKPySvpVd3f5Ah+PBW KkM1MaCCk/OJEDMqkkm9ItWwwCOv/J3kQXSV+ydldt9gLAMIpFOouADS/i0jZGb4eVztCbzqy gIwCKB3UEXfodgZ/wfoQOFMANn/aDRyKJNdi7w//LBfOdHsTinUBoikw62wx0nbFy/FXN0gFi zlnT9rHQWyKmnpGdS8OV9zTR6l4bomOiXb2HEmnrfqNhc01Fog8T8j9Nhyq9OfnqkMgoCMBfN zOlJD7nmBpx2OapQe6iDIxtb5eYT2cu4EXHIHsCK54EQaVLtu80iW30sqGl6pxmjruBPu5R3T df7deRf8lJEqeamPgS9Sk+2P8w8A5unKJQ97tz3Y7cbwP/e4Z7yBpixcmsKhYDr8EnRY1viN8 NmFBQMTB1ZNsQHFpsX3gULj0ND0I81eOMj1n1CHugXN7hrqeopVtC3uVENq8Vnf6zDu1oY3W/ IBmNxYfDdD0SHMtP6RCS+d1jNfLGLTtl4NpQUE7K+YCry7m78/n6+TPpdFizU3QvrqSfpnqad SRrXcY6AabpwPL2uvzja6Jd1CvFo5abonueB6eztrJ8XBJWyBxPX12lNdTGKMmTlWjbP8/v5G QhRpXX/Y1MZMKTFtj8gKkU3BHm4yaCN0vF508cC8R+T00RKCfUF5aRu+ScBton8oPPnaV1LwV mpKfU5xCzGmXKH4U/EzpudJAebhXjcLY08enQia+e9+hL8qiU5D+6QaEwu4bmLxtxXNoEBTO0 594tjD/6DbK5QVcdttCzLBv8VTGF3rqUXejpD6M2GRcaVrVhzGEmfbwu7C5g4X6KEmEYQw43/ pqPJzIR4yaPOkaSvPGAgKThOpIRuP96+X2bVzJ8jrDsbimI8qseHrcJNltKCDhszF88qNKkN9 it0Wwfle71h5rxQIklsGSqNCAArrlXptfsA39SdSUOhVGUYWlE01BKItr9ZtUEX6KWnqz00iI y268Y= Subject: Re: [Make-wifi-fast] [Cake] [Battlemesh] Wifi Memory limits in small platforms X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 20:10:45 -0000 > On Aug 22, 2019, at 21:37, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Dave Taht writes: >=20 >> On Thu, Aug 22, 2019 at 11:23 AM Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>=20 >>> Sebastian Gottschall writes: >>>=20 >>>> Am 22.08.2019 um 19:03 schrieb Dave Taht: >>>>> Sebastian Gottschall writes: >>>>>=20 >>>>>> Am 22.08.2019 um 15:15 schrieb Dave Taht: >>>>>>> It's very good to know how much folk have been struggling to = keep >>>>>>> things from OOMing on 32MB platforms. I'd like to hope that the >>>>>>> unified memory management in cake (vs a collection of QoS = qdiscs) and >>>>>>> the new fq_codel for wifi stuff (cutting it down to 1 alloc from = four) >>>>>>> help, massively on this issue, but until today I was unaware of = how >>>>>>> much the field may have been patching things out. >>>>>>>=20 >>>>>>> The default 32MB memory limits in fq_codel comes from the = stressing >>>>>>> about 10GigE networking from google. 4MB is limit in openwrt, >>>>>>> which is suitable for ~1Gbit, and is sort of there due to = 802.11ac's >>>>>>> maximum (impossible to hit) of a txop that large. >>>>> I did kind of conflate "qos + fq_codel" vs wifi in this message. = It >>>>> looks like yer staying with me. >>>>>=20 >>>>>>> Something as small as 256K is essentially about 128 full size = packets >>>>>>> (and often, acks from an ethernet device's rx ring eat 2k). >>>>>> what i miss in mac80211 is the following option "fq_codel =3D = off" >>>>>> its essential and i will definitly work on a patch to deal with = this >>>>>> way for low memory 802.11n platforms. >>>>> Well, it would be my hope that turning it off would A) not help = that >>>>> much on memory or cpu and B) show such a dramatic reduction in >>>>> multi-station performance that you'd immediately turn it on again. >>>> isnt it better to have a working platform with less performance = than a >>>> crashing platform with no performance? >>>> i mean i can user older mac80211 versions without that issue on a >>>> typical nanostation 2/5 which is often used just as CPE device >>>=20 >>> So before the queueing patches to mac80211, the maximum packet queue >>> size for ath9k was 3MB in total, or 2.2MB if only a single AC was = used >>> on the WiFi link (that's 128 packets in the driver + 1000 in the >>> pfifo_fast qdisc * 2074 bytes for the truesize of a full-size = packet). >>> Whereas now the default is 4MB for a non-vht device. So it's not >>> actually that big of a difference, and as you've already discovered = the >>> defaults can be changed. >>>=20 >>> Would it be helpful to add support for setting the memory limit in >>> hostapd (to avoid having to patch the kernel default)? >>=20 >> hmm. I guess exposing that via netlink, etc is a good idea. Me I just >> write the sys/kernel/debug/*/*/aqm files. >=20 > It already is, and you can set it through iw (as I pointed out > up-thread): >=20 > iw phy phy0 set txq memory_limit 2097152 >=20 > But it's not supported in hostapd, so you have to do that manually as = it > is now. >=20 >> btw: >>=20 >> qos_map in my mind, for APs at this point, should default to the best >> effort queue only. Not sure how to set that in openwrt (I just = patched >> it out of the kernel). >=20 > Think it's possible to set this in hostapd config; haven't tried it... I believe that OpenWrt's hostapd does not support that feature, = at least it did not last year when I looked... Best Regards Sebastian >=20 > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake