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 > <eric.duma...@gmail.com> > 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 ;) > > > >
