From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (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 BF41221F3A3; Tue, 2 Sep 2014 23:15:26 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x19so9072937ier.21 for ; Tue, 02 Sep 2014 23:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aNJ4E4YWNCxkGwKO2WIvZQ8/JJdqzTprFABwjYKNFbc=; b=IPjUBZcDRBkFAO+5NJvZnjkWVDjgfaFM5vcG8ggUop3hCPmJZRQ1PYrJyn7NPZ8KMG mfvLF8xypsnJFxW6Gh/uf+8ZpPdioG3qCSgV2uP5CM2e9tShTcc77Xvk9AYIgv6/lMt2 5SGlPqQ7jfjy+2QFImwddEClWgQpaCjs3aPevYxR+/DAdbthsaUlXfupvbJNg5a0P+Nk zsmKIIzdaOVnapedrYiHNhBPZMb1Guxq2i0Y0X66uAHDbT8hWcTsRHfFyvgdF0tH/Hl7 KyHjzdsf2XYHpCkDTnadxgIlqJdMdQNsb+sKTzlimbgTzMziyBbFVRO1S6ZGBB2t2GXr CkoA== MIME-Version: 1.0 X-Received: by 10.50.33.100 with SMTP id q4mr33614201igi.8.1409724925813; Tue, 02 Sep 2014 23:15:25 -0700 (PDT) Received: by 10.64.243.196 with HTTP; Tue, 2 Sep 2014 23:15:25 -0700 (PDT) In-Reply-To: References: <87ppfijfjc.fsf@toke.dk> <4FF4917C-1B6D-4D5F-81B6-5FC177F12BFC@gmail.com> <4DA71387-6720-4A2F-B462-2E1295604C21@gmail.com> <0DB9E121-7073-4DE9-B7E2-73A41BCBA1D1@gmail.com> Date: Tue, 2 Sep 2014 23:15:25 -0700 Message-ID: From: Aaron Wood To: Jonathan Morton Content-Type: multipart/alternative; boundary=089e0158b0346f2b010502232901 Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope... X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 06:15:27 -0000 --089e0158b0346f2b010502232901 Content-Type: text/plain; charset=UTF-8 > > What this makes me realize is that I should go instrument the cpu stats > with each of the various operating modes: > > * no shaping, anywhere > * egress shaping > * egress and ingress shaping at various limited levels: > * 10Mbps > * 20Mbps > * 50Mbps > * 100Mbps > So I set this up tonight, and have a big pile of data to go through. But the headline finding is that the WNDR3800 can't do more than 200Mbps ingress, with shaping turned off. The GbE switch fabric and my setup were just fine (pushed some very nice numbers through those interfaces when on the switch), but going through the routing engine (NATing), and 200Mbps is about all it could do. I took tcp captures of it shaping past it's limit (configured for 150/12), with then rrul, tcp_download, tcp_upload tests. And I took a series of tests walking down from 100/12, 90/12, 80/12, ... down to 40/12, while capturing /proc/stats and /proc/softirqs once a second (roughly), so that can be processed to pull out where the load might be (initial peeking hints that it's all time spent in softirq). If anyone wants the raw data, let me know, I'll upload it somewhere. The rrul pcap is large, the rest of it can be e-mailed easily. -Aaron --089e0158b0346f2b010502232901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What this makes me realize is that I should go instrument the cpu stats wit= h each of the various operating modes:

* no shaping,= anywhere
* egress shaping
* egress and ingress shaping at various limited = levels:
=C2=A0 =C2=A0 * 10Mbps
=C2=A0 =C2=A0 * 20Mbps
=C2=A0 =C2=A0 * 50Mbps
=C2=A0 =C2=A0 * 100Mbps

So I set this up tonight, and have a big pile of data to go thro= ugh. =C2=A0But the headline finding is that the WNDR3800 can't do more = than 200Mbps ingress, with shaping turned off. =C2=A0The GbE switch fabric = and my setup were just fine (pushed some very nice numbers through those in= terfaces when on the switch), but going through the routing engine (NATing)= , and 200Mbps is about all it could do.

I took tcp captures of it shaping past it's limit (= configured for 150/12), with then rrul, tcp_download, tcp_upload tests.

And I took a series of tests walking down from 100/12= , 90/12, 80/12, ... down to 40/12, while capturing /proc/stats and /proc/so= ftirqs once a second (roughly), so that can be processed to pull out where = the load might be (initial peeking hints that it's all time spent in so= ftirq).

=C2=A0If anyone wants the raw data, let me know, I'= ll upload it somewhere. =C2=A0The rrul pcap is large, the rest of it can be= e-mailed easily.

-Aaron

=
--089e0158b0346f2b010502232901--