From: Dave Taht <dave.taht@gmail.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Felix Fietkau <nbd@openwrt.org>,
Sujith Manoharan <sujith@msujith.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Avery Pennarun <apenwarr@google.com>
Subject: Re: TCP performance regression
Date: Mon, 11 Nov 2013 11:24:37 -0800 [thread overview]
Message-ID: <CAA93jw4By5d2JRzMCooXM2nV2bdUfqwKCivP1ktb3wGa1wNkww@mail.gmail.com> (raw)
In-Reply-To: <52812BF2.7090605@candelatech.com>
On Mon, Nov 11, 2013 at 11:11 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 11/11/2013 10:31 AM, Dave Taht wrote:
>> Ah, this thread started with a huge regression in ath10k performance
>> with the new TSQ stuff, and isn't actually about a two line fix to the
>> mv ethernet driver.
>>
>> http://comments.gmane.org/gmane.linux.network/290269
>>
>> I suddenly care a lot more. And I'll care a lot, lot, lot more, if
>> someone can post a rrul test for before and after the new fq scheduler
>> and tsq change on this driver on this hardware... What, if anything,
>> in terms of improvements or regressions, happened to multi-stream
>> throughput and latency?
>>
>> https://github.com/tohojo/netperf-wrapper
>
> Not directly related, but we have run some automated tests against
> an older buffer-bloat enabled AP (not ath10k hardware, don't know the
> exact details at the moment), and in general the performance
> is horrible compared to all of the other APs we test against.
I was not happy with the dlink product and the streamboost
implementation, if that is what it was.
> Our tests are concerned mostly with throughput.
:(
> For reference, here are some graphs with supplicant/hostapd
> running on higher-end x86-64 hardware and ath9k:
>
> http://www.candelatech.com/lf_wifi_examples.php
>
> We see somewhat similar results with most commercial APs, though
> often they max out at 128 or fewer stations instead of the several
> hundred we get on our own AP configs.
>
> We'll update to more recent buffer-bloat AP software and post some
> results when we get a chance.
Are you talking cerowrt (on the wndr3800) here? I am well aware that
it doesn't presently scale well with large numbers of clients, which
is awaiting the per-sta queue work. (most of the work to date has been
on the aqm-to-the-universe code)
This is the most recent stable firmware for that:
http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.17-6/
I just did 3.10.18 but haven't tested it.
Cero also runs HT20 by default, and there are numerous other things
that are configured more for "science" than throughput. Notably the
size of the aggregation queues is limited. But I'd LOVE a test through
your suite.
I note I'd also love to see TCP tests through your suite with the AP
configured thusly
(server) - (100ms delay box running a recent netem and a packet limit
of 100000+) - AP (w 1000 packets buffering/wo AQM, and with AQM) -
(wifi clients)
(and will gladly help set that up. Darn, I just drove past your offices)
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
Dave Täht
prev parent reply other threads:[~2013-11-11 19:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 5:30 TCP performance regression Sujith Manoharan
2013-11-11 5:55 ` Eric Dumazet
2013-11-11 6:07 ` Sujith Manoharan
2013-11-11 6:54 ` Eric Dumazet
2013-11-11 8:19 ` Sujith Manoharan
2013-11-11 14:27 ` Eric Dumazet
2013-11-11 14:39 ` Eric Dumazet
2013-11-11 16:44 ` Eric Dumazet
2013-11-11 15:05 ` David Laight
2013-11-11 15:29 ` Eric Dumazet
2013-11-11 15:43 ` David Laight
2013-11-11 16:17 ` Eric Dumazet
2013-11-11 16:35 ` David Laight
2013-11-11 17:41 ` Eric Dumazet
2013-11-12 7:42 ` Willy Tarreau
2013-11-12 14:16 ` Eric Dumazet
2013-11-14 9:54 ` Dave Taht
2013-11-11 16:13 ` Sujith Manoharan
2013-11-11 16:38 ` Felix Fietkau
2013-11-11 17:38 ` Eric Dumazet
2013-11-11 17:44 ` Felix Fietkau
2013-11-11 18:03 ` Dave Taht
2013-11-11 18:29 ` Sujith Manoharan
2013-11-11 18:31 ` Dave Taht
2013-11-11 19:11 ` Ben Greear
2013-11-11 19:24 ` Dave Taht [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw4By5d2JRzMCooXM2nV2bdUfqwKCivP1ktb3wGa1wNkww@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=apenwarr@google.com \
--cc=eric.dumazet@gmail.com \
--cc=greearb@candelatech.com \
--cc=nbd@openwrt.org \
--cc=netdev@vger.kernel.org \
--cc=sujith@msujith.org \
/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;
as well as URLs for NNTP newsgroup(s).