Что такое сетевая буферизация
Как избежать проблем с буферизацией при потоковой передаче видео?
При просмотре потокового видео на вашем Smart TV или через медиа-стример, умный проигрыватель дисков Blu-ray или Smart TV, нет ничего более раздражающего, чем постоянная остановка, запуск и/или показ экрана с надписью «загрузка».Эта информация относится к телевизорам и другим устройствам различных производителей, включая, но не ограничиваясь, производства LG, Samsung, Panasonic, Sony и Vizio.
Как работает потоковое видео и буферизация?
Чтобы предотвратить остановку загрузки видео, ваш сетевой компонент «буферизирует» видео. Таким образом, оно передает потоковое видео заранее до того, что вы смотрите, поэтому оно воспроизводится непрерывно. По крайней мере, это идея.
Когда видео попадает в точку потоковой передачи файла, возможна задержка. Это приводит к показу экрана «загрузки» и паузе в воспроизведении фильма.
Если потоковое видео достигает точки, в которой оно должно остановиться, пока не появится больше информации, оно будет приостановлено, и вы увидите вращающуюся стрелку или вращающийся круг на экране телевизора. Как только видео поток перехватывает, он воспроизводится снова.
Повторная буферизация может возникать из-за технической проблемы с поставщиком контента или вашим поставщиком интернет-услуг (ISP), но также может происходить, когда слишком много устройств используют ваше интернет-соединение одновременно. Однако в большинстве случаев это зависит от скорости вашего интернета.
Что такое скорость загрузки?
Скорость Интернета или скорость домашнего подключения означает, сколько данных (в данном случае потоковых фотографий, музыки и файлов фильмов) можно отправить из источника на проигрыватель. Источник может передавать потоковое видео Netflix, например, из Интернета, а также фотографии, музыку или видео, хранящиеся на компьютере в вашей домашней сети.
Медленное соединение задержит доставку аудио и видео информации о фильме, и в этом случае вы увидите экран загрузки. Быстрое соединение позволяет воспроизводить фильмы без перерывов и легко размещать видео высокой четкости или 3D и до 7.1 каналов объемного звука.
Большинство интернет-провайдеров рекламируют высокую скорость интернет-соединения. Там, где у нас когда-то были скорости коммутируемого соединения и DSL, измеренные в килобайтах в секунду (Кбит/с), теперь мы измеряем скорости в мегабайтах в секунду (Мбит/с). (Мегабайт составляет 1000 килобайт.) Поставщики услуг широкополосного и кабельного интернета предлагают скорость загрузки более 50 Мбит/с во многих регионах.
В дополнение к скорости интернет-соединения вашего провайдера услуг, такие как Netflix и Vudu, имеют свои собственные требования к скорости потокового видео. Вы можете проверить свою скорость интернета на различных сайтах.
Какая скорость нужна для домашней сети?
Дело не только в том, как быстро интернет приносит видео в ваш дом. Оказавшись там, информация должна быть отправлена с модема на маршрутизатор.
Следующее соображение заключается в том, как быстро маршрутизатор может отправлять видео и другую информацию на компьютеры, медиа-стримеры, смарт-телевизоры и подключенные к нему проигрыватели дисков Blu-ray с доступом в Интернет. Маршрутизаторы, предназначенные для работы с потоковым видео, иногда называемые AV-маршрутизаторами, могут передавать больше данных, уменьшая прерывания воспроизведения.
Скорость соединения маршрутизатора с устройством потоковой передачи/воспроизведения мультимедиа считается конечной переменной. Маршрутизатор может поддерживать потоковую передачу мультимедиа на высокой скорости, но аудио и видео могут попасть на ваш медиа-стример/проигрыватель только с той скоростью, с которой соединение может их передать.
Подключение с помощью кабеля Ethernet или аксессуаров, разработанных для AV
Использование кабеля Ethernet (Cat 5, 5e или 6) считаетсяя наиболее надежным способом подключения мультимедийного стримера или другого совместимого компонента к маршрутизатору. Этот тип прямого физического соединения обычно поддерживает скорость возможностей маршрутизатора.
Однако при подключении сетевого мультимедийного проигрывателя или компонента по беспроводной связи (Wi-Fi) или с помощью адаптера питания, скорость часто падает, иногда резко. Даже если есть скорость интернета 10 Мбит/с для вашего маршрутизатора, он может не поддерживать эту скорость для вашего устройства; это может показать, что он получает менее 5 Мбит/с, и вы получаете сообщение о том, что качество видео ухудшается в вашей учетной записи Netflix или Vudu.
При поиске аксессуаров для беспроводных адаптеров и адаптеров питания проверьте значения скорости; они указывают, оптимизированы ли они для AV, поэтому вы можете передавать потоковое видео высокой четкости и аудио. Другое соображение, касающееся беспроводных маршрутизаторов, заключается в том, насколько далеко они могут передавать стабильные сигналы. Расположение мультимедийного стримера/устройства воспроизведения, такого как Smart TV, на большом расстоянии (например, в другой комнате) может повлиять на стабильность сигнала, принимаемого через беспроводной маршрутизатор.
Скорость интернета продолжает расти
Теперь, когда мультимедиа стало цифровым, его получение дома происходит быстрее, чем когда-либо прежде, и такие службы, как Google Fiber, Verizon FIOS и Cox Gigablast, могут обеспечить широкополосную скорость до 1 Гбит/с. Конечно, с этими более высокими скоростями увеличиваются ежемесячные расходы на обслуживание.
Системы потоковой передачи и доставки, такие как маршрутизаторы HDBaseT, беспроводные адаптеры и адаптеры Powerline, постоянно совершенствуются, чтобы они могли одновременно переносить большие объемы видео высокой четкости (с особым вниманием к 4K) на несколько телевизоров и компьютеров одновременно. а также играть в видеоигры без задержки.
Явление излишней сетевой буферизации
В ситуациях, когда при большой пропускной способности сети обычные веб-страницы начинают долго грузиться или становится невозможно использовать аудио и видео чаты, играть в сетевые игры, можно предположить явление излишней сетевой буферизации.
Суть этого явления в накоплении большого количества «лишних» пакетов в буферах, встречающихся на пути от источника данных до приемника. Такие буферы присутствуют в коммутаторах, маршрутизаторах, других узлах сети.
Каким образом накапливаются пакеты в буферах
Буферы предназначаются для временного хранения пакетов данных в ситуациях, когда скорость передачи выше, чем скорость получения пакетов. В таком случае буфер задерживает на несколько миллисекунд пакет и передает его с задержкой, а если буфер наполняется, то часть пакетов может отбрасываться. На стороне отправителя протоколы контроля перегрузки замечают это явление и снижают скорость передачи данных, таким образом скорость трансляции данных по сети становится максимально возможной в зависимости от пропускной способности входящего канала.
В некоторых узлах сети буферы большого объема могут накапливать пакеты долгое время, в результате из-за возникающих пауз алгоритмы контроля перегрузки сбиваются и некорректно функционируют: одни пакеты задерживаются, другие отбрасываются. В буфере образовывается «затор» пакетов, что и вызывает временные негативные симптомы при работе по сети. Через время буфер освобождается от «лишних» пакетов, скорость работы сети нормализуется до следующего наполнения буфера.
Проблема явления излишней сетевой буферизации возникает при установке слишком больших объемов буферов в маршрутизаторах, свитчах, коммутаторах и других сетевых устройствах и системах. Производители идут на этот шаг в связи с резким снижением стоимости памяти. Проблема решается уменьшением размеров буферов на сетевом оборудовании, однако не всегда пользователь имеет возможность конфигурировать этот объем или не имеет доступ к данному оборудованию.
В каких случаях в буферах накапливаются «лишние» пакеты
Излишнюю сетевую буферизацию вызывают действия пользователя, связанные с передачей больших объемов данных по сети. Это могут быть:
Вопрос решения данной проблемы поднимается экспертами области цифровых технологий. На сегодняшний день явление до конца не изучено, точного решения по устранению проблем излишней буферизации пока не существует.
Память сети: как сохранить пакет
Настоятельно рекомендую ознакомиться с 15-м выпуском СДСМ перед тем, как приступить к чтению.
Содержание
Терминология
Назначение буферов
Будучи неоднократно обвинённым при рецензировании этой статьи, чувствую необходимость ещё раз повторить это: внутри чипа коммутации заголовки отделяются от тела пакета. В то время, как изначальные заголовки анализируются, помогают сделать лукап, уничтожаются, формируются новые, тело находится в одном месте физической памяти, не перемещаясь. Даже в тот момент, когда Traffic Manager выстраивает пакеты в очередь согласно их приоритетам, производит их диспетчеризацию и Congestion Avoidance, фактически он работает со внутренними временными заголовками, не двигая пакеты по памяти.
MMU занимается размещением пакетов в буферах, их извлечением или отбрасыванием. Он же контролирует разделение памяти на области (dedicated, shared, headroom, voq) и их загрузку.
Есть два подхода к размещению тел в буферах: Store-and-Forward и Cut-Through.
Store-and-Forward vs Cut-Through
Многие производители сегодня по умолчанию устанавливают режим Cut-Through, поскольку ошибки на Ethernet сегодня явление сравнительно нечастое, а приложение обычно само может обнаружить проблему и запросить переотправку (или не запрашивать, кстати).
Перегрузки: причины и места
Причины перегрузок
Поэтому однозначно нужно побольше памяти для буферизации. Но фактически это место, где пакеты обрастают задержкой. Так на заре 1G буферизация вызывала массу головной боли у трейдеров, чьи приложения получали свой бесценный трафик с задержкой и джиттером.
И поэтому тут уже недостаточно везде FIFO. Это задача, во благо которой трудится QoS.
Но в каком месте располагать эту память и где реализовывать QoS?
Места возникновения перегрузок
Но никто не хочет бороться с перегрузками в четырёх местах.
Поэтому обычно:
А) Чип делают такой производительности, чтобы он смог обработать весь трафик, даже если тот начал одновременно поступать со всех портов на этой линейной карте. Поэтому для устройства со 128 портами 100Гб/с используется чип с производительностью 12,8Тб/с.
Очевидно, бывают и исключения. Тогда или имеем непредсказуемые потери, или (чаще) невозможность использовать часть портов.
Б) Фабрику также делают без переподписки, чтобы она могла провернуть весь трафик, который пытаются в неё передать все линейные карты, даже если они делают это одновременно на полной скорости. Таким образом, не нужно буферизировать трафик и перед отправкой на фабрику.
В) Управление перегрузками на выходном чипе и выходном интерфейсе сводят в одно место.
Архитектура буферов
Crossbar
Это, скорее, умозрительный эксперимент, потому что в плане сложности, стоимости реализации и эффективности это проигрышный вариант.
Shared Buffer
По числу существующих в мире коробок этот вариант, однозначно, на первом месте.
Используется Shared Buffer на немодульных устройствах без фабрики коммутации, в которых установлен один чип (обычно, но может быть больше).
Итак, есть соблазн эту память взять и просто равномерно разделить между всеми портами. Такой статический дизайн имеет право на жизнь, но сводит на нет возможность динамически абсорбировать всплески трафика.
Гораздо более привлекательным выглядит следующий вариант:
Dedicated + Shared
Наличие Shared Buffer»а решает огромную проблему, позволяя сглаживать всплески трафика, когда перегрузку испытывает один или несколько интерфейсов.
Поэтому, зачастую, помимо Dedicated и Shared буферов, резервируют ещё Headroom buffers.
Headroom buffers
Коммутатор, заметив заполнение общего буфера, отправляет Pause для более низкого приоритета, тем самым притормаживая репликацию, но не RoCE.
Задача буфера Headroom здесь в том, чтобы сохранить те пакеты приоритетной очереди, что сейчас в кабеле, пока Pause летит к отправителю с просьбой притормозить. То есть пакеты репликации начнут дропаться, когда заполнится общий буфер, а пакеты RoCE будут складываться в Headroom.
Помимо lossless headroom бывает и headroom для обычного трафика, чтобы помочь сохранить более приоритетный. Но это на домашнее задание.
Разумеется, описанное выше лишь частный пример, и от вендора к вендору ситуация может различаться (разительно).
Например, бродкомовские чипы (как минимум, Trident и Tomahawk) имеют внутреннее разделение памяти по группам портов. Общая память делится на порт-группы по 4-8 портов, которые имеют свой собственный кусочек общего буфера. Порты из одной группы, соответственно буферизируют пакеты только в своём кусочке памяти и не могут занимать другие. Это тоже один из способов снизить влияние перегруженных портов друг на друга. Такой подход иногда называют Segregated Buffer.
Admission Control
В случае Shared Buffer оба механизма срабатывают в момент первичного помещения пакета в буфер. То есть, никакой двойной буферизации и проверки не происходит.
Как именно понять, сколько буфера занято конкретным портом/очередью и главное, сколько ещё можно ему выдать? Это может быть статический порог, одинаковый для всех портов, а может быть и динамически меняющийся, регулируемый параметром Alpha.
Alpha
Итак, почти во всех современных чипах память распределяется динамически на основе информации о том, сколько общей памяти вообще свободно и сколько ещё можно выделить для данного порта/очереди.
Предполагаем тут, что значение alpha одинаково для всех регионов, хотя оно может быть настроено отдельно для каждого.
При получении каждого пакета, механизм Admission Control вычисляет актуальный порог для региона, которому принадлежит пакет. Если порог меньше размера пакета, тот отбрасывается.
Если же больше, то он помещается в буфер и уже не будет отброшен никогда, даже если регион исчерпал все лимиты. Объём свободной памяти уменьшается на размер пакета.
Это происходит для каждого приходящего на чип пакета.
Написанное выше об Admission Control и Alpha может быть справедливо не только для Shared Buffers, но и для других архитектур, например, VoQ.
Output Queueing
Input Queuing
Более удачным вариантом оказывается буферизировать пакеты на входной плате после лукапа, когда уже становится понятно, куда пакет слать. Если выходной интерфейс заведомо занят, то и смысла гнать камикадзе на фабрику нет.
Постойте! Как же входной чип узнает, что выходной интерфейс не занят?
Combined Input and Output Queueing
Кроме того, для обеспечения QoS придётся хоть какой-то минимум его функций реализовывать в двух местах, что опять же скажется на цене продукта.
Представьте себе ситуацию: однополосная дорога, перекрёсток, машине нужно повернуть налево, сквозь встречный поток. Она останавливается, и ждёт, когда появится окно для поворота. А за ней стоит 17 машин, которым нужно проехать прямо. Им не мешает встречный поток, но им мешает машина, которая хочет повернуть налево.
Трагическая история, как в реальной жизни, так и на сетевом оборудовании.
Virtual Output Queueing
Ровно то же самое сделали разработчики сетевого оборудования.
Они взяли входной буфер побольше и подробили его на множество очередей.
Для каждого выходного интерфейса они создали по 8 очередей на каждом чипе коммутации. То есть перенесли все задачи по обеспечению QoS на входной чип. На выходном же при этом остаётся самая базовая FIFO очередь, в которой никогда не будет заторов, потому что их контроль взял на себя входной чип.
Если взять, грубо говоря, коробку со 100 интерфейсами, то на каждой плате в буферах нужно будет выделить 800 очередей. Если в коробке всего 10 линейных карт, то общее число очередей на ней будет 100*8*10 = 8000.
На сегодняшний день подавляющее большинство модульных сетевых устройств используют архитектуру VOQ.
Shallow vs Deep Buffers
Чуть позже мы поговорим о том, что такое хорошо, а что такое плохо. А пока посмотрим на реализации.
Такие буферы порой даже называют Extremely shallow buffers.
Очевидно, что не для всех задач такие маленькие буферы подходят. В частности, модульные коробки с VOQ явно не могут позволить себе дробить 64 Мб на несколько тысяч очередей (на самом деле могут).
Как такая память реализована зависит уже от чипа и коробки.
Например, Broadcom Jericho+ сгружает пакеты во внешнюю память в размере 4ГБ. Это обычная широко известная GDDR5, использующаяся в видеокартах.
А вот и фото Jericho2:
Фото чипа ZX EXPRESS:
А вот так выглядит сетевой процессор Cisco с внешней памятью:
Кастомный джуниперовский HMC обещает 1,25 Тб/с в обоих направлениях.
Если верить вики, то HBM 2-го поколения, используемый в последнем чипе Broadcom Jericho2, выдаёт порядка 2Тб/с.
Но это всё ещё далеко от реальной производительности сетевого ASIC. Фактически, шины до этой внешней памяти является узким местом, которое и определяет производительность чипа.
Hybrid Buffering
Данный параграф отменяет сказанное выше о том, что on-chip памяти не хватит для VOQ. Фактически, в случае гибридной буферизации она всё же дробится на тысячи очередей очень маленькой длины, чтобы обеспечить VOQ. Просто в нормальных условиях этой длины хватает, чтобы пропускать трафик мимо внешней памяти. При этом, в первую очередь начнёт офлоадиться на внешнюю память массивный трафик, идущий в низкоприоритетных очередях, а требовательный к задержками будет по-прежнему пролетать фаст-пасом.
В целом, это довольно старая дилемма. Подольше похранить или пораньше дропнуть?
Проект www.bufferbloat.net иронично определил этот термин, как «ухудшение производительности Интернета, вызванное предыдущими попытками её улучшения».
Особая история на границе датацентра (или на устройствах доступа в сети провайдера или на магистральных сетях).
Во-первых, это места, которые обычно заведомо строятся с переподпиской, поскольку WAN-линки дорогие, что автоматически означает, что ситуации, в которых трафика приходит больше, чем способен переварить интерфейс, ожидаемы. А значит нужна возможность пакеты хранить и обрабатывать их в соответствии с приоритетами. Большие буферы позволяют сгладить всплески.
Во-вторых, обычно приложения настолько чувствительные к задержкам, никто не будет пытаться растягивать на этот сегмент. Например, RoCE или распределённое хранилище. Для чуть менее чувствительных, таких как телефония, в больших буферах выделяется приоритетная очередь.
В-третьих, тут задержки на устройстве всё ещё делают основной вклад в общее время доставки, но уже не настолько драматический.
Итак, устройства с большим объёмом памяти годятся в места где заложена переподписка или могут появиться заторы.
Storage. Это штука крайне чувствительная к потерям и тоже гоняющая массивные объёмы данных. В случае хранилки тоже лучше не терять ничего. Но обычно она при этом и к задержкам предъявляет строгие требования, поэтому такие приложения обсудим пониже.
Однако, при этом крайне редко они единственные потребители сети в датацентрах, другим приложениям нужна низкая задержка.
Впрочем, это легко решается выделением очередей QoS с ограничением максимальной доступной глубины. И весь вопрос заключается тогда только в том, готова ли компания заплатить за глубокие буферы, возможно, не использовать их и поддерживать конфигурацию QoS.
Кстати, показательная таблица типичных задержек:
Low-latency lossless сети
Так что же можно сделать? На самом деле, как я уже говорил выше, условия сети датацентра хороши тем, что информация о перегрузке очень быстро доносится до отправителей. Поэтому и реакция на потерянный пакет не заставит себя долго ждать.
ECN-Based
Транзитное устройство, готовящееся испытать перегрузку, явным образом сообщает отправителям о том, что нужно охладить свою страсть.
Надолго забытый механизм сегодня извлекают из ящика стола, сдувают с него пыль, и вставляют в шкатулку, на которой нацарапано или DCTCP.
Транзитное устройство при заполнении буфера больше, чем до определённого порога, выставляет в заголовках IP обрабатываемых пакетов бит CE (Congestion Encountered) и отправляет пакет дальше.
Получатель, увидев в пришедшем пакете этот флаг, сообщает отправителю о перегрузке, и о том, что нужно снизить скорость.
Классический TCP может обнаружить только уже существующую перегрузку, а DCTCP, используя ECN, узнаёт о том, что она только приближается, и пробует её избежать.
Есть и другие реализации TCP, поддерживающие ECN, например, HTCP.
Нюанс с ECN-based Congestion Control механизмами в том, что до поры до времени они ничего не знают о надвигающейся перегрузке, а потом должен пройти ещё целый RTT, чтобы отправитель узнал, что какое-то транзитное устройство к ней близко. К тому времени, как отправители начнут снижать скорость, перегрузка уже может или рассосаться или наоборот дойти до уровня, когда начнутся дропы.
Bandwidth-Delay Product Based
Другие реализации замеряют эффективную полосу сети совместно с RTT, то есть сколько можно ещё напихать в трубу до того, как это создаст затор и увеличит задержку.
Примерами таких протоколов являются BBR и H-TCP.
RTT-BASED
В конце концов есть элегантные механизмы, которые замеряют время прохода трафика туда-обратно. Идея провальная для MAN/WAN-сегментов, и, честно говоря, при попытке программной вычисления RTT тоже. TIMELY от Google с аппаратным offload»ом вычисления RTT один из наиболее удачных примеров.
На самом деле, если бы не видео с прекрасной девушкой, рассказывающей про технические детали TIMELY, не знаю даже стал ли бы я упоминать про него. Наслаждайтесь, но берегите уши: TIMELY: RTT-based Congestion Control for the Datacenter.
Полезные ссылки
Заключение
Что такое сетевая буферизация
Новая неделя – и снова с вами мы! С прошлой недели наше сообщество серьезно выросло в размерах, и мы рады видеть новых игроков из Латинской Америки, Бразилии и Кореи в закрытой бете! Добро пожаловать! И раз уж вы начали играть в VALORANT, значит, у вас, наверное, полным-полно вопросов, и сегодня мы на них ответим.
Постараемся обойтись без длинных преамбул, ведь нам предстоит обсудить три большие темы. Первая тема – преимущество нападающего – очень важна для нас. Речь идет о том моменте, когда противник выбегает на вас из-за угла и, кажется, ведет стрельбу без потерь в точности. Об этом с вами поговорит Дэвид Стрейли, руководитель технического отдела.
Всем привет! Давайте же начнем.
Пока человечество не найдет способ двигаться быстрее скорости света, преимущество нападающего никуда не пропадет. Оно так или иначе присутствует во всех играх. Но наша цель – снизить его значимость в VALORANT. С философской точки зрения, чем меньше преимущество нападающего, тем большую тактическую глубину обретает мета игры.
Как его измерить?
Некоторые из этих переменных постоянны:
ИНТЕРПОЛЯЦИОННАЯ ЗАДЕРЖКА СЕТИ = 7,8125 мс (это «буферизация», которая позволяет сгладить позиционирование противников на экране; данный параметр можно изменить в меню настроек «Сетевая буферизация», если у вас низкая скорость подключения к сети).
ЧАСТОТА ОБНОВЛЕНИЯ СЕРВЕРА = 7,8125мс (1/128 сек. на серверах с тикрейтом 128).
СЕТЕВАЯ ЗАДЕРЖКА ДО СЕРВЕРА В ОДНУ СТОРОНУ зависит от расположения сервера, географического расположения вашего компьютера (или компьютера противника), а также путей маршрутизации Riot Direct. В долгосрочной перспективе, мы надеемся, что она не будет превышать 17,5 мс для 70% игроков. Мы пользуемся закрытой бетой для тестирования и улучшения игры, и хотя мы далеки от целевых показателей, мы видим постепенный прогресс.
ЧАСТОТА КАДРОВ КЛИЕНТА зависит от вычислительной мощности вашего компьютера; наша команда разработчиков, в свою очередь, старается оптимизировать частоту обновления серверов.
Сумма всех вышеуказанных значений равна преимуществу игрока, который нападает на вас из-за угла. Это то время, в течение которого игрок видит вас, пока вы еще не видите его.
Среднестатистическая скорость человеческой реакции – 247 мс, и это не шутка. В среднем преимущество нападающего в VALORANT составляет 40-70 мс, но даже такое время дает игроку значительную фору.
Вы наверняка сталкивались с ситуацией, когда противник убивал вас на бегу. На самом деле, с точки зрения противника и алгоритмов сервера, он стоял на месте.
Мы, разработчики, уже знаем об этой проблеме и ищем способы ее решения.
Для начала немного углубимся в вопрос.
Сетевая интерполяционная задержка (см. мой комментарий в прошлом разделе) вызывает рассинхронизацию между данными о передвижении и данными о получении урона продолжительностью в 7,8125 мс. Другими словами, когда вас убивают, для вас отображается позиция игрока, в которой он находился 7,8125 мс назад, а не та, из которой он действительно выстрелил.
Из-за этого может казаться, будто игрок двигался во время стрельбы, хотя на самом деле он стоял на месте. Эта проблема более распространена в тех случаях, когда игроки эффективно используют контр-стрейф, ведь благодаря развитым рефлексам они могут начать стрельбу спустя всего мгновение после такого выхода.
Как же разработчики собираются решить эту проблему?
А) Мы изучаем все параметры точности стрельбы в движении, пытаясь определить глубинный источник проблемы – возможность слишком быстро начинать точную стрельбу после движения или тот факт, что выстрелы в движении в некоторых случаях могут оказываться более точными, чем нам хотелось бы. Обо всех изменениях вы узнаете из описания нового патча.
B) Мы работаем над обновлением переходной анимации. Когда игроки останавливаются, нам хотелось бы ускорить процесс перехода анимации от «бега» к «статике». В данный момент анимация иногда отстает от совершаемых действий.
C) В момент вашей смерти ваш труп (обычно) заслоняет противника, из-за чего вам не видно, какие действия враг совершает сразу после вашей гибели. Мы собираемся устранить этот «трупный заслон» в ближайших патчах, чтобы вы всегда могли видеть противника. Это поможет вам определить, действительно ли он остановился в процессе движения.
E) Мы также думаем над предоставлением игрокам возможности отключать удаленную интерполяционную задержку – это избавит вас от 7,8125 мс рассинхронизации, но может вызвать появление «скачущих игроков» при потере пакетов. Средняя потеря пакетов бывает разной, но в целом она ограничивается 1-3%. В такой ситуации вы сможете наблюдать скачки в перемещении игроков раз в секунду. Это решение далеко от идеала. Мы протестируем варианты A и B (и, возможно, другие небольшие корректировки), а затем взглянем на результаты и решим, готовы ли пойти на столь радикальные меры.
Как бы нам ненароком целый роман так не написать. Ладно, переходим ко второй теме.
Да. Так, к сожалению, устроен интернет.
Если коротко, то нет. Низкий уровень задержек всегда лучше, так как ваши действия будут попадать на сервер быстрее, чем действия противника.
Единственная хитрость заключается в том, что игрок с высоким пингом усугубляет эффект преимущества нападающего для всех игроков. Но вы, как игрок с низким пингом, получаете точно такое же преимущество нападающего над игроком с высоким пингом, как и он над вами.
В целом условия равны, но удовольствия от такой игры мало. (** См. исключение в примечании ниже)
СОВЕТ: где между вами и врагами большая разница в пинге.
Играть с высоким пингом – далеко не лучший вариант, но таковы текущие обстоятельства, вызванные ограниченной численностью игроков в закрытой бете и еще не оконченным процессом создания инфраструктуры. Разработчики Riot заинтересованы в том, чтобы у всех был хороший пинг. Мы уже начали работать над усовершенствованиями, так что следите за дальнейшими новостями.
Если задержки асимметричны (то есть их уровень высок при передаче данных на сервер, но низок для потока к клиенту), то у игрок получает более ощутимое преимущество нападающего.
Этого наша команда разработчиков допустить не может. Отчасти в такой асимметрии виноваты мы (нам необходимо и дальше оптимизировать маршрутизацию до игровых серверов), а отчасти – сами игроки (те злоумышленники, что используют лаг-свитч). В будущем мы планируем заняться обоими аспектами этого вопроса.
Все еще с нами? Иан Филдинг, продакт-менеджер соревновательной команды VALORANT, обсудит с вами соревновательный режим VALORANT, а также ответит на вопрос, который, возможно, хорошо знаком команде Riot Games.
Почему в VALORANT не ограничен размер примейдов для участия в соревновательном режиме? Почему не сделать режим только для одиночек?
Для нас очень важно, чтобы соревновательный подбор игроков в VALORANT был направлен на стимулирование командной работы, ведь мы верим, что слаженное взаимодействие является важным критерием мастерства. И если у игроков есть группа друзей, с которыми они хорошо играют, то нам не хотелось бы препятствовать им и создавать ощущение, что вы можете по-настоящему испытать свои навыки только при игре в одиночку.
Если мы добавим режим только для одиночек, то он может стать главной проверкой способностей игрока и основным режимом соревновательной игры. Вместо этого мы решили дать игрокам самим определять размер своей команды. Мы также считаем важным то, что игроки уже сейчас начинают искать хороших союзников для соревновательных матчей, поскольку после выхода игры у них уже будут товарищи, на которых можно положиться.
Для тех, кто играет в одиночку или с небольшой группой, мы постарались сделать так, чтобы подбор игроков нашел вам игру со схожим размером примейда. Кроме того, во всех рангах (кроме наивысшего) работает система оценки личного уровня мастерства, которая определяет, насколько быстро должен повышаться или понижаться ваш ранг в зависимости от результативности. Таким образом, если вы играете особенно хорошо и делаете большой вклад в победу команды, то и ваш ранг будет расти быстрее.
Некоторые игроки беспокоятся, что для ускоренного повышения ранга необходимо увеличивать свой показатель KDA (соотношения убийств, смертей и содействий), однако такой подход совершенно не гарантирует победу команды.
Скажу вам прямо: победа или поражение в матче имеет наибольшее значение в определении вашего ранга. Если вы добиваетесь иной цели (к примеру, повышения показателя KDA), но проигрываете матчи, то ваш ранг будет падать.
Соревновательный режим уже в игре, но что же будет дальше?
Мы хотели поскорее запустить соревновательный подбор матчей в закрытой бете VALORANT, чтобы у нас была возможность узнать ваше мнение о режиме и начать его проработку вместе с вами. Мы получили много полезных отзывов и продолжаем активно разрабатывать изменения, которые нам необходимо внести до полноценного запуска соревновательного режима этим летом.
В краткосрочной перспективе наиболее важными пунктами в наших планах является облегчение прохождения калибровочных матчей в группе с друзьями и создание более наглядных значков рангов. В долгосрочной перспективе мы подумываем о добавлении прогресса рангов, а также ряда других предложенных вами функций. Ждите новостей в будущих выпусках!
И наконец, так как Пол Чемберлен, глава разработки античита VALORANT, так любит говорить о Vanguard, мы дали ему возможность поделиться небольшой новостью о том, как команда прислушалась к вашим отзывам.
Мы услышали отзывы игроков о том, что Vanguard слишком усердствует в обеспечении безопасности, поэтому решили несколько изменить подход к вопросу. С прошлой недели мы расширили совместимость Vanguard с другими уязвимыми приложениями. И хотя небольшое количество драйверов все еще блокируется, теперь почти все приложения, которые в прошлом конфликтовали с Vanguard, будут исправно работать, пока действует система защиты.
В будущем мы постараемся выбирать решения, которые бы минимально сказывались на функционале компьютеров, чтобы Vanguard, VALORANT и тот странный RGB-драйвер могли сосуществовать в мире и гармонии. Если же у нас это не получится, то мы скорее отключим саму игру, вместо того чтобы вмешиваться в работу других программ. Только в самых крайних случаях мы можем попытаться заблокировать работу приложения на вашем компьютере.
Мы продолжаем совершенствовать Vanguard и призываем вас делиться с нами отзывами и дальше, чтобы мы могли принимать оптимальные решения. Так что, пожалуйста, не забывайте делиться с нами своим мнением о наших мерах борьбы с читами, а мы постараемся, чтобы все (кроме читеров) остались довольны.
. В этот раз мы обойдемся без описания известных проблем, так как в статье только о них и шла речь (мы все еще активно боремся с просадками производительности клиента!). Увидимся на следующей неделе! 🙂
Анна Донлон и Джо Циглер
Исполнительный продюсер и директор игры
Анна (@RiotSuperCakes) указывает на проблемы, требующие решения, а Джо (@RiotZiegler) ищет способы решения этих проблем. Вместе они команда по. устранению проблем.