From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A0C0D21F317 for ; Tue, 24 Mar 2015 01:46:39 -0700 (PDT) Received: from u-089-d060.biologie.uni-tuebingen.de ([134.2.89.60]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7HGA-1ZOb7d3PV8-00x3t0; Tue, 24 Mar 2015 09:46:35 +0100 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: Date: Tue, 24 Mar 2015 09:46:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:Y7L+M48xaKfpdDhvBpfYCrCkz5OW5ZBC80W90eEoGQGDtHl/i6L 1DAYfcjMcLdbEePseaGF+xozjuynZ0wSTDQIwAVTi6zASez4djRIU7Y/vKUydiVmRppgBeR XnFhPWyF1Z1nbIYO9184CaF/4D0K5rcalkRzt1E8Lr5hGY0V9eXmQ4eCellsQLwJM8/NPZg gvp+G4ksG9wn7T+z25lpQ== 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: Tue, 24 Mar 2015 08:47:08 -0000 Hi Jonathan, On Mar 24, 2015, at 09:13 , Jonathan Morton = wrote: > What I'm seeing on your first tests is that double egress gives you = slightly more download at the expense of slightly less upload = throughout. The aggregate is higher. But it is only slightly higher, and the uplink is not really = saturated, it should be at around 30Mbps not 10 Mbps. Just to be clear = we are talking about the same data: columns 5 and 6 are without sqm = running, showing the download approaching the theoretical maximum, but = pummeling the upload while doing so, cerowrt 3.10.50-1 might hit other = limits besides shaping that limit the performance in this situation; the = initial double egress columns are 3 and 4. >=20 > Your second set of tests tells me almost nothing, because it exercises = the upload more and the download less. Why nothing? By reducing the total load on the shaper we can now = see that avoiding the IFB overhead increases the upload by roughly = 10Mbps, almost doubling it. IMHO this is the only real proof that = ingress shaping via IFB has some cost associated. I realize that the IFB = directly only affects the download direction but in this case the = recovered CPU cycles seem to be used to increase the upload performance = (which due to using simple instead of amplest.qos was costlier than it = needed be). > Hence why I'm asking for effectively the opposite test. The aggregate = is still significantly higher with double egress, though. I have not performed any statistical test, so I am talking about = subjective significance here, but I be the significance of the upload = increase in the dual_symmetric_egress (columns 7 and 8) is going to be = higher than the significance of the download increase in the = double_egress situation (columns 3 and 4: larger mean difference similar = variance, from quick visual inspection ;) ) >=20 > The ping numbers also tell me that there's no significant latency = penalty either way. Yes, the ping numbers are pretty nice, but even with SQM = disabled the worst case latency is not too bad (not sure why though, I = remember it to be much worse). Also the IPv6 RTT to Sweden seems = consistently better than the IPV4 RTT; but then again this is DTAG = linked, with DTAG=92s new network being designed in Sweden, so maybe = this is piggy-backing on their testing set-up or so ;) . > Even when CPU saturated, it's still effectively controlling the = latency better than leaving the pipe open. Many thanks for the discussion & Best Regards Sebastian >=20 > - Jonathan Morton