한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game Lag White Paper › Root causes of TCP retransmission

Physical errors (bad cable, optics, connectors) Bit errors: bad cable, optics, dirty fiber

Cause ID rt-physical · Primary owner Infra team (Network infrastructure) · Also Infra team (Server infrastructure), External (External)

Open the interactive card with figures and simulations →

Damaged cables, dirty fiber connectors, and worn-out optics cause bit errors, and network equipment silently drops the corrupted packets.

Why A bad cable, optic, or connector flips bits → Effect Equipment drops packets whose checksum (CRC) doesn’t match → On screen Only players whose traffic takes that path keep getting short hitches followed by fast-forward, at any time of day

Symptoms
Freeze, Fast-forward, Teleporting
Factors
Packet loss
Who’s affected
Specific zone/channel, Same household
When
Always
Owner
Primary owner Infra team (Network infrastructure) · Also Infra team (Server infrastructure), External (External)
Infra team action items
CRC errors accumulate on the receiving end of the bad direction, so check both ends. Network: check CRC and input error counters on device ports, check optical power (the switch’s optics info), clean fiber connectors, replace cables and optics. Servers/OS: check rx_crc_errors in ethtool -S on the server (the name varies slightly by driver), check optical power (ethtool -m), replace the server-side cable or NIC.
External action items
If the problem is in the player’s home, tell them to replace the Ethernet cable or router; if it’s on the ISP’s line, ask the ISP to inspect the line.
Ballpark numbers
Even 0.1% loss is one in every 1,000 game packets. With dozens of players on that path, someone hitches every few seconds. Bit errors hit larger packets more often.
On the graph
Outliers only · CRC errors per port, retransmission rate per server and per port
Where to look
CRC counters at both ends of the link: on servers, rx_crc_errors in ethtool -S or crc in ip -s -s link; on switches, the port’s FCS errors (dot3StatsFCSErrors) and input errors (ifInErrors). For fiber links, received optical power from ethtool -m and the switch’s optics info
Confirmed if
CRC errors on one port climb steadily at all hours, and only servers and connections through that port have high retransmission rates. Received optical power is lower than on other links of the same type
Ruled out if
CRC flat while only output discards rise points to queue overflow (“Send bursts overflow shallow buffers,” “Bottleneck queue overflow (congestion loss)”). Late collisions on one side rising together with CRC errors on the other point to “Duplex mismatch”
Check with
Infra tools (no game code needed)

Sources

  1. Interface statistics Linux kernel
    rx_crc_errors counts packets the receiving interface flagged with CRC errors; check with ip -s -s link and ethtool -S
  2. ethtool(8) — Linux manual page ethtool
    -S for NIC and driver statistics, -m for optic module (SFP+, QSFP) EEPROM and optical diagnostics
  3. RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
    Switch port FCS errors (dot3StatsFCSErrors), which are also counted in input errors (ifInErrors)

See also

Same layer: Root causes of TCP retransmission

Same symptom (Freeze), other layers

View the interactive card with figures and simulations