Ping, jitter and packet loss: traffic jams, delays and missing cars

Things seem calm on the Packet Highway. Routers direct traffic, toll booths are open, fibre links are glowing, and the NAT manager has demanded a personal safe for his notebook following the recent DDoS affair.

A complaint reaches the administrator.

— My Internet doesn't work.
— At all?
— No, websites open.
— So it works.
— But calls keep breaking up.
— I see.
— And my game lags.
— I see.
— And sometimes it takes seconds before anything responds.

The administrator starts diagnosing.

— Packets are arriving.
— Then why does everything run like a tractor climbing a hill?!
— Because arriving at your destination doesn't necessarily mean arriving on time.

Ping: hello, anybody home?

The administrator sends a special courier onto the highway. The courier reaches an address, knocks and asks:

— Hello, anybody home?

If the recipient answers, the courier returns with the message:

— Yes, I'm here.

The administrator measures the time between sending the question and receiving the answer. That's the basic idea behind ping. It usually uses ICMP Echo Request and Echo Reply messages, or their ICMPv6 equivalents.

Here's an illustrative output, using an IP address reserved for documentation:

$ ping -c 4 192.0.2.1
64 bytes from 192.0.2.1: icmp_seq=1 ttl=61 time=8.2 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=61 time=8.5 ms
64 bytes from 192.0.2.1: icmp_seq=3 ttl=61 time=8.1 ms
64 bytes from 192.0.2.1: icmp_seq=4 ttl=61 time=8.4 ms

4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 8.1/8.3/8.5/0.2 ms

Replies arrive in roughly eight milliseconds. Crucially, ping measures RTT (Round-Trip Time), the journey there and back. It doesn't measure the outbound time separately.

— Boss, the courier came back in eight milliseconds!
— How long did he take getting there?
— We don't know.
— And returning?
— We don't know that either.
— What exactly DO you know?!
— He made it back before the ninth millisecond.

Latency: how long does the journey take?

Latency is the time needed to deliver information. When diagnosing with ping, we usually observe RTT.

On the Packet Highway, distance, device processing and waiting in queues all contribute. Signals move very fast through fibre, but not instantaneously. Even the best administrator cannot persuade physics to make an exception.

— Boss, why is ping to a server in Australia higher than ping to Warsaw?
— Because Australia is farther away.
— But our Internet is fast!
— Does Australia know that? 🤣

A fast connection doesn't automatically guarantee low latency. A 10 Gb/s connection to a distant server may have a higher RTT than a 100 Mb/s link to a server next door.

Bandwidth tells you how much data you can transfer per unit of time. Latency tells you how long you wait for a response. Different properties of the same road.

Jitter: every car arrives at a different time

Imagine a bus service on the highway, scheduled every ten minutes. The first bus arrives on time. The second does too. The third is twenty minutes late. The fourth turns up thirty seconds later. The fifth arrives together with the sixth.

The dispatcher checks the statistics.

— On average, everything is exactly on schedule!

The passengers disagree.

Jitter is variation in delay over time. In networking, the related term is packet delay variation. There are several ways to calculate it, so different applications may display slightly different figures.

Consider these two RTT measurement series:

Probe	Link A	Link B
1	20 ms	5 ms
2	21 ms	8 ms
3	19 ms	80 ms
4	20 ms	7 ms
5	20 ms	100 ms

Link A is predictable. Link B can reply almost instantly, then make you wait many times longer.

— Which link would you choose?
— The one with five-millisecond ping!
— What about a hundred?
— A hundred what?
— The next measurement.
— ...

That's why a single low ping isn't proof of a good connection.

Why does jitter matter?

While browsing ordinary websites, short changes in delay may be barely noticeable. Voice calls, video meetings and real-time games are another story.

— Listen, I wanted to tell you that…

Silence.

— …today…

Silence.

— …I bought…

Suddenly all three fragments arrive together.

— IBOUGHTTODAYLISTEN! 🤣

Real-time applications often use jitter buffers to smooth irregular packet arrival. That helps, but there's a price: larger buffers may improve playback consistency while adding delay.

— Hello, can you hear me?

Three seconds pass.

— Yes.
— Why didn't you answer?!
— I answered immediately.
— So where was your answer?!
— In the waiting room.

Packet loss: cars that never arrived

So far, some cars have been late. Now a few simply disappear from the measurement. The administrator sends a hundred probes and receives ninety-seven replies. The report shows 3% missing responses.

— Three cars have vanished!
— Not necessarily.
— What do you mean?!
— The cars might have arrived, but their receipts didn't make it back.

Loss shown by ping means an expected ICMP response did not arrive within the timeout. Perhaps the request was lost, perhaps the reply, or ICMP was filtered or rate-limited. It doesn't automatically mean normal application traffic loses packets at the same rate.

What if data packets really are lost? It depends on the protocol.

With TCP, missing data can be retransmitted. This supports reliability but costs time and may reduce throughput. UDP itself does not provide retransmission; the application may implement recovery or simply accept the loss.

TCP:

— Car number 57 didn't arrive.
— Send the delivery again!
— Right away.

UDP:

— Car number 57 didn't arrive.
— Understood.
— What do we do?
— Depends what it was carrying.
— Part of a conversation.
— Probably too late for that now. The conversation is three seconds ahead.

We explored this distinction in our TCP and UDP story.

Zero per cent loss? Great! But from how many probes?

The highway manager receives a report.

— We have a perfect connection!
— Really?!
— Zero per cent packet loss!
— How many packets did you test?
— Four.
— FOUR?!
— And every single one came back! 🤣

Four successful pings do not prove the connection never drops packets. Even a hundred successes cannot guarantee loss-free operation. Short tests can miss intermittent problems.

The pattern matters too: isolated missing packets are different from several consecutive losses, often called burst loss.

— Only three cars are missing!
— Yes.
— Then why is everybody shouting?!
— Because all three were carrying consecutive seconds of the match final.

Bufferbloat: an enormous parking lot before the toll booth

Someone has a brilliant idea on the Packet Highway.

— Our toll booth can't handle enough cars!
— Shall we upgrade it?
— No. Let's build a gigantic car park in front of it.
— Why?
— So cars don't disappear!

The parking lot is built. It's enormous. It holds thousands of vehicles. Cars no longer need to be turned away as soon as the booth is busy. There's just one problem: they wait in line. For ages.

That's a useful metaphor for bufferbloat. Buffers are necessary, but excessively long queues on congested connections can dramatically increase latency.

With little load, ping might be 12 ms. During heavy uploading, it might climb to 350 ms. Throughput still looks respectable, but a voice call is now travelling through a parking lot the size of a province.

— The link is at one hundred per cent utilisation!
— So that's good?
— From an accountant's perspective, excellent.
— And the users?
— They're talking to the past.

Queue management methods such as FQ-CoDel and CAKE can help reduce bufferbloat. They don't create more bandwidth, but they may make a congested link behave much more sensibly.

Why does a router show loss when the Internet works?

The administrator examines a route. One intermediate router fails to answer many ICMP probes.

— Found the culprit!
— Who?
— Router number six!
— What about later routers?
— They're replying normally.
— And the destination?
— Also replying.
— Then how do you know number six is dropping user traffic?!
— Because… asterisks.

Another administrator calls from the next room:

— Go back and read the traceroute article! 🤣

A router may rate-limit diagnostic replies addressed to itself while forwarding ordinary traffic perfectly well.

Missing replies from an intermediate router, without corresponding losses at later hops, do not prove transit traffic is being dropped there. Problems that start at one hop and persist to the destination are a more useful clue, though still not always conclusive.

Look at the entire path, not one red number.

Which matters most: ping, jitter or loss?

At the managers' meeting, someone asks:

— Give us one number that tells us whether the Internet is good.
— You can't.
— You must be able to!
— It depends what you're doing.

Bulk downloads depend heavily on throughput, although latency and loss can limit it too. Games are sensitive to delay, sudden spikes and missing important data. Voice calls need predictable packet delivery, limited loss and sufficiently low latency.

With remote administration, even occasional loss or RTT spikes can make a terminal respond like a civil servant five minutes before closing time.

— Boss, we have a gigabit connection!
— What about SSH?
— I type one letter and wait.
— How long?
— The previous letter just arrived. 🤣

Finale: everything is operating within specifications

The administrator finishes diagnosing. The report says: RTT from 12 to 480 ms, high delay variation, intermittent missing responses and a large increase in RTT under load.

The manager reads the report.

— But the cars arrive!
— Not all of them.
— Most of them!
— Some take half a second.
— Half a second isn't long!
— It can be in a phone call.
— And while downloading a file?
— Not necessarily.

The manager thinks.

— Why don't we just calculate the average travel time and make everyone happy?
— If one car arrives in a second and another in an hour, on average they both arrived in half an hour.
— Exactly! An excellent result!
— ...

At the end of the day, the Packet Highway's information board displays:

“Traffic flowing freely. Delays from 8 to 900 milliseconds. Please report missing vehicles after 24 hours.”

“The Highway Authority accepts no liability for missing fragments of conversations, teleporting vehicles in online games, or administrators who forgot what they wanted to type while waiting for SSH.” 🤣