From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 73F1021F41B; Wed, 3 Sep 2014 04:08:08 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id mc6so9490632lab.23 for ; Wed, 03 Sep 2014 04:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lul0doHDjQdr1pT+pEJkmIYL+4w5v0fZ4ClHm3dqZpE=; b=Ne38hALx3544YMqRe4KWgrw25DwnfEMSTmx1codCLRybn28jRKL7AkjwdJxn6al+f2 w3kD7EwLB/w+O0BrjuYjrtug3CHP5SwEAKKQhiYxIYElyJO0kWZjSniRe/vJuj++z2J+ yJAkwa3DMw7x4MadWSczqGvAdNPZuTjU28W0gTXaRRxcPpk2U9JFztqFLZTK6gHxz2Ru l30kqi1Kg2bEN1La0+4sNWgLpdA5cD0AOsSPgn20DcBzbyv0ecaUxvgV3ZVwOf8YzLS/ KVqmPR7vCT2bIma2t8CItRS++gM9/rutYCb//JSlG0cmTMGj2qMLJzwJruP5fCXcjzvE HSrg== X-Received: by 10.112.135.230 with SMTP id pv6mr1988833lbb.105.1409742485776; Wed, 03 Sep 2014 04:08:05 -0700 (PDT) Received: from bass.home.chromatix.fi (178-55-226-0.bb.dnainternet.fi. [178.55.226.0]) by mx.google.com with ESMTPSA id a2sm8603604lbg.19.2014.09.03.04.08.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 04:08:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Wed, 3 Sep 2014 14:08:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0D3E3220-C12A-4238-974B-D83D13EF354E@gmail.com> 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> To: Aaron Wood X-Mailer: Apple Mail (2.1085) 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 11:08:09 -0000 On 3 Sep, 2014, at 9:15 am, Aaron Wood wrote: > What this makes me realize is that I should go instrument the cpu = stats with each of the various operating modes: >=20 > * no shaping, anywhere > * egress shaping > * egress and ingress shaping at various limited levels: > * 10Mbps > * 20Mbps > * 50Mbps > * 100Mbps >=20 > 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. >=20 > I took tcp captures of it shaping past it's limit (configured for = 150/12), with then rrul, tcp_download, tcp_upload tests. >=20 > 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). >=20 > 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. Given that the CPU load is confirmed as high, the pcap probably isn't as = useful. The rest would be interesting to look at. Are you able to test with smaller packet sizes? That might help to = isolate packet-throughput (ie. connection tracking) versus = byte-throughput problems. - Jonathan Morton