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

2015-10-05 Thread Ben Greear
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

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

2015-10-04 Thread Ben Greear
On 10/03/2015 06:20 PM, Neal Cardwell wrote: On Sat, Oct 3, 2015 at 6:46 PM, Ben Greear wrote: On 10/03/2015 09:29 AM, Neal Cardwell wrote: On Fri, Oct 2, 2015 at 8:21 PM, Ben Greear wrote: Gah, seems 'cubic' related. That is the

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

2015-10-04 Thread Eric Dumazet
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

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

2015-10-04 Thread Yuchung Cheng
On Sun, Oct 4, 2015 at 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

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

2015-10-03 Thread Neal Cardwell
On Fri, Oct 2, 2015 at 8:21 PM, Ben Greear wrote: > Gah, seems 'cubic' related. That is the default tcp cong ctrl > I was using (same in 3.17, for that matter). There have been recent changes to CUBIC that may account for this. If you could repeat your test with more

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

2015-10-03 Thread Ben Greear
On 10/03/2015 09:29 AM, Neal Cardwell wrote: On Fri, Oct 2, 2015 at 8:21 PM, Ben Greear wrote: Gah, seems 'cubic' related. That is the default tcp cong ctrl I was using (same in 3.17, for that matter). There have been recent changes to CUBIC that may account for

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

2015-10-03 Thread Neal Cardwell
On Sat, Oct 3, 2015 at 6:46 PM, Ben Greear wrote: > > > On 10/03/2015 09:29 AM, Neal Cardwell wrote: >> >> On Fri, Oct 2, 2015 at 8:21 PM, Ben Greear >> wrote: >>> >>> Gah, seems 'cubic' related. That is the default tcp cong ctrl >>> I was using

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

2015-10-02 Thread Ben Greear
I'm seeing something that looks more dodgy than normal. Test case id ath10k station uploading to ath10k AP. AP is always running 4.2 kernel in this case, and both systems are using the same ath10k firmware. I have tuned the stack: echo 400 > /proc/sys/net/core/wmem_max echo 4096 87380

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

2015-10-02 Thread Ben Greear
Gah, seems 'cubic' related. That is the default tcp cong ctrl I was using (same in 3.17, for that matter). Most other rate-ctrls vastly out-perform it. On 10/02/2015 04:42 PM, Ben Greear wrote: I'm seeing something that looks more dodgy than normal. Gah, seems 'cubic' related. That is the