Низкая частота отправки снапшотов Low snapshot / update rate

ID причины sy-low-send-rate · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента

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

Если сервер отправляет обновления позиций (снапшоты) всего несколько раз в секунду, буфер интерполяции приходится делать соответственно длинным, и другие персонажи видны в более далёком прошлом.

Почему Ради экономии трафика обновления позиций отправляются всего 5–10 раз в секунду → Следствие Для плавной картинки буфер нужен в 2 раза длиннее интервала между пакетами (200–400 ms), а если сделать его коротким, потеря одного пакета уже даёт фриз → На экране Смена направления у противника видна поздно и расходится с проверкой попадания. При коротком буфере микрофризы, при потерях телепортация

Симптомы: Микрофризы, Телепортация, Съеденные действия / роллбэк
Факторы: Задержка, Потери
У кого: Весь сервер
Когда: Всегда
Ответственные: Основной ответственный Команда разработки · Разработка сервера · Совместно Команда разработки · Разработка клиента
Команда разработки: задачи: Сервер: близкие объекты и тех, кто в бою, обновлять часто, а дальние редко, отправлять только изменения (дельта-сжатие), чтобы уменьшить размер пакета и поднять частоту. Клиент: автоматически подстраивать длину буфера интерполяции под интервал между пакетами.
Цифры для ориентира: При 10 обновлениях в секунду интервал между пакетами 100 ms, буфер 200 ms. Если добавить 75 ms задержки в одну сторону при пинге 150 ms, противник виден примерно на 0,3 с в прошлом.
На графике: Высоко с самого начала · интервалы прихода пакетов по клиентам, длина буфера интерполяции
Где смотреть: В захвате пакетов на стороне сервера отфильтровать только поток к одному игроку и смотреть в I/O Graphs Wireshark число пакетов в секунду и интервалы. Если есть игровые логи, смотреть вместе интервалы обновлений по объектам и запас буфера интерполяции на клиенте (сколько времени осталось до следующего снапшота)
Подтверждает: Обновления позиций всегда редкие, 5–10 в секунду (интервал 100–200 ms), буфер интерполяции больше 200 ms или его запас часто падает до 0
Опровергает: Если обновления уходят часто, а скачут только интервалы прихода, причина в джиттере и потерях. Если в толпе редко приходят только дальние объекты, это бюджет отправки и приоритеты для каждого соединения
Чем проверить: Инструменты инфраструктуры (игровой код не нужен)

Источники

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
При 10 обновлениях в секунду интерполяция 200 ms переживает один пропуск. В Half-Life по умолчанию 20 обновлений в секунду и интерполяция 100 ms
Snapshot Interpolation Gaffer On Games
При 10 пакетах в секунду, чтобы пережить две потери подряд, нужна задержка 350 ms, при 30 пакетах в секунду она сокращается до 150 ms
State Synchronization Gaffer On Games
Накопление приоритета: важные объекты отправляются чаще, а остальные по очереди в пределах лимита пропускной способности
8.8. The “I/O Graphs” Window Wireshark
Строит график числа пакетов и байтов, подходящих под фильтр отображения, по интервалам времени

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

Тот же слой: Архитектура синхронизации

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

Всплески времени кадра L1 Процесс игрового клиента
Сборка мусора на клиенте L1 Процесс игрового клиента
Синхронная загрузка и компиляция шейдеров в главном потоке L1 Процесс игрового клиента
Стриминг ассетов отстаёт из-за медленного накопителя L1 Процесс игрового клиента
Нагрузка на рендеринг при большом скоплении игроков L1 Процесс игрового клиента
Буфер интерполяции отсутствует или слишком короткий L1 Процесс игрового клиента
Чрезмерная экстраполяция (dead reckoning) L1 Процесс игрового клиента
Лавина догоняющих шагов при фиксированном таймстепе L1 Процесс игрового клиента

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