Use this tool to ping any device on the Internet or to ping yourself just click the link here. Your ping request will start from our www.T1Shopper.com server located at 1 Wilshire Blvd, Los Angeles, California, USA connected to the Internet via US COLO (AS32743).
Ping is a little software program that measures the time it takes to do three things: (1) The time it takes a message from Point A (that's you) to Point B (that's the remote device, like a server); (2) The time it takes that remote device (at Point B) to understand the request message and respond; (3) and finally the time it takes for the response message to from Point B back to you at Point A. Piece of cake. Now on a local network where two idle computers are plugged into a single quiet switch or router, the time might be one or two milliseconds (ms) but load that switch up or get those computers hustling and the time might go up to 3 or 10 ms. So why did the time increase? Did the distance change? No.
Ping is often thought of as measuring "distance", for example the greater the ping time, the more miles or kilometers between two devices. Not always true. Ping can return slow times if the requesting or the responding device or any host along the path of the ping is swamped/overloaded. The public Internet path between the two locations is an unpredictable place - lots of routers, switches, computers and other hosts along the way each one usually doing its job - moving your information through the Internet tubes. Each host looks at the ping message (which is formulated using the ICMP protocol) and then sends it off to the next switch or router until it finally reaches the remote device at Point B. Hopefully the remote device responds to the ICMP message and sends a response back to you at Point A.
If a response isn't received in a timely fashion, the ping program will display the result as a "*" (asterisk). A device that are only intermittently responding is usually under a heavy load (it may be struggling just to keep up with its primary job and does not have the resources to take on additional tasks like ping requests). Devices which never respond have either been turned off, are being power cycled ("bounced") or may have been specifically instructed not to respond to ping requests, are so busy they never get a chance to respond, never received the request message, or the response message simply didn't make it back to you. You can use the traceroute command to help determine which step along the way the message is getting stopped.
The results from the ping program show you a couple of things which may be confusing if you're anything like us. So here's a few tips. Remember that the response times show the round trip time, not one-way. Milliseconds are thousandths of a second so if the response time is 74 ms then that's the same as saying "0.074 seconds." The 56(84)in the first line of the example below indicates that the payload of "dummy data" contained in the ICMP message is 56 bytes and when combined with the 28 bytes of ICMP header data that tells the message where to go, the total packet size is (84) bytes. The ttl or "time to live" provides some indication of how many hosts there are between this web site and the remote device. The TTL starts off at 255 and at each host is should be reduced by one. In our below example you might think there should be 209 hosts along the path between this web server and the remove device at 184.108.40.206 but there's a bit of an issue with TTL and ping - when the remote device sends the response message back to us, it needs to set a TTL and it can use one of three values: (1) the decayed value it received in the request (which would be some number lower than 255 unless there's no hosts in between the two devices) or (2) it can insert a new default TTL of 255 or (3) in can insert some random TTL. So without some fancy foot work, the TTL on ping doesn't really tell us much about the number of hosts along the path. Use the traceroute command instead.
On to the ping statistics: the packet loss is the most popular measurement - anything higher than about 2% causes significant disruption such persistent connections such as dropped VPN tunnels, dropped ssh sessions and dropped VOIP calls. A typical question that a technical support person will ask you when debugging your Internet service is, "What's your packet loss?" The rtt (or round trip time) statistics show the minimum time, the average time, the maximum time and although it says mdev it actually is the standard deviation, not the maximum absolute deviation. The higher the deviation, the more fluctuation in the ping times which is bad. The rule of thumb with ping is low numbers are good, high numbers are bad. In other words low ping times (which means a faster response), low packet loss (which means all your messages are getting through) and low deviation (which means consistent results) are all things which should take you to your happy place.
PING www.w3.org (220.127.116.11) 56(84) bytes of data.
64 bytes from barney.w3.org (18.104.22.168): icmp_seq=1 ttl=46 time=78.9 ms
64 bytes from barney.w3.org (22.214.171.124): icmp_seq=2 ttl=46 time=79.0 ms
64 bytes from barney.w3.org (126.96.36.199): icmp_seq=3 ttl=46 time=79.1 ms
64 bytes from barney.w3.org (188.8.131.52): icmp_seq=4 ttl=46 time=79.2 ms
64 bytes from barney.w3.org (184.108.40.206): icmp_seq=5 ttl=46 time=78.9 ms
--- www.w3.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 78.975/79.073/79.281/0.328 ms
The ping utility comes included with a number of operating systems, including Windows, Mac, Unix, Linux and others. If you have a Windows operating system you can try ping out by clicking on Start-->Programs-->MS-DOS Prompt, and then at the C:WINDOWS prompt, enter:
Or get really fancy:
ping -a -n 8 -i 10 -l 100 -w 1 www.t1shopper.com
Your computer will run the ping program and display the results, much like what you will see when using the similar web-based, online ping program above!