Slashdot Mirror
NetBSD Sets Internet2 Land Speed World Record
Daniel de Kok writes "Researchers of the Swedish University Network
(SUNET) have beaten the Internet2 Land Speed Record using two Dell 2650 machines with single 2GHz CPUs running NetBSD 2.0 Beta. SUNET has transferred around
840 GigaBytes of data in less than 30 minutes, using a single IPv4 TCP stream, between a host at the Luleå
University of Technology and a host connected to a Sprint PoP in San Jose, CA, USA. The
achieved speed was 69.073 Petabit-meters/second. According to the research team, NetBSD was chosen 'due to the scalability of the TCP code.'"
"More information about this record including the NetBSD configuration can be found at:
http://proj.sunet.se/LSR2/
The website of the Internet2 Land Speed Record (I2-LSR) competition is located at:
http://lsr.internet2.edu/"
when UDP has so much less overhead?
Did they check for any inband compression? They data they're sending isn't randomised.
840GB/30 minutes = 466 MB/s, or 3,728 Mbps
So, is this just using a secure connection on our internet, or did they go ahead and string up an all new internet for no one but theirselves to be on? I don't really see the point of the latter - why not dump the money into vastly improving the current internet and stomping out spammers and things that make the place bad?
SecondPageMedia - Wha
That depends on whether the DVDs are in cases or not I think.
At 9.4 GB per DVD (Assume single-layer double-sided DVD-R), and a travel time of 3 weeks from Sweeden to California (2 weeks on the boat, one week of driving), you'd need to get about 90,000 DVDs in your station wagon to get an effective 1680 GB/hr. That wouldn't be possible if they were in cases, but if it was just the DVDs, it's probably a close call. Might have to upgrade to dual-layer DVD's, or change the saying to "an SUV full of DVD's".
On the other hand, if you count the time to actually read the data off of the DVDs (even worse if you count the time to put the data on the DVDs too), the station wagon of DVD's barrier was broken long ago - you probably couldn't spin a DVD fast enough to get 9.4 GB of data off it in 20 seconds.
paintball
...if the distance makes any real difference, something is wrong.
One of the biggest problems in networking is handling a large bandwidth-delay product (that's the amount of data in flight at once). Since distance increases the delay it is relevant.
Plus, I'm betting it's not a "land" speed record, seeing as how the data probably jumps through the air (satillite/microwave transmissions) at one or more points.
Nope. Think about it: what kind of wireless connection can handle 4 Gbps?
Man I hate to be on the recieving end of a Denial of Service attack on Internet 2. 900 gigabytes of data /30 min from multiple sourses would be crushing.
Veramocor
Actually google doesn't index a lot of /. because there aren't enough inter article links to find all the articles and because google just gets the default page setup a lot of comments are hidden, not to mention Google only indexes a certain amount of dynamic data from a particular site to avoid causing what was once called "the google effect" when a poorly designed web app on a slow server would be hammered as google crawled the catalog.
They might claim that NetBSD scales best, but it took some code changes to get it to do so (which have since been picked up and are included in the base).
:-)
The REAL reason for why they picked NetBSD is that Ragge (Anders Magnusson), the person doing a fair chunk of the testing, is heavily involved in the project and knows the code base. It was simply easiest to work with for him.
Surely someone's seen the "released" Windows code and can now tell whether it is BSD based or not.
Linux has often been used to set records. The sure way to see Linux trashing BSD is to add more CPUs. Linux scales tolerably well to 512 processors now! The Linux IP stack is very well suited to SMP.
This NetBSD record is really about having insanely great Internet connections separated by thousands of miles.
Long ago, the Linux developers did look into adopting the BSD stack. At the time though, the BSD stack was incompatible with the GPL. Alan Cox asked Berkeley to re-license under the GPL, and was turned down. At this point in time, using the BSD code wouldn't make any sense.
How about some evidence of that? Where is this 512 way smp machine running linux?
Since when does "pretty much the same" give "exactly the same" results? Even an off-by-one can change things drastically.
By the way, this isn't the first time I've heard that NetBSD's TCP/IP stack is the superior of the three. I once met the head of networking for a semi-conductor testing equipment company that did extensive tests between all three of the BSDs and Linux, and he said that NetBSD was the clear winner in TCP/IP performance.
Someone is WRONG on the Internet!
The same goes for doing a copy on transmission. BSD has generally hidden a software checksum and/or copy in the driver, because older hardware didn't support scatter-gather and checksum. Linux didn't hide it. Note that checksum comes free (seriously!) when doing a copy, since you need to access the memory anyway. Now that cards with scatter-gather and checksum are common enough to care about, Linux can take advantage of this feature for "zero-copy transmit". (obviously, the network transmit is itself a copy and the whole point of doing a transmit)
Zero-copy receive, in the BSD style, is a way to kill SMP scalability. It involves remapping pages, which leads to cross-CPU interrupts to invalidate the old mapping. It's cheaper to copy the data.