Calculator Inputs
Formula Used
Packet Loss (%) = (Lost ÷ Sent) × 100
Delivery (%) = (Received ÷ Sent) × 100
Offered load (Mbps) = (Sent × (Payload+Overhead) × 8) ÷ (Duration × 10⁶)
Application goodput (Mbps) = (Received × Payload × 8) ÷ (Duration × 10⁶)
TCP Throughput (Mbps) ≈ (C × MSS × 8) ÷ (RTT × √p × 10⁶)
How to Use This Calculator
- Collect sent and received packet counters for the same window.
- Enter the measurement duration in seconds.
- Set payload size and per-packet overhead for your stack.
- Optionally add link capacity to see utilization and headroom.
- Optionally add RTT, MSS, and C for TCP throughput estimation.
- Press Submit to view results, then export CSV or PDF.
Example Data Table
| Scenario | Sent | Received | Duration (s) | Payload (B) | Loss (%) | App Goodput (Mbps) |
|---|---|---|---|---|---|---|
| LAN baseline | 1,000,000 | 999,950 | 60 | 1200 | 0.0050 | 159.992 |
| Wi‑Fi congestion | 300,000 | 288,000 | 30 | 800 | 4.0000 | 61.440 |
| WAN with bursts | 500,000 | 485,000 | 120 | 1400 | 3.0000 | 45.267 |
Engineering Notes
- Low loss can still hurt TCP: Throughput often drops roughly with 1/√p when losses are random.
- Burst losses matter: Long bursts can cause timeouts and media glitches, even if average loss is moderate.
- Overhead choice: Use realistic per-packet overhead (L2+L3+L4) for wire-rate accuracy.
- Counter consistency: Ensure both counters cover identical start/end times.
Packet loss as a reliability indicator
Packet loss is the fraction of transmitted packets that never arrive. Engineers track it because it captures congestion drops, RF errors, buffer overruns, and policing events in one number. For interactive voice, sustained loss near 1% can be audible, while video often tolerates 2–3% with modern concealment. For bulk transfers, even small loss raises retransmissions, inflating delay and reducing effective capacity.
Interpreting loss rate, delivery, and pps
This calculator reports lost packets, loss percentage, and delivery percentage from sent and received counters. It also converts counts into packets per second using the measurement duration, which helps normalize tests of different lengths. A stable pps with rising loss typically indicates a constrained queue or noisy medium. A falling pps with rising loss can indicate upstream rate limiting, backoff behavior, or application throttling under similar traffic mix.
Goodput, overhead, and efficiency planning
Offered load uses payload plus per-packet overhead to approximate wire rate. Application goodput uses payload only, reflecting user data delivered. The difference between these values becomes large for small packets, where headers dominate. For example, 200-byte payload with 42-byte overhead adds 21% extra bytes on the wire. Efficiency summarizes how much of the transmitted bit rate becomes delivered application data.
Burst loss and loss events in real links
Average loss can hide bursts that cause timeouts and media gaps. If you know the number of loss events and the longest burst, the tool estimates average packets lost per event and a burstiness index. A high burstiness index suggests correlated loss, often caused by queue tail drops, Wi‑Fi interference, or route flap micro-outages. For real-time flows, combine burst insight with packet interval to estimate lost packets per minute.
TCP throughput sensitivity and RTT effects
When RTT, MSS, and the model constant are provided, the calculator applies a Mathis-style approximation where throughput decreases roughly with 1/√p, where p is loss fraction. Higher RTT magnifies the throughput penalty because the congestion window recovers more slowly. Use the estimate to compare scenarios, then validate with a controlled transfer test. Consider capping by link capacity and treating zero-loss cases as unconstrained.
FAQs
1) What does packet loss percentage represent?
Packet loss percentage is the ratio of lost packets to sent packets. It highlights how many transmissions failed to reach the receiver during the same time window, helping you quantify reliability and compare links or configurations objectively.
2) How should I set payload and overhead values?
Use the average application payload per packet. Set overhead to include headers and framing on the wire. Common starting points are 42 bytes for Ethernet plus IPv4 and UDP, or 54 bytes for Ethernet plus IPv4 and TCP.
3) Why are offered load and application goodput different?
Offered load counts payload plus overhead for every packet sent, approximating wire rate. Application goodput counts only delivered payload, reflecting usable data received. Loss and protocol headers make goodput lower than offered load in real networks.
4) Why does small loss reduce estimated TCP throughput?
Many TCP variants reduce the congestion window after loss. The Mathis-style estimate scales roughly with 1 divided by the square root of loss fraction and is also inversely proportional to RTT, so small losses can still cut throughput sharply.
5) How do bursts change the impact of loss?
Bursty loss can cause consecutive missing packets, increasing the chance of timeouts, decoder errors, or audible glitches. Even with the same average loss, longer bursts are typically worse for streaming, gaming, and interactive calls.
6) Where can I obtain sent and received counters?
Use interface statistics from routers or switches, host NIC counters, iperf summaries, or packet captures that report transmitted and received frames. Ensure both counters cover the same start and end timestamps for accurate results.