Cause ID rt-wireless · Primary owner External (External) · Also Infra team (Server infrastructure), Game team (Server development), Game team (Client development)
Wi-Fi and mobile networks retransmit a few times on the wireless link and drop the packet if that still fails. TCP resends the dropped packet only much later.
Why A weak signal or heavy interference makes wireless transmissions fail several times in a row → Effect Once the wireless device’s retry limit (usually a few to ten-odd attempts) is exceeded, the packet is dropped → On screen Freeze for as long as the TCP retransmission wait, while later packets sit in the receive buffer and then fast-forward
Primary owner External (External) · Also Infra team (Server infrastructure), Game team (Server development), Game team (Client development)
Game team action items
Server: turn on TCP_NODELAY (with Nagle on, RACK has no following packets to use for detecting loss), and while retransmission has the connection blocked, keep only the latest state update pending (cap what queues in the kernel with TCP_NOTSENT_LOWAT). Client: turn on TCP_NODELAY (the client OS recovers losses in the input direction), show network status on screen when losses cluster or ping spikes.
Infra team action items
Speed up loss recovery with RACK-TLP (the server can’t prevent wireless loss; the most it can do is recover faster), confirm the current Linux defaults net.ipv4.tcp_recovery=1 (RACK) and net.ipv4.tcp_early_retrans=3 (TLP) haven’t been changed.
External action items
Tell players to use a wired connection or 5 GHz/6 GHz Wi-Fi, and to move the router or change its channel.
Ballpark numbers
At 1% wireless loss, 1 in every 100 game packets disappears. Receiving 10 a second, that’s a hitch about once every 10 seconds. Without RACK-TLP, each loss freezes the game for an RTO (ping + 200 ms or more).
On the graph
Outliers only · Per-connection retransmission rate, per-connection RTT (ping)
Where to look
From the player’s PC, ping both the router (gateway) and the game server a few hundred times and compare loss and latency spread, then measure again on a wired connection or mobile data. On the server, check that player’s connection in ss -ti for retrans and rtt (mean/deviation)
Confirmed if
Ping to the router already shows loss or erratic latency, and it goes away on a wired connection. From the server, only that player’s connection shows high retrans and RTT deviation
Ruled out if
Clean up to the router with loss starting beyond it: points to the ISP or route (“Bottleneck queue overflow (congestion loss),” “Route change / bad ECMP path”). If several players on the same ISP get worse at the same time, start with the ISP segment
Check with
The player’s own environment
Learn more
Wireless retries add jitter (a few ms per retry), and only packets that exceed the retry limit become losses. So as wireless quality degrades, symptoms grow in this order: “jitter → occasional freezes → frequent freezes.” While a device moves between access points (roaming), it can lose packets in a row for tens of milliseconds to several seconds. Mobile networks retransmit heavily on the radio link to the cell tower, so trouble there more often shows up as latency spikes of hundreds of ms than as loss.
net/wireless/core.cLinux kernel Default retry limits in the Linux wireless stack: 7 for short frames, 4 for long frames (dot11ShortRetryLimit, dot11LongRetryLimit)
Wi-Fi roaming support in Apple devicesApple When a device moves to a new AP, it can’t send data until authentication with the new AP completes, which can take a few seconds with 802.1X
IP SysctlLinux kernel tcp_recovery defaults to 0x1 (RACK), tcp_early_retrans defaults to 3 (TLP on); TCP_NOTSENT_LOWAT and tcp_notsent_lowat cap the amount of data not yet sent
tcp(7) — Linux manual pageLinux man-pages TCP_NODELAY turns off the Nagle algorithm so even small data goes out immediately