Thread (1 message) 1 message, 1 author, 2016-04-13

RE: TCP reaching to maximum throughput after a long time

From: Machani, Yaniv <hidden>
Date: 2016-04-13 20:26:41
Also in: lkml

On Wed, Apr 13, 2016 at 17:32:29, Neal Cardwell wrote:
Miller; Eric Dumazet; Nandita Dukkipati; open list; Kama, Meirav
Subject: Re: TCP reaching to maximum throughput after a long time

I like the idea to disable hystart ack-train.


Yaniv, can you please re-run your test with CUBIC in three different
scenarios:

a) echo 0 > /sys/module/tcp_cubic/parameters/hystart_detect
This fixes the issues, got to max throughput immediately. 
b) echo 1 > /sys/module/tcp_cubic/parameters/hystart_detect
This shows the same results as before, starting low and increasing slowly.
c) echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect
This gets us a bit higher at the beginning, but never (waited ~60 sec) goes to the max.


Appreciate your help on this.
Yaniv

This should help us isolate whether the hystart ack-train algorithm is 
causing problems in this particular case.

Thanks!
neal



On Tue, Apr 12, 2016 at 11:32 PM, Eric Dumazet 
[off-list ref]
wrote:


	On Tue, 2016-04-12 at 20:08 -0700, Yuchung Cheng wrote:

	> based on the prev thread I propose we disable hystart ack-train. It 
is
	> brittle under various circumstances. We've disabled that at Google 
for
	> years.

	Right, but because we also use sch_fq packet scheduler and pacing ;)



Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help