Packet loss or high ping: working out which one you have

An opponent runs along a wall, stops dead for half a second, then reappears a body-length further on. Two shots that were on target do nothing, and the view snaps back a step, while the ping readout in the corner holds at 38 ms throughout. That is packet loss, or its close relative jitter. High ping looks different: everything arrives late by the same amount, all the time.

How the two feel

High ping is a constant delay. Every action lands late by the same margin, so after a minute your hands adjust and you lead moving targets a little more. Nothing jumps. What ping measures, and where it comes from covers the delay itself.

Loss is intermittent. The game stops receiving updates for a moment and has to guess, then corrects itself when the next update arrives, and those corrections are the teleporting and rubber-banding. A shot fired into the gap may never count. Jitter, packets arriving unevenly rather than not at all, feels much the same. Valve's own help page makes the point that for a game a late message is usually as bad as a dropped one. How prediction and interpolation produce each of these effects is in the netcode guide for players.

Minecraft: Java Edition runs over TCP, which resends anything lost, so loss there shows up as a freeze followed by everything happening at once.

What the game will show you

Counter-Strike 2 has a telemetry HUD under Settings > Game > Telemetry. Each part can be set to show always, never, or only past a threshold you choose. Ping is the round trip. The network problems readout has two percentages with up and down arrows: the share of ticks where your data did not reach the server in time (up) and where the server's data did not reach you in time (down). A detailed view adds raw loss and jitter columns, and a jitter graph draws a red line for every dropped message and a purple one for every reordered one. Valve's telemetry FAQ explains each readout.

A high ping with a miss rate of zero points to distance or routing. Misses on the down arrow only point at the path from the server to you. Misses on the up arrow only are the reverse; at home, suspect something else using the upload, such as a cloud backup. The "Buffering to smooth over packet loss / jitter" option under Settings > Game hides some of it at the cost of extra latency.

In Counter-Strike: Source, Team Fortress 2 and Garry's Mod, net_graph 1 still puts loss and choke figures on screen beside latency and frame rate. Minecraft's player list shows only a signal-strength icon beside each name, which says nothing about loss.

Try a cable before anything else

Plug the PC into the router with a cable and play the same server again. Wi-Fi shares its airtime with every other device and with the neighbours' networks, and it produces exactly this pattern: fine for minutes, then a burst of loss and jitter. Powerline adapters and mesh satellites share some of the same problems, so the test needs a real cable, even a long temporary one across the floor.

Measuring outside the game

On Windows, ping -t followed by the server's address pings once a second until stopped. Ctrl+Break prints the running totals, including how many were lost, without stopping it; Ctrl+C ends it. Leave it running while you play for ten minutes.

One target shows that loss exists, not where. pathping -n with the same address traces the route, then sends 100 queries to every hop a quarter of a second apart and prints loss per hop and per link. That takes about 25 seconds per hop, so a 12-hop route runs for five minutes; -n skips the name lookups. On Linux or macOS, mtr -r -w -c 100 with the address does the same kind of job and prints a report after 100 one-second cycles. WinMTR is a free Windows program built on the same idea.

Two caveats. Many game servers ignore ping, so a last line that never answers says nothing about the server being down; judge the path by the hops before it. And CS2's own matchmaking goes through Valve's relay network, so a trace to a match server's address does not follow the game's traffic. Community servers take a direct connection, and a trace to their address follows much the same route.

Reading the trace

Loss at one hop in the middle that does not appear at the hops after it is not loss your game sees. Routers treat pings addressed to themselves as low priority, and busy ones skip some. The mtr manual says so, and Microsoft's pathping documentation has an example where routers drop pings aimed at them while forwarding everything else. Real loss starts at a hop and continues on every hop after it, all the way to the destination.

Where it starts tells you whose it is. From the first hop, your own router or the Wi-Fi to it, the problem is at home. From the next few hops, it is your provider's network. Further along, often where the route crosses from one network into another, it is the path between your provider and the server's host, which neither you nor the server owner controls directly, and one reason ping has so little to do with distance. If it starts only at the last hop, look at the server or its host.

You, the route or the server

Start with the other players. If everyone on the server rubber-bands at the same moment, including players with low pings, the trouble is on the server's side: either the machine is falling behind its own tick, which the tick rate explainer covers, or the host's network is dropping traffic. Both are the owner's to chase. If it is only you, try another server in the same city, ideally the same data centre. Trouble there too points at your connection or your route to that area. A clean game there points at the route to that one host, or the host itself. Friends abroad travel a different route entirely, which is why playing across regions gives them different results on the same server. If the connection drops outright rather than stuttering, the can't-connect checklist is the better starting point.

What to send the server owner

A report an owner can act on has the server address, the date and time in UTC rather than "last night", whether you were on cable or Wi-Fi, your country and provider, a screenshot of the telemetry or net_graph while it happened, and the pathping or mtr output pasted as text. Add whether other servers in the same city were fine. Three reports like that from different players at the same hour give an owner something concrete to take to the host.

For your provider, send the trace that shows loss starting at a hop and continuing to the destination, taken on a cable, at two or three different times of day. Leave out traces where the only loss is on a middle hop, because that is the first thing a support desk will point out.