3

This was kinda of covered by the following Is minimum latency fixed by the speed of light? , but i would like to add the follow up a bit.

The scenario is as follows; we have two opposing sites one on the West Coast of the US and one in Ireland. The customer is in central Europe, and has requested a latency test. Ireland gives responses of ~65-70ms. However the West Coast guys claim to be faster with a response of 60ms.

Now a quick check says that light in fiber would take about 42ms to make the trip to the States and 8.5ms to Ireland. So obviously this is a single hop and does not include routers, switches, firewalls, protocol overhead etc.

Would I be right to call BS on their figures?

As a final note I tested a ping to Google IP address that was allegedly on the west coast from a site that covered a similar distance and was amazed to get a response time of 20ms. Suggesting ICMP packets that travel twice the speed of light.

So A) what am I missing B) Am I right to suspect shenanigans?

UPDATE: Guys thanks so far for your help and I have been reading various previous questions on this. About 5 years I had an issue where the hop from the UK to Ireland added 10ms of latency no matter what we did. In the end I moved the servers; So imagine my surprise when I have guys that claim they are 5ms faster with a transatlantic trip.

So again should I call BS? Oh and assume both sites are normal mortals that don't have access to Google magical routing, warp dives or flux capacitors. :)

UPDATE 2: Final update after hearing the arguments below and reading the various other articles would you call BS on his times??

Community
  • 1
James
  • 128
  • 3
  • 15
  • 3
    Google makes heavy use of anycast addresses, so that probably got answered by a server much closer to you. – Michael Hampton Oct 24 '12 at 17:59
  • Related: [How much network latency is typical for east-weast coat USA?](http://serverfault.com/questions/137348/how-much-network-latency-is-typical-for-east-west-coast-usa) – Chris S Oct 24 '12 at 18:07
  • Be weary of the path taken by the fibre; I have a fibre link between to data centres 3km apart, the fibre route is 10km, tripple! – jwbensley Oct 24 '12 at 19:07
  • Yeh I guessed that Google was using some fancy Routing or other tricks\magic because a trace route to the IP that was allegedly on the west cost showed a trace time of '00s of ms then jumped to 20ms... – James Oct 24 '12 at 21:48

3 Answers3

2

It is common for recent models of switches and or routers to introduce only single digit microseconds of latency, so the number of hops is not so important for this ping test.

You are right about the speed of light, and your numbers do not seem so odd. If the distance for this latency is about 40ms away (according to my math, it is 30ms by straight line), so having 20ms added by other impediments is certainly normal. I am more curious to know why Ireland is so slow.

One more thing to note is that when someone is talking about "link latency", they may very well be talking about the time for a packet to get to the other side. ping reports round trip latency so it is quite likely to see the number double.

And regarding Google, I wouldn't know where it is really located. Are you sure the server is on the west coast?

And here is a real-life example of me (my home in Tokyo) pinging an US kernel mirror (that would be a little short of 9000km by straight line) and getting a decent 110ms round trip response time, which would be 55ms one way link latency.

> ping  -i0.2 -c5 mirrors.us.kernel.org
PING mirrors.us.kernel.org (149.20.4.71) 56(84) bytes of data.
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=1 ttl=52 time=109 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=2 ttl=52 time=115 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=3 ttl=52 time=109 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=4 ttl=52 time=110 ms
64 bytes from mirrors2.kernel.org (149.20.4.71): icmp_req=5 ttl=52 time=117 ms

--- mirrors.us.kernel.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 839ms
rtt min/avg/max/mdev = 109.654/112.563/117.892/3.350 ms
chutz
  • 7,569
  • 1
  • 28
  • 57
  • +1 Light doesn't travel at 300MM/s in glass though, it travels about 197MM/s. By "straight" line, it's about 42.1ms from Dublin to LA. Also, while it might be possible that the routers introduce only a few microseconds of latency, it's not likely. Getting 60ms pings on that sort of distance would be quite hard. – Chris S Oct 24 '12 at 17:59
  • Can you show any real world data that supports any network in existence that has latencies between the West Coast and Central Europe of 40ms? Because that would be wildly faster (4x) than any network I have ever seen. 150-180ms would be more in line. – smithian Oct 24 '12 at 18:07
  • 60ms would be quite hard, but not impossible. Certainly less unlikely in a situation where it sounds that people pride themselves for having a fast connection. And just now I pinged mirrors.us.kernel.org and got 100-110ms of latency from my home which should be about 9000km away. Why would not someone with a better network be able to get it even faster. – chutz Oct 24 '12 at 18:22
2

The rule of thumb is that the speed of light in SMF is ~.6c (same neighborhood as Chris S' description). The port-to-port latency introduced by routers and switches is going to average out in the low double-digit range once any kind of buffering or fancy features are thrown into the mix. There's also a nominal amount of serialization delay that's introduced every time a packet is mapped onto the media itself. This value decreases as a function of link bandwidth - so there will be measurable differences between, say, an OC3 link and an OC768. This also tends to run in microseconds.

The rule of thumb I've generally used is about .25ms per 100km of actual link (one-way) with minimal hardware involved (i.e. DWDM equipment). This estimate has served very well in the construction of private metro networks and even a few long-haul dedicated runs. That said, the relationship between this number and reality in the circumstance of carrier MPLS clouds, the public Internet, etc is pretty much a toss-up. I'd suggest something like this for establishing the minimum practical latency.

That said...

First - the actual physical path taken by a given circuit is sometimes only tangentially related to actual geographic distance. Backhauling a circuit by hundreds of kilometers to the west and south only to send it hundreds of kiometers to the north is not unheard of.

Second - Nor, indeed, is the process of sending IP traffic through one or more exchange points that may, or may not, really be on the way. Economics of both circuit construction and carrier hand-off locations drive practical engineering more so than absolute minimization of latency.

Finally - when running a traceroute take the naming of the intermediate nodes with a grain of salt unless you personally know the network you're crossing. Naming conventions with airport codes (for example) can give a hint, but there's no way to conclusively know what you're looking at without some measure of additional knowledge.

rnxrx
  • 8,103
  • 3
  • 20
  • 30
  • So based on points 1&2) my absolute min for Europe to the US of 40 odd ms is going to be a large under estimation. On 3) I understand what you are saying but I have been to the actual physical location of both servers.... – James Oct 24 '12 at 22:09
  • Sorry and want to call BS on the West Coast guy.... – James Oct 24 '12 at 22:09
  • Europe is a good example - the cables themselves don't take the absolute straightest route but are going to be constrained to an extent by the lay of the sea floor. A run between locations that are 3000km apart might have 4500 or 5000 km of actual cable. – rnxrx Oct 25 '12 at 00:07
0

Try an IP address like 4.2.2.4 (It is for Sun Microsystems) that definitely is in US. You can't get to a clue by just PING. Maybe ICMP packets are shaped in some sites., although Google ping sounds weird because it's less than expected not more!

Mehdi
  • 80
  • 1
  • 6