Заметил что при разном размере MTU, при игре в онлайн игру (overwatch) отзывчивость игры разная.
Компьютер (сетевая карта intel) подключается напрямую к оборудованию провайдера т.е. роутера нет.
Был тариф 100Мб, сейчас тариф 300Мб зависимость от MTU не изменилась.
При "стандартном" MTU равном 1500 отзывчивость в игре меняется, как правило в зависимости от времени суток. Я пробовал ставить разный пакет MTU. При изменении от 800 до 1500 с шагом 100, разницы не заметно. От 1400 до 1500 менял с шагом 10 - тоже нет разницы.
Но вот при установке MTU больших размеров есть заметное улучшение отзывчивости.
Проверял неоднократно, стоит скажем 1500 и в игре ощущается некая ватная отзывчивость, ставлю MTU 4000 и отзывчивость становится лучше. Также ставил 8000 и тоже было лучше.
Но если поставить 3000 то в игре начинаются заметные фризы, персонажи иногда начинают двигаться рывками, тоже самое при MTU = 6000.
Вопрос такой - если большой размер MTU, то мелкие пакеты UDP, могут объединяться в один?
Смысл такой - при небольшом размере MTU игра шлет пакет UDP "стандартной" длины, часть из них может теряться или буферизироваться. А если размер MTU большой, то игра в один большой пакет сует сразу несколько мелких пакетов, в результате они приходят одновременно, а не с задержками из-за потерь или буферизации.
Василий Смирнов, а PMTUD [?] ты не производил?
Если эта строчка - это единственное что ты делал, то для интернета она имеет лишь эффект плацебо. Буквально, тебе только казалось что отзывчивость была выше. Дергание персонажей является результатом методики Traffic shaping [?], первичными симптомами которого может являться такая мнимая отзывчивость.
Ничего обещать не могу, но если найду время, то напишу более развернутые объяснения.
адрес одного из серверов близард 5.42.170.252
с некоторого узла сети близард ответ на ping перестает проходить от всех нижележащих узлов.
Несмотря на то что 1473 максимальный размер MTU, и сеть и игра замечательно работают и с большими (судя по всему фрагментироваными) пакетами.
эффект плацебо. Буквально, тебе только казалось что отзывчивость была выше.
нет исключено.
слишком много перепроверял.
ставлю 3000 и в игре сильные фризы.
ставлю 4000 (точнее 4096) - все быстро и гладко.
также стоит 1450 в игре чувствую ватность. Это очень очень хаорошо чувствуется на том пересонаже на котором я играю. Один из моментов - высунутся с развернутым прицелом, моментально выстрелить по голове злодея и тутже сбросив зуум прицела, спрятаться.
Если все хорошо то этот прием проделывается быстро, и противник даже если я не попал в хед не успевает сделать ответный выстрел или делает его после того как я прячусь за угол. Если же есть ватность то все это происходит меедленно и противник спокойно убивает меня в голову.
Ставлю 4096 и отзывчивость улучшается очень заметно, хоть и не идеально.
Поэтому я и хочу понять причину.
Василий Смирнов, ты можешь со мной не соглашаться. Выбор, все-таки, за тобой. Я говорю со стороны своего опыта, как разработчик онлайн проектов и ММО проектов в частности.
Качественный MTU в 1472Б ты посчитал правильно. Именно таким на маршрутах средний MTU и является. Выше этого значения MTU для себя ставить неразумно. С одной стороны это неразумно потому что игры далеко не дураки пишут. Для нас при работе с UDP протоколом очень важно определить MTU маршрута пользователя чтобы пакеты всегда шли атомарными и их доставка терпела как можно меньше накладных расходов. Мы самостоятельно определяем MTU для UDP и принципиально не шлем датаграммы больше этого размера. Поэтому твои пляски с локальными настройками для игры ничего не значат.
С другой стороны для твоего большого MTU на маршруте уготовано два сюрприза: Traffic Shaping [?] и IP Fragmentation [?]. Но об этом я, пожалуй, лучше полноценно напишу в ответе.
Третьим является то, что обозначенную тобой "отзывчивость" ты наблюдаешь на канале от сервера к тебе и твой MTU абсолютно никакой роли в этом месте не играет.
Евгений, спасибо большое за обстоятельные и главное информативные ответы.
Я бы сам не поверил, и понимаю что звучит это как бред, но тем не менее как говорится - не верь глазам своим - эффект есть и он чувствуется.
Вы пишите что определяете MTU маршрута, может быть Близард не такие дотошные...
Я когда игрался с размером MTU то ставил в районе 700. При этом у меня отвалился голосовой чат внутри игры. Мне было не вдомек о причине и я обращался в техподдержку близард... Все это длилось недели две гдето, пока меня не осенило...
Я это к тому что если бы близарды определяли размер пакета то сразу бы кодом ошибки сообщили о том что размер пакета слишком маленький.
Может все же как то сказывается кратность пакета...
С другой стороны для твоего большого MTU на маршруте уготовано два сюрприза: Traffic Shaping [?] и IP Fragmentation [?]
Про шейпинг я в общих чертах в курсе.
Я думаю еще должен влиять bufferbloat и кстати возможно размер пакета както влияет на буфферизацию...
MTU абсолютно никакой роли в этом месте не играет.
не должен играть... так точнее :)
Но опять же может есть суммирование или объединение нескольких пакетов UDP в один пакет большего размера, если MTU позволяет? Либо Близард определяет что MTU на компе большой и набивает его под завязку и это не смотря на фрагментацию сказывается благотворно т.к. принимающая сторона сразу принимает много мелких пакетов...
Посмотрел пакеты Wireshark.
Размер пакетов плавает.
поставил MTU 1472
Пока в игре стоял на месте, пакеты ко мне и от меня были до 100 байт.
При начале активной игры пакеты ко мне, стали доходить имея размер до 1269
от меня максимальный 188 https://habrastorage.org/webt/n9/8_/b8/n98_b8j-vcn...
Василий Смирнов, не забывай ставить упоминания. Сейчас я прочитал твои комментарии только лишь благодаря своему любопытству, потому что захотел заглянуть в вопрос. Иначе ждал бы ты моих слов аж до второго пришествия.
Близы - не дураки. Были "не дураками" когда делали Overwatch. Сейчас уже похуже. Протокол OW я неплохо знаю, там все очень качественно и MTU маршрута там определяется именно через PMTUD. Статистика из Wireshark у тебя верная. Игра крайне редко подходит к порогу MTU для UDP.
Все это длилось недели две гдето, пока меня не осенило...
Выводы неверные. При IP MTU в 700Б для UDP максимальный размер пакета будет еще меньше. Сетевой протокол OW делит датаграмму на два сегмента, в одном сегменте реализуется канал скоростной доставки данных, а в другом - канал достоверной доставки данных. Голосовой чат относится к потоку со скоростной доставкой данных с низким приоритетом. Высокоприоритетными являются потоки репликации мира. Главным же в пакете является канал достоверной доставки данных. Вот и все.
Ты просто зарезал себе ширину пропускания данных для скоростной доставки и голосовой чат просто перестал помещаться. Это не ошибка, а мера оптимизации протокола, чтобы обеспечить тебе сравнимый игровой опыт в твоих условиях.
Я думаю еще должен влиять bufferbloat и кстати возможно размер пакета както влияет на буфферизацию...
Ширина твоего сетевого канала составляет 300МБит/сек, т.е. где-то около 39321600Б/сек. Качественный MTU имеет размер 1472Б. За секунду твой канал переварит 26713 таких пакета без намека на буферизацию. Игре буквально незачем слать столько данных.
Поставишь ты MTU 4-6КБ, ничего не изменится. Разница с шириной твоего канала составляет порядки. Но игра, опять же, не будет пользоваться твоими локальными настройками, она будет руководствоваться настройками сетевого маршрута. И, опять же, не забывай про шейпинг и фрагментацию. Это - то, что уготовано твоим жирным пакетам на маршруте. Шейпинг приведет к потере данных. Фрагментация приведет к снижению скорости доставки или потере датаграммы.
Для игр типа OW буферизация является критической проблемой, поэтому на канале связи игры она всегда отключена. Пакеты всегда отправляются в сеть как только они переданы в сетевой интерфейс и читаются как только они приходят из сети. Именно это ты и видишь в статистике Wireshark.
не должен играть... так точнее :)
Нет. Точнее - это именно "абсолютно никакой роли в этом месте не играет". Свой локальный MTU можно менять только для соответствия параметрам локальной сети, на всех узлах которой он может уже быть расширенным. Для интернета тебе лучше подстроить MTU под значение твоего провайдера.
Маршрут никогда не выбирается исходя из MTU. Маршрут всегда выбирается исходя из лучших условий доставки.
Евгений Шатунов, спасибо большое за разъяснения и за очень интересную информацию по особенностям работы OW с сетью.
без намека на буферизацию. Игре буквально незачем слать столько данных.
я же не про буферизацию на моем компе, я про буферизацию на маршруте. По вечером в игре конкретный кисель - не успеваю за противниками, не попадаю резкими взамахами.
Я думаю это из-за того что по вечерам на маршруте гдето есть "узкие" места и происходит буферизация.
Маршрут всегда выбирается исходя из лучших условий доставки.
а значение MTU не входит влияет на условия?
Ведь Близард шлет не только udp, может быть большие пакеты идут по другому маршруту?
Для интернета тебе лучше подстроить MTU под значение твоего провайдера.
я так и сделал - 1472 поставил.
Есть ещё очень интересный вопрос - сколько примерно на каждом игровом сервере может одновременно крутится матчей и есть ли влияние этого на отзывчивость игры, или есть какие либо ограничения?
Василий Смирнов, все вот эти предположения дают понять что ты совсем не владеешь информацией о принципах работы компьютерных сетей и сетей телекоммуникаций. Если тебе это интересно, тебе стоит хоть немного изучить общие основы. Например.
я же не про буферизацию на моем компе, я про буферизацию на маршруте.
Буферизации на маршруте не существует. IP пакет посылается по некоторому маршруту, на котором он может потеряться по пути или прийти с искажениями. В этом случае засчитывается потеря пакета. TCP позволяет приемнику уведомить источник пакета о потере чтобы тот провел повторную отсылку. UDP потере не уведомляет вообще никак и никого. Датаграмма потерялась да и бог с ней.
Ты только представь себе это. Тут у тебя 300МБит/сек канал, а дальше каналы идут шириной уже в гигабиты и терабиты. И все вот это буферизировать на каждом узле? Лично у меня такое даже в фантазию не укладывается.
Кисель по вечерам - это издержки загрузки каналов, в результате чего твой маршрут строится далеко не оптимальным образом.
а значение MTU не входит влияет на условия?
Если у тебя нет доверия к моим словам, то лучше будет обратиться к документам по маршрутизации. Например.
сколько примерно на каждом игровом сервере может одновременно крутится матчей и есть ли влияние этого на отзывчивость игры, или есть какие либо ограничения?
Это закрытая информация. Читай что этих данных ни у кого нет и разглашены они быть не могут.
На отзывчивость игры это никак не влияет потому что сервера всегда строго балансируются и рассчитываются так, чтобы ни один игрок не чувствовал проблем с производительностью.
Такие вещи пользователей волновать не должны.
Игра вообще на пакеты не заморачивается - не её уровень. Она тупо отправляет сетевой подсистеме блок данных и говорит "пошли вон туда". А та уже сама разбирается, слать как один пакет или нашинковать на кусочки.
Игруля же должна по идее слать пакеты не больше 1500 байт.
Игра пакеты не шлет, она передает информацию по сети.
А уж как она там идет, и на какие пакеты ее делят, и каким транспортом ее отправляют - это игре не ведомо.
Вполне может оказаться что информация передается в бумажных пакетах, а в качестве транспорта используются олени в упряжке.
Отсюда вывод. Что исходные пакеты уходящие с сетевого интерфейса сервера, могут категорически не совпадать с вашими настройками протоколов. А то, что у вас заметные улучшения при настройке MTU, совпадение, и то не с частью сераерной стороны, а может быть с каким нибудь хопом на маршруте. Что бы понять, точно, почему так, надо анализировать все, игру, сервер, хопы, вплоть да среды передачи данных. Если повезёт, ответите на свой вопрос быст, нет так вообще не ответите.
Учите мат. часть гражданин.
Как минимум почитайте эту статью - https://help.keenetic.com/hc/ru/articles/214470885... . А потом заюзайте пинг с размером пакетов который вы выставляли, до игрового сервера. там все наглядно и посмотрите. Из мат. части - то если сервер не отдает сам по себе такой блок данных с необходимым объемом, то его заполняет не полезная информация, дабы размер подходил, то есть по факту за секунду времени при меньшем MTU, мы в секунде можем иметь в 1,5 раза больше полезных данных, нежели при большом. Почитайте старую книгу - компьютерные сети, модернизация и поиск неисправностей от bhv.
Сложный
