If the game is busy and pulls packets out of the socket (the network send/receive interface the OS provides) late, the OS buffer overflows.
Why Frames fall behind and the game reads the socket late → Effect The OS receive buffer fills up: UDP packets get dropped, and TCP shrinks the receive window so the sender stops sending → On screen Teleporting (UDP) or fast-forward (TCP)
Use a dedicated receive thread, tune the buffer size (SO_RCVBUF).
Ballpark numbers
The default receive buffer is tens to hundreds of KB, depending on the OS and settings. Updates in crowded places can reach hundreds of KB per second.
On the graph
Rises with load · UDP receive buffer drops, frame time
Where to look
Record Microsoft Winsock BSP\Dropped Datagrams (UDP datagrams dropped for lack of socket receive buffer space) and UDPv4\Datagrams Received Errors in Windows Performance Monitor along with frame time; in the game, count gaps in the sequence numbers of received packets
Confirmed if
Dropped Datagrams rises in crowded places or right after a long frame, and gaps appear in the game’s sequence numbers at the same moment. No loss on the connection at the same time
Ruled out if
Dropped Datagrams flat but sequence numbers still go missing: loss along the path
Check with
The player’s own environment
Sources
socket(7) — Linux manual pageLinux man-pages SO_RCVBUF is the maximum socket receive buffer size; the default comes from rmem_default and the maximum from rmem_max (Android also runs the Linux kernel)
RFC 9293: Transmission Control Protocol (TCP)IETF The TCP window field is the number of bytes the receiver can still accept; at 0, the sender waits, sending only zero window probes
Low Latency Workloads Management and OperationsMicrosoft Dropped Datagrams and Dropped Datagrams/sec in the Microsoft Winsock BSP counter set: UDP datagrams dropped because they arrived faster than the app could process them or the receive socket buffer was too small