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/"

Correct me if I'm wrong...

[AKAImBatman]

...but don't the three main BSD projects use pretty much the same TCP/IP stack?

Huh?

[Carnildo]

What is a petabit-meter? How is it a significant measure of transmission speed?

Re:Distances, people!!!

[endx7]

Actually, they data transfered across Sweden, part of Europe and then the United States which (according to them) took up 10,157 miles total.

Re:Distances, people!!!

[NNKK]

Not only did you not RTFA, you didn't read the *slashdot* article:

"between a host at the Luleå University of Technology and a host connected to a Sprint PoP in San Jose, CA, USA."

This wasn't across Sweden, it was across the Atlantic Ocean and North America.

Re:Huh?

[Dodger73]

What is a petabit-meter? How is it a significant measure of transmission speed?

I'd think a petabit-meter is the transfer of one petabit of data over a distance of 1m. That's significant, because transfer takes longer (and is less reliable) over a greater distance. Think switching times, packet routing and other latencies, and of course the short time the signal needs to travel halfway around the globe.
In other words, transferring 1 pb over 1 meter in one second is considered the same 'achievement' as 0.5 pb over 2m in one second (0.5 pb * 2m = 1pbm/s).
However, I think this form of measurement is not entirely correct for short distance, because where you might see a noticeable difference in transfer rates between transferring data over half a mile (e.g. from your ISP to you) and transferring it halfway around the globe, you won't notice much of a difference caused by above mentioned latencies between 1m and 2m distances.

What I mean to say is, I don't think that the latencies that are meant to be taken into account by using bm/s actually scale linearly (signal travel time does, but not the other factors) - it's more likely that they only matter at large distances (or when comparing transfer speeds at large differences in distance).

Where 1 pb transferred over 6000 miles in one second might be the same 'achievement' as 2pb transferred over 3000 miles in one second, that doesn't hold true for short distances. 1pb over 1m in one second seems to be a higher transfer rate to me than 0.5pb over 2m in one second.

IANANE (I Am Not A Networking Expert)

Land Speed?

[Anonymous Coward]

I didn't know you could get from Sweden to San Jose overland!

S.

"The Internet? Is that thing still around?

[AtariAmarok]

"I2 isn't going to replace the Internet some day, it's more of an acedemic playground not a construction project"

I remember the same thing being said about the actual Internet back in the mid-late 1980s. Academic playground, won't amount to much.

Linux Stack vs. *BSD stacks

[brunes69]

How different is the Linux stack that the *BSD stacks? Is there that large a performance difference?

And a better question, if NetBSD has a better stack, why doesn't Linux just adopt it? After all, it *is* BSD license..

Or is it just good old pride getting in the way again?

Re:That'll learn em.

[minus_273]

comsidering apple uses a variant of BSD .. there are probably more BSD boxen than linux ones :-p

Re:Correct me if I'm wrong...

[AKAImBatman]

That's a user application that uses sockets, not the implementation of the protocol stack, you disengenous fucktard.

What is? The TCP/IP stack? Or did you forget to scroll past the intro describing FTP.EXE? Oops! How embarassing!

For you that is.

And next time, please try to be a little more polite.

Re:Correct me if I'm wrong...

[drsmithy]

AFAIK, everything modern uses the BSD stack. Windows uses the BSD stack for crying out loud (a little known fact).

Actually, it appears to be a well known falsehood...

Re:Correct me if I'm wrong...

[drsmithy]

That bitter little tirade doesn't exactly scream "authorative" (or "objective", for that matter).

It's not like independently developed software projects implementing identical ideas have never suffered the same bugs and assumptions before.

Re:Correct me if I'm wrong...

[AKAImBatman]

His point that BSD source was originally used is perfectly valid. He did list an authorative source for that statement. We only have Microsoft's word that they rewrote all of the BSD code.

Putting that aside, many of the design decisions that were inherent in the BSD code will carry forward into compatible rewrites. Thus a BSD legacy exists, even if the current stack looks nothing like the original.

you poor bsd troll

[Anonymous Coward]

I think the 850GB was cheating.because the pc's harddrive and bus don't have such power,and maybe the cpu can't have such power and bandwidth.

I think even a windows or linux may achive a high record,though yet even lower than it ,but the difference may be omitting

Re:Linux Stack vs. *BSD stacks

[ragge]

Actually, the Linux IP stack buffer handling have a number of problem that the BSD stack do not suffer from. One is the inability to use a number of linked buffers in one packet (the "mbuf" style) so it allocates skbuff's (on a power-of-2-basis), another is that it must always do (at least) one datacopy even on transmission. This will result in that a machine with the Linux IP stack runs out of CPU much faster than with a BSD IP stack.

Re:Huh?

[Anonymous Coward]

The amount of data "on the fly" in a transfer is Bandwidth times Delay.

If you want to do a reliable transfer, you have serveral challenges:

1. Get the data out of your machine onto the wire at the desired speed
2. Get the data out of the wire into the other machine at the desired speed
3. record and address an amount of data equal to Bandwidth x Delay at both ends, so that the receiving end can find out whether data is missing, and the transmitting end can retransmit it.

Note that you need to take at least twice the wire delay into account... because the acknowledgements have to travel back (and actually, the resent data have to travel once more).

The challenge for the network stack is to address that huge amount of data, which is held simply to be retransmitted if necessary, at that high speed. (Until here, that's standard networking textbook material --- see, e.g., Tanenbaum, Computer Networks).

Now, the minimum delay possible is given by the distance divided by the speed of light (in the cable used, which is less than the vacuum speed of light). Add the delay caused by the routers on the path to that, or build a 16000 km one-piece fiber cable that works ;-)

So, data rate times distance is a useful measure of technology improvement.

Re:Dell 2650

[Anonymous Coward]

I work at said University as an admin, and it's because we have a lot of Dell 2650's ... 80% of our servers are dell probably.