Лаги, джиттер и потеря пакетов: откуда берутся проблемы с неткодом и как их решать
Если вы когда-либо играли в онлайн-игры, то наверняка знаете о лагах не понаслышке. Пропущенный выстрел, который должен был попасть в цель; мяч, резко меняющий направление прямо в воздухе; вы вдруг снова оказываетесь на несколько шагов назад в том месте, где находились секундой ранее. В этом нет ничего сверхъестественного: это обычные артефакты систем, обеспечивающих совместную игру с людьми из других стран почти так же эффективно, как и с соседом по комнате. По крайней мере, большую часть времени.
В этой статье речь пойдет о самых базовых вещах, почему вообще возникает сетевая задержка, с какими еще проблемами неткода можно столкнуться, а также с тем, что можно сделать со своей стороны, чтобы улучшить ситуацию. Также разберем остальную часть конвейера между ПК и игровым сервером, который может повлиять на получение лучшего игрового опыта без задержек и прочих неприятностей.
Итак, почему вообще возникают лаги? Почему в 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: там разбираются тесты сетевых проблем в разных играх и то, как разные технологии на них влияют. Прилагаем также и другие ссылки на видео и статьи о сетевом коде ниже:
Что такое джиттер? Обьясните своими словами понятным языком если это возможно.
своими не знаю как. Вот Викпендия: http://ru.wikipedia.org/wiki/Джиттер
Джиттер (англ. jitter — дрожание) — нежелательные фазовые и/или частотные случайные отклонения передаваемого сигнала. Возникают вследствие нестабильности задающего генератора, изменений параметров линии передачи во времени и различной скорости распространения частотных составляющих одного и того же сигнала.
В цифровых системах проявляется в виде случайных быстрых (с частотой 10 Гц и более) изменений местоположения фронтов цифрового сигнала во времени, что приводит к рассинхронизации и, как следствие, искажению передаваемой информации. Например, если фронт имеет малую крутизну или «отстал» по времени, то цифровой сигнал как бы запаздывает, сдвигается относительно значащего момента времени — момента времени, в который происходит оценка сигнала.
Джиттер является одной из основных проблем при проектировании устройств цифровой электроники, в частности, цифровых интерфейсов. Недостаточно аккуратный расчет джиттера может привести к его накоплению при прохождении цифрового сигнала по тракту и, в конечном счёте, к неработоспособности устройства.
При цифровой записи звука джиттер вносит в сигнал искажения, подобные детонации — явлению, вызванному неравномерностью движения магнитной ленты в аналоговом магнитофоне вследствие несовершенства лентопротяжного механизма. Однако вносимые цифровым джиттером искажения существенно заметнее искажений звука, вносимых детонацией. Видимо, это связано с большей «мягкостью» и «плавностью» детонационных искажений (можно сказать, «аналогового джиттера») , обусловленных эластичностью магнитной ленты и инерционностью механических элементов лентопротяжных механизмов.
Джиттер. Теория. Часть 2
Интерфейсный джиттер возникает, когда цифровой сигнал посылается с одного устройства на другое. В зависимости от свойств устройств цепи сигнала, джиттер может возникнуть, усилиться, накопиться или ослабнуть. Собственный джиттер передатчиков и приемников, потери в кабеле, шумы и наводки — всё это вызывает джиттер и порчу формы цифрового интерфейсного сигнала.
Формат цифровой передачи звукового сигнала AES3 регламентирует допуски на джиттер. Бытовая версия интерфейса — S/PDIF, описанная в стандарте IEC60958-3:20002, также содержит спецификации на джиттер. Это сделано для предотвращения проблем совместимости устройств, соединяющихся по цифровому интерфейсу.
Собственный джиттер
Если устройство работает автономно или синхронизировано с относительно безджиттерным сигналом, то джиттер, измеренный с передатчика сигнала, обусловлен лишь свойствами самого устройства. Такой джиттер называют собственным или внутренним джиттером (intrinsic jitter).
Уровень собственного джиттера определяется либо фазовым шумом собственного тактового генератора, либо характеристиками восстановления клока в ФАПЧ, если производится внешняя синхронизация.
Возьмем, например, кварцевый генератор, стоящий в CD плеере. Так как устройство работает автономно, джиттер на выходе определяется фазовым шумом тактового генератора и джиттером цифровых микросхем в цепи сигнала. Кварцевые генераторы имеют низкие фазовые шумы, а быстродействующие логические элементы имеют очень низкую флуктуацию времени задержки, так что джиттер мал — зачастую менее 1 пс RMS для частот джиттера выше 700 Гц.
Устройства, рассчитанные на внешнюю синхронизацию с перестраиваемой частотой,
могут иметь генератор управляемый напряжением (ГУН) в качестве клока. В этом случае фазовые шумы намного выше, чем для кварцевого генератора. Собственный джиттер ГУН обычно более 1 нс RMS для частот выше 700 Гц. Однако при восстановлении клока ГУН стоит в цепи ФАПЧ для синхронизации по внешнему источнику и собственный джиттер генератора ослабляется в ФАПЧ.
Собственный джиттер можно измерить даже при отсутствии референсного низкоджиттерного сигнала, если использовать в качестве последнего сигнал, восстановленный ФАПЧ. Характеристики ФАПЧ будут определять точку отсечки НЧ при измерениях. AES3 определяет допуск 3 дБ и частоту среза 700 Гц.
Джиттер, возникающий в кабеле
Другой источник джиттера цифрового интерфейса — неидеальные свойства линии передачи. Затухание в кабеле или несогласованность по импедансу может вызвать потери на ВЧ, что приведет к размыванию фронта импульсов, как показано на графике 7.
График 7. Серым цветом: идеальная форма сигнала AES3.
Голубым цветом: сигнал, прошедший через кабель
На увеличенном фрагменте показано смещение
точки пересечения нуля фронтом импульса
Это может и не стать серьёзной проблемой, если эффект проявится на каждом срезе фронта импульса, так как только повлечет за собой небольшую постоянную задержку в сигнале, что можно проигнорировать.
Однако это может быть только в случае постоянного следования импульсов — если следуют только нули или только единицы. Но реальный сигнал состоит из разных комбинаций битов, так что при порче сигнала в кабеле, это может привести к межсимвольным помехам или межсимвольной интерференции (intersymbol interference).
Проще говоря, импульсы сдвигаются и заходят на места соседних, и чем больше размывание фронтов сигнала в кабеле, тем дальше импульсы от теоретической точки пересечения нуля.
Так как интерфейс AES3 использует один и тот же сигнал для передачи тактового сигнала и данных, возможно возникновение джиттера из-за модуляции данных. Это означает, что нужно изучить закономерности взаимного влияния данных и тактового сигнала. Размывание формы сигнала в результате потерь в кабеле — одно из таких проявлений.
Межсимвольная интерференция
График 9. Межсимвольные помехи сигнала AES3
Черным цветом: 1-1-1
Серым цветом: 1-1-0
Синим цветом: 1-0-0
Голубым цветом: 0-1-0
Пунктирным синим: 0-0-0
На графике 9 показаны варианты сигнала формата AES3, с различными данными в первых трех битах, от 1-1-1 до 0-0-0. Данные закодированы по схеме, под названием двухфазная маркировка (bi-phase mark), также известная как манчестерский код или частотно-модулированное кодирование (Manchester code, FM code), с обязательной сменой уровня перед каждым следующим битом и двукратной сменой уровня в случае «1».
В нижней части показаны сигналы так, как они могут выглядеть после потерь при передаче по кабелю большой длины. Сигналы были получены с использованием симуляции кабеля на измерительной станции Audio Precision System Two. Потери в реальном кабеле могут вызвать тот же эффект: спад высоких частот с увеличением времени нарастания и спада импульсов.
График 8. Структура данных формата AES3. Заголовочная часть Y одинакова в каждом фрейме
В каждом случае данным предшествует заголовок Y, начинающий субфрейм B (График 8). Этот заголовок фиксирован и продолжается 5 битовых периодов (то есть 10 интервальных единиц, 10 UI). В результате этого, независимо от последующих данных сигналы после заголовка имеют примерно тот же самый уровень, так как они перед этим прошли тот же самый путь. Заголовок номинально длится 8 UI, но так как конец предшествующего бита и начало последующего фиксированы схемой кодирования, в результате постоянная часть имеет продолжительность 10 UI.
Черный, серый и синий графики имеют начало смены модуляции в момент времени 1465 нс (9 UI) от времени начала субфрейма, так как они имеют в начале своих данных «1». Голубой и синий пунктирный графики начинаются с «0», так что у них импульс еще не начался. Все пять графиков меняют направление в момент 1628 нс (10 UI), соответствующий концу первого бита (частота семплинга данных 48 кГц, так что 1 UI здесь равен 162,8 нс).
Пунктирные линии «a» и «b» показывают, что моменты пересечения нуля равны 1705 нс и 1745 нс. Более раннее время относится к графикам, соответствующим данным с «1» в первом бите, более позднее — с «0».
В результате потерь высокочастотной составляющей при эмуляции кабеля, переходные процессы увеличиваются, так что точка пересечения нуля смещается примерно на 100 нс. Такое взаимодействие между значением первого символа данных и временем начала второго символа данных называется межсимвольными помехами или межсимвольной интерференцией (intersymbol interference).
Эта интерференция ещё более сложная после второго битового символа (около 2050 нс с начала субфрейма, показана на увеличенном фрагменте графика 9). Здесь четыре различных момента времени пересечения нуля в соответствии с четырьмя возможными сочетаниями первых двух битов субфрейма. Наибольшая разница во времени обусловлена значением второго бита, но есть небольшая разница и в зависимости от значения первого бита.
Джиттер, вызываемый содержимым данных
Джиттером данных (data jitter) называют смещение фронтов импульсов части сигнала AES3, вызванного содержимым данных. Эта форма джиттера часто служит индикатором межсимвольной интерференции.
На графике 9 показан механизм образования джиттера данных, амплитудное значение которого составляет около 50 нс. Джиттер данных также может быть вызван нелинейностью линии связи, так что положительные и отрицательные составляющие фронта импульсов могут смещаться на разные значения.
Джиттер заголовка фрейма
Джиттером заголовка (preamble jitter) называют смещение фронта импульсов в заголовках фрейма AES3. Заголовки фрейма — это унифицированный несменяемый набор данных, используемый для определения начала блока фреймов данных и начала субфрейма (График 8). Заголовок Y в начале второго субфрейма B имеет абсолютно четкую постоянную последовательность битов. Эта неизменяемая часть данных может быть использована для измерений джиттера, так как нечувствительна к межсимвольной интерференции, и поэтому служит индикатором джиттера передающего устройства, а не джиттера, вызванного модуляцией данных.
Джиттер, вызванный шумами и помехами
Если фронты импульсов не размываются из-за потерь в кабеле, время нарастания и спада будет коротким, так что точка пересечения нуля практически не зависит от добавленных шумов. Но в случае длительного переходного процесса, вызванного потерями в кабеле, шумы и помехи «гуляют» по фронту импульса, тем самым, сдвигая точку пересечения нуля фронтом импульса по шкале времени.
Так, шум может изменить время определения фронта импульса. Чувствительность к шуму зависит от продолжительности переходного процесса, что, в свою очередь, обусловлено потерями в кабеле.
График 10. Формат сигнала AES3. Джиттер, вызванный шумами.
Сказанное проиллюстрировано на графике 10, где показано пять идентичных фрагментов Y-заголовка субфрейма B. (Как говорились выше, это неизменяемая комбинация данных нечувствительно к джиттеру данных, что позволяет изучить вызванный шумом джиттер более точно.) Две отметки, «a» и «b», показывают временной диапазон пересечения нуля третьим по счету импульсом. Интервал равен 31 нс. В этом примере производимое шумом отклонение является низкочастотным синусоидальным сигналом с амплитудой около 300 мВ. Такая помеха может быть вызвана линиями питания сети переменного тока.
Джиттер, вызванный шумами в кабеле, напрямую зависит от наклона фронта импульса в точке пересечения нуля. В случае короткого переходного процесса любые помехи не приведут к росту джиттера: изменение уровня сигнала вызовет лишь небольшое смещение по времени.
Замечание: В этом примере была проведена эмуляция длинного кабеля на измерительной станции Audio Precision System Two Cascade. Однако в случае короткого соединения уровень джиттера может быть по амплитуде меньше на несколько порядков.
Учтите, что направление смещения по времени зависит от направления переходного процесса. При нарастании сигнала добавление шума приведет к опережению фронта, тогда как при спаде фронт будет запаздывать. В отличие от джиттера данных, вызванного межсимвольной интерференцией, обсуждаемая форма джиттера больше касается устройств с восстановлением клока по кромке фронта импульса в заголовочной части данных. Так как этот фронт имеет только одно направление (положительный знак производной), смещение по времени последующих фронтов будет суммироваться.
В то же время, есть системы, использующие несколько кромок импульсов в субфрейме, где в равной степени берутся переходные процессы в обоих направлениях. Для таких систем взаимное погашение смещений уменьшает влияние низкочастотных составляющих вызванного шумом джиттера на восстанавливаемый тактовый сигнал. Смещения от высокочастотного шума не обладают такой корреляцией, так что взаимное подавление для ВЧ помех не работает.
Допуск на джиттер
Приемник (ресивер) цифрового звукового сигнала AES3 должен иметь возможность декодирования интерфейсных сигналов, у которых присутствует небольшой уровень джиттера по сравнению с длинной импульсов, которые необходимо декодировать. По мере увеличения уровня джиттера ресивер начинает неточно декодировать сигнал, а впоследствии теряет возможность его декодировать вообще – порой вызывая временное прекращение звука или даже полностью теряя захват цифрового сигнала (lock). Максимальный уровень джиттера до начала появления ошибок в данных называется допуском на джиттер (jitter tolerance).
Как было показано в соответствующем параграфе, ФАПЧ имеет свойства низкочастотного фильтра аналогично маховику: она реагирует на изменения, которые медленнее, чем значение частоты среза, и не обращает внимания на более быстрые изменения.
Допуск на джиттер, следовательно, не зависит от частоты джиттера выше частоты среза ресивера, но при уменьшении скорости дрожания фазы (то есть частоты джиттера), ресивер имеет больше шансов отследить эти измерения.
Это значит, что при низких скоростях джиттера ресивер может среагировать на бОльшие значения джиттера, поэтому допуск на джиттер возрастает.
График 11. AES3. Шаблон допуска джиттера.
По мере приближения частоты джиттера к частоте среза, допуск существенно уменьшается. Это происходит потому, что резонансы в ресивере приводят к тому, что согласование между отклонением времени синхронизации передачи входных данных и приблизительного подсчета времени синхронизации самим ресивером, получается хуже, чем, если бы ресивер совсем не реагировал на джиттер.
Спецификации интерфейса AES3 определяют шаблон допуска по джиттеру, показанный на графике 11. Допуск задается в интерфейсных единицах, UI. Линия на графике показывает нижний предел допуска по джиттеру ресивера к синусоидальному джиттеру на частоте, отложенной по оси X. Обратите внимание — этот шаблон подразумевает, что у ресивера частота среза больше приблизительно 8 кГц. Это значит, что ФАПЧ ресивера не сможет подавить джиттер ниже этой частоты, поэтому сигнал с джиттером проследует дальше. Если необходимо значительное снижение джиттера, нужно использовать вторую ФАПЧ с меньшей частотой среза.
Передаточная функция и коэффициент усиления джиттера
График 12. Передаточная функция джиттера.
При синхронизации устройства от внешнего клока (например, S/PDIF, word clock или синхросигнал видео), джиттер внешнего источника может повлиять на выходной цифровой сигнал. В результате джиттер цифрового выхода равен комбинации этого полученного и собственного джиттера устройства. Хотя зависимость между входным и выходным джиттером может быть достаточно сложной, можно приближенно рассмотреть передачу как простой линейный процесс. Передаточная функция джиттера (jitter transfer function) равна отношению входного джиттера к выходному, как функция частоты джиттера. Отношение называют коэффициентом усиления джиттера (jitter gain) на данной частоте.
График 12 показывает передаточную функцию джиттера для ФАПЧ с частотой среза 100 Гц. Обратите внимание, что на частотах ниже частоты среза коэффициент усиления равен примерно 0 дБ. Выше частоты среза ФАПЧ начинает уменьшать джиттер, с наклоном характеристики 6 дБ на октаву. Данная схема имеет ФНЧ второго порядка в цепи обратной связи с частотой среза 1 кГц, так что выше этой частоты наклон усиливается и становится равным 18 дБ.
Обратите внимание, что ниже частоты среза коэффициент усиления достигает максимального значения, примерно равного 0.5 дБ. Подобное небольшое усиление вполне обычно для частот, чуть ниже частоты среза. Это явление носит название пиковый джиттер или всплеск джиттера (jitter peaking). Оно возникает из-за особенностей фазовой характеристики цепи обратной связи ФАПЧ.
Стандарт AES3 ограничивает коэффициента усиления джиттера значением +2 дБ.
Джиттер от нелинейности
К сожалению, линейная теория передачи джиттера не учитывает нелинейных зависимостей. Так, фазовый детектор ФАПЧ часто имеет мертвую точку, где теряется чувствительность к небольшим фазовым отклонениям. В результате наблюдается дрейф сигнала на выходе ФАПЧ, пока фазовый детектор не заработает и не внесет коррекцию. Этот дрейф вызывает периодическое смещение вперед и назад, порождая джиттер.
Еще одна причина возникновения джиттера по причине нелинейности — это алиазинг высокочастотных компонент джиттера, переносящий паразитные компоненты в низкочастотный диапазон при работе ФАПЧ. Например, при передаче сигнала с частотой семплирования 48 кГц по интерфейсу AES3, составляющая джиттера на 47 кГц даст паразитную компоненту интермодуляции на частоте 1 кГц, в диапазоне, где джиттер не подавляется ФАПЧ. При измерении передаточной функции джиттера это приведет к резкому увеличению коэффициента усиления джиттера, кратного частоте семплирования.
Накопление джиттера
При соединении цифровых звуковых устройств в цепочку, каждое последующее устройство синхронизируется от предыдущего и вносит свой вклад в джиттер. Каждое устройство добавит собственный джиттер, а каждый соединительный кабель внесет джиттер, образующийся в кабеле при передаче. На каждом этапе джиттер также может усилиться или ослабнуть.
Этот процесс называют накоплением джиттера (jitter accumulation). Эффект зависит от характеристик каждого устройства и структуры данных на каждой стадии, и в самом худшем случае джиттер накладывается в наиболее нежелательном варианте. В цепи устройств с восстановлением клока джиттер также в худшем случае накапливается. Как показано в таблице 1, это может привести к значительному усилению джиттера, несмотря на всего несколько стадий передачи сигнала.
Таблица 1. Накопление джиттера в зависимости от усиления джиттера и количества устройств.
Для подсчета максимального значения возьмем джиттер на частотах ниже частоты среза передаточной функции, то есть там, где подавление джиттера отсутствует. Примем, для упрощения, что все устройства имеют одинаковое количество джиттера J (джиттер в кабеле и собственный джиттер). Также представим, что каждое устройство усиливает джиттер предыдущей стадии на то же самое значение, принимая во внимание, что усиления возможно только для частот джиттера вблизи максимума передаточной функции.
Таблица 1 отображает суммарный джиттер для трех цепочек устройств в виде множителя J.
Как мы видим, в случае отсутствия усиления (0 дБ) выходной джиттер просто суммируется. Помните, что это справедливо только для частот ниже граничной, на более высоких частотах джиттер подавляется, так что рост значительно замедляется.
Усиление более 0 дБ отражает явления подъема джиттера передаточной функции, который происходит только вблизи частоты среза. При широкополосном джиттере будет усилена только небольшая часть сигнала, однако есть причины, почему джиттер концентрируется в районе подъема.
Во-первых, джиттер данных дает узкие по спектру компоненты. Для низких уровней сигнала джиттер будет связан со знаком сигнала, так как при приближении сигнала к нулю старшие значащие биты данных изменяются одновременно. Если по интерфейсу передается сигнал одной частоты низкой амплитуды, возникающий в кабеле джиттер стремится к меандру на этой частоте. Зачастую максимум на спектре совпадает с подъемом в передаточной функции джиттера.
В цепи устройств с восстановлением клока с похожими характеристиками эффект повторяется на каждом этапе. Строчка со значением 6 дБ в таблице отражает уровень подъема джиттера оборудования, разработанного до того, как об этой проблеме стали серьёзно задумываться. Как показано в таблице, в таком случае суммарный джиттер достигает огромных значений, несмотря на небольшое число стадий.
Обычным признаком ненормального уровня накопления джиттера служит частая потеря данных или постоянный срыв синхронизации. К сожалению, такие ситуации сложно воспроизвести и служба технической поддержки здесь оказывается бессильной.
Начиная с 1997 года, спецификация AES3 имеет параграфы, которые посвящены потенциальной проблеме накопления джиттера. Основной из них определяет, что все устройства должны ограничить усиление джиттера значением 2 дБ для любых частот.
В дополнение, имеется установленное значение подавления джиттера, которому должны удовлетворять устройства подавления интерфейсного джиттера. Оговорено значение как минимум в 6 дБ для частот выше 1 кГц. Эта частота намного ниже, чем частота среза шаблона допуска на джиттер, так что устройствам необходим передающий тактовый сигнал, отличный от восстановленного, который определяется допуском на джиттер.
Джиттер
Jitter (джиттер или дребезг) — это неравномерность периодов времени, отведенных на доставку пакета. джиттер присущ только сетям с пакетной коммутацией. Задержка в доставке пакета и джиттер обычно исчисляется в миллисекундах, и на первый взгляд, не являются столь критичными и едва ли могут быть замечены человеком. Это так, до тех пор, пока это не касается передачи голоса или видео, другими словами, до тех пор, пока мы не столкнемся с передачей контента в реальном режиме времени.
Причины джиттера
Причиной джиттера могут быть разные факторы, обусловленные спецификой передачи информации в пакетных сетях: это и большая загрузка узлов коммутации, где пакеты выстраиваются в очередь и ожидают своей отправки в следующую точку агрегации и маршрутизации сетевого трафика, это и диверсификация маршрутов следования пакетов (пакеты, следовавшие друг за другом в источнике, могут быть переданы разными маршрутами к получателю, а значит, и вероятно обработаны разным количеством сетевых узлов, каждый из которых вносит свою, случайную задержу обработки пакета).
Начиная с версии 1.4, для Астериска был разработан патч JB, который позволяет применять JB не только в случае бридживания каналов (bridge channels), но и применим к таким приложениям, как голосовая почта и конференция, которые реализованы в Астериске в виде приложений. Ранее с JB в связке с приложениями можно было работать только через псевдо-канал local_chan, используя в вызове приложения конструкцию «j», тем самым имитируя формирования бриджа.
Чтобы понять, как работает JB в Астериске, необходимо глубже понять концепцию организации каналов в Астериске. Канал в Астериске возникает тогда, когда приходит звонок. Причем, для звонящего через Астериск, этот звонок будет исходящим, а для Астериск — входящим. Далее, пришедший звонок помещается в номерной план обработки вызова. Если образованный канал запускает приложение Dial(), тогда создается второй канал (исходящий с точки зрения Астериска) для совершения звонка к вызываемому. Если второй исходящий канал отвечен, Астериск соединяет эти два канала в бридж (bridge). Два канала позволяют передавать голос между собой: фреймы голоса, принятые в один канал, передаются в другой канал с помощью бриджа.
Пример 1. Рассморим сценарий вызова, когда sip-клиент звонит на zap-канал PSTN-интерфейса:
В этом примере Канал 1 является входящим с точки зрения Астериска, а Канал 2 — исходящим. Rx — прием звука в Астериск, а Tx — передача звука от Астериска. Звук, пришедший из zap-канала Tx передается через бридж в sip-канал Rx и, очевидно, не нуждается в де-джитировании в Астериске, так как для канальной коммутации (zap-канал) джиттер не характерен. В этом случае, де-джиттирование необходимо применять как можно ближе к sip Rx, т.е. в самом ip телефонном аппарате.
Когда звук приходит с sip-канала Tx, например от ip-телефона, пройдя пакетную сеть, в котором есть вероятность возникновения джиттера, попадает в Астериск и уже с джиттером попадает в zap-канал (см.рис 2).
Вот здесь и необходимо применить де-джиттирование. В силу того, что в zap-канал нельзя отправлять голосовые пакеты с джиттером (что приведет к ухудшению качества воспроизводимой речи в zap-канале), именно в zap-канале необходимо применить де-джиттирование. Делается это в настройках zapata.conf (chan_dahdi.conf) посредством включения опции jbenable=yes. Эта опция говорит: «Для трафика, попадающего в zap-канал включить JB».
JB можно применить и для sip-канала. Но это возможно только на исходящем канале и только с применением опции jbforce=yes. Это объясняется тем, что бридж будет «смотреть», что входящий де-джиттированный трафик снова возвращается в канал, в котором есть вероятность появления джиттера. Поэтому, в идеале применять JB в каналах с пакетной коммутацией необходимо в конечной точке, т.е. в ip-телефоне. В противном случае, например при звонках sip ⇒ sip, создавалось бы два JB, что вносило бы дополнительные задержки в одной голосовой сессии и отрицательно влияло на качество голоса. Другими словами, JB следует применять только на исходящем (с точки зрения Астериска ) Tx канале, а применение JB «посредине» голосового канала — крайне нежелательно.
Следует помнить, что JB работает только для каналов в бридже (sip ⇒ zap и пр.), причем в одном из каналов должна существовать вероятность появления джиттера, а во втором канале бриджа джиттер недопустим. Реализация его во входящем канале (sip ⇒ application Meetme() )допустима только в версии 1.6 или посредством патча, а также вызовом приложения через local-канал.
Из вышесказанного можно сделать вывод, что джиттер может возникать только в канале с пакетной коммутацией. Применять де-джиттирование (посредством джиттер-буфера) можно только, когда каналы находятся в бридже, более того, необходимым условием включения JB должно быть то, что для одного из каналов в бридже недопустима работа с джиттером (только в канале с канальной коммутацией). JB будет отрабатываться только на исходящем канале (с точки срения Астериска, Tx) в котором недопустимо появление джиттера (например, zap — канал).