From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E085821F225 for ; Sun, 29 Mar 2015 05:48:16 -0700 (PDT) Received: by lahp7 with SMTP id p7so80648484lah.2 for ; Sun, 29 Mar 2015 05:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=daidADuw7x87/8fpwztPc/0HzxDeCQaBOZtBq3/JNMs=; b=MufSK2HdVLEPD8IYXOtavT5GfwTXOxA+qXtSSlW9Iwz9EQNbA4u3TajcmBTL+9F4Tw F2/wLFksRryRg7sMCZ7PEqK5IPGqOwKelDfrfgQcX+oBviTHm9M9huL0u/VTPrZ/gEHZ popO7Cwbg/baeVXXs0WDDfuRjG+b+9H8u6fZcKr2JoBVn8H/kbTxMJSbKgItPLzF7SS1 cJmXnV4aS86n+QCUmomj1YR+xkzyEvgQl3BlD4cUxXi2mMoBJLXs8uYKjbzd2+Dm12Ck n0TLxibUSLEyXxPg5FFvswTg2iwCKCwrFir2i7qGDg1Pe9AjWFGLWsH1UgsW/mjHlAOe Bcsg== X-Received: by 10.152.43.3 with SMTP id s3mr25145912lal.101.1427633294002; Sun, 29 Mar 2015 05:48:14 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-163-98.bb.dnainternet.fi. [87.95.163.98]) by mx.google.com with ESMTPSA id d3sm1454323lbc.39.2015.03.29.05.48.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 05:48:13 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Morton In-Reply-To: Date: Sun, 29 Mar 2015 15:48:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <91FFBFA0-0E87-4A57-AF6C-83C42AB10D1D@gmail.com> 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> To: Sebastian Moeller X-Mailer: Apple Mail (2.2070.6) 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 12:48:45 -0000 > On 29 Mar, 2015, at 14:16, Sebastian Moeller wrote: Okay, so it looks like you get another 5% without any shaping running. = So in summary: - With no shaping at all, the router is still about 10% down compared to = downstream line rate. - Upstream is fine *if* unidirectional. The load of servicing = downstream traffic hurts upstream badly. - Turning on HTB + fq_codel loses you 5%. - Using ingress filtering via IFB loses you another 5%. - Mangling the Diffserv field loses you yet another 5%. 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. 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; 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. 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. >> 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 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. 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. Your results suggest that investigating this possibility might still be = worthwhile. Whether anything will come of it, I don=92t know. - Jonathan Morton