Pages feel sluggish and calls lag, and you want to know why. Network latency is the time data takes to cross a network, measured in milliseconds, and you can check it with ping, traceroute or MTR.
This guide is part of our wider coverage of network monitoring.
| Item | Value |
|---|---|
| One-way delay metric (IETF) | Type-P-One-way-Delay, defined in RFC 2679 (September 1999) |
| Advantages of round-trip measurement (IETF) | Ease of deployment and interpretation |
| Unit of the one-way delay metric | Seconds, or undefined if the packet never arrives |
| Common measurement tools | Ping, Traceroute and MTR |
Figures come from TechTarget’s latency definition and the IETF’s RFC 2679. They can change, so check the sources before you rely on them.
What network latency actually is
Latency is the delay between sending data and it arriving. It is usually quoted in milliseconds, and lower is better.
The IETF’s one-way delay definition is precise. A packet’s delay is the time between the source sending its first bit and the destination receiving its last bit.
Latency is not the same as speed. A link can carry a lot of data per second and still feel slow if each packet takes a long time to arrive. If you want the capacity side of the picture, see our guide to bandwidth monitoring.
Where the delay comes from
Several things add up to the total you see. Most can be traced to one of these sources:
- Propagation: the physical distance the signal must travel.
- Transmission: the time to push a packet’s bits onto the link.
- Queuing: time spent waiting in router buffers when traffic is heavy.
- Processing: time devices and servers take to handle the packet and respond.
Distance and hardware are fixed in the short term. Queuing is the part that changes minute to minute, which is why latency often worsens when a link is busy.
One-way delay versus round-trip time
Most everyday tools report round-trip time, the trip out and back. The IETF defines a separate metric for each, as the table above shows.
One-way measurement matters because paths are often not symmetrical. In the IETF’s words: “In today’s Internet, the path from a source to a destination may be different than the path from the destination back to the source (“asymmetric paths”), such that different sequences of routers are used for the forward and reverse paths.” A round-trip figure blends both directions together and can hide a problem in one of them.
Round-trip measurement has real advantages, though. The IETF’s RFC 2681 lists ease of deployment, since you often do not need special software on the destination, and ease of interpretation. That is why ping remains the first tool most people reach for.
One-way measurement also needs the clocks at both ends to agree. The IETF treats clock synchronization and resolution as measurement issues in their own right, so one-way testing is harder to set up.
How to measure latency
Network managers have a few standard tools. TechTarget names Traceroute, MTR (My traceroute) and Ping.
- Ping. Sends echo requests to a host and times the replies. A reply confirms the host is reachable by ICMP; no reply can mean filtering, loss or an unavailable host.
- Traceroute. Shows the path packets take and reports round-trip times to each responding hop, so you can see where delay jumps.
- MTR. Blends ping and traceroute, tracking both the delay between devices on the path and the total transit time.
Run a test several times, not once. A single reading can be an outlier, while minimum, average and maximum values show how steady the path is.
Test packets may be handled differently from your real application traffic. Treat a ping result as a good indicator, not a perfect copy of what a user experiences.
Reading the results and spotting trouble
There is no single “good” number, because it depends on the application. Real-time traffic such as voice calls is the least forgiving of delay.
The IETF gives the reasoning. Some applications do not perform well if end-to-end delay is large, and erratic variation in delay makes many interactive real-time applications difficult to support.
When you see high numbers, work through the cause in order:
- Compare against a baseline you recorded when the network felt fine.
- Run traceroute or MTR to find the hop where delay first jumps.
- Check whether the jump lines up with busy periods, which points to congestion.
- Look for dropped packets too, as covered in our guide to packet loss.
TechTarget also lists packet loss and jitter among the factors that degrade real-time quality. Latency, jitter and loss usually need to be watched together.
Common mistakes when measuring latency
Good data depends on a careful method. These are the slips that most often lead to wrong conclusions:
- Testing once. One reading tells you little. Take repeated samples and look at the spread, not only the average.
- Testing from the wrong place. A result from your laptop describes your Wi-Fi and path, not the path your users take.
- Ignoring direction. A round-trip figure cannot say whether the forward or the return path is at fault.
- Ignoring load. A quiet-hour test can look healthy while the same path struggles at peak time.
- Trusting a single hop. In traceroute output, a slow reading at one hop does not always mean that device is the cause, so confirm it with the hops beyond it.
Write down what you tested, when, and from where. Those notes turn a vague complaint about slowness into evidence you can compare later.
It also helps to separate the layers. If a local test is fast but a distant test is slow, the delay is probably on the wider path. If every test is slow, look first at your own network, such as the local link, the router or a busy device.
Keeping latency under watch
One-off tests answer “is it slow now?” Continuous monitoring answers “when did it start, and how often?” Scheduled probes to key servers, with alerts when the average drifts above your baseline, catch problems before users complain.
Keep the test conditions the same each time: same source, same target, same packet type. Otherwise you cannot tell a real change from a change in method.
Review the history regularly. Patterns such as slowdowns at the same time each day often point to a scheduled job or a congested link, and they are far easier to spot in a graph than in a single ping result. Pair latency charts with traffic and error data so a spike can be explained, not just noticed.
Frequently asked questions
Is latency the same as ping?
Show answer
No. Latency is the delay itself, while ping is a tool that measures round-trip time by timing replies to echo requests.
Is round-trip time just twice the one-way delay?
Show answer
Not necessarily. The forward and return paths can differ, so the two directions may have different delays, as the IETF’s RFC 2679 explains.
Which tool shows where the delay happens?
Show answer
Traceroute reports round-trip times from the source to each responding hop on the route, and MTR repeats those measurements continuously.
What counts as high latency?
Show answer
It depends on the application. Voice and other real-time traffic are the most sensitive to delay.
