Slow ramp-up for single-stream TCP throughput on 4.2 kernel.
Yuchung Cheng
ycheng at google.com
Sun Oct 4 12:33:04 PDT 2015
On Sun, Oct 4, 2015 at 10:28 AM, Eric Dumazet <eric.dumazet at gmail.com> 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
>
> Or try
>
> echo 40 >/sys/module/tcp_cubic/parameters/hystart_low_window
Or if you truly don't want to use cubic, Reno would be my choice b/c
1) Cubic in mid-low BDP behaves like Reno (tcp friendly mode)
2) Reno has several recent stretched-ack fixes which may be useful in wireless
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the ath10k
mailing list