From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 494353CB36 for ; Thu, 22 Aug 2019 15:37:43 -0400 (EDT) Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 528DF7BDAE for ; Thu, 22 Aug 2019 19:37:42 +0000 (UTC) Received: by mail-ed1-f71.google.com with SMTP id u3so3946169edm.13 for ; Thu, 22 Aug 2019 12:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=FL9VPPp3yTD9fTdX+QksmVSSpDGorzTRhHdxOZ2CiQk=; b=m1JX6GQDdVxwFPWMk4aQjbbcStsKkDd6F5NilgDK0WfDFAeYr0ZGFQpZSeCa+4C233 aD6JYRIcph1/sOMusfgrnL6n/7c1b2AfuwiypEOCBA8BcBgz7RdZXJvdNsDktkMCBzC/ YSs34yf0ZeRk7tiqXfsLH2LnfyoxSlnpLg0J2kZY1mX74Us1p90aMYpEJY7XFqsO9Ju2 9x5RmIrwxIxXLYsOYonj3lS5MZ+ic7qCaqzh+LNeDGFCax2XTak8lGNrQA3qrl1fgCGx jq5ChKmtwAt0xHdegpQyy0t1WNMGN+qkNbzzUUifFteE5S+opdbX0YQfJO9I6DVCI5K6 6sHw== X-Gm-Message-State: APjAAAXyEq8D+fPd7HQoPGLN6jrSRN2GFXsf7PzhKoqdCuvGifC6gq01 ix/vXFRxuf5N45J3nHbIomZIRgs67ueQs0YB1LT7G4/o1CUfb7+wof8e3AcJGHMtvqFPKcL3QLE 7uSQ2vCGPbpuwBb5S8Drq0A== X-Received: by 2002:a17:906:80da:: with SMTP id a26mr923835ejx.222.1566502661065; Thu, 22 Aug 2019 12:37:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqyCvq/bVyvt5eTzWyZOiZv7tXRBcq+3zw+g7QRnC6o224aAF7VkHn8MzkBg0568B7MZ8GBHug== X-Received: by 2002:a17:906:80da:: with SMTP id a26mr923812ejx.222.1566502660781; Thu, 22 Aug 2019 12:37:40 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id y37sm68656edb.42.2019.08.22.12.37.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 12:37:40 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5048C181CEF; Thu, 22 Aug 2019 21:37:39 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht Cc: Cake List , Sebastian Gottschall , Make-Wifi-fast , Dave Taht , Battle of the Mesh Mailing List In-Reply-To: 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> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 22 Aug 2019 21:37:39 +0200 Message-ID: <87ef1dng8s.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [Battlemesh] Wifi Memory limits in small platforms 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 19:37:43 -0000 Dave Taht writes: > On Thu, Aug 22, 2019 at 11:23 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Sebastian Gottschall writes: >> >> > Am 22.08.2019 um 19:03 schrieb Dave Taht: >> >> Sebastian Gottschall writes: >> >> >> >>> 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) a= nd >> >>>> the new fq_codel for wifi stuff (cutting it down to 1 alloc from fo= ur) >> >>>> help, massively on this issue, but until today I was unaware of how >> >>>> much the field may have been patching things out. >> >>>> >> >>>> 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. >> >> >> >>>> Something as small as 256K is essentially about 128 full size packe= ts >> >>>> (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 >> >> 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. >> >> Would it be helpful to add support for setting the memory limit in >> hostapd (to avoid having to patch the kernel default)? > > hmm. I guess exposing that via netlink, etc is a good idea. Me I just > write the sys/kernel/debug/*/*/aqm files. It already is, and you can set it through iw (as I pointed out up-thread): iw phy phy0 set txq memory_limit 2097152 But it's not supported in hostapd, so you have to do that manually as it is now. > btw: > > 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). Think it's possible to set this in hostapd config; haven't tried it... -Toke