From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by lists.bufferbloat.net (Postfix) with ESMTPS id DC3DC3ED11 for ; Mon, 21 Dec 2015 08:05:04 -0500 (EST) Received: from u-089-d060.biologie.uni-tuebingen.de ([134.2.89.60]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LwJko-1aFgqR0M6o-0183Ws; Mon, 21 Dec 2015 14:05:01 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Mon, 21 Dec 2015 14:05:02 +0100 Cc: Kevin Darbyshire-Bryant , Jonathan Morton , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <85A5A21C-E468-4F81-8A36-0F1AD6C84435@gmx.de> References: <6F86FBB0-AA69-44F3-82D0-31465906974D@gmx.de> <56657A82.2080601@darbyshire-bryant.me.uk> <95560E7E-DEAF-40D8-B704-CEA38A0CDE62@gmx.de> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:0c/0uQUhrvC4fvZqGDywNdObtE1fLIvqTkUpTqEJYtEdDu75+nY 1oAzneBfAf3Duw/N3khKUZvpEysegp6a4ZjNTeIQDG7G31qM6T4i1WZH8+fDLbPWHy/yisY CtG3O2OMsDNIHWr8qnn7I6H+/sWz2NoX/H43O8/DIFDSyCnKdJDguRTKWqqpc4YB6vSwocj pbDXoZ0sPj/NCwxX3zJ7g== X-UI-Out-Filterresults: notjunk:1;V01:K0:o5vTy7tq2iY=:2cT5kOEnWszkQEdox1uV/U /b+/rNw2koFiroNVGO1cAgcVihc160vCeohKsh3cv+PuuwTZtBlUe9Qosd5cGAIdeKitnpGTl akLTMZvvG75B8uw939Df+U6FcWONK8U87EOXkYd/Spa8BkmTpZ3M/17rZuwrmpF3A1BbjL3QZ WsmI6Pgk7cDN1749AJWVB2lugZZpAn5XwRhi+81+k8OOGV8mqRxINvw6qFk34Ogtgm22quplC DlZP0zwtYDxaPPAl94fyKNxmTrxJUqeLztWm4jsxlb1eejvl3TNPIxdg2k5yjeZqDGUJNbXFc OFZaTRclP4OtavmBgG6XTwv/3ww0B417PNgQnbxpNG+zi3Yym2EsfhKpszBdNZF2loZohkjHR icC1pBiFB+KnZHlFubDT/2UqV9GxAbC9uWscBrmvj+fww72XyfqEXRKK0tlxJy1tQiXA4Mrrz EeHtkhL87g4Jkdr5GsKwXI2NLvx08H+AQNH/Hau3VmH61V2aU8e4z50bzTzxpRyMeKVS4idr0 IktTNxd90NNpz5l9wpU8yqGmqnW6tF+EyiB5ovWdTl/QxyoUx7kcSpbsUxnrfZvvNULjZV5e4 kYZkg9gMZRpIQeMxGdiHRJQoC8VXpY2+F0MyQJnd5oC2rnGNeCEu1/4+w0EfP+LIXXGQGQmMm peOvnwbSR7KpIrd6PCllbtB/SJsrE+qk/t0nVyuQ3zTfHPm9h3ZsTlrNOl4GVSXnqBGiE554x mN0UHQSmq5kQCA+9SXa/hHcdwpfWVjig2dy1mpRot2WxA40QFKxN1seKAFkZspZPwgn6y0EAS gzkzoVR Subject: Re: [Cake] second system syndrome 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: Mon, 21 Dec 2015 13:05:05 -0000 Hi Dave, > On Dec 21, 2015, at 13:00 , Dave Taht wrote: >=20 > in terms of the pppoE stuff needing elevated priority, this is code > that doesn't exist already and is already handled by the fast/slow > queue stuff in fq_codel? So I am still working on and off on my pet idea of shaping on a physical = interface (say ge00 in cerowrt parlance) instead of pope-ge00. In that = case we actually see all PPPoE-pakets (like PADI, PADO and friends see = https://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet#PPPoE_= Discovery_.28PPPoED.29) and since all other traffic relies on the status = of the =E2=80=9CPPP tunnel=E2=80=9D these deserve the highest priority. = Since they are relatively rare, current fq_codel+htb sort of works okay = (well, I try steering everybody to set up sqm on the pppoe interface to = actually avoid stepping into this mess), but the shaper will have no = information about the maintenance packets at all and hence will slightly = undershape the link (undershape as in not shaping sufficiently). As far = as I can tell the PPPoE deamon uses LCP echoes to test the link state, = now these are only sent once per second (on cerowrt) but miss/drop 5 of = these in a row and the PPP connection is teared down and reestablished = which takes a while, potentially long enough for all active flows to = time out, not nice=E2=80=A6 Especially since it is possible to drive sqm = into drop-tail behavior by simply flooding it, do this for a few seconds = and watch PPPoE disconnect... =09 The challenge of shaping on PPPoE instead, is that the kernel accounts = different amounts of overhead for ingress and egress there. In case you = wonder fq_codel=E2=80=99s maxpacket statistics helped me figuring that = out by simply looking at the maxpacket sizes for pppoe-ge00 (maxpacket = 1516) and ifb4pppoe-ge00 (maxpacket 1538), which for all I know is just = a heuristic and not real proof. The numbers themselves are easily = explained given that I have an overhead of 24 bytes specified: 1516-24 =3D= 1492 this is the PPPoE payload (the 8 byte PPP + PPPoE header live = inside the classical ethernet MTU) and 1538-24 =3D 1514 (were the kernel = helpfully added part of the ethernet overhead: 6 (dest MAC) + 6 (src = MAC) + 2 (ether type) but forgot all about the other ethernet details = worth 24 more Byte on the wire). All of which makes me wish the kernel would leave the overhead = handling completely to user space, because it clearly is doing something = complicated (at least given the scarcity of information besides RTF = source code). I guess I can fix^Wwork-around this by teaching sqm to = handle ingress and egress overhead independently. Best Regards Sebastian=