Slow ramp-up for single-stream TCP throughput on 4.2 kernel.
Ben Greear
greearb at candelatech.com
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.
http://www.candelatech.com/downloads/tcp_cong_ath10k_2.pdf
Thanks,
Ben
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list