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.
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.
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