Re: Is tcp autotuning really what NFS wants?

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

On Wed, 10 Jul 2013 10:39:38 -0700 Ben Greear <greearb@candelatech.com> wrote:

> 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...

Yes please!

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]