TCP Algorithms are "Funny" (Score 3, Interesting)

I've spend a lot of time looking at this type of problem. I had a customer that wanted to transfer data at greater then 10 mbps across the internet, across the country. Lets just say with windows this is impossible.

The problem has to do with TCP algorithms. I found the ones in windows are optimized for common cases. Linux has multiple TCP/IP algorithms you can choose from. Most are significantly better the one used in windows.

The "problem" with TCP is it has to assume that packet loss equals network congestion. This is a good thing for an over-loaded network link. As the link fills up, it starts dropping packets. As the computers on each end of a TCP connection see this packet loss, they start "Backing off". They slow down their transmission rates until the packet loss is gone. In most cases they back way off, and then slowly increase the speed until they start seeing a little packet loss. The methods they use to determine what is congestion, how much they slow down, and how they recover from it greatly effects total usable bandwidth.

The bottom line: TCP Algorithms greatly effect transfer speed, and no algorithm is good for every situation. Linux gives you flexibility in this area (And by default uses a better one), and windows gives you zero.

To test raw bandwidth, you have to saturate a link with UDP data, and count how much data is received. This is pretty pointless as its not the useable bandwidth, but it does tell you the "raw" potential. The problem is the "raw" potential can be subverted by a small amount of packet loss.