Die Pakete erreichen den Server, werden aber verworfen, weil der Ringpuffer der NIC (ein Puffer, der ankommende Pakete kurz zwischenspeichert) überläuft oder der CPU-Kern, auf dem der Kernel den Empfang verarbeitet, voll ausgelastet ist.
Warum Ansturm von Spielern, Interrupts auf einem einzigen Kern, CPU-Steal in der VM oder überlasteter virtueller Switch → Folge Verworfen im Ringpuffer (rx_missed_errors o. Ä., Name je nach Treiber) oder in der Empfangswarteschlange des Kernels (softnet dropped) → Auf dem Bildschirm Bei großem Andrang auf dem ganzen Server gleichzeitig Input-Lag und kurze Freezes
Drop-Zähler wie rx_missed_errors in ethtool -S und dropped in /proc/net/softnet_stat ins Monitoring aufnehmen, Ringpuffer vergrößern (ethtool -G), RSS und Interrupts auf mehrere Kerne verteilen, Game-Thread und Empfangsverarbeitung auf getrennte Kerne legen, CPU-Reserven schaffen, bei VMs CPU-Steal und Last des virtuellen Switches prüfen.
Größenordnungen
Pakete, die der Server beim Empfang verwirft, sendet der Client erneut. Deshalb tauchen sie in den Retransmission-Metriken des Servers kaum auf und zeigen sich zuerst in Drop-Zählern wie rx_missed_errors in ethtool -S (Name je nach Treiber) und in dropped in /proc/net/softnet_stat.
Im Graphen
Plateau am Limit · softirq-Auslastung pro Kern, Drop-Zähler der NIC
Wo nachsehen
Drop-Zähler in ethtool -S (rx_missed_errors o. Ä., bei mlx5 rx_out_of_buffer und rx_discards_phy), missed in ip -s -s link sowie 2. Spalte (dropped) und 3. Spalte (time_squeeze) von /proc/net/softnet_stat prüfen, mit mpstat -P ALL %soft (Verarbeitung von Soft-Interrupts) pro Kern ansehen. Bei VMs auch %steal
Spricht dafür
Zu Zeiten großen Andrangs steigen Drop-Zähler oder softnet dropped, %soft des Kerns für die Empfangsverarbeitung verharrt nahe 100 %. Auf allen Verbindungen dieses Servers verzögern sich Eingaben gleichzeitig
Spricht dagegen
Drop-Zähler des Servers unverändert, Retransmissions häufen sich bei Verbindungen bestimmter Regionen oder Provider: Verlust auf der Route. Gehen vom Server gesendete Pakete unterwegs verloren, steigt TcpRetransSegs in nstat auf dem Server, diese Zähler bleiben unverändert
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Interface statisticsLinux kernel rx_missed_errors ist die Zahl der Pakete, die der Host mangels Puffer nicht annehmen konnte (in /proc/net/dev unter drop mitgezählt), Prüfung mit ip -s -s link
Ethtool countersLinux kernel rx_out_of_buffer (kein Puffer in der Empfangs-Queue) und rx_discards_phy (verworfen wegen zu wenig Portpuffer) im mlx5-Treiber
net/core/net-procfs.cLinux kernel /proc/net/softnet_stat hat eine Zeile pro CPU in Hexadezimal, die 2. Spalte ist dropped, die 3. Spalte time_squeeze
Documentation for /proc/sys/net/Linux kernel netdev_max_backlog: Obergrenze der Empfangswarteschlange für Pakete, die schneller ankommen, als der Kernel sie verarbeitet
Scaling in the Linux Networking StackLinux kernel RSS: Die NIC verteilt den Empfang auf mehrere Empfangs-Queues, die auf mehreren CPUs verarbeitet werden
proc_stat(5) — Linux manual pageLinux man-pages steal in /proc/stat: Zeit, in der in virtualisierten Umgebungen ein anderes Betriebssystem die CPU genutzt hat
mpstat(1) — Linux manual pagesysstat mpstat -P ALL zeigt die Auslastung pro Kern, %soft ist die Zeit für Soft-Interrupts, %steal die Wartezeit, während der Hypervisor andere virtuelle CPUs bediente
net/ipv4/proc.cLinux kernel In nstat angezeigtes TcpRetransSegs (RetransSegs im Abschnitt Tcp)
Verwandte Ursachen
Gleiche Schicht: Grundursachen von TCP-Retransmissions