lkml.org 
[lkml]   [2016]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: TCP reaching to maximum throughput after a long time
Date
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.dumazet@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 ;)
>
>
>
>



\
 
 \ /
  Last update: 2016-04-13 22:41    [W:0.049 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site