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@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
