Ist der Sendepuffer eines einzelnen Spielers mit langsamer Leitung voll und sendet der Server blockierend (der Aufruf kehrt erst zurück, wenn im Puffer wieder Platz ist), wartet der Server-Thread auf diesen einen Spieler.
Warum Sendepuffer eines langsamen Clients voll → Folge Wegen blockierendem Senden wartet der Server-Thread, bis im Puffer wieder Platz ist → Auf dem Bildschirm Alle, die dieser Thread bedient: Freeze oder Zeitlupe
Nicht blockierend senden, Obergrenze für die Sende-Queue pro Client, veraltete Updates verwerfen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Send-Q pro Verbindung
Wo nachsehen
Mit ss -tn Verbindungen suchen, deren Send-Q (unbestätigte oder noch nicht gesendete Bytes) den Sendepuffer füllt, im Moment der Tick-Spitze im Thread-Dump (Stack) des Spielservers prüfen, ob Threads im send-Aufruf hängen
Spricht dafür
Bei einer langsamen Verbindung mit voller Send-Q hängt der zuständige Thread in send, und nur die Spieler dieses Threads stehen mit still
Spricht dagegen
Hängende Threads warten außerhalb von send (Lock, DB-Aufruf): „Lock-Contention“, „Synchrone Aufrufe im Game-Thread“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
send(2) — Linux manual pageLinux man-pages Ist im Sendepuffer kein Platz, blockiert send(), im nicht blockierenden Modus kehrt der Aufruf sofort mit EAGAIN zurück
send function (winsock2.h)Microsoft Auch bei Winsock blockiert send ohne Pufferplatz, außer im nicht blockierenden Modus
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes