Re: Is tcp autotuning really what NFS wants?

[Ben Greear <greearb@candelatech.com>]

On 07/10/2013 10:33 AM, Dean wrote:
>  > This could significantly limit the amount of parallelism that can be achieved for a single TCP connection (and given that the
>  > Linux client strongly prefers a single connection now, this could become more of an issue).
>
> I understand the simplicity in using a single tcp connection, but performance-wise it is definitely not the way to go on WAN links. When even a miniscule amount
> of packet loss is added to the link (<0.001% packet loss), the tcp buffer collapses and performance drops significantly (especially on 10GigE WAN links).  I
> think new TCP algorithms could help the problem somewhat, but nothing available today makes much of a difference vs. cubic.
>
> Using multiple tcp connections allows better saturation of the link, since when packet loss occurs on a stream, the other streams can fill the void.  Today, the
> only solution is to scale up the number of physical clients, which has high coordination overhead, or use a wan accelerator such as Bitspeed or Riverbed (which
> comes with its own issues such as extra hardware, cost, etc).

I have a set of patches that allows one to do multiple unique mounts to the same server from a single
client, but the patches are for the client side, so it would not help
non-Linux clients.  And, the patches were rejected for upstream as not being
useful.  But, if you are interested in such, please let me know and I can point
you to them...

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com