Check packet loss against ITU-T targets. See the throughput it leaves you, which applications stay in spec, and what the standards call acceptable.
Boundaries from ITU-T Y.1541 Table 1 (IP packet loss ratio for QoS classes 0 to 4) and the application targets in ITU-T G.1010 Table I.1.
| Band | Packet loss |
|---|---|
| No loss | 0 |
| Within ITU class limits | up to 0.1% |
| Real-time still in spec | up to 1% |
| Voice only | up to 3% |
| Outside every published target | over 3% |
ITU-T G.1010 Tables I.1 and I.2. Audio and video targets assume a packet-loss concealment algorithm; every data application targets zero information loss, because TCP has to retransmit what is dropped.
| Application | Target |
|---|---|
| Voice calls (VoIP) | Target: under 3% |
| Video calls | Target: under 1% |
| Streaming audio and video | Target: under 1% |
| Interactive games | Target: zero loss |
| Remote shell and control | Target: zero loss |
| Web browsing | Target: zero loss |
| File transfers | Target: zero loss |
| Target: zero loss |
You might also find these calculators useful
Find the bandwidth-delay product and the TCP window a link needs
Measure network jitter from ping: PDV, buffer size and the ITU limits
Calculate network latency: propagation, transmission, and processing delays
How much internet speed you need, and how long a transfer takes
Most answers to that question are opinions on a forum. There are published ones. ITU-T Y.1541 sets an IP packet loss ratio of 0.1% as the upper bound for every specified network QoS class, and ITU-T G.1010 sets a target for each kind of application: under 3% for conversational voice, under 1% for video and streaming, and zero for web browsing, file transfer, email and interactive traffic. Enter the loss you measured and this calculator grades it against those targets, then shows the throughput TCP can actually reach at that loss rate.
Packet loss is the share of packets that never arrive. TCP treats each loss as congestion and cuts its sending rate, so throughput falls far faster than the loss rate alone suggests: it scales with the inverse square root of the loss probability, not linearly. That relationship is the Mathis equation, and it is why 1% loss can cost far more than 1% of your bandwidth. The equation is a steady-state approximation — RFC 3649 restricts it to loss at or below 1%, so above that this page marks the figure as an extrapolation rather than quietly printing it.
Mathis Throughput Equation
Establish whether the loss you measured is inside the ITU network class limit or well past it before you open a ticket.
Check a candidate link against the G.1010 targets for conversational voice and videophone before committing to it.
Show why a gigabit link delivers a fraction of its rate over a long path with a small amount of loss.
Combine a high round-trip time with a small loss rate to see the ceiling TCP will hit regardless of the circuit.
Ask what packet loss is acceptable and you will be told 1%, 2% and 5% by three different sources. ITU-T G.1010 and Y.1541 publish actual numbers, per application and per network class.
Throughput falls with the square root of the loss rate. On a long path, a fraction of a percent can hold a gigabit link to a few megabits — which is why a speed test disappoints while ping looks fine.
Voice tolerates more loss than video. A file transfer tolerates loss in the sense that it still completes — it just slows down. Grading them all on one scale hides that.
A named standard and a measured ratio make a far stronger case to an ISP than a description of the symptoms.
For the network itself, ITU-T Y.1541 sets an IP packet loss ratio of 0.1% as the upper bound for QoS classes 0 through 4. For applications, ITU-T G.1010 targets under 3% for conversational voice, under 1% for videophone, one-way video and streaming audio, and zero information loss for web browsing, bulk transfer, email, interactive games and remote control. Anything at or below 0.1% is acceptable by every one of those measures.
Yes, by the standard. ITU-T G.1010 classes interactive games with command and control traffic, whose target is zero information loss and under 200 ms one-way delay. Games are not graded on a tolerance band the way voice is, because a lost update is not concealed — it is a missed input or a position correction. At 1% you are already past the target, and past the 0.1% network class limit tenfold.
It is severe. At 10% no application category in ITU-T G.1010 is inside its target, conversational voice included, and TCP throughput collapses: the Mathis relationship puts a 1460-byte MSS on a 50 ms path at roughly 900 Kbps regardless of how fast the line is. Loss at this level is normally a hardware or line fault rather than congestion you can tune away.
On a healthy wired connection, effectively zero — a well-run path shows no loss over a 100-packet ping. ITU-T Y.1541 states its 0.1% objective is achievable on common IP network implementations, so treat 0.1% as the ceiling for normal rather than the expectation. Occasional loss on Wi-Fi or a mobile link is common and not by itself a fault.
TCP reads loss as congestion and reduces its window, so the sustainable rate scales with the inverse square root of the loss probability rather than with the loss itself. Round-trip time multiplies the effect, because the sender waits a full round trip before it can grow the window again. That is why the same 1% loss barely dents a link within a data centre and cripples an intercontinental one.
Run ping with a large sample — 'ping -c 100 8.8.8.8' on macOS or Linux, 'ping -n 100 8.8.8.8' on Windows — and read the loss percentage from the summary line. mtr and pathping additionally show which hop is dropping packets, which matters because loss at an intermediate hop is often the router deprioritising its own ping replies rather than real forwarding loss.
It is the most common cause at home. Interference, distance, and contention with neighbouring networks all produce loss that wired Ethernet does not. Testing the same path over a cable is the fastest way to establish whether the loss is in your own last metre or upstream of it.
Test over wired Ethernet to rule out Wi-Fi, replace ageing cables and check for duplex mismatches, and apply QoS so real-time traffic is not queued behind bulk transfers. If loss persists across a wired path to multiple destinations, it is upstream — capture a timestamped mtr run and report it. Reducing MSS helps only where the loss is caused by fragmentation on a lower-MTU path.