Voyager 1 is heading for the stars, talk about latency!

It now been 35 years since Voyager 1’s launch to Jupiter and Saturn, sooner or later, the workhorse spacecraft will bid adieu to the solar system and enter a new realm of space—the first time a manmade object will have escaped to the other side.

Voyager 1 is currently more than 11 billion miles from the sun. it’s twin Voyager 2, which celebrated its launch anniversary 3 weeks ago, trails behind at 9 billion miles from the sun.

There are no full-time scientists left on the mission, but 20 part-timers analyze the data streamed back. Since the spacecraft are so far out, it takes 17 hours for a radio signal from Voyager 1 to travel to Earth. For Voyager 2, it takes about 13 hours. This means Voyager 1 has a round-trip latency of about 34 hours, meaning that if you send a command it takes 34 hours for the acknowledgement to get back, that’s a long time to find out if you didn’t press the wrong button.

We at Riverbed deal with latency issues all the time, in an Enterprise setting we don’t tend to see round trip times of 34 hours but we do see the impact of even acceptable levels of latency on business applications every day.

Since there is a physical distance between two points, let’s say your datacenter is in Belgium and your branch office is in New York, we need to cross a distance of about 4000 miles, assuming this gives us a RTT latency of 100ms*, it takes 0.2 seconds for your keystroke to be acknowledged between your branch and your datacenter at the speed of light.

* speed of light over 4000 miles plus the added delay impact of network topology and constraints of the actual cable (light does not actually travel at Lightspeed over a fiber cable because of light refactoring etc. only in a Vacuum does it reach 299 792 458 m / s and electric signals only approximately reach the speed of light even in theory)

The bad news is that a lot of applications compound this problem by needing a lot of round trips across the network to work, even before sending actual data. If you let these applications create all these network messages your users will start to feel like they are waiting 34 hours for your applications to get going (open your vpn to your remote company fileshare and start browsing directories, utter madness).

So what we do is avoid a lot of these round trips coming from the application so that the impact is greatly reduced, let’s say that instead of needing 300 messages to get going, you can do the same with 20? That’s a 4 second wait instead of a minute. Utter bliss.

See how I’ve cleverly avoiding mentioning bandwidth? That’s because with application chattiness issues it generally doesn’t play a role, the application overhead messages are small enough to fit even the tiniest link, so latency is the secret application killer here.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s