If the server sends position updates (snapshots) only a few times a second, the interpolation buffer has to be that much longer, and you see other characters further in the past.
Why Position updates sent only 5–10 times a second to save bandwidth → Effect Smooth rendering needs a buffer of twice the packet interval (200–400 ms); with a shorter buffer, a single missed packet causes a freeze → On screen Opponents’ direction changes show up late and disagree with hit registration. With a short buffer: stutter, plus teleporting on packet loss
Primary owner Game team (Server development) · Also Game team (Client development)
Game team action items
Server: send nearby or in-combat targets often and distant ones rarely, send only what changed (delta compression) to shrink each update and raise the rate. Client: adjust the interpolation buffer length automatically to the packet interval.
Ballpark numbers
At 10 per second, the packet interval is 100 ms and the buffer 200 ms. Add the 75 ms one-way latency of a 150 ms ping, and you see opponents about 0.3 s in the past.
On the graph
Always high · Packet arrival interval per client, interpolation buffer length
Where to look
Server-side packet capture filtered to the flow going to one player, with packets per second and intervals in Wireshark I/O Graphs. With game logs, update interval per entity together with the client’s interpolation buffer headroom (time left until the next snapshot arrives)
Confirmed if
Position updates are always sparse at 5–10 per second (100–200 ms apart), and the interpolation buffer is set above 200 ms or its headroom often hits 0
Ruled out if
Updates go out densely but only the arrival intervals wobble: points to jitter or loss. Only distant entities arrive rarely when it’s crowded: per-connection send budget and priority