From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F187321F2AA for ; Sun, 29 Mar 2015 07:16:54 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LbMF8-1ZIjqj1DUw-00kwYF; Sun, 29 Mar 2015 16:16:51 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <91FFBFA0-0E87-4A57-AF6C-83C42AB10D1D@gmail.com> Date: Sun, 29 Mar 2015 16:16:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9943A1F0-70B9-4162-9858-D04E223163B5@gmx.de> References: <08BAF198-87C5-42B8-8899-53F34E47156E@gmail.com> <896FAE61-B45A-4F34-9449-5ADB82194DD9@gmx.de> <48350C2E-C33A-4534-84BC-5D56F4AAF0EA@gmail.com> <8AC58249-8199-405B-997A-E8F7285A34FB@gmx.de> <3615CBEA-5DC1-4722-9EE9-13B3570E8118@gmx.de> <91FFBFA0-0E87-4A57-AF6C-83C42AB10D1D@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:g0D+35nVoKpvkNmKVcYtPMn8GyqJzP/ToHFN1UdUkAshtZLV0Qy CLg+rVrU6OhYXYTW73X08eznmJKWCvuzfXGzkfvL1g1EJJY/DOEOTzPbhi/8hQtebIU2RyB /HrNgKsJjPC/LGIfVKMMik9PiPN2Ylt6K0oBzC1koTAVUPcIVBM/zLJG6lZaR5Tl/Kcc/ku htP/idANDbiOP9m13oeQw== X-UI-Out-Filterresults: notjunk:1; Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] archer c7 v2, policing, hostapd, test openwrt build X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 14:17:27 -0000 Hi Jonathan, On Mar 29, 2015, at 14:48 , Jonathan Morton = wrote: >=20 >> On 29 Mar, 2015, at 14:16, Sebastian Moeller wrote: >=20 > Okay, so it looks like you get another 5% without any shaping running. = So in summary: >=20 > - With no shaping at all, the router is still about 10% down compared = to downstream line rate. Yes, roughly, but as I tried to explain, this is known quirk = currently with VDSL2 lines of DTAG using vectoring, somehow the worst = case overhead of the G.INP error correction is subtracted from the = shaped rate at the BRAS, so this ~10% is non-recoverable from the user = side (it is confusing though). > - Upstream is fine *if* unidirectional. The load of servicing = downstream traffic hurts upstream badly. Yes, that is a theme though all the different variants of the = tests I did. > - Turning on HTB + fq_codel loses you 5%. I assume that this partly is caused by the need to shape below = the physical link bandwidth, it might be possible to get closer to the = limit (if the true bottleneck bandwidth is known, but see above). > - Using ingress filtering via IFB loses you another 5%. > - Mangling the Diffserv field loses you yet another 5%. >=20 > Those 5% penalties add up. People might grudgingly accept a 10% loss = of bandwidth to be sure of lower latency, and faster hardware would do = better than that, but losing 25% is a bit much. But IPv4 simple.qos IFB ingress shaping: ingress 82.3 Mbps = versus 93.48 Mbps (no SQM) =3D> 100 * 82.3 / 93.48 =3D 88.04%, so we = only loose 12% (for the sum of diffserv classification, IFB ingress = shaping and HTB) which seems more reasonable (that or my math is wrong).=20= But anyway I do not argue that we should not aim at decreasing = overheads, but just that even without these overheads we are still a = (binary) order of magnitude short of the goal, a shaper that can do up = to symmetric 150Mbps shaping let alone Dave=92s goal of symmetric 300 = Mbps shaping. > I should be able to run similar tests through my Pentium-MMX within a = couple of days, so we can see whether I get similar overhead numbers out = of that; That will be quite interesting, my gut feeling is that the = percentages will differ considerably between machines/architectures. > I can even try plugging in your shaping settings, since they=92re = (just) within the line rate of the 100baseTX cards installed in it. I = could also compare cake=92s throughput to that of HTB + fq_codel; I=92ve = already seen an improvement with older versions of cake, but I want to = see what the newest version gets too. I really hope to try cake soon ;) >=20 > Come to think of it, I should probably try swapping the same cards = into a faster machine as well, to see how much they influence the = result. >=20 >>> You see, if we were to use a policer instead of ingress shaping, = we=92d not only be getting IFB and ingress Diffserv mangling out of the = way, but HTB as well. >>=20 >> But we still would run HTB for egress I assume, and the current = results with policers Dave hinted at do not seem like good candidates = for replacing shaping=85 >=20 > The point of this exercise was to find out whether a theoretical, = ideal policer on ingress might - in theory, mind - give a noticeable = improvement of efficiency and thus throughput. I think we only have 12% left on the table and there is a need = to keep the shaped/policed ingress rate below the real bottleneck rate = with a margin, to keep instances of buffering =93bleeding=94 back into = the real bottleneck rare=85,=20 >=20 > The existing policers available are indeed pretty unsuitable, as = Dave=92s tests proved, but there may be a way to do better by adapting = AQM techniques to the role. In particular, Codel=92s approach of = gradually increasing a sparse drop rate seems like it would work better = than the =93brick wall=94 imposed by a plain token bucket. >=20 > Your results suggest that investigating this possibility might still = be worthwhile. Whether anything will come of it, I don=92t know. Good point. Best Regards Sebastian >=20 > - Jonathan Morton >=20