[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADVnQymteJ+44hWiNtCnktooC9VKRf1cEYvOCfgsVmzyH+ES_g@mail.gmail.com>
Date: Tue, 25 Apr 2017 13:54:11 -0400
From: Neal Cardwell <ncardwell@...gle.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Soheil Hassas Yeganeh <soheil@...gle.com>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net-next 10/10] tcp: switch rcv_rtt_est and rcvq_space to
high resolution timestamps
On Tue, Apr 25, 2017 at 1:15 PM, Eric Dumazet <edumazet@...gle.com> wrote:
> Some devices or distributions use HZ=100 or HZ=250
>
> TCP receive buffer autotuning has poor behavior caused by this choice.
> Since autotuning happens after 4 ms or 10 ms, short distance flows
> get their receive buffer tuned to a very high value, but after an initial
> period where it was frozen to (too small) initial value.
>
> With tp->tcp_mstamp introduction, we can switch to high resolution
> timestamps almost for free (at the expense of 8 additional bytes per
> TCP structure)
>
> Note that some TCP stacks use usec TCP timestamps where this
> patch makes even more sense : Many TCP flows have < 500 usec RTT.
> Hopefully this finer TS option can be standardized soon.
>
> Tested:
> HZ=100 kernel
> ./netperf -H lpaa24 -t TCP_RR -l 1000 -- -r 10000,10000 &
>
> Peer without patch :
> lpaa24:~# ss -tmi dst lpaa23
> ...
> skmem:(r0,rb8388608,...)
> rcv_rtt:10 rcv_space:3210000 minrtt:0.017
>
> Peer with the patch :
> lpaa23:~# ss -tmi dst lpaa24
> ...
> skmem:(r0,rb428800,...)
> rcv_rtt:0.069 rcv_space:30000 minrtt:0.017
>
> We can see saner RCVBUF, and more precise rcv_rtt information.
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Acked-by: Soheil Hassas Yeganeh <soheil@...gle.com>
Acked-by: Neal Cardwell <ncardwell@...gle.com>
neal
Powered by blists - more mailing lists