Topics

Blogs

Forums

Samples

Media

Labs

Resources
 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 The Bandwidth of Sneakernet to the Cloud
posted on Friday, August 21, 2009 4:00 AM

Just what is the bandwidth of a van full of hard drives traveling 300 miles at a speed of 65 mph?

After a short Twitter discussion based on this post which suggested Ye Olde Sneakernet is the best way to transfer large data sets from the enterprise to the cloud (which is, unfortunately, not as uncommon a suggestion from cloud providers as you might think) I was dared to compute the actual bandwidth of said sneakernet (probably because I said I had the urge to do just that, but is that really important? I didn’t think so.)

I have a hard time passing up dares like that, but you knew that, didn’t you? So let’s get out our papers and dust off the old math textbooks, shall we?

HERE COMES THE MATH…

2008-dodge-grand-caravan-cargo-van-cargo-holdjpgOur van is a 2008 Dodge Caravan with an interior carrying capacity of 143.8 cubit feet. There are 1728 cubic inches in one cubic foot, which means a total of 248451 cubic inches are available for our hard drives. 

Our hard drives are Maxtor BlackArmor Portable hard drives, 160 GB each. Dimensions are: 5.17" H x 3.32" W x 0.67" L for a total of 11.5 cubic inches. Let’s say 12 cubic inches per drive, just to make the  calculations a little easier.

That means there are: 248451 / 12 = 20704 hard drives in the back of our van. That’s a total of 3,312,640 GB. 

Okay, that was the hard part. The rest should be fairly straightforward.

The van is traveling at 65 mph. We assume no congestion (traffic jams) for the purposes of this illustration.

It will take the van 4.6 hours to reach its destination, which means it takes 16560 seconds to arrive at “the cloud”. Given the amount of data we’re transferring, that means an effective transfer rate of: 200 Gbps.

That sounds pretty good, until you consider the latency incurred from a pit stop and I’m not sure there’s a way (yet) for application delivery to address that.

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

Related blogs & articles:



 
      

Feedback

8/21/2009 5:22 AM
Gravatar You still have to transfer all that data, swap it for new bits, and bring it all back...
diiq
8/21/2009 6:19 AM
Gravatar @destari calculates the bandwidth required to transfer the data into the cloud (based on some assumptions regarding parallelization of drives and speed of drives, of course):

"(3312640 GB)/((20 MB/s)*(10 (# drives used in parallel))) = 16563s, + original 16560=33123, so about 100GB/s"

So apparently we have a bandwidth bottleneck at the point of xfer into the cloud.

Lori MacVittie
8/21/2009 6:30 AM
Gravatar bytes != bits

I think you missed bytes vs bits (disk vs wire). I come up with 1600 Gbps.

My math:
(143.8 cu ft/van) * (1728 cu in/cu ft) / (12 cu in/drive) * (160 GB/drive) * (8 bits/byte) / (300 miles/65 mph * 3600 seconds/minute) = 1595 Gb/s

For an even better calculation we would need to account for the 1024=1k vs 1000=1k issue, protocol overhead, etc.
tarsier
8/21/2009 6:39 AM
Gravatar You also need to hope that nothing bad happens while you are on the road.

I once worked at a company that lost all a set of tapes containing all of its customer data and all of its source code during a sneakernet transfer.

Another place I worked had classified data on tape that was in a car accident. The guy who was transporting it woke up and told the police to call corporate security - urgent - and then lost consciousness again. It could have been his last breath, and instead of saying "tell my wife and kids I love them", he has to waste it on "call corporate security!".

Even if it was encrypted (it wasn't in the first case), expect significant stress when you get back to your office (or your family).

I'd rather sit back and saturate the pipe for 10 days, than load tapes in my minivan and head out on the turnpike with them if I could.

[ A couple times in the past I've driven around with servers in my car that were worth more than my house -- to help with a quick data center move. That always made me really nervous too. I wonder if my auto insurance would cover such a situation? ]
Rick
8/21/2009 6:54 AM
Gravatar @tarsier

Blast it you're right! I hate that conversion - I always forget that piece of it.

I always assume 1k = 1024 cause that's the way it's supposed to be, but I suppose you're right, you have to consider that the mainstream definition of 1k = 1000 and that might factor in as well.
Lori MacVittie
8/21/2009 8:11 AM
Gravatar Unfortunately your hard drives weigh 9316.8 lbs. far in excess what your van can carry. Bits, it seems, have both size AND weight.
Phil
8/21/2009 8:57 AM
Gravatar another way to looking at acceleration techniques...

minimize requests via pit stop acceleration ala Depends (as demonstrated by astronaut Lisa Marie Nowak)

increase delivery time by reducing drag coefficient and employing a police escort to increase speed of travel

:-)
appgirl
8/22/2009 3:33 AM
Gravatar You still have to transfer all that data, swap it for new bits, and bring it all back...
So apparently we have a bandwidth bottleneck at the point of xfer into the cloud.

it's very nice
baguscs
8/22/2009 5:38 AM
Gravatar Or you could use 2.5 inch, 1 TB SSDs, and get a bandwidth of 1200 Gbps.
Bob
8/22/2009 1:47 PM
Gravatar The guy who was transporting it woke up and told the police to call corporate security - urgent - and then lost consciousness again. It could have been his last breath, and instead of saying "tell my wife and kids I love them", he has to waste it on "call corporate security!".
Acai
8/23/2009 7:52 AM
Gravatar it's very nice
Obiavite
8/23/2009 5:11 PM
Gravatar 300 miles is short enough to consider packing a van full of hard drives and hitting the road - one tank of gas, two bathroom breaks and a lunch and you're there. Heck, if you leave right after breakfast you can have lunch when you get there.

The problem here is that when you are only traveling 300 miles, it is sort of an unfair comparison with the net. Assuming you are renting the van, your transport costs (ignoring that it was pointed above that the van can't hold the weight) are slight - conceivably less than a dollar a mile, even when you factor in the return trip - and the rate is high - 200 GBytes/s.

If you were moving that data cross country instead of cross state, Seattle to Lowell for example, then your rate is more realistic.

Now, continuing to assume continual travel at a constant velocity, your 16,560 seconds becomes 168,923 seconds, and the new calculation looks like this:

3,312,640 GB / 168,923 seconds = 19.61 GBytes/s

This is still quite fast - about 160Gbps fast, or about 7 days through a fully loaded Viprion (@ 40Gbps) - it is an order of magnitude slower than the nearly 1600 Gbps you get between Seattle and Spokane and the costs climb for every mile you travel, every meal you eat, and every night you spend in a motel.

Furthermore, that is a lot of data, and when there is a lot of data, there is almost always room for de-duplication and compression. Even presuming conservative numbers - 35% de-duplication and 12% compression on the remainder - of what can be done in-line during the transfer with the right architecture, that leaves us with only 2,040,586 GB - a number which shaves 3 whole days off the time it takes a full Viprion chassis to process.

Now you can move all the data coast-to-coast in about the time it will take a normal person to drive the same distance. You might even get to write an iRule or two. And when it's over, you get to keep the BIG-IP and ARX product as capital investments on your balance sheet instead of all those operational costs.
Ian
12/17/2009 3:21 AM
Gravatar The Cloud Computing
Lori MacVittie
12/19/2009 2:11 AM
Gravatar Thanks for the hint, I was looking for sth. like that for months :-)
thai silk
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 8 and 7 and type the answer here:

Copyright 1996 - 2007 F5 Networks, Inc. | Privacy Statement | Terms Of Use