Slashdot Mirror
Purdue Streams a Movie At 7.5Gb/sec
the_psilo writes, "My friend just got back from the Supercomputing conference in Tampa, FL where she and the rest of the Purdue Envision Center rocked the High Performance Computing Bandwidth Challenge by streaming a 2-minute-long, 125-GB movie over a 10-Gb link at 7.5 Gb/sec. They used 6 Apple Xserve RAIDs connected to 12 clients projecting onto their tiled wall (that's 12 streams in all). Lots of accolades from the people who set up the challenge. More links to articles and reviews can be found at the Envision Center Bandwidth Challenge FAQ page."
The two-minute video is a scientific visualization of a cell structure from a bacterium.
The Envision Center site hosts a reduced version of the video.
We don't need no stinkin reduced version!
I'm sure our employers wouldn't mind if we took a look at the full version.
*psst* *psst* *psst* *mumble* *mumble* *mumble*
The whole thing? Really?
My boss has told me to take the full version of my personal desk stuff home now.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
There is significant overhead associated with the use of TCP/IP. A typical 6.0 Mb/s connection will deliver appx. 4.2 Mb/s this is only about 70% of the connections actual bandwidth. So, 75% is looking pretty good.
What rocks is the ability to reliably deliver 7.5 Gb/s AND do something useful with it.
Probably no compression at all:
4096 * 3072 * 3 bytes per pixel = 36MB per frame (exactly... resolution I'll bet was not chosen randomly )
36 * 30 frames * 120 seconds = 126.5625 GB
About time the envision center actually did something. They have been a huge money pit for a long time. They demolished the pool hall in the student union which had been a student favorite for about 20 years for the center and have had very little actual results up until this point.
Purdue Alum
I have a friend who just got back from the same conference. He works at Ohio State University in the electron optics facility (read: likes to play with awesome equipment). Here's what he sent along to me: "This week I am in Tampa, Fl at the Supercomputing Conference "SC 06" with the guys from OSC (Ohio SuperComputer group). We have connected the Global Link boxes up and I am attempting to run the Quanta from Florida. Traffic is being routed from the conference to Atlanta, the Internet2, then though to the Third Frontier Network and back to OSU." With the bandwidth he had, he was able to observe, interact, and analyze a sample in a scanning electron microscope (the Quanta) in Ohio, in real time. Now that's a use for bandwidth; it's a lot cheaper to have a great internet connection than to buy the latest electron microscopes.
Not to mention the hardware itself (NICs, routers, bridges, etc.) adds some not-insignificant overhead as well.
Right. While any idiot can get 10 Gb/s link and get 7.5 Gb/s or more out of it, the real feat here was in doing something useful with it at the same time. Remember that in streaming video applications, there's typically a lot of dropped packets because the client has to actually do something with the video immediately. It may just buffer it, but the application that's doing the buffering is often busy doing other stuff as well, like, say decoding video and audio streams and actually piping all that data through to the I/O bus -- oh, and the NIC is usually sitting on that same I/O bus, so that makes things even worse.
My blog
When you try and fill a 10g pipe with a single tcp session, the congestion avoidance mechanisms of tcp will prevent you from filling the pipe. Essentially the sender will ramp up the rate of packets very quickly initially until the receiver sends back a congestion notification. The sender will then cut the send rate *in half*, and climb it back up very slowly - 1 extra byte per round-trip if memory serves (don't quote me on that). This works great for 100m, but to climb from 5g to 10g takes about 30 minutes if you have a cross-US round-trip-time (RTT).
e d_issues/ipj_9-2/gigabit_tcp.html
To get around this you can:
1. Patch your TCP stacks with a few high-performance modifications
2. Figure out - using the RTT, interface buffer sizes, and bandwidth - what the number of outstanding packets can be before the receiver sends back a "slow down" message. Then configure the sender to have a smaller packet queue.
Great article on this here:
http://www.cisco.com/web/about/ac123/ac147/archiv
It's tough to say if that was the problem here (I'm actually assuming it was not) since after a little digging I didn't see any details on their implementation. And no, I'm not interested in truly digging (I have a pesky job thingy to get back to).