On Thu, 2008-11-06 at 10:23 -0600, Ben Collins-Sussman wrote:
> I'm clearly out of my league here; perhaps a degree in computer
> science would have helped me here.
Not really. :)
> From talking to a friend, the story I hear is that the parallel
> solution might be faster only in the situation of a congested pipe.
> That is, because TCP only allows a certain number of packets to be 'on
> the wire' at once, sending the files serially over a congested network
> may cause more waiting overall. (Send max data allowed; wait for
> response; repeat.) In an uncongested LAN environment, there'd be no
> noticeable speedup at all.
Okay, I've talked this over with some friends and it bears a little
discussion.
TCP has a "window size" which is limited by the receiver's buffer size
(the "receive window") and by link congestion (the "congestion window").
The congestion window changes over the lifetime of the connection based
on perceived network conditions. The sender will not put more than
<window size> bytes of data onto the wire before receiving an
acknowledgement.
On an uncongested, high latency, high bandwidth link, it's theoretically
possible for the receive window to limit the transmission speed, but in
practice I don't think that will ever happen. A friend tells me that
the default receive window on a Linux box was about 750K. It would take
a lot of bandwidth and a very high latency to be able to shove 750K of
data onto the wire before receiving an ack.
On a congested link, you can effectively grab more than your fair share
of bandwidth by opening multiple connections (effective window size = N
* congestion window size). That's faster, until everyone does it, at
which point it's the same speed. Sort of like how driving an SUV
improves your road visibility until everyone else has one too.
There is another reason using multiple connections might improve
transfer speed, which is "slow start". TCP connections start slow and
get faster in order to determine the congestion window without messing
up a congested network; by opening four connections, you speed up this
process by starting at 4X the initial effective congestion window. Of
course, again, you do that at the cost of being a bad citizen on a
congested link.
Finally, it appears that the TCP congestion avoidance algorithm will
generally only use about 75% of an uncongested link's bandwidth. Using
four connections can increase that to a bit over 90%. This assumes that
the limiting factor is network bandwidth and not computing resources on
either end, of course. Source:
http://research.microsoft.com/~milanv/socks.htm
Realistically, none of this justifies any additional architectural
complexity for commits in my opinion. The speed benefits are likely to
be minimal, may be swamped by the negative effects of additional
overhead (e.g. SSL handshakes), and when they do exist, may come to the
detriment of other users of the network.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 18:00:23 CET