I'm from Europe and I've checked one hosting server in Australia. PING was only 3 ms. And I've thought that PING mainly depends on physical distance between my PC and the server. Any comments?
ping does not mean much of anything and is a horrible way to test network performance. Do keep in mind that most routers on the internet give ICMP the lowest priority when it comes to the things they do. The best way to look at network performance is by looking at mulitple traceroutes in conjunction with good end to end pings from various route servers.
If I check PING with http://dnsstuff.com, I get 3ms. With http://dns-tools.domaintools.com/ I get about 82ms. Traceroute values are from 1 to 82ms. Now: Which PING tool is reliable? Or better: how to read traceroute values to get an appropriate server speed performance information?
There are two major problems with man web based Traceroutes. 1) They integrate Ping (ICMP echo request) with traceroute (ICMP TTL) to try to determine additional information about path failures, timeouts,etc. 2) They try to use Loose Source Route Request (LSRR) to allow for traceroute attempts via specific off site hosts. This is an advanced option. The problem with issue #1 is as follows. In addition to sending out a series of ICMP packets with continually incrementing TTLs (a traceroute) many Traceroutes also attempts to ping (ICMP Echo Request) each hop along the way. This is inherently problematic with backbone routers. A backbone router (such as core-7513-bmia-lkgnoc-253.mia.net) is intended to do two things: Maintain a global routing table through constant BGP conversations with its peers, and forward packets as quickly as possible from interface to interface according to that routing table. In order to satisfy that second task, the router will be designed with several potential paths which packets can take which do not involve the central processor. An ICMP Echo Request packet cannot take any of these paths, since it demands attention by the central processor. Such attention will be given very low priority - as the router has more important things to do. When the router is busy, therefore, any ICMP packets sent to it may well timeout. Some Traceroutes will interpret this as a network problem, when it probably is not. This phenomenon is most often seen with a traceroute which shows intermediate steps which have high reply times (say 500ms or more) while the end-to-end times may be very low (say 80ms). The router is doing its job, forwarding packets, but isn't especially responsive to Pings and such. This is why we always say that traceroutes are intended to give you a view of the route packets will take, whereas Ping is intended to give end-to-end round trip times. The idea of end-to-end is very important here. If someone decides to ping one of our routers, in a misguided attempt to diagnose network problems, they will only create more red-herrings. The _only_ significant time measure is from end to end, not from end to middle and middle to end. If a person sees very high end-to-end ping times, then a traceroute _may_ shed additional light on why, BUT IT MAY NOT, since routers are designed to behave the way they do. As for the second problem noted above, the use of LSRR: all of the routers on our network are configured to reject all source route requests (as should yours be). LSRRs have no legitimate use on the Internet, and the decision by the some Traceroutes to try to use them was a bad one. Almost as bad as trying to ping backbone routers and pass that off as a valid Internet diagnostic. Hope this helps.