Titanfall 2

[Sanliam 0]

Разбнжался XD

Хочу верить.

[greyjedi 0]

btw

Давно обратил внимание на то, что режимы раскиданы по двум экранам, хотя на первом экране 80% свободного места, а на втором все 95%.

Однако даже на главном экране большинство режимов в некоторое время пустуют. Утром по российскому времени реально найти матч только в истреблении, очень редко в охотой за наградой и пилотах против пилотов. В остальные режимы можно не заходить. И это на царской консоли.

[Kuzaurus 134]

@Sanliam, прекрасный отзыв 

[faxit 0]

Давно обратил внимание на то, что режимы раскиданы по двум экранам, хотя на первом экране 80% свободного места, а на втором все 95%.

Однако даже на главном экране большинство режимов в некоторое время пустуют. Утром по российскому времени реально найти матч только в истреблении, очень редко в охотой за наградой и пилотах против пилотов. В остальные режимы можно не заходить. И это на царской консоли.

хуан чтоль царская консоль?) норм шутканул

[Vetal17 0]

Пацантрэ, а почему на карте 24/7 Angel city текстуры низкого разрешения ? (PS4)

[Juhani 0]

Пацантрэ, а почему на карте 24/7 Angel city текстуры низкого разрешения ? (PS4)

Потому что игра использует облака майкрософт и майки строят козни пс4. 

Вчера, играя с корешами, они тоже замечали эту вещь. 

[Vetal17 0]

Потому что игра использует облака майкрософт и майки строят козни пс4. 

Вчера, играя с корешами, они тоже замечали эту вещь. 

кек. А вообще странная фигня, текстуры как на X360. Может спецом сделали, в классическом стиле.

[zanswer 0]

@Juhani, кстати насчёт облаков, уже не только Microsoft. :(

 

Они и свои сделали, в итоге на форуме полно жалоб на высокий пинг, да я и сам его наблюдаю переодически. :(

[Vetal17 0]

 

в итоге на форуме полно жалоб на высокий пинг, да я и сам его наблюдаю переодически. :(

Высокий пинг ? О_о И это с показом значения пинга и возможностью выбора сервера ? Тогда ты не видел CoD: Infinite Warfare 

[zanswer 0]

@Vetal17, у меня до ближайшего сервера в Германии, 87 мс, если верить меню, ~100 мс в игре в среднем, но иногда ~200/300 мс, а есть те у кого средний пинг ~5 мс, а иногда ~200/300 мс. Хотя для них и 100 мс это уже заоблачный пинг.

[Juhani 0]

@Vetal17, у меня до ближайшего сервера в Германии, 87 мс, если верить меню, ~100 мс в игре в среднем, но иногда ~200/300 мс, а есть те у кого средний пинг ~5 мс, а иногда ~200/300 мс. Хотя для них и 100 мс это уже заоблачный пинг.

У меня тоже 100 мс. Но это норма для меня, учитывая, что живу я на краю мира и дальше только обрыв, а там вода и бесконечная снежная пустыня. 

[Vetal17 0]

@zanswer, @Juhani, в сетевых настройках консоли MTU понижайте, поможет ;)

[zanswer 0]

@Vetal17, Xbox One использует Path MTU Discovery, чего вы хотите добиться понижением MTU?

[Vetal17 0]

@zanswer, если пинг высокий, MTU помогает сократить лаг за счет уменьшения размера основного пакета. 

[yanfel18 2]

@zanswer, @Juhani, в сетевых настройках консоли MTU понижайте, поможет ;)

 

как это делается?

[zanswer 0]

@Vetal17, исключая факт возможной фрагментации, не вижу причин для уменьшения латентности.

 

Важно помнить, что Layer 4 модели OSI отвечает именно за сегментацию PDU, то есть PDU вышестоящего уровня может быть значительно больше Layer 3 MTU.

 

Но, существует определённая зависимость между размером пакета и количеством пакетов которое может обработать промежуточное устройство. Чем меньше пакет, тем больше пакетов нужно для передачи одного и того же объёма, тем выше нагрузка на промежуточные устройства.

 

Но, на самом деле, мы сейчас говорим о использовании UDP, это 18 байт Ethernet заголовок + 20 байт IP заголовок + 8 байт UDP заголовок + наш Layer 5-7 PDU. Какого размера наш Layer 5-7 PDU?

 

Вот к примеру мой MTU 1400 байт, из него вычтем 28 байт, это наши IP и UDP заголовки, получим 1372 байта под Layer 5-7 PDU. Если он будет меньше этого значения, значит фрагментация не случится, при условии, что на пути не окажется участков с меньшим MTU, что мало реально.

 

Если больше, то Xbox One автоматически сегментирует PDU на несколько пакетов, что опять же избавит нас от проблемы фрагментации.

 

А теперь представим, что мы снизили MTU ещё ниже, значит, мы увеличили накладные расходы на заголовки, это раз, второе повысили нагрузку на промежуточные узлы, третье сервер на той стоооне, всё равно не сможет обработать нашу команду, пока не получит весь набор данных, который раньше был в одном пакете, а теперь в трёх. То есть наши данные будут находиться в его буфере, а значит задержка не куда не денется.

 

А ещё важно не забыть из чего складывается задержка: задержка выполнения сетевого кода игры + задержка пакетизации + задержка в очереди + задержка серилизации + задержка распространения сигнала в физической среде + задержка устранения дрожания при получении. И это заметьте ещё не учтена задержка на каждом промежуточном устройстве и устройстве получателе.

 

И так мы снова отравляем наши данные, за один пакет мы получаем выше описанное единожды, сервер сразу может обработать нашу команду, а теперь за два пакета, значит применим выше описанное к каждому пакету и не забудем, что сервер не выполнит команду пока не получит команду полностью.

 

Но, я готов поспорить, что средний пакет сетевой игры менее 1372 байт и даже при сломанном PMTUD он не подвергнется фрагментации.

 

Не очень стройно получилось, но, пишу с телефона, поэтому не удобно следить за повествованием полноценно.

 

К слову, чтобы было понятно всем раз и на всегда, установка Layer 3 MTU, а именно его обычно и настраивают, требуется только для:

 

1) Отсутствия возможности выполнить Path MTU Discovery, его выполняют все ОС.

2) Если мы используем туннельный интерфейс с шифрованием, например GRE over IPsec. Мы можем и тут использовать PMTUD, но, лучше выполнить настройку вручную, мы точно знаем, сколько у нас уйдёт на накладные расходы, заголовки туннельных протоколов.

3) У нас используется один из протоколов семейства PPP: PPTP, L2TP, PPPoE и тд., да, они все умеют передавать на этапе согласования параметров через LCP протокол данные о MTU/MRU, но не все реализации это делают, поэтому опять же, мы можем использовать PMTUD или настройку в ручную.

4) Мы точно знаем, что промежуточный узел не отправляет ICMP type 3 code 4 needed fragmentation сообщение, а MTU ниже чем установлено на нашем интерфейсе.

 

В ином случае, это обезьяний труд, вы можете наслаждаться игрой с MTU долго и нудно, но поверьте, если ваш пакет попадёт на process level, вместо interrupt level на промежуточном маршрутизаторе, то задержка возрастёт многократно, а сделать вы с этим нечего не сможете и таких примеров настолько много, что я пожалуй закончу. :)

[Kuzaurus 134]

Кто прочитает весь текст выше, готов поставить бутылку водки. 

[zanswer 0]

@Kuzaurus, терпи бро, сейчас будет совсем жёстко, не люблю быть голословным, поэтому я покажу всё так, как есть, в рамках реального сетевого обмена между двумя узлами в сети.

 

P/S/ Ребят, модераторы, я постараюсь очень кратко показать, что происходит на самом деле при сетевом обмене, при разности MTU, думаю это всем будет полезно, обещаю, что сделаю всё в рамках одного сообщения.

[Runer1990 0]

@Vetal17, исключая факт возможной фрагментации, не вижу причин для уменьшения латентности.

 

Важно помнить, что Layer 4 модели OSI отвечает именно за сегментацию PDU, то есть PDU вышестоящего уровня может быть значительно больше Layer 3 MTU.

 

Но, существует определённая зависимость между размером пакета и количеством пакетов которое может обработать промежуточное устройство. Чем меньше пакет, тем больше пакетов нужно для передачи одного и того же объёма, тем выше нагрузка на промежуточные устройства.

 

Но, на самом деле, мы сейчас говорим о использовании UDP, это 18 байт Ethernet заголовок + 20 байт IP заголовок + 8 байт UDP заголовок + наш Layer 5-7 PDU. Какого размера наш Layer 5-7 PDU?

 

Вот к примеру мой MTU 1400 байт, из него вычтем 28 байт, это наши IP и UDP заголовки, получим 1372 байта под Layer 5-7 PDU. Если он будет меньше этого значения, значит фрагментация не случится, при условии, что на пути не окажется участков с меньшим MTU, что мало реально.

 

Если больше, то Xbox One автоматически сегментирует PDU на несколько пакетов, что опять же избавит нас от проблемы фрагментации.

 

А теперь представим, что мы снизили MTU ещё ниже, значит, мы увеличили накладные расходы на заголовки, это раз, второе повысили нагрузку на промежуточные узлы, третье сервер на той стоооне, всё равно не сможет обработать нашу команду, пока не получит весь набор данных, который раньше был в одном пакете, а теперь в трёх. То есть наши данные будут находиться в его буфере, а значит задержка не куда не денется.

 

А ещё важно не забыть из чего складывается задержка: задержка выполнения сетевого кода игры + задержка пакетизации + задержка в очереди + задержка серилизации + задержка распространения сигнала в физической среде + задержка устранения дрожания при получении. И это заметьте ещё не учтена задержка на каждом промежуточном устройстве и устройстве получателе.

 

И так мы снова отравляем наши данные, за один пакет мы получаем выше описанное единожды, сервер сразу может обработать нашу команду, а теперь за два пакета, значит применим выше описанное к каждому пакету и не забудем, что сервер не выполнит команду пока не получит команду полностью.

 

Но, я готов поспорить, что средний пакет сетевой игры менее 1372 байт и даже при сломанном PMTUD он не подвергнется фрагментации.

 

Не очень стройно получилось, но, пишу с телефона, поэтому не удобно следить за повествованием полноценно.

 

К слову, чтобы было понятно всем раз и на всегда, установка Layer 3 MTU, а именно его обычно и настраивают, требуется только для:

 

1) Отсутствия возможности выполнить Path MTU Discovery, его выполняют все ОС.

2) Если мы используем туннельный интерфейс с шифрованием, например GRE over IPsec. Мы можем и тут использовать PMTUD, но, лучше выполнить настройку вручную, мы точно знаем, сколько у нас уйдёт на накладные расходы, заголовки туннельных протоколов.

3) У нас используется один из протоколов семейства PPP: PPTP, L2TP, PPPoE и тд., да, они все умеют передавать на этапе согласования параметров через LCP протокол данные о MTU/MRU, но не все реализации это делают, поэтому опять же, мы можем использовать PMTUD или настройку в ручную.

4) Мы точно знаем, что промежуточный узел не отправляет ICMP type 3 code 4 needed fragmentation сообщение, а MTU ниже чем установлено на нашем интерфейсе.

 

В ином случае, это обезьяний труд, вы можете наслаждаться игрой с MTU долго и нудно, но поверьте, если ваш пакет попадёт на process level, вместо interrupt level на промежуточном маршрутизаторе, то задержка возрастёт многократно, а сделать вы с этим нечего не сможете и таких примеров настолько много, что я пожалуй закончу. :)

полезная инфа.

[Vetal17 0]

@zanswer, норм расписал, но в чем проблема попробовать изменить значение ? Пару матчей если только просрать, если не поможет.

[zanswer 0]

И так мы располагаем вот такой топологией: 

 

https://www.dropbox.com/s/aup6pr96mae5msz/Screen%20Shot%202017-01-21%20at%206.48.20%20PM.jpg?dl=0

 

Наш VPC01 будет направлять пакеты в сторону VPC02, замерим время передачи, в зависимости от размера пакета и посмотрим, как работает Path MTU Discovery.

 

VPC01#ping ip 192.168.2.1 size 1400 repeat 1 - размер пакета 1400 байт, максимальный MTU нашего канала.
Type escape sequence to abort.
Sending 1, 1400-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 2/2/2 ms

VPC01#ping ip 192.168.2.1 size 1200 repeat 1 размер пакета 1200 байт, меньше MTU нашего канала.
Type escape sequence to abort.
Sending 1, 1200-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 2/2/2 ms

VPC01#ping ip 192.168.2.1 size 100 repeat 1 - размер пакета 100 байт, невероятно низкий MTU, ниже нашего канала.
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 2/2/2 m

 

 

Время затраченное не коммутацию пакета, не изменилось, вопрос почему? Ответ, потому, что промежуточному устройству совершенно всё равно какого размера наш пакет, если он меньше установленного MTU, то есть пакет не попадает на process level, поскольку пакет один, то мы не можем наблюдать воздействие на промежуточное устройство в зависимости от размера пакета.
 

Frame 271: 1464 bytes on wire (11712 bits), 1464 bytes captured (11712 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:04:00 (aa:bb:cc:00:04:00), Dst: aa:bb:cc:00:01:00 (aa:bb:cc:00:01:00)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.2.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 1450
    Identification: 0x0020 (32)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (1)
    Header checksum: 0xf1df [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.1.1
    Destination: 192.168.2.1
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xd42d [correct]
    [Checksum Status: Good]
    Identifier (BE): 16 (0x0010)
    Identifier (LE): 4096 (0x1000)
    Sequence number (BE): 0 (0x0000)
    Sequence number (LE): 0 (0x0000)
    [No response seen]
    Data (1422 bytes)

 

В данном случае я направил стандартный ICMP type 8 пакет, размером 1450 байт, обратите внимание на поле Flags, именно оно отвечает за флаг предотвращающий фрагментацию пакета, в случае, если он превышает размер MTU вышестоящего интерфейса.

 

Frame 272: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
Ethernet II, Src: aa:bb:cc:00:01:00 (aa:bb:cc:00:01:00), Dst: aa:bb:cc:00:04:00 (aa:bb:cc:00:04:00)
Internet Protocol Version 4, Src: 192.168.1.254, Dst: 192.168.1.1
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 56
    Identification: 0x0249 (585)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (1)
    Header checksum: 0x352c [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.1.254
    Destination: 192.168.1.1
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 4 (Fragmentation needed)
    Checksum: 0x1b46 [correct]
    [Checksum Status: Good]
    Unused: 0000
    MTU of next hop: 1400
    Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.2.1
    Internet Control Message Protocol

 

В ответ я получаю стандартный пакет ICMP type 3 code 4 который сообщает мне, что я должен использовать MTU не более 1400 байт, обратите на поле MTU of next hop, да дамы и господа, именно так и работает Ptah MTU Discovery, в общем случае.

 

Именно по этой самой причине, Xbox One, не отправляет пакет размером больше, чем установленное в ходе проверки MTU канала и так делает любая современная ОС-и.

 

Да, в реальной, большой сети, где через устройство проходит миллионы пакетов, их размер, установленные опции и многое-многое другое, будет в значительной степени влиять на задержки, но MTU далеко не определяющая проблема, учитывая, что для решения проблемы разности MTU в канале, существует Ptah MTU Discovery Protocol, проиллюстрированный выше.

 

И нет, вы не можете влиять даже на 10% того, что происходит с пакетом по пути от интерфейса Xbox One до интерфейса сервера Titanfall.

А там может быть асимметричная маршрутизация, джиттер, из-за попадания пакетов в разные QoS очереди, перегруженный канал, не эффективно настроенный маршрутизатор, который выполняет коммутацию пакетов не аппаратно, а программно. Всё, что в ваших силах, это канал от Xbox One до вашего провайдера, то есть включая ваш маршрутизатор, который может быть перегружен, настроен так, что Xbox One выбирает 802.11g протокол, а не 802.11n и так далее.

@Vetal17, вы вольны делать со своей консолью, всё, что только хотите, для экспериментов, в этом нет нечего плохого.

Я лишь указал не теорию сетей, которая настолько объёмная и сложная, что я затрудняюсь описать все возможные причины влияния на задержки в канале. Просто MTU часто упоминают, как волшебное средство, чтобы всё стало хорошо, в том числе и производители SOHO устройств, D-Link, TP-Link и прочие, предлагая выполнить ping -f -l 1500 8.8.8.8 и уменьшать значение, пока пакеты не пойдут, а потом настраивать свой интерфейс компьютера.

Этого делать не нужно, кроме описанных выше случаев, Ptah MTU Discovery Protocol был описан в RFC 1191 в 1990 году! Вдумайтесь только в это, в 1990 году уже знали о этой проблеме и успешно её решили, с оговорками выше.

Изменено 21 января 2017 пользователем zanswer

[gr1bok 0]

@zanswer,

[Losidze 0]

@zanswer, Реально чётко всё по полочкам разложил, приятно читать.

[Kabanchzzz 0]

Кто прочитает весь текст выше, готов поставить бутылку водки. 

[un1x0d 0]

Не, в это ДНО можно играть только или в компанию, или с друзьями сквозь зубы.

 

Насколько надо быть дибилом разработчиком, чтобы в пилотах против пилотах допустить возможность расстрела на респауне. Вчера загружаюсь в игру уже идущую, появляюсь .... и сразу умираю от дробовика со спины. Появляюсь опять и опять умираю от того же чувака с дробовиком на том же месте. И вся игра пилотов против пилотов на этом строится. Увидел красный квадратик респауна. Прискакал туда, поставил турель и тупо расстреливаешь на респауне народ. Особенно эта тактика действует на картах кишках.

 

Разработчики - вы просто дибилы клинические.