Slashdot Mirror
Ubuntu Download Speeds Beat Windows XP's
narramissic writes "Doing a download speed test of his Time Warner cable connection, James Gaskin discovered something odd, something that he is quick to note isn't a rigorous benchmarked lab test. The discovery: His Ubuntu machine 'returned a rating from the Bandwidth.com test of 22-25mbps over several tests' while the same test done from a Windows XP PC returned a rating of 12-14mbps. The two computers used in the test are 'almost identical: both off-lease Compaq small form factor D515s, part of the very popular corporate desktop D500 family. Both have Pentium 4 processors running at 2GHz. The Ubuntu machine has 768MB of RAM, while the XP box has only 512MB of RAM. Both run Firefox 3 as their browser.' Gaskin's question: Can a little extra RAM make that much difference in Internet download speeds or does Ubuntu handles networking that much faster than Windows XP?"
Anecdotally, I have also noticed that Ubuntu boxes tend to hog bandwidth, as compared to an XP box at home. When someone on the home LAN starts downloading or streaming something from a linux box, everyone else notices it immediately. The XP box is (inadvertently?) more polite about it. Still, if you're the only one pulling in the big byte loads, faster is definitely better.
possibly due to tcp window scaling
http://en.wikipedia.org/wiki/TCP_window_scale_option
ubuntu does it. Windows XP does not.
The TCP window scale option is an option to increase the TCP receive window size above its maximum value of 65,536 bytes. This TCP option, along with several others, is defined in IETF RFC 1323 which deals with Long-Fat networks, or LFN.
-rant mode, how I found out about it.
The secure side of the Presidents Choice banking web site is royally hosed by a machine that tries to use tcp window scaling. Why can't a web service provider, one that should be extra careful about security understand a standard concept.
Yeah people keep claiming this with no real data to prove it up so it's about as worthless as the shit that the article claims. My parents have an XP box with only 512 megs of RAM and it easily maxes out at the 22mbps that they have. And that's with a half dozen apps open and at least 8 things running in the background on the systray. Seriously, the extra 256 megs of RAM isn't going to give you magically 2x the bandwidth.
Product A in lab tests always performs over 100% better/faster than product B.
Product B in normal use always performs over 100% better/faster than product A.
Which are you going to want to use? Perhaps product A is designed to max the test, while product B is designed to handle varying conditions.
Paying taxes to buy civilization is like paying a hooker to buy love.
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.
Dell XPS M1530 Intel Core 2 Duo (2.16ghz) 3 gigs RAM Dual Booting Windows Vista Home Premium AND Ubuntu 8.10 http://www.bandwidth.com/tools/speedTest/ Six tests per OS. Vista: Download/Upload 7616/2795 7865/2724 6407/2755 10050/2800 12320/3925 15854/2905 Ubuntu: Download/Upload 12939/5897 8849/12122 15373/18646 20040/17093 8461/14969 17885/13807
Well, even if the hardware was the same, I'd blame the drivers. On Windows, lots of networking equipment has crummy drivers coded by companies that really don't care that work, but with much higher latency and bandwidth than the hardware is capable of.
I actually get better performance off the USB wifi card in my desktop than the PCI one built-in, because the PCI one has lousy drivers and the USB one has good drivers.
Comment of the year
I know Comcast has a thing (Powerboost) where it gives you double download speeds for the first x minutes of a download. Could that be at work here?
Fine, what is this then:
Windows (Cygwin):
$ ping -n 20 www.google.com
Pinging www.l.google.com [74.125.39.147] with 32 bytes of data:
Reply from 74.125.39.147: bytes=32 time=12ms TTL=245
[...]
Ping statistics for 74.125.39.147:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 11ms, Maximum = 41ms, Average = 16ms
Ubuntu:
lukas@9a:~$ ping www.google.com
PING www.l.google.com (74.125.39.147) 56(84) bytes of data.
64 bytes from fx-in-f147.google.com (74.125.39.147): icmp_seq=1 ttl=245 time=15.3 ms
--- www.l.google.com ping statistics ---
22 packets transmitted, 1 received, 95% packet loss, time 21003ms
rtt min/avg/max/mdev = 15.321/15.321/15.321/0.000 ms
Happens on my network no matter what I change - cables or notebooks, Vista runs ok, Ubuntu sucks big time. The only non-standard thing is that I have wired connection with manual IP address (connected by Linux based Asus router).
lukas@9a:~$ lspci | grep Eth
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
winXP x64 sp2:
ubuntu 8.10 x64:
huh, weird.