Полезные свойства джиттера
Джиттер это дрожание фронта тактового сигнала. Чем меньше джиттер тем лучше. Большой джиттер ухудшает параметры АЦП, ухудшает трассировку ПЛИС. Однако есть ситуации когда джиттер полезен. Например его можно использовать при автоматической подстройке тактовой частоты.
Давайте рассмотрим классическую задачу подключения АЦП по параллельной шине.
В общем виде схема подключения выглядит так:
Шина данных АЦП поступает на выводы ПЛИС, непосредственно внутри блока ввода-вывода находится DDR триггер или десериализатор и далее по параллельной шине данные поступают на FIFO. Проблема заключается в прохождении тактового сигнала. Если использовать глобальный буфер, то время распространения сигнала до буфера и обратно может составлять 5 нс. Это очень много. Это сравнимо с периодом тактовой частоты, которая легко может составлять 200-500 МГц.
Несколько слов почему это плохо. В общем случае АЦП должно работать в некотором диапазоне частот. Рассмотрим для примера ситуацию с задержкой такта на 2.8 нс, при тактовой частоте 500 МГц. 
На первый взгляд всё прекрасно, данные АЦП прекрасно защёлкиваются. Но вот что произойдёт если частота уменьшиться до 357 МГц, это как раз и составит 2.8 нс? 
Данные наезжают на фронт и мы получаем искажение данных. При дальнейшем уменьшении частоты наезд исчезнет и данные снова будут правильными.
Есть два классических способа решения проблемы:
1. В блоке IOB есть элемент задержки, он может установить задержку до 2.4 нс. В большинстве случаев этого достаточно.
2. Существуют специальные элементы bufio, через них путь тактовой частоты становиться гораздо короче.
К сожалению этого не всегда достаточно. Задержка может превышать 2.4 нс, особенно на больших ПЛИС. И не всегда тактовый сигнал заведён на вывод bufio.
Существует простое и элегантное решение этой проблемы. Для этого достаточно сделать так, что бы фаза внутреннего тактового сигнала всегда точно совпадала с фазой тактового сигнала АЦП. Существующие внутри ПЛИС узлы DCM, MMCM, или PLL умеют плавно изменять фазу. А вот датчиком может служить D-триггер внутри блока IOB. Вот схема включения:
Входной сигнал тактовой частоты проходит сквозь IOB и поступает на вход DCM, одновременно он же поступает на вход D-триггера. На тактовый вход D-триггера поступает сигнал после DCM, этот же сигнал поступает на триггеры шины данных АЦП. И вот что происходит, рассмотрим несколько ситуаций:
Ситуация 1 – фронт глобального сигнала значительно левее фронта входного сигнала. На выходе триггера – нули. 
Ситуация 2 – фронт глобального сигнала в зоне джиттера. На выходе – случайная последовательность. Именно это и есть то самое полезное свойство джиттера. По факту появления случайной последовательности можно определить факт подстройки тактовой частоты. 
Ситуация 3 – фронт глобального сигнала значительно правее входного сигнала. На выходе – единицы. 
Все эти ситуации легко обрабатывается конечным автоматом. В моей реализации существует цикл накопления, в течении 1024 тактов производится подсчёт 1. Если значение счётчика больше 576, то производится сдвиг фазы влево. Если значение счётчика меньше 448, то происходит сдвиг фазы вправо.
На рисунке представлен результат моделирования компонента.
Сигнал clk_in1 – это входная тактовая частота
clk0 – подстроенная частота
clk_fd – детектор фазы
Сигнал phase_locked=1 означает что достигнута подстройка фазы.
psen – сдвиг фазы DCM
psincdec – направление сдвига фазы
shift0 – текущее значение счётчика фазы
Видно, что после подстройки существует небольшой колебательный процесс — сдвиг в пределах одного значения. В реальных системах в установившемся режиме также наблюдается изменение фазы в пределах одного-двух отсчётов. Перед началом подстройки было так:
Видно, что есть большое смещение между частотами. А после подстройки так:
Частоты совпадают.
» Готовые компоненты представлены на GitHub:
Я выложил два компонента:
ctrl_dcm_phase_v6 –DCM установлен внутри. Это для ПЛИС Spartan 3, Virtex 4, Virtex 5
ctrl_dcm_phase_v8 – внешний DCM или MMCM, это для Virtex 6, Kintex 7.
Несколько слов про моделирование. Поскольку в основе лежит случайный процесс, то это создаёт некоторые проблемы. Но они решаемые. В стенде используется компонент model_line_v1, который как раз формирует джиттер на тактовом сигнале. Для формирования джиттера используется функция UNIFORM из библиотеки math_real.
В заключении хочу отметить, что эти компоненты используются во многих наших проектах. И они нам сильно помогают.
Джиттер. Теория. Часть 1
Цифровые аудиосистемы отличаются от аналоговых двумя главными особенностями:
- Сигнал, непрерывно меняющийся по напряжению или току в аналоговой форме, представляется в цифровом виде фиксированным числом дискретных числовых значений
- Эти числовые значения представляют сигнал не постоянно в течении всего времени, а только в определенные моменты времени, моменты квантования
Обычно моменты квантования определяются аналогово-цифровым преобразователем (АЦП) и цифро-аналоговыми (ЦАП) преобразователем, которые служат для преобразования сигнала из аналоговой формы в цифровую и обратно. Эти устройства зачастую имеют задающий генератор для управления частотой квантования или частотой дискретизации.
Моменты квантования также могут задаваться преобразователем частоты дискретизации — SRC, который использует математические вычисления для трансформации цифрового сигнала одной частоты в другую. В случае если SRC не имеет физического устройства, задающего моменты квантования, вычислительный процесс производится с использованием виртуального тактового генератора.
Цифровое аудио невосприимчиво к многим недостаткам аналоговой записи и аналоговой передачи сигнала: искажения, шумы на линии, шумы пленки, детонации, взаимное проникновение каналов. И даже если сигнал в цифровой форме не полностью избавлен от недостатков, он несомненно очень устойчив к большинству из таких воздействий. Но на практике цифровой сигнал встречается с новыми проблемами: нестабильность тактового генератора, падение характеристик сигнала в кабеле, паразитные наводки. Все это приводит к изменению формы сигнала и небольшим сдвигам во временной области, или джиттеру.
Джиттер также может возникать в случае самотактующегося сигнала (например, S/PDIF). В этом случае джиттер может привести к ошибкам в распознавании данных, к сбою синхронизации или потере отдельных битов. Джиттер задающего генератора также может ухудшать точность оцифровки в преобразователях в процессе квантования.
График 1. Цифровой сигнал формата AES3 под воздействием джиттера
Что такое джиттер?
Джиттером называется отклонение сигнала, такого как тактующий сигнал генератора, во времени от номинала.
Например, джиттер сигнала тактового генератора возникает по причине того, что фронт импульса реального и идеального генераторов различаются, что, кстати говоря, совершенно нормально. В отличие от достижимого в теории идеального сигнала, точка пересечения нуля фронта реального сигнала для разных импульсов различается по времени. Говоря иначе, джиттер — это фазовая модуляция формы цифрового сигнала.
Составляющая джиттера может быть извлечена из тактового или самотактующегося цифрового сигнала и проанализирована в отдельности. Среди наиболее полезных путей изучения влияния джиттера является исследование частотной характеристики и выявление главных частотных компонентов джиттера.
Измерения джиттера
При небольшом количестве джиттера, фронт меандра смещается назад или вперед на небольшую величину по времени. При увеличении джиттера, смещения достигают больших величин.
Амплитудой джиттера называют величину смещения по времени и измеряют в единицах времени: либо в долях секунды (наносекунды, пикосекунды), либо в интервальных единицах (unit). Для тех кто сталкивается с измерениями джиттера впервые, надписи по осям графика могут сбить с толку — зачастую и по вертикальной, и горизонтальной оси отложено время.
Частотой джиттера называют частоту, с которой происходит фазовый сдвиг. Также как в случае наложения шума или помехи, сигнал привносимый джиттером может быть чистой синусоидой, сложным колебанием или полностью случайным процессом.
Интервальная единица (UI)
Интервальной единицей (UI, unit interval) называют отрезок времени, обратно пропорциональный частоте следования данных. Этот термин часто используется при исследованиях джиттера. UI определяется как минимальный номинальный временной интервал в выбранной схеме кодирования. Для сигнала в стандарте AES3 при передачи данных частотой 48 кГц содержатся: 32 бита в субфрейме и 64 бита во фрейме, что дает 128 импульсов на фрейм после применения для кодирования двухфазной модуляции. В этом случае:
1 UI / (128 * 48000) = 163 нс
UI используется в нескольких спецификациях на джиттер в стандарте AES3¹ (стандарт сообщества Audio Engineering Society для интерфейса передачи двухканального цифрового аудио), в результате допуски по спецификации пропорционально масштабируются для разных данных и частот семплирования.
1. AES3-1992 — «Recommended Practice for Digital Audio Engineering — Serial Transmission Format for Two-Channel Linearly Represented Digital Audio Data» J. Audio Eng. Soc., vol. 40 No. 3, страницы 147-165, июнь 1992. (Последняя версия, включающая поправки, доступна на сайте www.aes.org).
Например, длина UI в секундах для частоты 96 кГц вполовину меньше, чем UI для 48 кГц. Требования по джиттеру для передачи и приема находятся в тех же пропорциях.
Примечание: Некоторые спецификации на пересылку данных определяют UI как продолжительность одного бита при передаче. Такое определение несовместимо со спецификацией AES3 и не будет здесь использоваться.
Как можно увидеть джиттер?
Джиттер цифрового сигнала можно увидеть по смещению импульсов, которые сдвинуты относительно идеального тактового сигнала. И любые правильные измерения джиттера основаны на сравнении подверженного джиттеру сигнала с идеальным клоком.
На практике зачастую нет идеального тактового сигнала, с котором можно сравнить испытуемый сигнал. Поэтому при измерении джиттера приходится опираться на сам сигнал, на смещения по оношению к самому себе.
Простейший и наиболее неудачный пример такого пути — это «наблюдение формы сигнала на осциллографе», подключив сигнал с джиттером к осциллографу, как показано на графике 2. К сожалению, вы получите вводящий в заблуждени результат, который будет зависеть от несовершенства генератора осциллографа, а также от спектра джиттера сигнала. Вместо джиттера, такой способ показывает интервальное отклонение. Между ними есть определенная связь, но на некоторых частотах джиттер не будет виден вовсе, тогда как на других амплитуда джиттера может удвоиться. В частности, если речь идет о низкочастотном джиттере.
График 2. Наблюдение смещения фронтов сигнала на осциллографе.
Неверный способ оценки джиттера!
Вместо этого, можно сэмулировать идеальный тактовый сигнал автоподстройкой фазы относительно низкоджиттерного генератора, используя ФАПЧ (PLL) (см. параграф Фазовая автоматическая подстройка частоты). Такой способ самоуточнения сигнала аналогичен наложению ВЧ фильтра с частотой среза, равной частоте среза ФАПЧ. Полученный идеальный тактовый сигнал можно, например, использовать для внешней тактовки осциллографа или как референсный сигнал при просмотре на двухлучевом осциллографе.
Если тактовать осциллограф от референсного сигнала с ФАПЧ и отмасштабировать отображение по времени ровно в один UI, множество следующих друг за другом импульсов будут отображаться как один, накладываясь двух на друга из-за послесвечения точек люминофора экрана. Такая характерная картинка называется глазковая диаграмма (eye pattern). Величина открытия глаза на диаграмме зависит от смещения по времени фронтов импульса. Узость глазного просвета показывает джиттер (меньше просвет — больше джиттер).
График 3. Глазковая диаграмма, построенная APWIN.
Синяя линия сформирована тестируемым сигналом;
серый прямоугольник показывает минимальный допуск спецификации AES3
(синяя линия не должна заходить внутрь серого прямоугольника)
Используя цифровую обработку сигнала (DSP), можно вычислить идеальный задающий сигнал усреднением анализируемого сигнала. После этого есть возможность выделить сигнал и его джиттер с очень большой точностью. По этим данным анализатор может построить отклонение импульсов по амплитуде и времени в виде глазковой диаграммы (график 3); отобразить джиттер во временной области (график 4), или, используя БПФ, построить спектральное разложение джиттера (график 5).
График 4. Джиттер с основной частотой 5 кГц во временной области
График 5. FFT анализ выделенного из сигнала джиттера
Джиттер при семплинге
Джиттер может влиять на цифровой сигнал в двух широких областях: в процессе преобразования аналога в цифру и обратно, и при передаче в цифровом виде.
Джиттером дискретизации или джиттером семплинга (sampling jitter) называют ошибки выбора моментов времени квантования в процессе оцифровки в АЦП, при преобразования в аналог в ЦАП или в преобразователях частоты дискретизации (SRC). Большое значение джиттера в перечисленных случаях может привести к слышимому ухудшению качества сигнала.
Интерфейсный джиттер
В отличие от постепенного ухудшения звука при увеличении джиттера семплинга, большое значение интерфейсного джиттера при передаче звуковых данных может привести к потере целостности данных. Так что становится важным контролировать значение джиттера при передаче данных. Джиттер цифровых звуковых интерфейсов должен находиться в определенных допусках, чтобы его можно было скомпенсировать на приемной стороне.
Джиттер генератора синхросигнала
Во многих задачах цифрового аудио важно хранить, передавать и обрабатывать сигнал синхронно на всех участках цепочки. Это требует стабильной единой частоты дискретизации. В других задачах важно, чтобы частота семплирования сигнала была строго пропорциональной другой частоте, например частоте кадров видеоряда, чтобы не было расхождения видео и аудиодорожки. Способ управления таймингом в этом случае зовется тактовой синхронизацией (clock synchronization).
Когда тактовый генератор синхонизирован с внешним источником синхронизации, добавляется джиттер от генератора синхросигнала. Также джиттер может быть добавлен на этапе передачи сигнала синхронизации. К счастью, можно отфильтровать джиттер сигнала синхронизации. Зная характеристики джиттера генератора синхросигнала, можно отфильтровать джиттер на приемной стороне.
При тактовании от внешнего генератора таким образом, характеристики подавления джиттера сильно влияют на качество звукового сигнала. В других обстоятельствах это становится не так важно.
Фазовая автоматическая подстройка частоты (Phase-Locked Loop)
При быстром вращении тяжелого маховика на скорость его вращения влияют только продолжительно прикладываемые усилия по ускорению и замедлению, с полным игнорированием коротких по времени воздействий. Нечто похожее наблюдается при работе схемы фазовой автоматической подстройки частоты (ФАПЧ).
На входе ФАПЧ имеется фазовый детектор, который формирует управляющий сигнал на основе сравнения разности фаз входного сигнала и цепи обратной связи. Далее сигнал следует на ФНЧ и генератор управляемый напряжением (VCO). Управление возможно из-за наличия цепи отрицательной обратной связи с заданным коэффициентом усиления (PLL Loop Gain).
Если фазовая разность равна нулю, управляющее воздействие отсутствует, контур замыкается. Если же имеется разность фаз, она управляет источником тока (CP), подающего разностный периодический сигнал на ФНЧ. Отфильтрованный дельта-сигнал управляет генератором VCO, который преобразует напряжение в производную фазы по времени, т.е. в частоту. Происходит регулирование частоты таким образом, чтобы фазовая разность стала равной нулю. Происходит фазовая автоматическая подстройка частоты.
ФНЧ вводится намеренно, для достижения ФАПЧ свойства «маховика». ФНЧ сглаживает ВЧ-помехи во входном сигнале и уменьшает полосу, в которой частота VCO стабилизируется схемой ФАПЧ.
График 6. Передаточные функции ФАПЧ
Ниже частоты сопряжения, благодаря ООС, выход ФАПЧ практически повторяет сигнал на входе, при этом фазовый шум ГУН подавляется. С ростом частоты ООС ослабевает, так что джиттер на выходе ФАПЧ будет в большей степени зависеть от собственного фазового шума ГУН и в меньшей от джиттера входного сигнала. Ключевой момент в реализации ФАПЧ приемника или передатчика состоит в компромиссе между собственным джиттером и его подавлением.
Что такое джиттер?
Недавно спрашивал про преимущества проводного подключения над Wi-Fi и кто-то упомянул про джиттер. Кто может объяснить простыми словами, что есть джиттер, как его вычислить и насколько оно выражено в домашних сетях.
- Вопрос задан более трёх лет назад
- 44151 просмотр
4 комментария
Простой 4 комментария
Tomaszz @Tomaszz Автор вопроса
Если джиттер это:
В телекоммуникациях под джиттером часто понимается разброс минимального и максимального времени прохождения пакета IP от среднего времени прохождения пакета[5]. Например, посылается 100 пакетов IP. Минимальное время прохождения пакета IP — 395 мс, среднее — 400 мс, максимальное — 405 мс. В этом случае (405-400=5; 400-395=5) джиттер можно считать маленьким. Если же посылается 100 пакетов IP, и минимальное время прохождения пакета — 1 мс, среднее — 50 мс, максимальное — 100 мс, (100-50=50; 50-1=49) джиттер большой.
И если пинг по Wi-Fi практически идентичен пингу проводного подключения (±1 мс), то можно ли говорить о влиянии джиттера на качество связи(гейминга) в FPS шутере?
Если я немного прав, кто может пояснить, что помимо нижеперечисленного определяет ту самую существенную разность между проводным и беспроводным геймингом:
К Wi-Fi подключено 1 устройство — ПК.
Расстояние между роутером и компьютером минимальное (скажем, 1 метр);
Устройства в одной комнате и между ними нет препятствий (стена, перегородка, какой-нибудь предмет);
Нет помех, Wi-Fi канал не перекрывается, роутер работает на 5Ггц.
Разность пингов проводного и Wi-Fi не более 1-2 мс, потери пакетов отсутствуют.
Что ещё?
Stalker_RED @Stalker_RED
Tomaszz, примите поздравления, у вас идеальный wi-fi.
Для полного счастья можно еще ширину канала измерить, может там тоже все красиво.
На практике так везет не всем, и сильно не всегда. Гораздо чаще встречаются ситуации, когда полно шумов, преград, помех, соседей, багов в драйверах и прочей фигни.
Если расстояния 1 метр, то проще провод подключить.
А вот если хотя бы выйти из комнаты, то уже начнётся падение сигнала — тем более, что у вас 5Ггц, он на 5 метрах уже сильно ослабеет.
Но вообще на 5Ггц на коротких дистанциях не должно быть проблем. Он для этого и создавался как раз.
Tomaszz, еще
Надежность — вдруг кто-то встанет перед роутером и перекроет сигнал, у вас будет фриз и вы проиграете
Стабильность — нужно, что бы все было хорошо на протяжении всей игры
Максимальное расстояние до роутера
Интерференция — вдруг сигнал отражается от закрытой двери и гасит себя
Задержка — разность пингов может и маленькая, но это не гарантирует отсутствие лагов или фризов
Количество устройств на том же канале — не важно, где и чьи они, но они могут засорять канал
Время обработки сигнала — сейчас уже ничтожно мало, но иногда встречаются подобные проблемы
Решения вопроса 1
Есть разные понятия джиттера, основное это резкое изменение фазы сигнала (например при последовательном воспроизведении двух музыкальных треков). Однако в сетях джиттером обычно называют просто «прыгающий пинг», т.е. разброс во времени прохождения сетевых пакетов. Т.е. если у вас все пакеты идут по 2 миллисекунды, то джиттера нет. Если все пакеты по 200 миллисекунд то джиттера тоже нет. Но если часть пакетов идет по 2 и часть по 200 — то это джиттер. Джиттер есть практически в любых броадкастных сетях, в т.ч. и в Ethernet, при высоких загрузках среды передачи. В WiFi выраженность джиттера будет зависеть от нескольких факторов, основной это загруженность используемого частного канала. В многоквартирном доме или офисном здании с кучей небольших компаний это может быть достаточно серьезной проблемой. Джиттер плох в основном для игр и реалтаймовых протоколов (голоса, видео).
Если вы не наблюдаете рандомных задержек пинга даже при существенной нагрузке на сеть, то проблемы джиттера у вас нет.
Лаги, джиттер и потеря пакетов: откуда берутся проблемы с неткодом и как их решать
Если вы когда-либо играли в онлайн-игры, то наверняка знаете о лагах не понаслышке. Пропущенный выстрел, который должен был попасть в цель; мяч, резко меняющий направление прямо в воздухе; вы вдруг снова оказываетесь на несколько шагов назад в том месте, где находились секундой ранее. В этом нет ничего сверхъестественного: это обычные артефакты систем, обеспечивающих совместную игру с людьми из других стран почти так же эффективно, как и с соседом по комнате. По крайней мере, большую часть времени.
В этой статье речь пойдет о самых базовых вещах, почему вообще возникает сетевая задержка, с какими еще проблемами неткода можно столкнуться, а также с тем, что можно сделать со своей стороны, чтобы улучшить ситуацию. Также разберем остальную часть конвейера между ПК и игровым сервером, который может повлиять на получение лучшего игрового опыта без задержек и прочих неприятностей.
Итак, почему вообще возникают лаги? Почему в 2021 году это все еще является проблемой — с мощностью современных компьютеров, повсеместным использованием широкополосного Интернета и спустя десятилетия попыток разработчиков решить эту проблему?
С точки зрения разработчиков, реализация даже базового мультиплеерного режима — задача непростая. Необходимо получать данные от множества игроков одновременно, неоднократно — тысячи раз в секунду — передавать эту информацию на некий центральный сервер, а затем возвращать обработанный результат на ПК каждого игрока.
Состояние игры должно быть идеально синхронизировано с минимальной задержкой независимо от того, имеете ли вы дело с игроками в одной локальной сети или с разных континентов. Поэтому вам придется придумать способ компенсации задержки игроков. При этом лучше избегать необходимости ожидания игроками, пока сервер сообщит им результаты их же собственных действий, ведь динамике это на пользу не пойдет. Для этого вам, вероятно, потребуется показать эффекты ввода каждого игрока сразу же, а затем уже сглаживать любые различия между ПК игрока и сервером таким образом, чтобы это было внешне неочевидно.
Мы не можем знать, что делают другие игроки, пока сервер не сообщит нам об этом. Поэтому мы вынуждены отображать действия других игроков в матче такими, какими они были в прошлом. Также достаточно большую проблему может составить читерство, поэтому необходимо убедиться, что игроки имеют ограниченный доступ к данным с сервера, не позволяющий компьютеру игрока принимать решения о том, что на самом деле произошло в игре — например, насколько успешен был выстрел или какое количество здоровья осталось у игрока.
С двумя-то игроками это реализовать достаточно сложно, а теперь представьте, каково организовать подобное для игры с 10, 20 или даже сотнями игроков на одном сервере. При разработке игры жанра battle royale со всеми ее особенностями реализация хорошего мультиплеера является одной из самых сложных частей разработки даже для опытной команды, поэтому неудивительно, что временами в игре могут возникать сетевые проблемы. Конечно, это не делает такие сбои менее раздражающими, и чем быстрее скорость и выше конкуренция в игре, тем больше такой опыт может помешать вам получить от нее удовольствие.
Помимо лагов и сбоев, могут возникнуть и другие проблемы с сетью: rubber banding, когда игровой мир возвращает вас туда, где вы были несколько секунд назад; получение урона сразу после того, как вы оказались за укрытием; промахи ваших собственных выстрелов, а то и вовсе потеря связи с игрой.
Так что же вызывает все эти проблемы?
Обычно в играх можно столкнуться с тремя сетевыми явлениями, каждое из которых по-разному влияет на пакеты данных с вашими вводами и игровые состояния, которые передаются между вашим компьютером и сервером.
Первое из них — задержка. Она возникает тогда, когда пакеты с данными слишком долго передаются серверу и затем возвращаются к игроку. Проще говоря, задержка — это скорость реакции вашего интернет-соединения, то есть время, необходимое для передачи данных с вашего устройства на сервер. Важно отметить, что задержка зависит от качества вашего интернет-соединения, а не от скорости.
Часто задержку путают с лагами, и хотя они не означают одно и то же, но имеют причинно-следственную связь. Лаг — это задержка прибытия пакета от источника к месту назначения или, с точки зрения геймплея, задержка между нажатием кнопки и ответом игры, выведенным на экран. То есть, по сути совокупность вообще всех явлений, которые происходят между этими двумя событиями.
Джиттер — это колебания задержки, означающие, что пакеты отправляются и принимаются с разной скоростью. Это похоже на плохой frame pacing: то ваш пинг меняется с 20 миллисекунд до секунды, то с секунды до 90 миллисекунд, а затем возвращается к 30 миллисекундам, которые были когда-то уже давно.
Потеря пакетов — это когда пакеты вообще не достигают места назначения. Она вызывает необходимость повторной отправки одних и тех же данных и и потенциально — странное поведение игры.
Конечно, наличие даже одной из этих проблем может довольно сильно раздражать. С точки зрения игрока, если вы не чувствуете, что контролируете игру, если ваша производительность страдает от проблем с сетью, велика вероятность, что вы просто закроете игру и больше в нее не зайдете. Для разработчиков и издателей это будет означать, что аудитория станет меньше, а если у вас free-to-play тайтл, это поставит под угрозу само его существование. Особенно важно это для соревновательных игр, поскольку любые повторяющиеся проблемы могут заставить игроков и организаторов турниров отказаться от их проведения до тех пор, пока проблемы не разрешатся.
Так почему же возникают подобные сбои?
Существуют три основных типа проблем с соединением:
- проблемы «первой мили», вызванные домашней сетью вашего ПК и подключением к Интернету;
- проблемы «средней мили», обусловленные перемещением данных по маршруту между вашим интернет-провайдером и игровым сервером;
- проблемы «последней мили», связанные непосредственно с игровым сервером.
Обычно первая и последняя миля вызывают наименьшую задержку — в нашем примере это около одной миллисекунды. Средняя же миля имеет наибольшую задержку, ведь именно на ней пакеты преодолевают все географическое расстояние между вашим компьютером и сервером.
Начнем с того, что может улучшить со своей стороны сам игрок, — с проблем, связанных с ПК и домашней сетью.
Точно так же, как производительность игры ограничивается компонентами ПК, такими как центральный процессор или видеокарта, сетевое соединение тоже зависит от многих элементов. На то, как будут отправляться и приниматься пакеты данных, могут влиять настройки игры, сетевое оборудование вашего ПК и его драйверы, ваша операционная система и ее настройки. Но есть и физические аспекты — например, то, как ваш компьютер подключен к роутеру, какой у вас роутер и как он настроен — и, конечно же, подключение к Интернету, предоставляемое провайдером.
Пожалуй, наиболее важным для игр является переключение с беспроводного на проводной Интернет, что может значительно снизить задержки, джиттер и потерю пакетов. Помимо этого, возможно, стоит изучить роутеры с более гибко настраиваемой прошивкой — например, отдать предпочтение роутерам OpenWRT или pfSense — или просто повысить скорость вашего интернет-соединения — особенно в домашних условиях, где оно используется несколькими людьми, которые могут смотреть потоковые видео, загружать файлы из Интернета и выполнять другие задачи с высокой пропускной способностью одновременно. В идеале роутер должен иметь возможность отдавать приоритет критическим с точки зрения задачам, таким как онлайн-игры и видеоконференции, по сравнению с такими вещами, как воспроизведение видео с YouTube.
Наконец, полезно будет убедиться, что драйвера обновлены, вы отключили все приложения, которые используют значительный объем ЦП или пропускной способности сети в фоновом режиме, а также что сетевые настройки игры установлены правильно.
Теперь поговорим о средней миле, где у вас нет особого контроля над тем, что происходит, ведь пакет данных, отправляемый вашим компьютером, выходит в более широкий Интернет.
В первую очередь ваш пакет должен обработать местный интернет-провайдер. Но совсем скоро он перейдет к оптоволоконным магистралям, которые соединяют города и страны друг с другом. Здесь маршрут, по которому идет пакет, не обязательно окажется самым быстрым, и нет никакой гарантии, что пакет вообще доберется до конечного пункта назначения. Помните, что предшественник Интернета был разработан министерством обороны США для работы в условиях ядерной войны. Таким образом, доставляемость для него важнее скорости.
Сами маршруты со временем могут перенасыщаться и повреждаться, а потому изменяться. Так, вы можете обнаружить, что ваше соединение с определенным сервером может оказаться быстрым и надежным в один день, но на следующий уже совсем никуда не годится.
Так что же могут сделать разработчики игр для оптимизации на этом участке? Географическое расстояние критически влияет на пинг, поэтому можно открывать новые игровые серверы, которые находились бы в недостаточно обслуживаемых регионах базы игроков. Это уменьшит задержку для этих игроков и вероятность того, что какое-то соединение между игроком и сервером замедлится или полностью выйдет из строя. Но, конечно, запускать серверы повсеместно может оказаться непросто, особенно для небольшой компании с ограниченными ресурсами — да и это не решит всех проблем.
Другая идея состоит в том, чтобы вообще не полагаться на общедоступный Интернет для передачи пакетов от игрока к серверу — вместо этого пакеты могут передаваться через частные оптоволоконные маршруты, которые арендуют разработчики или их партнеры. Это дорого, но при использовании таких выделенных полос вы будете меньше зависеть от периодов занятости в вечернее время, когда возможны более высокие пинги и, как следствие, снижение надежности сетевого соединения.
Такой контроль над маршрутизацией также открывает некоторые интересные возможности для киберспорта, где отборочные и другие важные матчи проводятся онлайн. Можно настроить маршрутизацию и выбрать расположение сервера так, чтобы у обеих команд был одинаковый пинг, даже если одна из них находится географически ближе к серверу, и тем самым обеспечить участникам более справедливую игру.
Наконец, перейдем к последней миле в цепочке — игровым серверам.
До сих пор мы предполагали, что имеем дело с игроками, подключенными к одному выделенному серверу для проведения матча, поскольку часто это обеспечивает наилучший опыт. Так разработчики игр или их партнеры могут гарантировать, что на каждом сервере достаточно оборудования и обеспечивается самое быстрое подключение к Интернету, но есть и другие варианты.
Client hosting — это когда ПК одного из игроков сам по себе выступает в качестве сервера. Это хороший способ для разработчиков игр минимизировать затраты, но опыт каждого участника матча будет зависеть от качества соединения игрока-хоста. Таким образом, если такие игроки подключаются к сети через Wi-Fi или вовсе испытывают проблемы с подключением, другие игроки тоже столкнутся с лагами, джиттером и потерей пакетов.
Назначенный хост также имеет нулевую задержку для сервера, что дает ему огромное конкурентное преимущество перед остальными и, конечно, не является идеалом для соревновательных игр. При этом, если он покидает игру, необходимо найти другого хоста, что прерывает игру для всех участников на несколько секунд, пока не поизойдет так называемая миграция хоста.
Другой вариант — одноранговая (peer-to-peer) сеть, где игроки напрямую подключается друг к другу. Как правило, в таком случае тоже существует некий хост, который номинально отвечает за обработку новых соединений, поэтому проблема с миграцией хоста в данном случае сохраняется.
При таком способе подключения два игрока в одном регионе быстро увидят действия своих оппонентов, в то время как те, кто находятся далеко друг от друга, столкнутся со значительными задержками между действиями и выводом их результатов на экран — или, возможно, будут лучше стрелять, если это вы играете с высоким пингом. В любом случае, вам придется подстраиваться под каждого оппонента индивидуально, что может быть довольно сложно. Поэтому не так уж часто можно увидеть подобную серверную архитектуру вне файтингов «один на один» — хотя исключения, подобные Brawlhalla, конечно, существуют.
Помимо различных архитектур серверов, разработчикам игр необходимо оптимизировать пакеты, которые отправляются каждому игроку и обратно, и выбирать, как часто будет обновляться игровой мир. Чем чаще это происходит, чем выше частота тиков, тем быстрее должна выполняться обработка состояния игры на ПК игрока и на сервере, но в целом игра при этом становится более отзывчивой.
Некоторые игры работают с переменным весом тиков — например, королевские битвы, в которых скорость тиков повышается по мере выбывания игроков, или Counter-Strike, где сторонние и киберспортивные матчи проводятся со скоростью 128 тиков в секунду по сравнению со встроенным в игру матчмейкингом, работающим на 64 тиках.
Матчмейкинг — наиболее важная часть мультиплеера. Чтобы свести игроков в одном матче, вам, как разработчику игры, понадобится учитывать такие факторы, как пинг, уровень навыков, количество игроков в группе и выбранные каждым игроком карты и режимы. Каждый новый фактор существенно уменьшает размер пула для подбора игроков — что, в свою очередь, увеличивает время ожидания игры в среднем.
Даже небольшие инженерные улучшения или улучшенная маршрутизация в состоянии помочь с матчмейкингом, если это увеличит пул игроков — и, следовательно, позволит улучшить игровой опыт, не увеличивая время ожидания.
Наконец, последнее — методы борьбы с лагами, которые разработчики могут реализовать со своей стороны в коде.
Так называемое предсказание на стороне клиента часто используют в шутерах от первого лица. Его можно разделить на предсказание ввода и расчет траектории (dead reckoning): первое будет скрывать задержку действий самого игрока, в то время как второй — других игроков.
Предсказание ввода подчиняется следующей последовательности: клиент генерирует команду игрока, которая передается на сервер, где происходит вычисление следующего состояния игры, после чего оно отправляется обратно всем клиентам, и каждый из них отображает сцену на своем устройстве. Но все это время игроку тоже нужно что-то показывать, поэтому суть метода состоит в выполнении перемещения клиента локально, просто предполагая, что сервер примет команду. Недостатком его является то, что, если ответ сервера не будет соответствовать прогнозу клиента, возникнет резкое заметное изменение положения аватара игрока на экране.
Dead reckoning — это, по сути, алгоритм оценки положения объекта в виртуальном мире на основе его предыдущего положения, направления движения, скорости, ускорения и других параметров. Получив первый блок данных протокола состояния (protocol data unit, PDU) для объекта (например, персонажа другого игрока), каждый клиент начинает перемещение этого объекта, применяя согласованный алгоритм dead reckoning. Его движение обновляется при получении последующих PDU. Если для пакетов, несущих PDU, возникнет увеличенная задержка или вовсе их потеря, каждая копия виртуального мира продолжит показывать движение объектов в соответствии с алгоритмом до тех пор, пока не получит следующее обновление. Кроме того, при несоответствиях между статусом сервера и предсказанным клиентом некоторые игры могут сделать переход к новому статусу менее резким, используя алгоритмы сглаживания.
В дополнение к предсказанию клиента сервер может прибегать к методу компенсации сетевой задержки, чтобы правильно объединить виртуальные реальности, которые из-за проблем с неткодом испытывают рассинхронизацию. В таком случае сервер хранит историю последних позиций игроков (так, серверы, на которых работает движок Valve Source, сохраняют позиции игроков в течение 1 секунды), и когда ему нужно вычислить новое состояние, он сначала оценивает момент, когда действие было выполнено в клиентской версии состояния игрового мира. Другими словами, сервер «перематывает время» в соответствии с задержкой конкретного клиента, вычисляя выполнение введенной им команды (например, удалось ли выстрелу игрока поразить цель). Для этого используется следующая формула:
Время выполнения команды = Текущее время сервера — Задержка пакета — Интерполяция представления клиента
Иллюстрация выше представляет собой пример скриншота, сделанного на сервере сразу после того, как он подтвердил обращение. Красный хитбокс показывает позицию цели на клиенте, как это было некоторое время назад. Пока команда игрока (то есть, выстрел по цели) добиралась до сервера, цель продолжала двигаться влево. После того, как команда прибыла на сервер, для расчета факта попадания сервер восстанавливает позицию цели (синий хитбокс) на основе предполагаемого времени выполнения команды. Так сервер отслеживает траекторию выстрела и подтверждает или не подтверждает попадание.
Впрочем, иногда такой алгоритм приводит к ошибкам попадания, когда цель уже скрылась за укрытием. Эту проблему можно было бы решить, если бы клиент мог послать сообщение «попадание» вместо сообщения «выстрел». Однако серверы не могут разрешить клиентам сообщать о попаданиях по соображениям безопасности: некоторые клиенты могут этим воспользоваться в собственных целях и прибегнуть к читерству.
Мы рассмотрели основные причины различных задержек и других нежелательных аспектов производительности сети. Как у игрока, у вас есть немало опций, которые могут значительно улучшить качество вашего игрового опыта. Надежное сетевое соединение может сделать игру намного стабильнее и интереснее. Также мы рассмотрели варианты, что со своей стороны могут сделать разработчики и как они могут повлиять на игровой процесс.
Для получения дополнительной информации о лагах и о том, что вы можете с ними сделать, можно ознакомиться с каналом Battle(non)sense: там разбираются тесты сетевых проблем в разных играх и то, как разные технологии на них влияют. Прилагаем также и другие ссылки на видео и статьи о сетевом коде ниже:
- Explaining how fighting games use delay-based and rollback netcode
- Netcode 101 — What You Need To Know
- Netcode for Game Developers