From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 78E033B260; Fri, 6 May 2016 04:41:58 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MTSKd-1b76Au0ez1-00SRtG; Fri, 06 May 2016 10:41:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Fri, 6 May 2016 10:41:53 +0200 Cc: Eric Dumazet , Jonathan Morton , Roman Yeryomin , "codel@lists.bufferbloat.net" , ath10k , make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <542135C7-D7CC-4E33-B35B-C2AD259FA5AB@gmx.de> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:PhU8DMFx6QVPst6NHFcHMC7QUcyymSViprzEaxtutuEpWNHbpRW wYY8QuoJLKZSOgzAdTg5M4/D4UeguYhEIQQ75lQpeUqoI9AwZoFhmKM6wq/DeJZLhCDnYFZ l1pd9FeUXbQs8g6v8g7D5xMBEMlO+cyNS6/Qtn0+M6Z0FXaSSlqbjJ2ZklgGxx1xEIx3XJ8 s0JI8yBEn+PCaLoFRK2Ag== X-UI-Out-Filterresults: notjunk:1;V01:K0:zjRAihByLFs=:4oLCeqYAWidAVp2Dhu5Ymq e81SaWAsDdasdhc5PkpCClsp02Mhl/nrysXAGRhLclKWbtVNYCDd3pL7a1U6U5aoQ0F/aKF5x 9XW81s23kgB2Bh6Vb9Qr/HWLS+vSLqvRDotfImsUmFrr6JhEHvV9JDQUxbA56fRlKd0ywOk5G MJ/u5YXowCgqm3RFcJgSNxdusT3c7ggEhdIZhqk18hru+accpV6SoxugwQ7uoO8/CrNtt9nLM UxUClY4R3r5l117aULJlTTxHcXhwKwvZq8nxYnOUVNTCE2ciz253jGIAo3tzOCXmqlRw4TGnF VrljhMx0qCJfjR0CVy9zi//fXIy2CfHSSO1MiIlA+FW1Q4eGGzyMkMUxvUZ8XLQu79Wi4fE5z J5DpP8fZD/4Jd/ZjVTb54Eg9ojJD83iVlABJAsI/xyMG1U0JNjLH8DONsFJcgH45zakxY7xEO 32irPapbIOM6x8s8O3KajKMpt0eFF42lDeT9id84XfKIuM6acv+TJXnpgK1Jj8/Vrqt0F1smn 1PZgWFAWVUaxBVOPcQiEERoqeRdqO2ulIIOCGLbmCCPFTtF3sjeXoglUpxVwSdGH5iOsAsxIs 2OZdZ/+D4/hAvXnLCsEq0M2iPqJ58v/fbw4AVgllJ9TGo0Cp1/5fV9lPnmMBkV0xiWhxz6Cic qKaAJKKIG5+mHUsINFvFXQpdizqsLlHzlYTaQ145sTr+qPnVo7s6waIhr9eF1VP/Hajj9vUn0 85LQCe28gS/TieTUpg2oUDutNqGREOtUafk48Zi6AkQr4NQSt5KdBswOyaJMDPWSYZmZQa/3N /ArzGGT Subject: Re: [Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood 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: Fri, 06 May 2016 08:41:58 -0000 Hi All, > On May 5, 2016, at 21:41 , Dave Taht wrote: >=20 > On Thu, May 5, 2016 at 12:23 PM, Eric Dumazet = wrote: >> On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote: >>> On 5 May 2016 at 19:12, Eric Dumazet wrote: >>>> [=E2=80=A6] >>=20 >> fq_codel has a default of 10240 packets and 1024 buckets. >>=20 >> http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413 >>=20 >> If someone changed that in the linux variant you use, he probably = should >> explain the rationale. >=20 > I guess that would be me. IIRC, I was making a a lot og noise back then as well. >=20 > Openwrt has long shipped with the fq_codel default outer queue limit > being lower than the default (e.g. 1024). Think: itty bitty 32MB > routers. 10240 packets can =3D boom, particuarly while there were 4 > fq_codel instances per wifi interface (and people in the habit of > creating 2 or more wifi interfaces). In my case I could force a OOM reboot of my 64MB router by a = =E2=80=9Csimple=E2=80=9D unidirectional UDP flood with randomized port = numbers; at 10240 packet limit that was eating approximately 20MB of the = 64 MB ram of the device which made it go =E2=80=9Cboom=E2=80=9D. I tried = to convince people that bad queueing is not the most important concern = under those conditions, staying up is rather more important=E2=80=A6=20 >=20 > back then: I viewed the probability of flooding all 1024 queues as low > and thus the queue depth would be sufficient for any given set of > flows to do well. (and long ago we gave codel a probability of working > on all queues). And did not do enough udp flood testing. :( I would argue that the main goal for behaviour under attack = should be (IMHO) =E2=80=9Cstaying alive=E2=80=9D rather than unscheduled = OOMs reboots/crashes. Keeping the lights on so to speak should be the = first priority followed by trying to still maintain fairness guarantees. >=20 > Totally not the right answer, I know. And the problem is even worse > now, with 128MB arm boxes like the armada 385 (linksys 1200ac, turris > omnia) using software GRO to be bulking up 64k packets at gigE and > trying to ship them to an isp at 5mbit, or over wifi at some rate > lower than that. >=20 > cake switched to byte, rather than packet, accounting, for these > reasons, and we're still trying various methods to peel apart > superpackets at some load level efficiently. Speaking out of total ignorance, I ask why not account GRO/GSO = packets by the number of their fragments against the packet limit? = Counting a 64kB packets as equivalent to a 64B packet probably is the = right thing if one tries to account for the work the OS needs to perform = to figure out what to do with the packet, but for limiting the memory = consumption it introduces an impressive/manly level of uncertainty (2 = orders of magnitude).=20 Best Regards Sebastian >=20 > And routers are tending to ship with a lot more memory these days, > overall. We are discussing changing the sqm system to dynamically size > the packet limit by overall memory limits here, for example: > https://github.com/tohojo/sqm-scripts/issues/42 >=20 > AND: As sorta now implemented in the mac80211 fq_codel code, it's per > radio, rather than per interface (or was, when I last thought about > it), which is *vastly saner* than four fq_codel instances for each > SSID. >=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel