From: David Lang <david@lang.hm>
To: Aaron Wood <woody77@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope...
Date: Tue, 2 Sep 2014 23:36:41 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1409022326420.433@nftneq.ynat.uz> (raw)
In-Reply-To: <CALQXh-Ncs5itEOj9KmePbwdRCKKGX4t3JC8ysg9SWOcVRQ2dMQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/Plain, Size: 2047 bytes --]
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
>
[-- Attachment #2: Type: TEXT/PLAIN, Size: 140 bytes --]
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
next prev parent reply other threads:[~2014-09-03 6:37 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 16:57 Aaron Wood
2014-08-29 17:03 ` Rick Jones
2014-08-29 17:11 ` Steinar H. Gunderson
2014-08-29 17:26 ` Jonathan Morton
2014-08-29 17:15 ` Jonathan Morton
2014-08-29 17:19 ` Jonathan Morton
2014-08-29 17:25 ` Sebastian Moeller
2014-08-29 18:06 ` Dave Taht
2014-08-30 11:02 ` Jonathan Morton
2014-08-30 13:03 ` Toke Høiland-Jørgensen
2014-08-30 17:33 ` Jonathan Morton
2014-08-30 20:47 ` Jonathan Morton
2014-08-30 22:30 ` Dave Taht
2014-08-31 10:18 ` Jonathan Morton
2014-08-31 10:21 ` Toke Høiland-Jørgensen
2014-09-01 17:01 ` Dave Taht
2014-09-01 18:06 ` Jonathan Morton
2014-09-01 18:32 ` Dave Taht
2014-09-01 20:25 ` Aaron Wood
2014-09-01 21:43 ` Jonathan Morton
2014-09-01 22:14 ` Aaron Wood
2014-09-02 9:09 ` David Lang
2014-09-02 9:27 ` Jonathan Morton
2014-09-03 6:15 ` Aaron Wood
2014-09-03 6:36 ` David Lang [this message]
2014-09-03 11:08 ` Jonathan Morton
2014-09-03 15:12 ` Aaron Wood
2014-09-03 19:22 ` [Bloat] [Cerowrt-devel] " Sebastian Moeller
2014-09-03 19:30 ` Dave Taht
2014-09-03 23:17 ` Bill Ver Steeg (versteb)
2014-09-04 0:33 ` Dave Taht
2014-09-04 3:36 ` Jonathan Morton
2014-09-04 14:05 ` Bill Ver Steeg (versteb)
2014-09-04 15:10 ` Michael Richardson
2014-09-04 7:04 ` Sebastian Moeller
2014-09-04 11:15 ` Jonathan Morton
2014-09-04 11:23 ` Sebastian Moeller
2014-09-02 8:55 ` Sebastian Moeller
2014-09-02 13:40 ` [Bloat] " Jonathan Morton
2014-09-02 15:37 ` Dave Taht
2014-09-02 15:47 ` Jonathan Morton
2014-09-02 17:36 ` Jonathan Morton
2014-09-02 17:41 ` Dave Taht
2014-09-02 18:28 ` Jonathan Morton
2014-09-03 11:04 ` Jonathan Morton
2014-08-30 21:53 ` Stephen Hemminger
2014-08-30 11:14 ` Jonathan Morton
2014-08-30 17:19 ` Aaron Wood
2014-08-30 18:01 ` Jonathan Morton
2014-08-30 18:21 ` [Bloat] [Cerowrt-devel] " Sebastian Moeller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1409022326420.433@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=woody77@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox