Calls stutter, pages stall and you suspect packet loss. It happens when packets never reach their destination, and the usual culprits are congestion, faulty cables, overloaded devices or bad configuration.
This guide sits within our wider coverage of network monitoring.
| Item | Value |
|---|---|
| Loss level noticeable on voice and video | 2% packet loss |
| Example: 10% loss with 500ms latency | A 10-second download takes over 20 seconds |
| Most common cause on wired networks | Faulty cables |
| Typical configuration fault | Speed or duplex mismatch between two devices |
| How TCP reacts to a lost packet | Retransmits it |
These figures come from PathSolutions’ guide to diagnosing and fixing packet loss. They can change, so check the source before you rely on them.
What packet loss is and why you notice it
Data crosses a network as small packets. When some of them are dropped on the way, the receiver has to ask for them again or, for live traffic, simply go without.
The effect depends on the kind of traffic. TCP is built to cope: a packet that is not acknowledged gets retransmitted, so a file download still completes, only more slowly.
Real-time traffic is less forgiving. Voice and video suffer first, because there is no time to wait for a resend, and the listener hears gaps and clipped words. Loss and delay often show up together, which is why it helps to read this alongside our piece on network latency.
Common causes of packet loss
Causes fall into a few groups. Working out which group you are in saves a lot of random swapping of equipment.
- Link congestion: more traffic is offered than a link can carry, so packets are dropped. An ISP that oversubscribes a link can cause the same thing at busy times.
- Overburdened devices: buffers on a router or switch fill up faster than they empty, and the excess is dropped.
- Defective hardware: on wired networks the most common reason is faulty cables. Wireless networks lose packets to interference, weak signal and distance.
- Faulty configuration: a speed or duplex mismatch is the standard example.
Congestion and overloaded devices
Congestion is the one most people meet first. PathSolutions notes that during peak periods, when many people use a service at once, there will be loss from congestion.
A tell-tale sign is loss that rises and falls with the working day or with evening streaming. If it tracks usage, look at utilisation on the busiest links before you touch cabling.
Hardware, cabling and Wi-Fi
Damaged cables, worn connectors and failing ports are common on wired segments. Wi-Fi adds its own problems, and Netmaker lists overlapping Wi-Fi channels among them.
Because a bad port can be the real fault, swapping to another port is a quick and cheap test. Netmaker says that doing so will fix the problem when the port is to blame.
Duplex and configuration errors
If one device is set to half-duplex and its neighbour to full-duplex, the link produces collisions and frame check sequence (FCS) errors. The result is loss that looks random but is entirely repeatable once you look at the interface counters.
How to measure packet loss
Start by proving the loss exists and finding where it begins. Basic tools are enough for a first pass.
- Run ping against a nearby device, then the gateway, then a remote host, and note where loss first appears.
- Use a combined traceroute and ping tool such as MTR, which Netmaker describes as an open-source option, to see loss hop by hop. Loss at one intermediate hop alone does not prove forwarding loss; check whether it persists to the destination.
- Graph results over time with a tool such as PingPlotter, which Netmaker calls excellent for visualising loss over time.
- Check interface error counters on switches and routers for the matching link.
On that last step, PathSolutions says network equipment vendors collect and store hundreds, sometimes thousands, of error counters that report the types of drops detected on interfaces. Polling those counters regularly is what a monitoring system does for you, and it feeds into wider network performance monitoring.
Fixes, in a sensible order
Work from the cheapest, most likely fix outward. Change one thing at a time and retest, so you know what actually helped.
- Replace the suspect cable with a known-good one and try a different switch port.
- Fix speed and duplex so both ends agree, usually by setting both to auto-negotiate or both to the same fixed values.
- Reduce congestion by adding capacity or prioritising important traffic, such as voice, with QoS.
- Tune Wi-Fi by moving off crowded channels and improving signal where distance is the problem.
- Update firmware on routers, switches and modems if the fault points to a device bug.
- Escalate to your provider with traceroute evidence if the loss starts beyond your own network.
Keeping a record so you can prove the cause
A single test shows a moment in time, and intermittent loss rarely appears on demand. Keep a simple log so that the evidence is there when the fault returns.
- Note the time, the affected application and the path tested each time loss appears.
- Record which change you made, and the result of the retest straight afterwards.
- Compare the pattern with busy periods, backups and scheduled jobs that load the link.
- Keep traceroute output, because a provider will usually want to see where along the path the loss starts.
The aim is to move from a vague complaint such as “the network is bad” to a specific finding: this interface, this hour, this error counter. That specificity is what turns a long troubleshooting session into a short one, and it makes it easier to tell whether a fix worked or the fault merely went quiet.
Once the cause is found, leave a monitor in place on that link. Loss that returns after a fix is often the first sign of a cable that is degrading or a link that has outgrown its capacity.
When some loss is acceptable
Not every drop is a fault. Because TCP retransmits, light loss on a low-latency link may go unnoticed. PathSolutions gives the example that 10% loss might add just one second to a 10-second download on such a link.
Latency changes the picture. With 10% loss and 500ms latency, the same download can take over 20 seconds, because loss detection, retransmission and congestion control can substantially increase transfer time.
For voice and video the tolerance is far lower. PathSolutions says 2% loss is typically noticeable to a listener or viewer, so set alert thresholds for real-time links well below those for bulk transfers.
Frequently asked questions
What is a normal amount of packet loss?
Show answer
Ideally none on a healthy wired link. Voice and video users typically notice loss at around 2%, so that is a sensible upper limit to alert on for those paths.
Does packet loss always mean a faulty cable?
Show answer
No. On wired networks faulty cables are the most common cause, but congestion, overloaded devices and duplex mismatches produce the same symptom.
Can Wi-Fi cause packet loss?
Show answer
Yes. Interference, weak signal, distance and overlapping channels can all drop packets. Testing over a cable helps separate wireless problems from wider network ones.
Why is a download slow when TCP recovers lost packets?
Show answer
Each retransmission costs time. The higher the latency, the longer every resend takes, so loss hurts more on slow paths.
