Latency, jitter and packet loss: how to tell lag apart

Everything that feels bad on a network gets called lag, which is why so much time is spent fixing the wrong thing. There are three distinct measurements, they have different causes, and one minute of ping tells you which one you have.

Latency is how long a round trip takes and it is mostly set by distance. Jitter is how much that time varies and it is usually somebody's own connection. Packet loss is messages that never arrive and it is usually one specific hop. A fourth thing gets called lag too and is not a network problem at all: a server that has run out of CPU and is missing its own ticks. Telling those four apart is the whole skill, and the rest of this post is how.

The three numbers, and what each one feels like#

Latency is a floor set by physics and a ceiling set by equipment. Light in fibre covers roughly 200 km per millisecond, and a packet has to go both ways, so every 1,000 km of path costs about 10 ms of round trip before anything touches it. Real routes are never straight, and every router, every optical amplifier and every congested link adds to it.

Jitter is the one that actually ruins games. A game client is a prediction engine: it guesses where everything will be and corrects when the server tells it otherwise. A steady delay is easy to predict around. A delay that swings between 30 and 140 ms is not, and the corrections are what players feel as rubber-banding and mis-timed hits. Under 5 ms is excellent, under 15 ms is fine, above 30 ms is a broken experience whatever the average says.

Packet loss is binary per packet and statistical in aggregate. Below 0.1% nobody notices. Between 0.5% and 2% a shooter feels wrong and a survival game mostly does not. Above 2% everything feels wrong. The distribution matters more than the number: 2% spread evenly is survivable, and 2% arriving as a burst of forty consecutive lost packets once a minute is a disconnection with extra steps.

Consistent 90 ms plays better than a jittery 40. Predictability beats speed in a game.

Where the milliseconds actually go#

The number in the corner of the screen is not the whole delay between pressing a key and seeing the result. Knowing the rest of the budget stops you chasing 10 ms of network while 80 ms sits somewhere else.

Two of those stages are worth understanding properly.

The tick. A server processes the world in discrete steps. Your input arrives at some point during a step and is not acted on until the next one, so a server running 20 ticks per second adds up to 50 ms and averages 25. At 64 ticks per second that is up to 15.6 ms. This is why tick rate is quoted at all, and why raising it costs CPU rather than bandwidth - what tick rate actually means has the trade in full.

The interpolation buffer. Clients deliberately render the world slightly in the past so that a late packet does not produce a visible gap. In the older Source engine games this was explicit and adjustable: cl_interp_ratio 2 at cl_updaterate 66 buffers two updates, which is about 30 ms of deliberate delay. Newer titles set it for you and mostly do not expose the knobs. The buffer is why a game can feel smooth at 100 ms and terrible at a jittery 40: the buffer absorbs consistent delay and cannot absorb variance.

Telling them apart in sixty seconds#

One command. Run it for a hundred packets, not five.

$ ping -c 100 -i 0.2 play.example.com--- play.example.com ping statistics ---100 packets transmitted, 100 received, 0% packet loss, time 19871msrtt min/avg/max/mdev = 41.2/43.8/58.1/2.4 ms

The summary line answers all three questions:

• 0% packet loss and a low mdev with a high avg: pure latency. The server is far away or the route is bad. Nothing on the server fixes it.
• A low avg and a max several times the min, with mdev above about 10: jitter. Look at the client's own connection first.
• Anything above 0% loss, sustained: packet loss. Find the hop.
• All three fine while the game still feels bad: it is not the network. Skip to the server section.

mdev is the mean deviation, which is a good enough proxy for jitter. Windows does not print it, so use the spread between Minimum and Maximum instead:

ping -n 100 play.example.com

Two caveats about ping that matter. It uses ICMP, and a game uses TCP or UDP on a specific port, so a firewall or a rate limiter can treat them differently - mtr --tcp --port 25565 or --udp tests the real thing. And pinging the server's address tests the path, not the game: a server pegged at 100% CPU answers pings instantly while its world runs at half speed.

Reading an mtr report without being fooled#

mtr pings every hop along the path and is the single most useful tool here, and also the most misread.

$ mtr -rwzbc 200 play.example.comHOST                                 Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???    192.168.1.1               0.0%  200   0.6   0.7   0.5   2.1   0.2 2. AS12345  10.0.0.1                  0.0%  200   8.1   8.6   7.9  18.4   1.1 3. AS12345  core1.isp.example        14.0%  200  11.2  11.9  10.8  29.1   2.0 4. AS3356   ae-1.fra.example.net       0.0%  200  38.4  38.9  38.1  44.2   0.8 5. AS64500  play.example.com           0.0%  200  41.0  41.6  40.9  48.7   1.2

That report shows a healthy path. The 14% at hop 3 is not loss, and reading it as loss is the classic mistake.

• Loss at an intermediate hop that does not continue to the end is not real. Routers deprioritise ICMP aimed at themselves while forwarding traffic perfectly. Only loss that appears at a hop and persists on every hop after it is loss your traffic is suffering.
• The last line is the one that counts. If the final hop shows 0% loss, your path has no loss, whatever the middle of the report looks like.
• A latency jump at one hop is normal - that is the long-distance link. A jump that keeps growing at every subsequent hop is congestion.
• The return path is invisible. mtr shows you the forward route only, and internet routes are frequently asymmetric. If the report looks clean and the problem is real, run mtr from the server back to the player as well. That is often where the bad hop is hiding.
• Run it during the problem. A clean report at 3pm proves nothing about an evening that falls apart at 20:00, which is exactly the signature of a congested peering link.

Reading traceroute and mtr goes deeper into interpreting a report, and WinMTR does the same job on Windows.

Jitter: bufferbloat, wifi and the queue in your own house#

Most jitter is generated within twenty metres of the player.

Bufferbloat is the big one and almost nobody checks for it. Home routers hold a large queue of packets waiting to go out. When somebody uploads a video or a game updates in the background, that queue fills, and every packet after it waits behind a queue that may hold several hundred milliseconds of traffic. Ping goes from 40 ms to 400 ms while the line is busy, and returns the moment it is idle.

Test it in thirty seconds: start a continuous ping, then start a large upload, and watch the numbers. If they triple, that is bufferbloat. The fix is smart queue management - fq_codel or cake - on the router, with the shaper set to roughly 85-90% of the measured line rate so that the queue forms in equipment you control rather than in the ISP's. OpenWrt exposes it as SQM and several consumer routers call it Smart Queue.

Wifi is the other half. A retransmitted frame arrives late, not never, so wifi produces jitter rather than loss. 2.4 GHz shares its spectrum with every neighbour and most microwaves, 5 GHz can change channel without warning when it detects radar, and mesh systems that use one radio for both clients and backhaul halve the airtime. A cable removes all of this and is the single highest-value thing a complaining player can do. Powerline adapters are wifi's equal in unpredictability and should be treated the same way.

A VPN is genuinely worth testing when the evidence points at a bad ISP route, because it can move your traffic onto a different path. It is equally capable of adding a congested hop. Measure with it and without it, on the same evening, before deciding.

Packet loss: what it does to TCP and to UDP#

The symptom depends entirely on the protocol, which is why the same 2% loss produces two completely different complaints.

TCP games freeze and catch up. TCP guarantees delivery and order, so a lost packet stops everything behind it until the retransmission arrives, which costs at least one round trip. Minecraft Java is TCP, which is why loss there shows up as a half-second stall followed by everything happening at once, rather than as teleporting.

UDP games skip. UDP does not retransmit, so the game simply never receives that state update and the client's prediction runs on until the next one corrects it. That is the teleport, the shot that does not register and the door that opens twice. TCP versus UDP for game servers covers why nearly every action game chose UDP and what that costs.

Where the loss actually comes from, in rough order of frequency:

1. A saturated uplink, usually the player's own. A full upload queue drops packets once the buffer is full, which is the endgame of the bufferbloat above.
2. Wifi or a bad cable. A damaged cable or a duplex mismatch produces a small, constant loss that nothing else explains.
3. A congested link somewhere in the middle, appearing at the same hours every day.
4. The server's own socket buffers overflowing when the process cannot read fast enough. On Linux, netstat -su shows receive buffer errors, and those are packets the machine received and threw away.
5. An MTU blackhole, which is not loss at all but looks identical for large packets. Test it directly: ping -M do -s 1472 play.example.com on Linux, or ping -f -l 1472 play.example.com on Windows, sends a 1500-byte packet that must not be fragmented. If small pings work and that one fails, the path cannot carry full-size packets, and the cause is usually a tunnel somewhere.

When it is the server, not the network#

This is the category that gets misdiagnosed most expensively, because people buy a bigger plan to fix a router in their own living room, or move a server to fix a plugin.

The test is one line: if ping to the server is flat and low and the game still stutters, the network is fine. What you are feeling is the server failing to complete its work inside a tick.

Common causes:

• CPU at its limit. One container, a hard throttle at the share you bought, and a game loop that cannot finish in time. A server sitting at 100% is slow, not broken. CPU versus RAM for game servers and reading a server load graph cover reading that honestly.
• A single expensive tick. An autosave that writes a large world, a chunk generation burst, a plugin doing database work on the main thread. In Minecraft this shows up as MSPT spikes rather than sustained load, and spark finds it - diagnosing lag with spark.
• Memory pressure. A garbage collection pause stops the world for as long as it takes, and a server at its memory limit is worse than one with headroom. Why TPS drops works through the Minecraft case.
• A noisy neighbour on shared hardware, which looks like intermittent slowness with no local explanation - shared CPU and noisy neighbours.

On RE:NODE the panel console graphs memory, CPU and disk against the plan's limits, which is the fastest way to separate "my server is out of CPU" from "my network is dropping packets" before spending money on either. Something worth having in place before the complaints arrive is covered in monitoring that tells you something.

What you can fix, in order#

Cheapest and most effective first. Most groups stop after step three.

1. Measure before changing anything. A hundred-packet ping and one mtr from each complaining player. Write the numbers down. Half of all reported lag is one person on wifi.
2. Cable the loudest complainer. It costs nothing and resolves a surprising proportion of jitter complaints on its own.
3. Fix bufferbloat on the router. Also free, also under-used, and it fixes the evening-time complaints that correlate with somebody else in the house.
4. Prove where the loss is, from both directions. Loss on the return path is invisible from the player's side. If it lands inside one ISP's network, the only real fix is a ticket to that ISP with an mtr report attached.
5. Put the server where most of your players are. Latency is distance and nothing changes that. RE:NODE runs one location, Germany, which is a sensible middle for Georgian, Turkish, Eastern and Western European players and is a poor choice for a group in Australia. Choosing where your server lives is the honest version of that decision.
6. Fix the server's tick budget if the numbers say the server is the problem: view distance, entity counts, the plugin doing work every tick.
7. Accept the floor. When the ping is steady and matches the distance, that number is what the route gives you, and no plan, tick rate or protocol changes it.

FAQ#

What is a good ping for a game server?

Under 30 ms is indistinguishable from local for almost everything. 30 to 60 ms is fine for survival, building and roleplay and noticeable in a shooter if you look. 60 to 100 ms is playable and the point where competitive players complain. Above 120 ms it is a different experience rather than a worse version of the same one.

How much packet loss is acceptable?

Below 0.1% nobody notices. Around 1% a shooter feels unreliable. Above 2% it is broken. Bursty loss is much worse than the same percentage spread evenly, so judge by the pattern, not the headline number.

Why is my ping fine but the game still stutters?

Because the delay is not on the network. Either the server is missing ticks, which is a CPU or plugin problem, or the client is dropping frames, which is a local one. A flat ping alongside a stuttering game is the clearest signal there is that the network is not at fault.

Does upgrading my hosting plan reduce ping?

No. Distance sets latency, and a bigger plan does not move the machine. More CPU helps when the server is failing to complete its ticks, which is a different symptom with a similar complaint attached to it.

Is jitter or high latency worse?

Jitter, by a distance. Game clients are built to hide a steady delay and cannot hide a varying one. A stable 90 ms plays better than a 40 ms connection that swings to 200 every few seconds.

Can a VPN reduce my lag?

Sometimes, and only when the problem is a bad route rather than distance. A VPN can put your traffic on a better-peered path, and it can just as easily add a hop and a queue. Test both, at the time of day the problem happens.