Packet Loss
Packet loss is data that never arrives. Under UDP the game does not wait for it. The client keeps predicting from the last state it holds, so each lost update extends the window in which it is guessing. The correction when the next update lands is larger, and visible.
,
What Happens When a Game Packet Is Lost?
A multiplayer game is a stream of small packets in both directions. The player's client sends inputs to the server many times a second, and the server sends back snapshots of the world. Many games send one snapshot per tick, and Apex Legends servers tick 20 times a second (Respawn, April 2021). Packet loss means some of those packets never arrive. UDP does not retry them, and the match does not pause to wait, so the receiver carries on with what it last knew.
What the loss costs depends on which packet went missing:
A lost snapshot (server to client). The client has no new state for the gap. It keeps showing the last state it had, or guesses forward from it, and other players jump to where they now are when the next snapshot lands.
A lost input (client to server). The server never hears that the player pressed a key, so it typically keeps simulating the player with the last input it had. The player's own client has already acted on that input, so it is corrected when the server's reply arrives. The TRIBES II networking paper, by Mark Frohnmayer and Tim Gift, describes this as the client's and the server's copies of the character drifting apart, with a brief, visible warp (TRIBES II networking model).
In both cases a lost packet is a gap in what the game knows, and the game fills the gap with a guess. How large those guesses get, and how games keep them small, is the rest of this page. The correction itself is what desync covers.
In Practices - Insights from Edgegap's Blog
Article's key insights
Latency has a floor, and everything else stacks on top of it: The physical travel time between two machines is the minimum delay any online game can have. Routing, tick rate, update rate and processing all add to it. Netcode cannot remove that delay. It can only decide where players feel it.
The shortest path is rarely the fastest: A direct peer-to-peer connection looks like the shortest route between two players, but packets still cross both players' ISPs and whatever routes those networks choose. A well-placed server between them is often both faster and fairer.
Lag compensation moves the cost, it doesn't erase it: Lag compensation rewinds the server so a high-ping player's shot counts, which means the target can be hit after reaching cover. The only real fix is keeping ping gaps small, which makes it a matchmaking and server placement problem as much as a netcode one.
Tick rate is a time budget: A server's tick rate sets how many milliseconds it has to simulate each step of the game. Higher rates cut delay and sharpen hit registration, but cost more CPU and bandwidth. A server that overruns its budget stutters for everyone in the match.
Two separate choices, not one: Where the game runs (peer-to-peer, relay or dedicated server) and how state is shared (lockstep, rollback or state replication) are independent decisions. Any sync model can run on any hosting model.
Which Lost Packets Does a Game Resend, and Which Does It Skip?
Under UDP the protocol resends nothing, so the game decides, one kind of data at a time. The TRIBES II paper shows three common answers:
State is replaced, not resent. When a packet carrying an object's state is reported dropped, the server does not resend that packet's contents. It marks the object's changed values as unsent again and sends the object's current state at the next opportunity, unless a later packet has already carried it. The paper calls this the "Most Recent State" approach and says it guarantees only that the latest version arrives.
Events are resent. A shot fired or an item picked up happens once, and the next snapshot does not replace it. TRIBES II retransmits these "guaranteed" events and processes them in order. Events marked non-guaranteed are never retransmitted.
Inputs are sent more than once. Each move travelled in three consecutive packets, so a move was lost only if three packets in a row were dropped. Every packet from the client carried the moves the server had not yet acknowledged.
Redundancy has a cost, and the paper records it. The original TRIBES (1998) put every unacknowledged move into every packet, which guaranteed delivery. But a drop widened the window, the larger packet was more likely to drop, and the loop fed itself. TRIBES II reduced the number of resends to stop it.
An input window needs a ceiling for the same reason.
How Do Games Hide a Lost Update?
When state does go missing, the client still has to draw something. Infinity Ward's 2019 Modern Warfare explainer, as summarised in Edgegap's Call of Duty netcode article, describes three answers, mixed per player according to their connection:
Buffering keeps the client slightly behind the latest data, so a late packet does not cause a hitch. The cost is delay.
Extrapolation assumes the player keeps doing what they were doing. The cost is a visible pop when they change direction.
Prediction treats the extrapolated input as if the server had confirmed it. The cost is a larger correction, and too much of it makes the game hard to play on a poor connection.
Each answer turns loss into something else: delay, a guess, or a correction.
Overwatch protects the input side instead. When the server runs out of input to simulate, it tells the client to simulate slightly faster for a while, so the server's input buffer refills before loss causes mispredictions. Each packet also bundles every input the server has not yet acknowledged. Both come from Timothy Ford's GDC 2017 talk, as summarised in Edgegap's Overwatch deep dive. The cost moves again: some bandwidth, and a small shift in timing.
Interpolation and client-side prediction cover the mechanisms in depth.
Why Does the Loss Pattern Matter More Than the Percentage?
The loss percentage says how many packets went missing. It does not say how they went missing, and that decides whether a player notices.
Each defence covers a gap of a certain length, so what matters is how many packets in a row are lost. Take a server that sends one update per tick at 20 ticks a second, the rate Apex Legends servers run at (Respawn, April 2021). Every lost update adds 50 ms to the gap.
What is lost | Gap | What covers it |
|---|---|---|
One snapshot | 50 ms | The interpolation buffer. Valve's Source engine defaults to 100 ms, so one lost update still leaves two to blend between (Valve). |
Five snapshots in a row | 250 ms | Not that buffer. The client holds the last state or extrapolates, then corrects when the next update lands. |
One or two input packets in a row | n/a | Redundancy. TRIBES II sent each move in three consecutive packets. |
Three input packets in a row | n/a | Not covered. The moves unique to those packets are lost, and the player is corrected. |
Two connections can both average 5% loss. One loses isolated packets, which the defences above usually absorb. The other loses them in bursts, which they do not. The percentage is the same and the experience is not.
So track the longest run of consecutive lost packets for each player, next to the average. That one number shows whether the loss is being absorbed. The gaps here are estimates from the figures cited.
A higher update rate shrinks each gap, at a cost in bandwidth. Respawn calculated that moving Apex from 20 Hz to 60 Hz would triple it, from about 60 kB/s to 180 kB/s.
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
How Do You Tell Where the Loss Is Happening?
Loss can start in four places, and the developer owns only one: the player's home network, their internet provider, the route between that provider and the data center, and the data center itself.
Respawn's 2021 deep dive found loss in several of them: on a player's provider network, on the link between a provider and its data center, and on return routes that differ from the outbound path. It also traced severe loss, across every game on a handful of servers, to one faulty network device in a data center, while the servers themselves were fine. Its own summary of most loss reports was that it is "probably not your fault", and usually not the developer's either (Respawn).
What separates the places is where the loss clusters. Loss that follows one player is their connection. Loss that follows one server, across many players, points at that host or its network. Loss that follows one provider, across many servers, points at the route.
Apex gave players a performance display in Season 6 that shows packet loss and choke as a percentage of packets per second. A player can report "10% packet loss, 300 ms latency" instead of "lag", and the developer gets numbers it can sort by player and server.
Two kinds of data answer different questions. Loss counters, per player and per server, show what did not arrive. A packet capture shows what each packet carried. Some netcode libraries record captures on the server: SnapNet's Unreal SDK writes them as JSON files that open in Chrome's tracing viewer, with segment widths proportional to the bits each entity and field uses (SnapNet documentation). That is bandwidth data, which is what tells you whether sending each input three times, or raising the update rate, is affordable. Their documentation advises capturing a few seconds at a time, because the files grow quickly.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Packet Loss Often Starts Outside Your Game, So Design for It and Measure It
Packet loss is often a property of the connection, Wi-Fi and home hardware included, and the game's job is to cope with it. Respawn's data points the same way: provider networks, the link into the data center, and one faulty device.
So measure how well it copes. Log loss per direction, and the longest run of consecutive lost packets for each player, and tag every match with its server's location. Compare the longest run with what your redundancy window and buffer can cover. If the runs fit, the loss is being absorbed. If they do not, widen the defences, or check whether the loss sits on one server or one location, which is hardware you can act on.
Edgegap does not publish a packet loss figure, and no server placement fixes a player's home network. A shorter route does give every player, including those on Wi-Fi, more room for the defences, because a resend or a correction costs a round trip. It also narrows the gap between players: in Edgegap's 2020 1v1 study, per-match placement narrowed it in 66% of matches, by 31 ms on average (1v1 case study).
,
