If the client processes only a fixed amount of received packets per frame, a flood of packets keeps getting pushed to the next frame.
Why Thousands of updates per second arrive in crowded places → Effect The main thread hits its per-frame processing limit and can’t read them all → On screen Other players’ movements show up later and later, then all at once
Primary owner Game team (Client development) · Also Game team (Server development)
Game team action items
Client: receive and parse on a separate thread, merge stale position updates for the same entity and apply only the latest. Server: in crowded places, send updates for distant characters less often to cut traffic.
Ballpark numbers
Once unprocessed packets pile up, it takes only a few seconds to fall a full second behind.
On the graph
Rises with load · Unprocessed received packets, receive-to-apply delay
Where to look
Log how many packets the client leaves unprocessed each frame and the delay from packet arrival to when the game applies it, and view them alongside the number of nearby players
Confirmed if
In crowded places the leftover packet count and apply delay keep growing, while ping and the server’s send interval stay normal
Ruled out if
No apply delay but the packets themselves arrive late: the network path. Frame time rises sharply: “Rendering load from large crowds”
Check with
Game server or client logs and metrics
Sources
Actor Priority in Unreal EngineEpic Games When bandwidth runs short, not every actor is replicated every time; actors are prioritized by distance from the viewer and time since their last replication
Replication Graph in Unreal EngineEpic Games Games with many players and replicated objects (such as MMORPGs) need to group them by location and send only what each player needs, or the server CPU becomes the bottleneck