On Wed, 10 Jul 2013 10:39:38 -0700 Ben Greear <greearb@xxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
