Measure latency, jitter and loss as separate things

short · 45 min · Objective 5.4

Task

Make "the network is slow" objective. Latency, jitter and packet loss are three different measurements with three different causes, and the first useful step in any performance complaint is deciding which one you actually have. You will measure all three and then read the interface counter that tells congestion loss from corruption loss.

Steps

  1. Baseline the healthy path. ping -c 50 192.168.20.10 and read the summary: the min/avg/max/mdev line gives you latency (avg) and jitter (mdev, the variation), and the packet-loss percentage. Write the three numbers down as normal.
  2. Add latency and watch only that number move: sudo tc qdisc add dev eth0 root netem delay 100ms. Re-run the ping — avg rises by ~100 ms, mdev stays low. Constant added delay is latency without jitter, which is fine for bulk transfer and bad for interactive traffic.
  3. Swap it for variable delay to create jitter: sudo tc qdisc change dev eth0 root netem delay 100ms 80ms. Now mdev climbs — the variation, not the average, is what makes a voice call choppy.
  4. Swap it for loss: sudo tc qdisc change dev eth0 root netem loss 5%. The ping summary now shows ~5% packet loss. Note how even small loss will punish TCP, which reads loss as congestion and slows down.
  5. Remove the impairment: sudo tc qdisc del dev eth0 root, and confirm the three numbers return to baseline.

Verify

ping -c 50 -q 192.168.20.10 | tail -2
tc qdisc show dev eth0
ip -s link show eth0 | grep -A1 -E "RX:|TX:"

The ping summary is the measurement: three numbers — average latency, mdev as jitter, and loss percent — that name which fault you have rather than lumping them as "slow". tc qdisc show confirms which impairment is active, and the interface counters are where you separate the two causes of loss: rising drops mean a full queue (congestion), rising CRC errors mean corruption (a physical fault). Reading which counter climbs decides the fix.

Notes

The counter distinction is the single most useful diagnostic in this objective. Packet loss from congestion shows as interface drops and is fixed with capacity or QoS; packet loss from errors shows as CRC errors and is fixed at the physical layer. They present identically to the user — packets not arriving — and the fixes are opposite, so confusing them wastes real money replacing cable that works or adding bandwidth that a bad connector will still corrupt.

Jitter deserves its own mention because it matters more than absolute latency for real-time media. A steady 80 ms call is fine; latency swinging between 20 and 150 ms is not, because the receiver cannot assemble a smooth stream from packets arriving at irregular intervals. Its cause is variable queuing, so the remedy is QoS — a priority queue for voice so it is not stuck behind bulk traffic.