From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0DCFA21F29C; Tue, 2 Sep 2014 23:37:11 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s836afqh016085; Tue, 2 Sep 2014 23:36:41 -0700 Date: Tue, 2 Sep 2014 23:36:41 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Aaron Wood In-Reply-To: Message-ID: 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============3912872492254902126==" 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:37:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============3912872492254902126== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII On Tue, 2 Sep 2014, Aaron Wood wrote: >> >> 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. it's actually probably the connection tracking, not the routing engine or iptables. I've seen this a lot on high-traffic systems. I saw something earlier this week about how the connection tracking has a global lock, so it's effectivly single threaded, but there is work being done to fix this. Now, lock contention isn't an issue on a single-core box like the 3800, but the rest of the work is. If you can find a place to set it up without NAT, (or with 1:1 NAT that doesn't need connection tracking), you will see much better performance from it. For the Scale conference, I disable connection tracking and run them as bridges to a dedicated VLAN per SSID and do the firewalling and NAT upstream from the APs David Lang > 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 > --===============3912872492254902126== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat --===============3912872492254902126==--