Комментарии 6
Ничего не понятно, но какой же язык прекрасный, словно LTE-Довлатова прочел
(что бы это ни значило)
В такие моменты понимаешь насколько хрупок тот мир в котором мы живём!
Круто!
Позволю себе лишь одно замечание.
Насколько я понял, когда Вы считаете джиттер для трафика в приоритетной очереди, Вы как бы отбрасываете из расчетов весь остальной трафик, как не влияющий на приоритетный трафик. Но это не совсем верно. Представьте ситуацию: на маршрутизатор прилетел длинный пакет с низким приоритетом и, так как в более приоритетных очередях в этот момент ничего не оказалось, отправился на сериализацию в выходной интерфейс. В этот момент прилетает высокоприоритетный пакет VoIP или синхронизации и... он не может немедленно отправиться на выход, так как через выходной интерфейс в это время сериализуется длинный низкоприоритетный пакет, и пока этот процесс не закончится, вынужден будет ждать в очереди. Чем больше средняя длина низкоприоритетных пакетов, дисперсия этой длины, чем выше интенсивность поступления низкоприоритетного трафика и чем тоньше выходной канал, тем больше этот эффект будет оказывать влияние на джиттер и среднюю задержку высокоприоритетного трафика. В ТМО есть формулы для расчета параметров приоритетных очередей. Они чуть сложнее приведенных в статье.
Именно для снижения этого эффекта раньше неотъемлемым атрибутом QoS на низкоскоростных каналах (<E1) являлась фрагментация - дробление пакетов низкоприоритетного трафика на короткие фрагменты.
Да, была такая мысль учесть сериализацию при расчете буферизации. Например, средний размер пакета на порту 1200Б. Если пакет уже начал передаваться, то мы попадаем в легкую неизвестность, сколько байт уже передалось и как долго еще ждать. Одно дело, если осталось передать 8Б, другое если 1100Б. Наверное, для такого случая можно взять среднее по больнице 600Б. Посчитать время сериализации 600Б пакета для 10Г линка, это 0,48мск. И подумать с какой вероятностью этот пакет вообще возникнет. Самым примитивным образом я бы сделал это так. Допустим на линке трафика 6Г, значит вероятность, что на порту что-то уже передается 60%. И вот дальше не знаю насколько законно будет время сериализации 0,48мкс умножить 0,6 (на вероятность того, что это событие вообще произойдет). Получим 0,288мкс. Соответственно, чем ниже загрузка линка, тем меньше вероятность того, что мы попадем в очередь из-за того, что порт кем-то занят и тем меньше нужно вносить поправку.
Т.е. опять же, широкий линк лучше узкого)
Профиль является дальнейшим развитием 8275.1
8275.2 Является костылем, а не развитием 8275.1. Тот же Хуавей его реализовал только в 2021 году, потому что на нормальных сетях используется 8275.1 + спутник.
Нам рассказывали, что для 8275.2 требуется:
1) Клиент и сервер находились в одном L2 домене и на пути не должно быть L3 устройств. Количество транзитных L2 устройств максимум 2-3.
2) Пакеты 8275.2 не должны передаваться по MPLS
У вас реально что-то заработало или для галочки запущено? БС лочат синхру и сколько держат?
Нет, профили 8275.2 и 8275.1 дополняют друг друга и используются в разных ситуациях. У каждого есть плюсы и минусы. Невозможно на современных сетях прогнать все по 8275.1.
В схеме R1-R2-R3-БС прекрасно отработает 1 профиль.
Добавляем в схему свич/релейку/аренду без поддержки 1 профиля R1-R2-РРЛ-R3-аренда-БС - и праздник заканчивается. Между R2 и R3, а также R3 и БС 1 профиль никак не пролезет.
Чтобы решить эту проблему придумали 2 профиль. Ничего не мешает на R2 по Eth пригнать 1 профиль, а на выходные порты выдать 2 профиль по IP, которому до промежуточной трансмиссии дела нет. На Boundary Clock источник и получатель синхронизации между собой не связаны никакими протоколами и условностями (ну кроме того, что если порт в режиме Slave/Master, то он может работать только на одном профиле). И тогда схема будет.
R1---G.8275.1---R2---G.8275.2---R3---G.8275.2---БС
Дополнить 2 профиль QoS'ом, правильным шейпером и он пролезет практически везде (ну кроме аренды) с приемлемым качеством.
Если говорить о том, что было описано в статье, то реализована схема условно
R1---G.8275.2 ATR---БС
Т.е. мы всю сеть представили в виде аренды и вперед считать джиттер.
Фактически G.8275.2 может работать точно также, как G.8275.1, передавая фазу между двумя соседними железками. А может в режиме ATR (adaptive time recovery) - это когда по дороге есть хоть одна железка, которая не поддерживает PTPv2. По сути 1 и 2 профиль это просто транспортный заголовок для PTPv2. Железка анализирует содержимое PTPv2, а не Eth- или IP.
Плюсом 1 профиля, например, можно назвать возможность корректно работать в лагах, чтобы избегать разности в задержках на линках разной длины.
Все что вам рассказывали - правда. Так в стандарте написано. Но рассказали не все. Вот про режим ATR вам не рассказали, а он как раз чтобы пригнать фазу, если из подручных материалов есть только мох и шишки) В т.ч. через MPLS. Статья собственно о том, как прогнать фазу через MPLS и почему это может заработать. Или не заработать.
Ну а касаемо заработало или нет - заработало. Базы лочатся, абоненты интернет качают и далее по списку. Другое дело, что это все не от хорошей жизни. В хорошей будет 8275.1 в связке с ATR
Как запустить LTE TDD, когда инфраструктуры нет, но очень хочется?