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.
if you do the math, none :)
4096*3072(res)*3(bytes per pixel)*30(frames per second)*120(seconds) = 126Gb of data
so no compression, just the raw data
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
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).
Am I missing something?
Yes.
125 / 7.5 = 16.67 seconds.
You're not converting your units properly. The 125 is measured in GB, while the 7.5 is measured in Gb.
http://publicvoidlife.blogspot.com
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.
While there is overhead associated with TCP/IP, it's nowhere near 30%. On a 100 Mbit link in a LAN, you routinely get 11 MB/s (just verified by transferring an Ubuntu image via FTP over the local ethernet with noname switching hardware). With a theoretical maximum of 12.5 MB/s, that's an efficacy of 90%.
6 Mbit sounds like a DSL connection to me. Quite possibly your provider or the servers you download from are responsible for your effective 4.2 Mbit, because TCP/IP isn't.
--- The light at the end of the tunnel is probably a burning truck.