Анатомия игровых лагов › Первопричины повторных передач TCP

Несовпадение дуплекса Duplex mismatch

ID причины rt-duplex · Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда инфраструктуры · Серверная инфраструктура

Открыть карточку в основной версии с иллюстрациями и экспериментами →

Если на одной стороне включено автосогласование, а на другой скорость и дуплекс заданы жёстко, одна сторона работает в полудуплексе и под нагрузкой каждый раз теряет пакеты из-за коллизий.

Почему Скорость и дуплекс жёстко заданы только на одной стороне → Следствие Одна сторона работает в полном дуплексе, другая в полудуплексе, возникают коллизии и поздние коллизии → На экране Обычно всё нормально, но при росте трафика у всех, чей трафик идёт через это устройство, фриз, потом перемотка

Симптомы

Фриз, Перемотка

Факторы

Потери

У кого

Весь сервер, Одна локация или канал

Когда

При наплыве игроков, Вечерний пик

Ответственные

Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Команда инфраструктуры · Серверная инфраструктура

Команда инфраструктуры: задачи

На обеих сторонах включить автосогласование или на обеих задать одинаковые значения. Сеть: проверить скорость и дуплекс в состоянии порта коммутатора, по счётчикам порта проверить, растут ли поздние коллизии на полудуплексной стороне и ошибки CRC и слишком короткие кадры (runt) на полнодуплексной. Серверы и ОС: проверить скорость и дуплекс через ethtool.

Цифры для ориентира

Для 1 Gbps по меди автосогласование обязательно, а на 10 Gbps и выше полудуплекса нет вообще. Поэтому сейчас проблема встречается в основном на старом оборудовании 100 Mbps и медленнее, на портах управления и на некоторых стыках линий связи.

На графике

Растёт вслед за онлайном и нагрузкой · поздние коллизии и ошибки CRC на порту, доля повторных передач

Где смотреть

Посмотреть фактические скорость и дуплекс на обеих сторонах линка. На сервере ethtool, запущенный только с именем интерфейса, на коммутаторе состояние порта или dot3StatsDuplexStatus по SNMP. Заодно посмотреть поздние коллизии (на сервере tx_window_errors, на коммутаторе dot3StatsLateCollisions) и ошибки CRC

Подтверждает

Одна сторона показывает полудуплекс, другая полный дуплекс. При каждом росте трафика на полудуплексной стороне растут поздние коллизии, а на полнодуплексной ошибки CRC

Опровергает

Если скорость и дуплекс на обеих сторонах совпадают, а растут только CRC, это «Физические ошибки (неисправные кабели, оптические модули и разъёмы)». На линках 10 Gbps и выше полудуплекса нет, поэтому для них эта причина исключается

Чем проверить

Инструменты инфраструктуры (игровой код не нужен)

Источники

1. Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
   Стандарт 1000BASE-T требует автосогласования
2. IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
   10-гигабитный Ethernet поддерживает только полный дуплекс
3. IEEE P802.3ba Objectives IEEE
   40- и 100-гигабитный Ethernet тоже поддерживают только полный дуплекс
4. Interface statistics Linux kernel
   tx_window_errors: число передач, сорвавшихся из-за поздних коллизий (late collision), rx_crc_errors: число пакетов, принятых с ошибкой CRC
5. ethtool(8) — Linux manual page ethtool
   speed, duplex и autoneg в ethtool -s задают скорость, дуплекс и автосогласование, а с одним только именем интерфейса ethtool показывает текущие настройки
6. RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
   dot3StatsDuplexStatus (текущий дуплекс: halfDuplex или fullDuplex), dot3StatsLateCollisions (число поздних коллизий)

Смотрите также

Тот же слой: Первопричины повторных передач TCP

• Потери на беспроводном участке
• Переполнение очереди в узком месте (потери от перегрузки)
• Переполнение неглубоких буферов всплесками отправки
• Отбрасывание избытка полисером
• Физические ошибки (неисправные кабели, оптические модули и разъёмы)
• Отбрасывание пакетов на принимающем сервере
• Отбрасывание пакетов файрволом или conntrack
• Перегрузка промежуточного оборудования (файрвол, IPS, защита от DDoS)
• Чёрная дыра MTU (большие пакеты теряются раз за разом)
• Истечение записи NAT или балансировщика посреди соединения
• Смена маршрута и неисправный путь ECMP
• Ложные повторные передачи из-за скачков задержки
• Ложные быстрые повторные передачи из-за нарушения порядка
• Задержка и потеря ACK (забитая отдача)
• Неподходящая настройка RTO
• Медленное восстановление потерь в thin stream
• Удаление опций TCP промежуточным оборудованием
• Нулевое окно (остановка, похожая на повторную передачу)
• Повторная передача запроса на подключение (SYN)

Причины с тем же симптомом (Фриз) на других слоях

• Всплески времени кадра L1 Процесс игрового клиента
• Сборка мусора на клиенте L1 Процесс игрового клиента
• Синхронная загрузка и компиляция шейдеров в главном потоке L1 Процесс игрового клиента
• Стриминг ассетов отстаёт из-за медленного накопителя L1 Процесс игрового клиента
• Проверки модуля защиты игры (античита) L1 Процесс игрового клиента
• Переключение Wi-Fi ↔ LTE/5G L2 ОС и устройство клиента
• Нехватка памяти и своп на клиенте L2 ОС и устройство клиента
• Нехватка видеопамяти (VRAM) L2 ОС и устройство клиента

Карточка в основной версии с иллюстрациями и экспериментами