Latency is how long a round trip takes; packet loss is the share of packets that never arrive. Latency has a floor set by distance that no connection speed removes. Packet loss on a wired path should be zero, and a little of it costs more than a lot of latency because TCP backs off.
- Latency is milliseconds. Packet loss is a percentage
- One percent loss can cost more than 50 ms of extra delay
- A saturated link produces both symptoms from one cause
- Loss on a wired path is a fault, not a tuning problem
- A ten packet ping proves nothing. Run it for minutes
On this page
The two numbersWhat each one actually measures
Packet loss vs latency is a comparison of two numbers that come from the same network test and describe unrelated properties of network performance. Most monitoring tools collect both metrics in one pass, which is why they are so often read as one.
Latency is elapsed time. Send a packet, wait for the answer, record how long it took. That round trip time includes the distance the data traveled, the time each router spent handling it, and any time it sat in a queue. It is reported in milliseconds and it is a single number per packet.
Packet loss is a count. Send a hundred data packets to a destination, see how many answers come back. Ninety six answers means four percent packet loss. It says nothing about how long the ninety six took, or about how much data was in them.
A network path can have either, both or neither, and the four combinations are genuinely different network issues.
| Low loss | High loss | |
|---|---|---|
| Low latency | Healthy | A fault: a bad cable, a failing port, wireless interference |
| High latency | Distance, or a congested queue | A saturated link, which produces both at once |
The bottom right cell is the common real world case and the reason the two get conflated. A network link carrying more data than it can handle queues packets, which raises latency, and then drops the packets that will not fit, which is loss.
One cause, two performance symptoms, and two metrics that move together. Reading them as one number is how a capacity problem gets diagnosed as a hardware fault.
The latency floorWhy latency has a floor you cannot buy your way past
Light travels about 200,000 kilometers per second in fiber, which is around two thirds of its speed in vacuum. That number sets a hard minimum on any path.
London to New York is roughly 5,600 kilometers, so a one way trip is about 28 milliseconds and a round trip about 56, before any equipment touches the packet. In practice the fiber does not run in a straight line and each router adds a little, so 70 to 80 milliseconds is a good result on that path.
Nothing changes that. A faster network connection does not reduce it, because bandwidth and latency are separate properties: a wider road does not shorten the journey. This is the single most useful thing to explain to somebody who has just upgraded their internet connection and is disappointed with the performance.
What can be reduced is everything on top of the floor.
Queuing. A busy network link holds packets in a buffer before sending them. This is the largest avoidable component and the one that varies minute to minute.
Processing. Each hop takes a small amount of time to look at a packet and forward it toward the destination. Small, and it adds up over many hops.
The last mile. The access technology matters more than people expect. Fiber adds almost nothing; older technologies and satellite add a great deal.
The path taken. Data does not travel in a straight line across a network. A route that goes through a distant exchange point adds real milliseconds, and this is what changes when a provider adjusts peering.
Why loss is worseWhy a small amount of loss hurts so much
This is the part that surprises people: one percent packet loss can cost more network performance than fifty milliseconds of extra latency, and the reason is TCP.
TCP interprets a lost packet as a sign of congestion, because that is what packet loss usually means. Its response is to reduce how fast it sends data, then build back up slowly. On a network path with steady low level loss, the connection spends its life backing off and recovering and never reaches the performance the link could support.
The effect compounds with latency. Recovering from a lost packet takes at least one round trip, so the same one percent loss costs far more on a long path than a short one.
High latency and low loss is workable. High loss and high latency together is where a link that looks fine on paper delivers a fraction of its rated performance.
Different applications feel it differently, and the difference is in the user experience rather than in the metrics.
File transfers and web pages use TCP, so they slow down rather than break. The user reports that the network is slow.
Voice and video use UDP, which does not retransmit. A packet that never reaches its destination is simply gone, and the user hears a gap or sees the picture freeze. Voice tolerates a little loss and no jitter; these applications are the ones where packet loss is heard rather than measured.
Remote desktop feels latency more than loss. Every keystroke waits a round trip, so 150 milliseconds is perceptible and 300 is unpleasant, even with no loss at all.
JitterJitter, the third number from the same test
Latency and packet loss are the two numbers in the title, and every network monitoring tool reports a third one next to them. Jitter is the variation in latency from one packet to the next, and it is reported in milliseconds like latency itself.
RFC 3550, the RTP standard, defines interarrival jitter as the mean deviation of the difference in packet spacing at the receiver compared to the sender. In plainer terms: how unevenly the packets arrive, not how late they are.
A network path averaging 40 milliseconds with 2 milliseconds of jitter is steady. The same average with 60 milliseconds of jitter is not, and a report that prints only the average shows the two as identical. That is the first reason to read all three metrics rather than one.
Where it comes from. Packets wait in queues, and the queue is not the same length for every packet. One crosses an idle switch, the next waits behind a burst of backup traffic. The average absorbs that variation and the receiver has to cope with it.
What it does to voice. A VoIP application has to play audio at a constant rate, so it holds arriving packets in a jitter buffer and plays them out evenly. A buffer deep enough to absorb the variation adds delay to every call.
A buffer that runs dry produces a gap the caller hears, and that gap is indistinguishable from packet loss to everyone except the person reading the metrics. This is the most common way jitter is reported as a loss problem.
What it does to everything else. File transfers and web applications barely notice it, because TCP delivers in sequence and nobody is listening in real time. So jitter can be the only metric out of range on a network where the users raising issues are the ones on the phone.
Measuring it. Ping prints minimum, average and maximum round trip time, and the spread between minimum and maximum is a crude jitter reading. Continuous monitoring that samples all three metrics and graphs them together is what turns a vague complaint into a specific finding.
DiagnosisFinding which one you have
Settling packet loss vs latency takes one test rather than two, and the mistake is running it for ten seconds.
Ping the destination continuously, not briefly. A ten packet ping tells you almost nothing. Run it for several minutes, or across the period the user complains about, and read both numbers at the end: the average time and the percentage of packets lost.
Ping each hop, not just the final destination. A traceroute shows the network path; pinging each hop along it shows where the loss or the delay begins. Troubleshooting works outward from the first hop rather than inward from the destination.
The rule that matters: a network problem is real only if it persists at every hop after the one where it appeared.
Do not trust a single slow hop. Routers generate ICMP replies at low priority, so a busy router answers your ping slowly while forwarding real traffic perfectly. A hop showing 90 milliseconds with 20 milliseconds after it is doing its job.
Test at the times it happens. Both performance symptoms are usually load related, so a clean test at nine in the morning proves nothing about four in the afternoon. This is the case for continuous monitoring rather than a test run when somebody complains.
Test from both directions if you can. Packet loss is often asymmetric, and a network path that is clean one way and lossy the other is a real and common finding.
Causes and fixesThe causes, and what fixes each
| Symptom | Common cause | What fixes it |
|---|---|---|
| High latency, no loss | Physical distance | Nothing. Move the service closer to the user |
| High latency, no loss | A congested queue upstream | More bandwidth, or traffic shaping |
| Loss on a wired link | A bad cable or failing port | Replace it. This is a hardware fault |
| Loss on wireless only | Interference, distance, channel overlap | Site survey, channel plan, more access points |
| Loss at one hop and after it | A saturated link at that point | More capacity there, or less traffic |
| Loss and latency rising together | A link at capacity | Bandwidth, or shaping so the important traffic wins |
| Jitter with little loss | Variable queuing | Quality of service marking for VoIP traffic |
Two entries deserve emphasis. Packet loss on a wired link inside your own network is a fault, not a performance tuning problem, and the answer is to find the failing component rather than to buy capacity. And nothing at all fixes distance, which is why content delivery networks exist: they move the data closer to the destination.
PitfallsWhere people go wrong
Buying bandwidth for a latency problem. A faster network connection does not shorten the distance. It helps only if the latency was caused by queuing on a full link.
Judging a network path from a ten packet ping. Intermittent packet loss is invisible in a short test, and intermittent loss is the kind people complain about.
Blaming the slow hop in a traceroute. ICMP replies are low priority. Only latency that persists through every subsequent hop is real.
Treating any packet loss as acceptable. Zero is the correct target on a wired network. Loss on wireless is normal and a small amount is expected; loss on copper or fiber inside a building is a broken thing.
Ignoring jitter. Voice quality depends more on the consistency of the delay than on its size. A steady 80 milliseconds is fine and a delay swinging between 20 and 120 is not, and only one of those two shows up in an average.
Measuring only to the final destination. The number that matters for finding a fault is where it starts, and that means testing each hop along the network path.
Assuming the problem is the internet connection. A saturated internal network link, a duplex mismatch or a failing switch port produces exactly the same complaint, and the test is the same. Cloud applications get blamed for network issues that start inside the building.
ComparisonThree numbers from one test, and what each one actually points at
| Criterion | Latency | Packet loss | Jitter |
|---|---|---|---|
| What it measures | Time | A percentage | Variation in time |
| Unit | Milliseconds | Percent | Milliseconds |
| Has a floor set by physics | Yes | No, zero is achievable | No |
| Fixed by more bandwidth | Only if queuing | Only if saturation | Only if queuing |
| Worst for voice and video | Somewhat | Yes | Yes, most of all |
| Worst for file transfer | Somewhat | Yes, TCP backs off | Barely |
| Usually a hardware fault | No | Yes, on a wired path | No |
Reading down the last row is the fastest triage there is. Latency and jitter are almost always about design and load. Loss on a wired path is almost always about something broken.
FAQFrequently asked questions
What is the difference between packet loss and latency?
Latency is how long a round trip to the destination takes, in milliseconds. Packet loss is the share of packets that never arrive, as a percentage. Different measurements, different causes, different fixes.
Which is worse for network performance, packet loss or latency?
Packet loss, usually. TCP treats a lost packet as congestion and slows down, so one percent loss can cost more throughput than fifty extra milliseconds of delay. Both metrics belong in the same monitoring view, since a saturated link produces both.
What is an acceptable amount of packet loss?
Zero on a wired path inside your own network. Anything above zero there is a fault to find. A small amount on wireless is normal.
What is good latency?
Under 100 milliseconds for general work, under 150 for voice, and as low as you can get for remote desktop, where every keystroke waits a round trip and the user experience degrades well before anything is measurably broken.
Does more bandwidth improve latency?
Only if the latency came from queuing on a full network link. It does nothing about distance, which is the component most people are actually measuring.
Why is my ping high even on a fast connection?
Because bandwidth and latency are separate properties. A wider road does not shorten the journey, and distance sets a floor no connection speed removes.
What is jitter?
Variation in latency from one packet to the next, defined in RFC 3550 as the mean deviation in packet spacing between sender and receiver. Voice and video applications care about it more than about the absolute delay, because a jitter buffer can absorb a steady delay and not a changing one.
How do I test for packet loss?
Ping continuously for several minutes, during the period the problem happens, and read the loss percentage at the end. Then ping each hop along the network path to find where it starts, which is where troubleshooting actually begins.
Why does one hop in a traceroute show high latency?
Because generating a reply is low priority work for a busy router. Only delay that continues through the hops after it indicates a real problem.
What causes packet loss on a wired network?
A failing cable, a bad port, a duplex mismatch, or a link carrying more data than it can hold. The first three are faults to find and the fourth is capacity.
Why does packet loss ruin a video call more than a download?
Because video uses UDP and nothing retransmits a packet that missed its destination, so it is simply gone. A download uses TCP, which retransmits and slows down instead.
Can I have low latency and high packet loss?
Yes, and it usually means a hardware fault rather than congestion. A saturated link raises latency as it loses packets, so loss without delay points elsewhere.
How does this relate to ping and traceroute?
Those are the tools that produce both numbers. This page is about reading them, and running ping and traceroute properly is its own subject.
Keep readingRelated concepts
Read next · Protocols TCP vs UDP TCP backs off when it loses a packet and UDP does not, which is why loss sounds like a gap and looks like slowness. Open this next10 min- Diagnostics · 11 min Ping and Traceroute These are the tools that produce both numbers, and running them properly is most of getting a useful answer.
- Protocols · 11 min What Is ICMP? A slow hop in a traceroute is usually low priority reply generation rather than a real delay.
- Diagnostics · 11 min CRC Errors, and the Four Moves That Find the Cause What a link with a handful of errors actually feels like.
- Design · 11 min Ring Topology, and the Networks Where It Never Went Away What the added hops actually cost.
- Infrastructure · 11 min Quality of Service, and the Condition It Needs to Do Anything What the queue on the right costs.
- Protocols · 9 min What IGMP Is, and Why Multicast Floods Without It Telling the symptoms apart.
- Diagnostics · 11 min A Network Troubleshooting Checklist, in the Order That Saves Time What to do when nothing is broken and everything is slow.
- Design · 9 min Hub and Spoke Topology, and the Traffic That Goes the Long Way What the doubled distance actually does to the traffic.
- Fundamentals · 10 min Full Duplex vs Half Duplex, and the Duplex Mismatch That Slows Real Networks Duplex modes explained, and the mismatch that looks like packet loss from the outside.
- Wireless · 9 min 5GHz Channels, and Why Most of Them Come With Conditions What to check before blaming the wireless.