Dean <seattleplus@xxxxxxxxx> 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
And just remember bufferbloat.
> 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).
This is true on high speed links with few bottlenecks, but not so much when
there is a DSL-type bottleneck and excessive buffers.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
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
