Ist das RTO-Minimum zu weit gesenkt, kommt es schon bei leichter Verspätung zu unnötigen Retransmissions. Der Standardwert (200 ms) ist für Spiele zu lang, jeder einzelne Verlust führt zu einem langen Stillstand.
Warum RTO-Minimum für den Rechenzentrumsbetrieb stark gesenkt, oder Standardwert unverändert auf Internetstrecken → Folge Zu niedrig: Flut von Retransmissions schon bei kurzen Verzögerungen. Zu hoch: lange Wartezeit bei jedem Verlust → Auf dem Bildschirm Mit Standardwert pro Verlust einige hundert ms Freeze, dann Zeitraffer. Zu weit gesenkt: weniger Freeze, aber unnötige Retransmissions nehmen sprunghaft zu und verschwenden Leitungskapazität
Ab Linux 6.15 prüfen, ob sich die RTO-Obergrenze für Spielverbindungen mit TCP_RTO_MAX_MS senken lässt (dadurch wird auch die Zeit bis zur Aufgabe kürzer, daher zugleich per TCP_USER_TIMEOUT festlegen, wann eine Verbindung als abgebrochen gilt), das RTO-Minimum nur für interne Verbindungen zwischen Servern per Socket-Option TCP_RTO_MIN_US (ab 6.15) senken, prüfen, ob sich per Socket-Option TCP_THIN_LINEAR_TIMEOUTS nur für Spielverbindungen das Verdoppeln bei aufeinanderfolgenden RTOs abschalten lässt.
Aufgaben Infrastrukturteam
rto_min pro Route nur für interne Verbindungen zwischen Servern senken, auf Internetstrecken den Standardwert beibehalten und mit RACK-TLP und Thin-Stream-Einstellungen (tcp_thin_linear_timeouts) ergänzen.
Größenordnungen
Linux-RTO = Umlaufzeit + max(200 ms, RTT-Abweichung × 4). Bei jedem Fehlschlag doppelt so lang, maximal 120 s. Ab Linux 6.15 lässt sich diese Obergrenze mit TCP_RTO_MAX_MS bis auf 1 s senken.
Im Graphen
Von Anfang an dauerhaft hoch · RTO pro Verbindung, unnötige RTOs
Wo nachsehen
Eingestelltes RTO-Minimum des Servers (rto_min in ip route show, ab Linux 6.11 sysctl net.ipv4.tcp_rto_min_us) sowie rto und rtt in ss -ti prüfen, Zuwachs von TcpExtTCPSpuriousRTOs in nstat ansehen
Spricht dafür
Auf Servern mit gesenktem Minimum liegt rto bei Internetverbindungen dicht an rtt, und TcpExtTCPSpuriousRTOs steigt stark. Mit Standardwert ist rto bei Spielverbindungen mindestens 200 ms größer als rtt, und jeder Verlust bedeutet einen Stillstand dieser Länge
Spricht dagegen
rto entspricht der Standardberechnung (rtt + ca. 200 ms), wenige unnötige RTOs, aber auffallend lange Stillstände: Verluste in Folge oder Wiederherstellungsverfahren („Langsame Wiederherstellung bei Thin Streams“, „Zwischengeräte entfernen TCP-Optionen“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
RFC 6298: Computing TCP's Retransmission TimerIETF RTO = SRTT + max(G, 4·RTTVAR), Empfehlung mindestens 1 s, bei jedem Fehlschlag doppelt, ein Maximum muss, falls vorhanden, mindestens 60 s betragen
include/net/tcp.hLinux kernel Linux: TCP_RTO_MIN 200 ms, TCP_RTO_MAX 120 s
net/ipv4/tcp_input.cLinux kernel Linux-RTO ist SRTT + rttvar, und rttvar sinkt nicht unter das RTO-Minimum (standardmäßig 200 ms)