When a client’s outgoing data keeps piling up, the server drops stale updates or disconnects it.
Why The client’s connection can’t keep up with what the server sends → Effect The server drops stale updates, or disconnects the client once a limit is exceeded → On screen Just that player sees teleporting or gets a disconnect
Send less (update rate by distance), keep sending at lower quality, keep less data queued in the kernel (TCP_NOTSENT_LOWAT on Linux).
Ballpark numbers
With a 256 KB send buffer, a 30 KB/s connection builds up more than 8 seconds of backlogged data. Linux may also grow this buffer automatically to several MB.
On the graph
Outliers only · Send-Q per connection, dropped updates per client
Where to look
Per-client send queue length, dropped updates, and disconnect reasons logged by the game server; on the server, that connection’s Send-Q and cwnd together from ss -tni
Confirmed if
Only the connections of players who teleport or disconnect keep a full Send-Q, and the game log shows dropped updates or a disconnect for exceeding the send queue for those players
Ruled out if
Send-Q empty while the player still teleports: not a server send-side problem. Look at that player’s connection loss (“Wireless link loss”) or on-screen interpolation
Check with
Game server or client logs and metrics
Sources
IP SysctlLinux kernel tcp_wmem: the maximum auto-tuned send buffer defaults to 64 KB–4 MB (depending on memory); tcp_notsent_lowat and TCP_NOTSENT_LOWAT limit the amount of unsent data
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Recv-Q and Send-Q in ss: for a listening socket, connections waiting for accept and the backlog limit; for a connected socket, bytes the app hasn’t read yet and sent bytes not yet ACKed