Slow ramp-up for single-stream TCP throughput on 4.2 kernel.

Ben Greear greearb at
Mon Oct 5 06:35:53 PDT 2015

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.


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list