From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: Slow ramp-up for single-stream TCP throughput on 4.2 kernel.
Date: Mon, 05 Oct 2015 06:35:53 -0700 [thread overview]
Message-ID: <56127CB9.1020100@candelatech.com> (raw)
In-Reply-To: <1443979705.32531.71.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/04/2015 10:28 AM, Eric Dumazet wrote:
> On Sun, 2015-10-04 at 10:05 -0700, Ben Greear wrote:
>
>> I guess I'll just stop using Cubic. Any suggestions for another
>> congestion algorithm to use? I'd prefer something that worked well
>> in pretty much any network condition, of course, and it has to work with
>> ath10k.
>>
>> We can also run some tests with 1G, 10G, ath10k, ath9k, and in conjunction
>> with network emulators and various congestion control algorithms.
>
> You could use cubic , but disable or tune HyStart, which is known to be
> problematic anyway.
>
> echo 0 >/sys/module/tcp_cubic/parameters/hystart_detect
I ran some more tests this morning. The first bump in the graph
has the setting above. Seems to work pretty good.
The second is using RENO. Also good, and a small bit of higher over-all
throughput (about 555-560Mbps of RX throughput).
Third is 'highspeed'. It ramps up quickly, but seems a bit more jagged, and
not quite as fast as RENO.
>
> Or try
>
> echo 40 >/sys/module/tcp_cubic/parameters/hystart_low_window
The last graph is this setting (with hystart_detect set back to 3,
which was the default on my system).
This is better than stock cubic, but it still is awful compared
to the others.
http://www.candelatech.com/downloads/tcp_cong_ath10k_2.pdf
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
prev parent reply other threads:[~2015-10-05 13:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 23:42 Slow ramp-up for single-stream TCP throughput on 4.2 kernel Ben Greear
2015-10-03 0:21 ` Ben Greear
2015-10-03 16:29 ` Neal Cardwell
2015-10-03 22:46 ` Ben Greear
2015-10-04 1:20 ` Neal Cardwell
2015-10-04 17:05 ` Ben Greear
2015-10-04 17:28 ` Eric Dumazet
2015-10-04 19:33 ` Yuchung Cheng
2015-10-05 13:35 ` Ben Greear [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=56127CB9.1020100@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.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).