Manage Learn to apply best practices and optimize your operations.

Ping latency test results: How slow is your WAN link?

Understand your ping latency test results to determine whether your WAN link needs WAN optimization, QoS or other technologies.

In part 1 of this article, Measuring WAN latency, we reviewed the importance of understanding the latency of key WAN links. In this second part, we’ll look at the mechanics of using the ping network utility to get those measurements and learn what those ping latency test results mean.

How the ICMP ping test works

Ping is a single-purpose IP networking utility that implements the Internet Control Message Protocol (ICMP) echo command directed to a target host that then replies as rapidly as it can. A version of the ping utility is typically built into every operating system, and you can certainly expect to find it on any common corporate platform like Windows or Mac OS X.

You can run ping latency tests from any network station, and the target host can be any other station -- such as a computer, router or any device with an IP address on the network. As our goal, however, is to measure the time required for the ping data to traverse the WAN, the closer the target host is to the WAN link the better.

More on using ping

Learn to troubleshoot Windows network connectivity using ping commands.

Reading ICMP ping tests.

Use ping to test your SAN.

Most current-generation WAN routers -- and the LAN switches to which they are connected in the wiring closet -- implement ping, so in many cases it is possible to initiate the ping request from the console of the WAN router, or other network device in the wiring closet, with the target being another switch/router at the edge of the network on the other end of the WAN.

While an ideal scenario would be to initiate the ping from the wiring closet at, say, your headquarter location, to a target station sitting in the wiring closet of a branch office (or vice versa) -- that’s often not possible.

In most cases, physical or logical access to WAN router/switch console functions is restricted by an organization’s security policy. Because the wrong command entered at a switch/router console can bring the device down, most organizations restrict access to device consoles, and rightfully so.

Similarly, many organizations disable the automatic response to pings in their network infrastructure gear, as such as response might open that switch/router up to a denial of service attack. Thus, you may quickly determine that the source and target stations you will use to generate measurements may simply be computers -- which, because they run IP, can respond to a ping -- located on the other side of the WAN that you are trying to measure.

Since virtually all of today’s networks implement network address translation (NAT), the station that you choose as a target needs to either have a public IP address or be mapped on your firewall so that your ping request will be received.

Fortunately, the latency of the LAN is generally quite low, in the range of 1 to 2 ms, so if you need to ping from LAN to LAN across your WAN, you can realize that 2 to 4 ms of your measurement is related to the two local LANs and subtract that amount.

Gathering ping latency test measurements

Now that you understand the network tool, you can gather ping latency test measurements. While ping's only job is to generate the echo command across the network, you will still find that the ping utility has multiple options -- most if not all of which we can safely ignore. The ping implemented in Windows 7 has 16 separate options.

To run ping, the simplest approach is to open up a command line prompt in Windows or bring up the Terminal program in Mac OS X. If you have an aversion to anything that requires a pulsing command prompt, there are numerous free GUI front ends available for ping. Feel free to experiment with ping parameters as there is little harm that can be caused -- so long as you don’t request ping to send huge packets of data ceaselessly.

Enter ping followed by either the network name of the target station -- if known -- or the target public IP address of the target router, switch, network station or other IP device.

At the window, type in the following:

Ping <Target IP Address or Target IP Host Name>

Then hit return. This will attempt to ping the target IP station.

Windows will, by default, generate the echo request four times and then summarize results. Mac OS X runs continually by default.

By adding the -c 4 option, you can make ping under OS X behave as it would under Windows and run four times.

At the window, type in the following:

Ping –c 4 <Target IP Address or Target IP Host Name>

Then hit return. This will attempt to ping the target IP station.

After displaying the detailed results, you will be shown a summary -- which is what we really care about.

Understanding ping latency test results

Look first for the word “loss” -- as in packet loss. You want that number always to be zero. If it isn’t then either your network is undergoing a momentary and severe stress, or it is engineered incorrectly. If “loss” is non-zero, you are probably already getting complaints from users. Non-zero loss always requires further monitoring and likely action.

Since any packet loss situation should be short-lived, ping can be used over the course of the following minutes or hours to determine if packets are still being lost. If packet loss is still being reported a few hours later, then it is time to escalate. Contact your ISP to bring them into the situation. At a minimum, they can advise as to whether they are detecting any technical issues with your link. It may be that your traffic load is such that you need to upgrade to a higher-bandwidth Internet connection.

Our goal is to have consistently low latency on our network, and ping will tell us how long it took for each echo to traverse the network -- i.e., make the round trip. The statistics in the summary will show us how consistent the latency is.

If you log your ping results, even manually, you can establish baselines for your specific network connections. You will need these baselines as reference points if you suspect network problems.

We typically see differences of 10 to 20 ms between ping responses run in a series -- or 1/10 to 1/5 of a second difference. Not enough to be noticeable by users. If you start seeing large swings in the ping response time -- that is not good. That variation in latency is known as jitter and can cause problems for latency-sensitive, real-time applications like VoIP.

Temporary fluctuations in round-trip time can just indicate a busy network. For example, a ping across our WAN link to the Internet showed 62 ms but increased to 250 ms when a file upload was in progress. When latency and jitter results remain unacceptable, though, it is time to either start looking at WAN optimization and QoS solutions to control bandwidth utilization or start thinking of upgrading your WAN bandwidth.

Read the other tips in this series:


This was last published in November 2011

Dig Deeper on WAN technologies and services