Всем привет! Меня зовут я сам прихожу Денис Вдовин, я системный архитектор в отделе мультисервисных (пакетных) сетей компании РТК-Сервис, и мне бы хотелось рассказать одну историю, которая началась с салата еще в зимние каникулы. В ней в разных пропорциях смешались ISIS, QoS, загадочный PTPv2, распределение Пуассона, теория массового обслуживания и LTE TDD, отчего она показалась мне крайне интересна и достойна публикации отдельной статьей.
Сей трактат, направленный на решение конкретной прикладной проблемы, будет довольно длинным и с каждым листом А4 сложность для понимания будет нарастать. Затрагиваются, казалось бы, совсем далекие друг от друга галактики, поэтому если вы где-то не смогли уследить за руками факира — это норма. Главное, что в конце вас ждет награда - мы научимся вычислять джиттер на обычном калькуляторе по графикам из Заббикса. Поехали.
К исходу десятого дня новогодних праздников, когда оливьешка, к слову, уже далеко не первой свежести, методично доламывала остатки нейронных связей в мозгу, замещая собой серое вещество, откуда-то из недр памяти всплыли мимолетом сказанные пару месяцев назад заказчиком слова, что у них есть сотни секторов БС LTE TDD и они не работают. Надо сказать, что на сетях заказчиков мы выполняем полный комплекс настроечных и монтажных работ: пишем HLD и LLD, готовим спецификации, монтируем и кроссируем, после чего долго и упорно, нажимая кнопки, претворяем в жизнь идеи, заложенные в дизайне. Короче, делаем сеть высокой культуры и быта «под ключ». И вот подумалось, это как это так, когда мы после нескольких десятков бессонных ночей уже почти закончили приведение сети из сотен маршрутизаторов к целевому дизайну, у нас там нестареющий MPLS, всякие FRR (которые FastReRoute), куда ж без него - BGP, на подходе сложнейший QoS, а какое-то там LTE не работает? Да что оно себе позволяет? И закипела кровь от такой несправедливости!
Что за зверь LTE TDD?
Как говорится, чтобы починить что-то неработающее, надо случайно сломать что-то работающее понять, что ж там конкретно не работает и к какому снаряду мы вообще подходим. Перво-наперво проведенный опрос свидетелей показал, что проблема действительно существует в заявленном виде. У заказчика (оператора фиксированной и мобильной связи) есть базовые станции разных поколений: 2G, 3G, 4G (LTE), которые связаны с контроллерами через таким трудом перенастраиваемую нами сеть MPLS (т. н. MBH – Mobile Backhaul – модненькое название обычной сети, по которой гоняются сервисы мобильной сети). В целом как бы все работает, но вот для предоставления 4G используется две технологии: LTE FDD и LTE TDD. С первой все хорошо, а со второй не очень. Точнее очень нехорошо. При включении базовой станции (БС) в системе управления вываливаются аварии о потере синхронизации, а на соседних БС (в т.ч. FDD) начинаются какие-то проблемы, из-за чего даже принято решение вывести сектора из эфира (а это, на минуточку, когда-то были миллионы инвестиций). Оказывается, базовые станции TDD, например, существенно дешевле своих FDDшных собратьев, но более требовательны к качеству синхронизации (это нам пока вообще ни о чем не говорит). Лучше всего синхронизируют системы спутникового позиционирования GPS/ГЛОНАСС/Baidu. Когда это дело закупалось, что GPS, что ГЛОНАСС были безлимитными и чем-то совершенно естественным и доступным в любом месте страны, как воздух, солнце и вода. Но в 2022 году средствами РЭБ сигнал был много где (но не везде) заглушен, и на бОльшей части БС LTE TDD праздник мобильного интернета закончился. И уже почти три года бОльшая часть секторов греют воздух, вместо того чтобы радовать абонентов видосиками и мемасиками, потому что на альтернативном источнике PTPv2 оно не заработало. Видимо, куда-то сюда и надо будет копать.
С предысторией немного разобрались, пора понять, что это за технологии.
Предупреждение: читателям из мобильного мира и просто с тонкой душевной организацией просьба закрыть глаза на следующие пару абзацев, чтобы ваши чувства случайно не были оскорблены неточностью терминологии или некорректным описанием принципов. Для выстраивания общей картины сказать несколько слов про ваши технологии так и так придется, не обессудьте.
LTE FDD – Frequency Division Duplex – частотное разделение.
За каждым оператором специальным органом ГКРЧ (Государственная комиссия по радиочастотам) по результатам гладиаторских боев (в формате все против всех, а нынче у кого толще кошелек) в каждом регионе присутствия закрепляется (или не закрепляется) некий спектр частот (для простоты — несущих). Правило простое: чем спектр шире, тем быстрее будет загружаться рутуб, тем счастливее будут абоненты. Поэтому за частоты борьба идет не на жизнь, а насмерть. А с трибуны за этим действом наблюдают военные, которые знают, что частота все равно останется у них :-)). Downlink и Uplink разнесены по разным частотам. Т.е. вместо одной на базу нужно две.
Чтобы было понятнее, что за страшное испытание выпало на долю коллег из мобильного мира — это сродни тому, как в пакетных сетях получить новый блок IPv4. Если не получилось (а это не получилось), то в ход идут NAT, CG-NAT, NAToverNAT, а от безысходности и IPv6. И вот, несчастные операторы сотовой связи, жонглируя этими немногочисленными несущими, пытаются с одной стороны выжать максимум с одной БС, а с другой – размазать диапазон на весь город, чтобы одна БС не мешала другой (условно говоря, БС на одной частоте должны светить в разные стороны или находиться в разных частях города). И эти частоты нужно изолировать друг друга промежутками, а это неэффективное использование ценного ресурса. А ведь еще кто-то нехороший залазит на твою частоту. А еще используются очень сложные технологии кодирования и мультиплексирования типа OFDM, из-за чего оборудование существенно дороже (правда, скорости и дальность чудо как хороши). В ход идут разные ухищрения: рефарминг (перераспределение частот между технологиями), запуск VoLTE, отключение 3G, MVNO и т. д. Ужас-ужас, в общем, как сложно, поэтому у каждого оператора есть большие отделы ПиО (планирование и оптимизация), которые в эти шахматы на ежедневной основе вынуждены играть без перерывов на выходные и обед. Так или иначе, технология FDD доминирует в мире LTE, на ней построено большинство сетей.
Как водится, есть второй способ подойти к снаряду: LTE TDD – Time Division Duplex – временное разделение.
Downlink и Uplink работают на одной частоте, но под них выделяются разные временные промежутки (таймслоты), в зависимости от регулировки которых можно получать разное соотношение upload и download, не тратя драгоценную несущую (на картинке, кстати, полоса поделена 50/50). Технология использует более простые алгоритмы модуляции, оборудование стоит дешевле, пинги больше, а главное, не очень-то распространена из-за текущих ограничений по скорости, дальности и требований к точности синхронизации (чтобы это ни значило). Из-за этого желающих ее использовать не то, чтобы вагон, а скромная маленькая тележка, в которой, как оказалось, мы путешествуем вместе с заказчиком. Вероятно, со временем к этой технологии присмотрятся более пристально, т.к. там еще есть свободные частоты.
Синхронизация — кто ты такое?
Есть в нашем мире коммутаторов и маршрутизаторов несколько вещей, которые выбиваются из стройной пакетной парадигмы, как-то отторгаются, что ли, нашим ethernet-сознанием. На мой взгляд, это мультикаст во всех его проявлениях (кроме, может, MVPN), QoS и синхронизация (а в последнее время и BGP из-за приставки MP- становится все менее уютным и ламповым) — страшно далеки они от нашей повседневной жизни, наполненной ip и mpls-заголовками.
Так или иначе, но без синхронизации в мобильных (да и во многих других, например, энергетических, финансовых, военных) сетях — никуда. Последние 15 лет пакетный транспорт вытеснял-вытеснял, да так и недовытеснил TDM, но подвинул солидно. Для этого ему пришлось научиться в синхронизацию. Как говорилось выше, можно сделать дорого и красиво, просто прикрутив к каждому потребителю/маршрутизатору по GPS-модулю (дополнительное оборачивание в консервную банку для преодоления РЭБа не предлагать!), а можно попытаться передать синхронизацию через сеть. Ведь TDM-транспорт с этим как-то же справляется? Давайте и мы попробуем разобраться, что там у нас в пакетке было придумано.
Но сначала предлагаю узнать, что бы этакого можно было засинхронизировать, и зачем это надо. Фаза, время дня, частота, амплитуда. Все это хорошо понятно радиоинженерам и любителям электроники, а для тех, кто страшно далек от этих вещей, есть вот такой жизненный пример, который я подсмотрел на каком-то форуме. Значит, примерно за месяц-два до Парада на 9 Мая начинаются мероприятия по подготовке.
Задача, надо сказать, нетривиальная. Заставить несколько тысяч человек шагать в ногу. В чем тут проблема? Поначалу каждый, чувствуя в себе личность, еще не подавленную железной волей командира, норовит шагнуть в случайный момент времени. В словах «шагом марш» без учета многозначительной паузы набирается 9 букв. Кто на какую стартанет — неизвестно. Т.е. не выровнено абсолютное время старта. Далее — этот ниже, этот выше, этому сапог жмет — длина шага у всех будет разная (т. е. кто-то будет убегать вперед, а кто-то отставать — в итоге с фазой каждого следующего шага начинаются проблемы). Ну и усиливают трескучие боли в седой голове командира проблемы с частотой шага — этот спешит, этот вразвалочку. В итоге картина ежегодно за месяц до парада вырисовывается совершенно неприглядная, и на взгляд обывателя даже катастрофическая. Но в ходе нудных и трудных ежедневных тренировок производится синхронизация всех участников, как внутри парадных коробочек, так и между ними. Общее движение всей колонны начинается в одно и то же время, далее каждый шаг начинается у всех в одно время (фаза), с одинаковой длиной (амплитуда) и происходит с одной частотой. Надеюсь, стало понятнее.
Или вот дирижер машет палочкой. Это он не просто так делает, чтобы ему потом восторженные зрители в ладошки похлопали.
Перед глазами оркестрантов — только ноты, в которых указано, какие звуки надо извлечь из инструмента. Музыкантов в яму посажено много, они громкие и никого, кроме себя, как бы эгоистично ни было, не слышат, особенно кто дудит в духовые. А вот глядя на взмахи палочки дирижера (и его выразительно говорящие глаза), можно понять, насколько усердно и с какой частотой надо лупить по струнам. В итоге тромбон и арфа, сидящие в разных частях ямы, что называется, попадают в одни и те же ноты. Такой вот кожаный тактово-амплитудный синхронизатор. Так что, если вам понравилась музыка, то 50% успеха — на дирижере. И ест свой хлеб он не зря.
Протоколы синхронизации в Ethernet и IP-сетях
Итак, на текущий момент в ходу есть несколько протоколов синхронизации: NTP (и его отпрыск для локальных сетей SNTP), 1588v2 он же PTPv2, SyncE.
Синхру можно передать на разных уровнях модели OSI: физическом, канальном, сетевом.
Есть разные потребители синхронизации, которые хотят разное и в разных комбинациях: абсолютное время (время суток), частоту, фазу (по-другому время, но не путать с абсолютным).
Наверное, первый протокол синхронизации, который появился и крайне активно используется в пакетных сетях — NTP – Network Time Protocol.
Есть сервер точного времени, у которого клиент запрашивает это самое точное время. Работает в т.ч. через сеть интернет, поэтому точность его невелика, измеряется в миллисекундах. Условно говоря, если нужно выставить часы, чтобы будильник вовремя зазвонил или в лог-файле была временная отметка — великолепное решение. Все компьютеры в мире им пользуются и никто не жалуется. Раз интернет, значит, работает поверх IP, т.е. на сетевом уровне. Фактически протокол выполняет синхронизацию абсолютного времени или времени суток. Не так давно в российском сегменте интернета были большие проблемы с NTP, отчего части вирусологов и экспертов в области международной политики, вероятно, даже пришлось переквалифицироваться в ntpлогов.
Нельзя просто так взять и закопать TDM, не взяв оттуда принцип частотной синхронизации. Сказано — сделано. Держите протокол SyncE – Synchronous Ethernet – в чистом виде косплей на частотную синхронизацию из TDM. Работает на физическом уровне.
В сети есть эталонный источник, который передает эталонную частоту. Каждая транспортная железка на пути до потребителя должна поддерживать этот протокол, имея на борту отдельный чип для обработки физического синхросигнала. И это сложность, потому что аппаратная поддержка — это затраты на оборудование. А помимо этого, у ряда вендоров возникают и лицензионные ограничения. В общем, это уже серьезный протокол за серьезные деньги, который умеет передавать только частоту. И нужно хорошо понимать, кому и зачем он нужен. Сам протокол разбирать не будем, он выходит за рамки статьи. Общая архитектура красиво изображена в википедии.
Ну и, наверное, вишенкой на нашем прекрасном торте синхронизации и вершиной инженерной мысли является стандарт IEEE 1588, второе имя ему PTP – Precision Time Protocol. Есть две версии 1 и 2. Одна старая, другая новая, они между собой несовместимы. Смотреть будем на самую молоденькую от 2008 года 1588v2 или PTPv2. Заявленная точность измеряется в наносекундах, что очень жирно и на 5-6 порядков лучше, чем у NTP. Умеет синхронизировать абсолютное время, фазу и частоту.
Мне, как человеку, у которого всю жизнь перед глазами туда-сюда мельтешат пакеты в асинхронном режиме, где задержки в буфере составляют десятки миллисекунд, решительно непонятно было, каким образом можно было заставить пакетную сеть передавать синхронизацию. Ну ладно время еще, ладно фазу, но частоту-то как, камон? В этом, наверное, и есть гениальность людей, которые все эти протоколы изобретают. Будем разбираться.
Главной особенностью PTPv2 является то, что он как кофе 3 в 1 — дешевый (не всегда), желанный и умеет сразу все — передавать абсолютное время, фазу и частоту. Сам по себе 1588v2 в живой природе себя особо не проявил. Фактически он описывает набор сигнальных сообщений, правила их обработки и математику, по которой вычисляются требуемые потребителям величины. И имя ему 1588v2 Default Profile. Это база. Просто транспорт для практических реализаций, если хотите. А уже дальше товарищи из разных отраслей народного хозяйства дополнили протокол профилями под собственные нужды: телекоммуникационный, энергетический, финансовый, военный. Профили отличаются видами транспорта (ethernet, ip), требуемой точностью, частотой отправки сигнальных сообщений, видами поддерживаемой синхронизации.
Но давайте сперва про сам 1588v2. Чтение, наверное, лучше начать вот с этой статьи.
С аппаратной точки зрения в простейшем виде это сервер, который по сути своей владеет только сакральным знанием о точном мировом времени. Где уж он его берет — от GPS, ПЗГ, ВЗГ, SDH, атомных часов или сам придумывает – значения для нас не имеет. Там есть специальные люди, которые в этом очень сильно разбираются и всю эту синхронизацию в масштабах мира поддерживают. Далее есть клиент, который умеет получать сигнал точного времени и выгодным для себя образом интерпретировать, попутно задавая серверу наводящие вопросы. С программной точки зрения это всего-навсего 2 простейших сигнальных сообщения, которые всю эту магию и колдуют:
Announce – сервер рассказывает о своих возможностях, настроенном профиле, поддерживаемых видах синхронизации, классе точности. Посылается нечасто, что-то типа Hello в других протоколах, где он описывает, что жив-здоров и свои возможности. Потребитель по этому сообщению выбирает тот сервер, который ему больше мил и люб.
Sync – сервер отправляет в сторону клиентов данные о своем времени (timestamp). А вот это уже самое главное. На основе сообщения Sync происходит синхронизация абсолютного времени (без поправки на задержку), и, что самое волшебное, частоты. Как? Разберемся чуть позже.
DelayReq и DelayResp – для того, чтобы сделать время более точным, необходимо убрать из расчетов задержку, возникающую при передаче пакетов через сеть (мы ведь помним, что все эти сообщения — это просто пакеты?). Клиент отправляет в сторону сервера сообщение DelayReq и получает в ответ с DelayResp. Ну дальше включается калькулятор, который по двум нехитрым формулам корректирует абсолютное время и фазу.
Есть и еще сообщения, но они нам не особо интересны, т. к. суть не раскрывают.
Теперь давайте в картинках разберемся, какое сообщение (Sync, DelayReq, DelayResp) на что влияет. Право, я перечитал множество статей с формулами несколько раз, но доходило крайне туго, пока не увидел у какого-то интуриста расчеты на конкретных числах.
Поехали. Одно единственное сообщение Sync самым примитивным образом корректирует абсолютное время на клиенте.
Вот так незамысловато сервер вставил в пакет Sync текущую метку своего точного времени (в примере 0 секунд), отправил пакет по сети, где он, судя по графику, летел 1 секунду. У клиента в это время была своя рандомная шкала времени. На момент прихода пакета Sync натикало 19 секунд. Клиент просто берет и покорно применяет себе время сервера, не думая ни о каких задержках.
Такс, самое простое позади, очень примерно выставили время, пусть это делу пока особо и не поможет.
Но мы же знаем, что пакет по сети летит какое-то время, накапливая все большую и большую задержку: обработка маршрутизатором (наносекунды), буферизация (миллисекунды), сериализация (время передачи в линию — от наносекунд до миллисекунд в низкоскоростных линиях типа ADSL), передача по линии (где чем длиннее линия, тем больше задержка, например на спутниковых каналах легко набегает по 200мс в одну сторону). И вот эту задержку нам бы надо компенсировать. Делается это с помощью сообщений DelayReq и DelayResp.
Клиент, ежели ему зачем-то надо (а оно не всегда так) выяснить совсем точное время, отправляет сообщение DelayReq с указанием своего абсолютного времени отправки (1 секунда). Сервер, немного подумав (неважно сколько), в ответ отправляет сообщение DelayResp, указав, что он получил это сообщение в 3 секунды по своей шкале. Клиент получает это сообщение и начинает строить в голове логическую цепочку: так, отправил я в 1 секунду, он получил в 3. Значит шло оно 3-1=2 секунды. Но мое-то время на предыдущем этапе по сообщению Sync также было выставлено с задержкой! Значит надо разделить на полопам. (3-1)/2=1 секунда. Это будет время односторонней задержки. И продолжает рассуждать: у меня на часах на момент получения DelayResp было 4 секунды, добавляем посчитанную одну секунду для коррекции и вуаля — мы с сервером полностью выровняли свое время. Сообщения Sync и Delay посылаются на постоянной основе несколько раз в секунду в зависимости от выбранного профиля.
Что тут занимательного? Время отправки и получения сообщения DelayResp ни на что не влияет, ни в каких в формулах расчета не участвует, оно просто переносит данные о метке времени. А вот сообщение DelayReq очень даже влияет. Также как и Sync. Ну и что? А то, что каналы в сервер-клиент и клиент-сервер должны быть симметричными. Зная, как вольно, бывает, обращаются в сетях с метриками или настройками прямых и обратных rsvp-туннелей, это может привести к проблемам. Зарубим себе на носу. И второе, чем меньше джиттер при доставке сообщение Sync и DelayReq, тем более точно подстраивается шкала времени клиента. Запишем и это в нашу книгу пожеланий.
А самое главное знаете что? Мы сейчас с вами увидели принцип фазовой (временной) синхронизации! Это ли не чудо? Да, вот так просто. Фазовая (временная синхронизация) — это когда на разных железках одно и то же действие начинается в один и тот же момент. А еще знаете что? Именно этот тип синхронизации так нужен для корректной работы LTE TDD (но об этом чуть ниже).
Но и это еще не все, до чего смогли додуматься эти крейзи инженеры. Ну вот казалось бы, ладно еще можно понять, когда у вас на физическом уровне в SyncE эталонная синусоида посылается с такой-то частотой, бери и по фронту синхронизируйся. Но как вы через пакеты-то это делаете??? А оно, оказывается, еще легче легкого.
У каждого девайса есть встроенный тактовый генератор, который вообще-то — уникальная неповторимая снежинка. Мало того, что частота может различаться на пару сотен герц, так еще и окружающие условия могут влиять (все как у людей). По итогу получаем, что 1 секунда на сервере гарантировано вообще не тоже самое, что на клиенте. Настало время побеждать и эту проблему.
Сообщения Sync имеют периодический характер. И вот за счет них-то и производится коррекция, а точнее — можно вычислить коэффициент, с которым часы (генератор) клиента убегает или отстает от сервера. Сервер отправляет сообщение Sync, проставив метку времени отправки 1 секунда, спустя пару секунд (в нашем примере) отправляет еще одно сообщение Sync (проставив метку 3 секунды). Клиент получает оба сообщения, видит, что первое он получил в 6 секунд, а второе в 12. Далее разницу времени отправки на сервере он делит на разницу времени получения на клиенте и получает искомый коэффициент, на который можно смело умножать время на клиенте. В нашем карикатурном случае часы на клиенте бегут в три раза быстрее, чем на сервере. Если коэффициент меньше 1, значит часы на клиенте бегут вперед, если больше 1 — отстают. Все гениальное — гениально! Таким образом решена проблема частотной синхронизации.
Я долго думал, ну как же так получилось, что частоту и фазу удалось откорректировать через показания времени, присланном в пакете с пакетами? И вот буквально на днях дошло. Частота измеряется в герцах. А что такое герц? Это единица делить на секунду. Т.е. величина обратно пропорциональная времени. Разработчики стандарта взяли за основу поговорку «время временем вышибают» и воплотили в жизнь. Чертовы гении. Ну а с фазой совсем просто — это опять же просто время запаздывания или отклонения одного сигнала от другого.
Профили PTPv2 (1588v2)
Мы молодцы, разобрались с физическими логическими основами пакетной синхронизации. Это хорошо. Но было лишь начало. Теперь давайте посмотрим, какие профили бывают. Как с умным видом говорилось ранее, протокол PTPv2 описывает формат сообщений и что из них можно выжать. А дальше каждый сам волен придумывать себе настройки под разные требования. Кому-то нужна только частота, кому-то подавай и фазу. Этим — точность десятки микросекунд, тем — наносекунды. У этих есть только Ethernet, у этих IP (и заметьте, про MPLS ни слова).
ITU-T определил три профиля PTP для телекоммуникационных приложений, описанных в спецификациях G.8265.1, G.8275.1 и G.8275.2.
G.8265.1 Profile используется для обеспечения точной частотной, но не временной синхронизации базовых станций мобильной связи. Хорошо подходит для 2G, 3G, LTE FDD. Старые сервера синхронизации умеют поддерживать только его. Реализован у многих мобильных операторов (чуть позже разберем как). В железе выглядит следующим образом.
Сервер с завидной регулярностью шлет сообщения Sync, на основе которых клиент (базовая станция) производит корректировку частоты. И изредка Announce, как аналог Hello в других протоколах. Работает поверх IP и тем удобен. И как бы все. Но не совсем. По факту в нем есть сообщения DelayReq и DelayResp, но для вычисления фазы они не используются. Вероятно, их можно использовать для выставления абсолютного времени. А еще 8265 в принципе по жизни работает без коррекции на промежуточных девайсах.
G.8275.1 Profile предназначен для обеспечения высокоточной частотной синхронизации, фазовой синхронизации и синхронизации времени суток (ToD – time of day). Этот профиль работает только на канальном уровне методом мультикаст-вещания. Хорош собой, но требует обязательную поддержку на каждом транзитном устройстве. А это — капитальные затраты на обновление плат, софта, лицензий и железок в целом. Каждое устройство на пути производит коррекцию времени (вставляет время входа и выхода пакета, чтобы уже в сообщении Sync компенсировать джиттер). Профиль полностью независим от загрузки сети и в этом его жирнейший плюс. Но вот то, что его нельзя запустить без модернизации сети, — минус. Подходит для запуска 2G, 3G, LTE FDD и TDD.
G.8275.2 Profile предназначен для обеспечения точной частотной синхронизации, фазовой синхронизации и ToD при лишь частичной поддержке со стороны сети. А вот это уже интересно. Профиль является дальнейшим развитием 8275.1, но может, во-первых, работать поверх IP, а, во-вторых, не обязательно должен поддерживаться всеми транзитными маршрутизаторами. Второй пункт на самом деле в стандарте описан по-другому. В сети есть несколько типов устройств:
Boundary Clock (BC) – устройство, которое умеет производить расчеты времени. В т.ч. источник синхронизации (GrandMaster Clock)
Ordinary Clock (OC) – потребитель синхронизации по-нашему, например, базовая станция
Transparent Clock (TC) – транзитное устройство, которое умеет вносить корректировку задержки времени прихода и ухода пакета с железки
Позаимствуем картинку с сайта хуавея, которая описывает структуру сети, предложенную стандартом (кстати картинка одинакова для 1 и 2 профилей).
Каждое транзитное устройство в сети по стандарту должно быть BC или TC, т. е. на аппаратном уровне обеспечивать поддержку PTPv2 (ставить временные отметки в пакете), а это снова капитальные затраты на модернизацию сети. Но, PTPv2 на сетях операторов я видел (правда, неизвестно с каким профилем), а вот чтобы мы его как-то настраивали в железе – припомнить не могу… И вот за эту-то соломину будем цепляться зубами, интерпретируя эти данные нужным нам образом, но чуть позже. Прежде давайте посмотрим, как выглядит в Wireshark’е сигнальный обмен между сервером и клиентом (БС).
Со стороны сервера мы можем лицезреть три типа сигнальных сообщений: Announce, Sync и DelayResp.
Как видим, изредка сервер напоминает миру сообщением Announce (149 пакет) о своем существовании и параметрах. Периодическими сообщениями Sync (142,152,161,170 пакеты) производится коррекция частоты и просто поддержание точного времени суток. Ну а сообщения DelayResp летят в ответ на запрос клиента DelayReq из следующего дампа и служат для корректировки фазы. Кстати, обратите внимание, что на одно Sync приходится 8 сообщений Delay. Это как раз параметры выставляемые в телекоммуникационном профиле G.8275.2. Например в энергетическом профиле частота отправки этих сообщений будет немножечко другая, и по сути это и будет единственная разница между профилями. Но от частоты отправки этих сообщений зависят характеристики сервера (сколько клиентов в единицу времени он может обслуживать).
Но давайте взглянем на обещанный дамп глазами клиента (базовой станции):
Как видим, кроме как DelayReq базовая станция ничего не шлет. Да ей и не требуется. Частоту и время она получила из сообщений Sync, а вот фазу берет из сообщений Delay. Вот, собственно, и вся магия.
Для закрепления давайте еще глянем на общие параметры частоты отправки Sync и Delay, под которые БС подстроилась, проанализировав сообщения Announce от разных серверов. Это выгрузка параметров с базовой станции, уж простите за качество.
Что здесь примечательного. Для начала БС поняла, что она Ordinary Clock, т. е. потребитель синхронизации. Настроена на работу с профилем G.8275.2 поверх IPv4 в unicast-режиме. Т.е. в настройках руками указаны сервера. Есть такое поле Domain = 44. Оно служит для разделения разных групп источников синхронизации, но для нас, как пакетчиков, оно интересно тем, что при анализе дампов оно может указать, какой профиль используется G.8275.2, G.8265.1, G.8275.1, потому что под профили эти номера доменов заранее предопределены. Как минимум в ходе реверс-инжиниринга (читай – ковыряния в дампах) мне это сильно помогло разобраться в происходящем. Ну и мы видим, что телекоммуникационным профилем G.8275.2 определена (точнее запрошена базой) частота отправки сообщений Sync 16Гц (или pps – packet per second), а сообщений Delay – с частотой 128 Гц (или опять же pps). Как раз разница в 8 раз, что мы видели в дампе выше.
А теперь давайте подумаем, что мы имеем заключить из всего вышесказанного и увиденного? На базовой станции есть работающий профиль G.8275.2, зацепленный за сервер синхронизации, который по стандарту обладает наносекундной точностью. Это раз. Профиль есть, значит, есть фаза и частота, но LTE TDD не работает. Это два. Три — на пакетной сети никто не настраивал аппаратную поддержку этому профилю, хотя стандарт его требует. Т.е. в сети есть один Boundary Clock (он же Grandmaster, он же источник синхронизации) и множество Ordinary Clock (базовые станции). А всяких промежуточных Transparent clock нет. Четыре — режим IPv4, но мы-то знаем, что у нас на сети никого IPv4 нет — у нас там MPLS. Крайне любопытная картина вырисовывается. Т.е. фактически мы подаем на базовую станцию синхронизацию частоты и фазы. Точности частоты хватает, чтобы работало 2G, 3G и сектора LTE FDD, а вот точности фазы для запуска LTE TDD категорически не хватает. А это уже кое да что.
Кстати, по ходу разбирательств во всей этой синхронизации на глаза попалась хорошая справочная табличка, в которой описаны разные виды рекомендаций для тех или иных технологий передачи данных.
Что там у мобилы?
Что ж, пора, наверное, поскролить тик-ток интернет на предмет того, какие, собственно, требования выдвигаются со стороны мобильной сети для разных технологий. Основательный гуглеж показал, что веб-комьюнити, например, вот здесь. примерно сходится на одних и тех же параметрах и для LTE TDD требует точность синхронизации ± 1,5мкс.
Вторят нашим отечественным коллегам и именитые импортные товарищи из Ericsson, которые в сотовой связи сильно хороши.
Доверяй, но проверяй. Если мы в пакетных сетях руководствуемся требованиями RFC, то мобила живет и строится по законам, описанным законодателем мобильной моды — 3GPP — 3rd Generation Partnership Project — консорциумом, разрабатывающим спецификации для мобильной телефонии. На слайдике выше указан любопытный документ 3GPP TS 36.133, в котором на 47 (из 462) странице озвучиваемые интернетом требования вполне подтверждаются. Хотят точность меньше 3 мкс для каких-то маленьких ячеек и 10 мкс для больших.
И вот теперь впору слегка пригорюниться и словами одного автоблогера задать витающий в воздухе вопрос: «3GPP, вы там у себя не офигели»? Мы тут в пакетных сетях задержки измеряем в миллисекундах, как мы вам должны микро- и нано- обеспечивать? У нас даже скорость света конечна, по проводу длиной 10км пакет физически летит со скоростью 280000км/с 0,03мс (это уже 30мкс), а еще сериализация, буферизация, маршрутизация...
Но если хорошенечко призадуматься, то тут явно что-то не то. И верно, раз транспортная сеть физически не в состоянии обеспечить микросекундые задержки (delay), значит, речь о другом. И это другое — джиттер (jitter) или дрожание. Пакеты приходят с какой-то задержкой и она плавает, например, в диапазоне от 10 до 15мс. Вот эта разница между максимальной и минимальной задержкой в 5мс и будет джиттером. Т.е. для успешного запуска LTE TDD нам нужно всего-то навсего — обеспечить джиттер синхропакетов в пределах 3 мкс... Без коррекции на промежуточных маршрутизаторах… Пффф, да раз плюнуть.
Средний по больнице MBH
Для понимания, откуда берется задержка, а вместе с ней и джиттер, надо глянуть на среднестатистическую структуру обычной российской семьти. Строится она по одним и тем же лекалам у всех операторов: мобильная кора (пакетная и голосовая с контроллерами), сама сеть MBH из маршрутизаторов агрегации (подороже и помощнее) и доступа (подешевле и послабее), и собственно базовая станция, ради которой все это делается. Но давайте разберем чуточку подробнее, как это выглядит.
PS/CS Core через Opt. A (набор вланов под разные интерфейсы мобильной сети Abis, Iub, S1 и управление OAM) стыкуются с городской/областной mpls-сетью. Эта сеть обычно имеет выделенный уровень агрегации из мощных маршрутизаторов с большим количеством портов и толстых линков, который строится по кольцевой топологии. Пример очень простой, обычно роутеров больше. На агрегаторы опираются кольца доступа, состоящие из железок с функциональным названием CSR (Cell Site Router). К CSR’ам уже непосредственно подключаются базовые станции. С т.з. физики, наверное, у всех все одинаково. Различия начинаются в части логической архитектуры, что выливается в разный набор используемых протоколов для организации транспортной и сервисной составляющей: ospf/isis, ldp/rsvp, l2vpn/l3vpn, canon/nikon, vpls/evpn, иерархический/плоский vpn — в общем, вариативность хорошая. Но по факту единственная цель дотянуться вланом или по l3 от PS Core до базовой станции, попутно обеспечивая резервирование узлов и линий связи с быстрым переключением на резерв.
Теряем время
Давайте попробуем разобраться, в каком месте сети набегает задержка и что добавляет ей неопределенности — того самого джиттера. Для этого рассмотрим трассу от PS Core до базовой станции, развернув схему выше в цепочку и пустим скупую слезу пакет размером 1500Байт.
При передаче по сети пакет проходит через маршрутизаторы и по линиям связи. Крупными мазками в маршрутизаторе он проходит:
стадию внутренней обработки включая десериализацию (восстановление битового потока в пакет и поиск выходного интерфейса)
буферизацию перед отправкой в линию, если она вдруг занята
сериализацию (передача набора битов в линию)
С линиями все просто. Оптический или электрический сигнал распространяется хотя и очень быстро, но с конечной скоростью, которая где-то в районе скорости света. Но т. к. у нас тут сферический конь не в вакууме, то она поменьше. Мне нравится думать про 280000 км/с (не знаю откуда взял). В итоге чем длиннее линия, тем дольше пакет будет по ней ехать.
Давайте рассчитаем примерную задержку для нашей сети, вызванную длиной линии. Примем, что длина каждого линка равна 10км. Сигнал преодолеет 10км за 10км/280000км/с= 0,035мс = 35мкс. По дороге у нас пять таких линий, значит, в сумме это займет 0,035мс*5= 0,175мс = 175мкс. В целом немного. Для примера, если речь будет идти про спутниковую связь, то для геостационарной орбиты пока пакет слетает в космос на высоту 35000км делить на 300000км/с (тут уже вакуум) это займет 116мс. Отразится от спутника и долетит до наземного терминала это еще минимум 116мс, итого минимально физически возможное время односторонней задержки 232мс (а на самом деле сильно больше). У Старлинка в этом случае сильно веселее, орбита на 550км — это примерно 3,6мс. Этот параметр фактически зависит только от ограничений, налагаемых вселенной, и его не обойти. Наверное все, кто работал в эксплуатации, сталкивались с абонентами, которые жаловались на высокий пинг из условного Владивостока до Москвы — это как раз случай с расстояниями. И увы, здесь помогут только просветительская деятельность и надежда, что когда-нибудь сервер с танчиками поставят поближе к абонентам. Хотя бывают случаи, когда операторы из Владивостока стыкуются где-нибудь на М9 в Москве — это двойная пытка с административной составляющей для абонентов.
Теперь давайте посчитаем, сколько времени пакет проводит внутри маршрутизатора. Скажу сразу, сделать это получится весьма условно, потому что зависит как минимум от типа обработки пакета. Допустим если он умеет обрабатывать «на лету», то ему не надо дожидаться поступления всего пакета, а достаточно только заголовка, из которого можно выяснить выходной интерфейс. Но обработать-то заголовок оно сможет, а вот передать дальше - нет, пока не получит весь пакет целиком. Почему? Потому что наш старый добрый Ethernet работает с полем контрольной суммы (FCS), которое вставляется в конец кадра. Т.е. сначала надо узнать, пришел ли пакет целым, а потом нужно сосчитать новую сумму, т.е. пакет так или иначе должен оказаться в маршрутизаторе целиком. Это будет десериализация. Операции десериализации (сборка пакета из битового потока) и поиск выходного интерфейса в целом можно распараллелить. Сколько времени будет длиться обработка пакета — одному чипу известно: это очень индивидуально, даже лезть не будем, но в современных маршрутизаторах это наносекунды. Но если кто-нибудь подскажет, как сделать трейсы пакетов на Huawei, Juniper и Nokia аналогично как в этой статье по циске, то нашей статье явно добавится точности. А так посчитаем только то, что можем точно посчитать.
Сперва переведем наши 1500 байтов в биты, чтобы делить и умножать одни и те же единицы. 1500 байт * 8 = 12000 бит.
Все начинается с того, что PS Core на скорости 100G выплевывает пакет в сеть. Это сериализация. Время передачи всего пакета размером 12000 бит со скоростью 100Гб/с из порта в линию составит 12000бит / 100Гбит/с = 0,12 мкс. Немного. Узел Agg1 в сторону Agg2, работая на 20G, затратит на эту же операцию сериализации в 5 раз больше времени, т. е. 0,6 мкс. Интерфейсы Agg2 и CSR1 в сторону БС работают на скорости 10G, поэтому они потратят по 1,2 мкс. Ну и CSR2 смотрит в БС на скорости 1G, т.е. он потратит 12 мкс. Просуммируем время сериализации 0,12 + 0,6 + 1,2 + 1,2 + 12 = 15,12 мкс = 0,01512 мс. В целом тоже не очень много.
Какие выводы? С одной стороны, чем больше размер пакета, тем больше времени на его передачу надо. Товарищи, которым важно работать с данными в режиме реального времени, типа голоса или эмуляций потока поверх RTP, давно смекнули, что с мелкими пакетиками проще гарантировать какую-никакую стабильность (технология ATM со своими ячейками в 53 байта была родоначальником этой моды). С другой, чем выше скорость порта, тем меньше время, затрачиваемое на передачу. И этот параметр уже зависит от наших финансовых возможностей. Говорят, что купить можно все, кроме времени. Мы с вами только что разрушили этот миф! В дата-центрах все очень богатые и работают на межгалактических скоростях в 100G и 400G чуть не на доступе с основной целью — уменьшить задержку. Это у нас в провайдинге миллисекундой больше, миллисекундой меньше — все равно проблема абонента. А они там сети строят для себя любимых, чтобы ублажить протокол TCP или его гугловского братишку QUIC, которые в большинстве реализаций крайне чувствительны к задержке.
Но если подумать, что такое 15мкс, которых у нас набрались за пяток маршрутизаторов — мелочи? Ан нет, можно очень неудачно вляпаться. Давайте откатимся на 10-15 лет назад, в эпоху xDSL и Serial-интерфейсов, которые местами встречаются и сейчас. Там скорости вращаются в районе 2Мб/с. А для 1500Б пакета это сразу же +6 мс на процедуре сериализации. А давайте сделаем еще хуже (мы это умеем) — выкручиваем MTU до 9000Б. И тут же получаем 30 мс. А это, на минуточку, пинг из Екатеринбурга до Москвы. Вот так легко и непринужденно мы довели сеть до крайности, заменив 4000 км оптики всего одним неудачным маршрутизатором. Чем еще плох медленный процесс сериализации? Пока железка мучительно передает пакет в линию, остальные томятся в буфере, а это уже про массовое влияние. Про half-duplex и коллизии уже говорить не будем — сегодняшняя статья не о том, как сломать жизнь себе или абонентам. Хотя нет, все-таки будем. Мы-то ведь как думаем, что потоки E1, Frame Relay, PPP и ADSL далеко в прошлом и больше мы об этом ничего не услышим. Услышим и еще как. Низкоскоростные интерфейсы не выходили и вряд ли уйдут из нашей жизни. Тот же LTE на своих радио-интерфейсах в сторону абонентов будет выдавать совсем небольшие скорости, в пределах нескольких мегабит в ЧНН в зависимости от числа абонентов на БС. Правда и здесь можно купить себе симочку подороже с более приоритетным QCI (quality class identifier — мобильный qos) и наслаждаться прелестями капитализма. В LTE TDD дополнительно добавляется задержка из-за half-duplex, потому что прием и передача ведутся по очереди (пусть и в разных пропорциях). Но LTE — это про абонентов. А в сетях провайдеров очень распространены радио-релейные линии, которые работают на скоростях и в 100М, и в 250М. Или остался SDH, который выкидывать жалко умеет EoS (Ethernet over SDH), и вот мы уже передаем Ethernet на скорости VC4 в районе 150М. Так что процедуру сериализации со счетов сбрасывать никак нельзя.
Ну ладно, с сериализацией разобрались. Пакет вылетел из PS Core по 100G линку, пролетел 10 км и попадает на AGG1. Здесь его ждет обратный процесс — десериализация. Из битового потока сознания нужно собрать пакет обратно. По сути это займет столько же времени, поэтому просто добавляем еще 15,12 мкс к нашим расчетам и на этом успокаиваемся.
Всего на линии и в процессе сериализации/десериализации мы потеряли 175 + 15 + 15 = 205 мкс = 0,2мс. Знаете, что объединяет все виды задержки, которые были описаны и посчитаны в этой главе? Они нам неинтересны! Они статичны, даже если земля перестанет держаться на трех китах, формула расстояние = скорость*время не изменится. Понятно, что если размер пакета будет 100Б, а не 1500Б, то времени на его передачу уйдет поменьше, но сам принцип расчета останется простым и понятным как три копейки. На наши потуги запустить чудо-синхронизацию для LTE TDD оно особо не повлияет, потому что это delay, а не jitter, с которым мы будем биться. Хотя вообще-то в теории есть ситуация, когда и задержка повлияет — это процедура handover’а, т.е. передачи абонента с одной базы на другую, но это не точно.
Ну а вообще мы посмотрели на все основные виды задержки, которые возникают на сети, кроме буферизации. А вот она-то как раз ломает нашу стройную систему расчетов постоянной задержки, внося хаос и обеспечивая тот самый джиттер.
Буферизация
Это время, которое пакет находится в буфере (памяти), ожидая своей очереди на отправку (фактически до начала сериализации). Время это носит абсолютно случайный характер и зависит от множества параметров: сколько уже пакетиков лежит в буфере, сколько очередей и какие у них настройки, есть ли полисер, в какую очередь пакет попал, какой максимальный размер буфера, сколько юзеров в сети и как сильно им хочется интернета, насколько мощные сервера, есть ли шейпер и много другое, что делает процедуру буферизации на первый взгляд непредсказуемой.
В пакетных сетях буферизация возникает по двум основным причинам:
понижение скорости
одновременный приход пакетов
Сперва про понижение скорости. Тут все довольно просто. Нельзя просто взять и пакет, летящий на скорости 10G, передать в порт 1G. Сперва его нужно пропустить через замедлитель интернетных частиц, коим является буфер коммутатора/маршрутизатора. Так сказать, произвести выравнивание линейных скоростей интерфейсов.
Но есть нюанс, который довольно сложно уловить. Замедляется не столько скорость отдельного пакета, сколько скорость потока данных. Ну вот смотрите. Есть сервера условного Яндекса или ВК, жесткие диски которых умеют производить чтение и передачу видосиков в сеть на скорости 100G, а есть телефонная станция, обученная сызмальства только теореме Котельникова, передающая разговор на скорости 64 кбит/с. Сервер Яндекса и телефонная станция могут быть подключены по 100G-интерфейсу. Но сервер будет передавать информационный поток на этой скорости, а телефонная станция как использовала свои 64 кбит/с, так и будет. Понятно, что поток данных на скорости 100G нельзя целиком засунуть в 10G, пакеты начинают складываться в буфер, потом буфер кончается и они теряются (а в это время усиленно работает TCP, который вычисляет реальную пропускную способность канала с точностью до нескольких килобит на основании всего двух параметров — двусторонней задержки и процента потерь, попутно подстраивая/понижая скорость чтения жесткого диска до 10G, но это из другой оперы). При этом условная телефонная станция, несмотря на потрясающую скорость интерфейса, передает голосовой поток на скорости 64к, что без всякой буферизации прекрасно пройдет через 10G линк.
Если пример с серверами не подходит, то возьмем из жизни. Вот перед нами 10 полосное шоссе, у которого из-за ремонта осталась только 1 полоса. В месте сужения полос возникнет пробка, которая, чем больше машин, тем длиннее растянется. Фактически, пробка — это буфер, который производит выравнивание возможностей 10-ти полосного шоссе с узкой дорогой. С другой стороны ночью, когда трафика нет, можно ворваться на однополоску — тапку в пол, волосы назад, т.е. выравнивать тут особо нечего, т.к. дорога свободна.
Все мы знаем, что пакетные сети изначально построены на обмане потребителя теории вероятности. Это когда у нас у коммутатора 20*1G портов и 2*10G, причем только один 10G смотрит в аплинк. Итого мы запихиваем 20G в 10G, называя это нейтральным словом мультиплексирование в соотношении 2:1 (а в случае с платами переподпиской). И в общем-то здесь все в порядке, вероятность того, что трафика одновременно будет хотя бы пару гигов, крайне низка, и на графиках в Cacti никто никакого криминала не увидит. В теории. А вот если копнуть чуть поглубже, то становится понятно — вероятность, что два пакета придут одновременно и захотят попасть в один и тот же выходной порт очень сильно больше 0.
По итогу, одному из пакетов придется полежать в буфере, пока другой проходит сериализацию. Чем больше «одновременных» пакетов, тем дольше они будут сидеть в очереди. Это в чистом виде теория массового обслуживания, которую каждый из нас пропустил через себя с утра в плацкартном вагоне в очереди к столь вожделенному туалету на подъезде к конечной станции.
Оба механизма, приводящие к необходимости буферизации, желательно понять и простить, чтобы знать, где очередь (а вместе с ней джиттер) может возникнуть, а где нет.
Радикальный сетевой фундаментализм
А вот теперь будет немножечко хардкора, без которого эта заметка не имела бы такого смысла. Как чинить джиттер — не секрет, для этого существует QoS с правильной классификацией и продуманным планировщиком, но об этом немного попозже. Пока же обсудим одну статью в моем ультра кратком изложении, которая попалась на глаза за неумеренным потреблением оливье. Итак, простой парень из солнечного Сан-Хосе с исконно калифорнийским именем Diptanshu Singh задался вопросом, а как, собственно, посчитать этот джиттер. Если быть точнее, то в своей статье он вывел формулу для расчета времени буферизации, а это ни что иное, как джиттер. Я проверил, она работает на практике, поэтому хочется объяснить, что к чему, ведь это позволяет с простым калькулятором в руках проверить те или иные техрешения и предсказать, что заработает, а что нет.
Процесс буферизации в сети представляют собой модель массового обслуживания, которая хорошо изучена, разложена на компоненты и описана. Удобнее всего рассматривать на примере условного магазина с покупателями. Есть интенсивность поступления клиентов в очередь, есть сама очередь возле кассы, есть скорость обработки очереди (расторопность кассира).
Поступление клиентов в очередь удобно представлять в виде распределения Пуассона. Это когда мы знаем, что за час в среднем придет 5 человек, но когда конкретно они это сделают — загадка, друг на друга они не ориентируются. Могут прийти все вместе, а могут и нет. А могут и вообще прийти не 5, а 8. Это важный момент, свойственный именно пакетным сетям. Допустим, в TDM-сетях поступление данных осуществляется с постоянной скоростью через равные промежутки времени длиной в 1 таймслот (или канальный интервал для тех, кому ИКМ-30 ближе) и там все дальнейшие расчеты смысла уже не имеют. В распределении же Пуассона много случайностей.
Для процесса Пуассона придумана формула, которая рассказывает, с какой вероятностью за какое-то время произойдет n событий. Например, при средней интенсивности 5, придет все-таки не 5, а целых 8 человек. Эта формула на самом деле интересна, потому что через нее можно получить все что угодно. И, что особенно радует, нам она не нужна, с ней математики пусть работают ))
Есть разные модели массового обслуживание, мы будем рассматривать самую простую M/M/1, которая нам подходит. В ней первая «М» означает поступление пакетов по распределению Пуассона. Вторая «М» — обработка пакетов «без памяти» вне зависимости, было что-то до этого сделано или нет. И «1» означает, что у нас только один обработчик очереди (когда мы будем считать реальную сеть, будет понятно, почему это допустимо).
Базовыми характеристиками, описывающими систему массового обслуживания, являются интенсивность поступления пакетов λ и интенсивности (скорость) их обработки µ. Отношение интенсивности поступления к интенсивности обработки обозначается буковкой ρ
Если соотношение меньше 1, значит система успевает обрабатывать всех клиентов, если больше — значит клиенты начинают теряться. Чем ближе ρ к нулю, тем меньше время ожидания в очереди.
Вообще-то, лично я бы уже на этой формуле закончил всю эту математику. Если вдуматься, то фактически здесь мы видим не только скорость убывания, но и в каком-то смысле коэффициент буферизации. Т.е. условно при интенсивности поступления 5 человек и скорости обслуживания кассы в 6 человек, ρ=5/6 = 0,83 из них оказались бы постоянно в очереди. А почему бы не взять и именно так не интерпретировать эту формулу? Я бы так и сделал. И ошибся. Потому что именно понимание деталей процесса отличает математиков от меня — они-то знают, что каждый клиент, который находится на кассе, отнимает время у всех, кто стоит дальше за ним. Склоняю голову перед их умищем. Дальше в статье идет большая простыня из формул, которые приводят нас к простому способу вычисления среднего количества пакетов в отдельно взятой очереди N (внимание, формулой ниже этот же параметр обозначается буквой q).
Если на пути много очередей (в нашем случае маршрутизаторов), то для каждой из них считается свой N, где λ это скорость поступления пакетов усредненной длины, а µ это скорость обработки интерфейсом этих пакетов. И в итоге мы получаем, что при интенсивности 5 и скорости обработки 6, в очереди будет не 0,83 клиента (как я ошибочно хотел насчитать ранее), а 5/(6-5)=5 клиентов. Если бы интенсивность поступления была 3, то очередь 3/(6-3)=1 уменьшилась радикально. Популярное мнение, что лучший qos — это широкие линки, правильное. Но в целом мы с вами увидели ключевую формулу для расчета джиттера.
Без стеснения жонглируя формулами товарищ выводит схему расчета джиттера T для отдельного порта или маршрутизатора.
Честно говоря, не понял, что он хотел показать, используя в этой формуле букву q, а формулой выше букву N – это одно и тоже – среднее число пакетов, лежащих в буфере. Но не суть, главное теперь у нас есть формула расчета джиттера, которая в переводе на человеческий звучит как отношение числа пакетов в буфере q (или N) к интенсивности поступления пакетов.
Ну и если маршрутизаторов по трассе много, то нужно посчитать, сколько пакетов сидит в буферах на всех изучаемых портах и разделить это на сумму интенсивностей поступления трафика в эти порты.
В своей статье он зовет это задержкой, и c т.з. маршрутизатора он полностью прав — мы считаем время задержки пакета в буфере. Но с т.з. сети это уже в чистом виде джиттер. Позволю себе открыть паинт и переписать формулу.
Очень интересно, но ничего не понятно? И это хорошо — вы нормальный!
Для желающих окунуться поглубже и подсмотреть еще пару фокусов, вот здесь товарищ показывает нам, как еще можно провернуть эти формулы, причем удобненько в экселичке. На самом деле можно рекомендовать проделать это упражнение, в ходе которого можно спрогнозировать с какой вероятностью джиттер будет увеличиваться при разной загрузке порта.
Кто виноват?
Кажется, сейчас самое время не отходя от кассы попробовать натянуть эту математику на нашу сеть и разобраться, почему же LTE TDD не захотело само заработать. Вспомним, что ключевым моментом является жесткое требование к джиттеру при передаче пакетов синхронизации в пределах 3мкс, чтобы обеспечить достойную фазовую синхронизацию. Профиль PTPv2 G.8275.2 с коррекцией фазы у нас есть, но что-то ему не хватает для счастья. Поэтому берем ту же самую сеть и с интересом препарируем кусочек, выделенный зеленым прямоугольничком. В нем у нас сервер синхронизации (в народе бывает зовется IPClock) по красной пунктирной стрелочке безуспешно пытается доставить фазу на базу.
Для начала нужно понять, где будет возникать джиттер. Напомню, что он появляется или при понижении скоростей, или, если трафик из нескольких линков пытается попасть в один. С одной стороны, это вызывает буферизацию, а с другой – наш маршрутизатор можно описать через распределение Пуассона и модель М/М/1, что позволяет использовать формулы из прошлой главы.
Итак, IPClock посылает пакеты на скорости 1G, он их источник, делает стабильно в рамках возможностей своего процессора. Никакого джиттера там нет. Следующая железка AGG1, в ней сходится несколько аплинков, т.е. для джиттера самое оно. Записали. На AGG2 мало того, что аплинки из разных направлений, так еще и понижение скорости с 20G до 10G. Наш кандидат. У CSR1 условно говоря только один аплинк, из которого прилетит трафик в сторону CSR2, оба порта работают на скорости 10G, условия не выполняются, так что мимо. Ну и последний девайс – это CSR2, он выполняет понижение скорости с 10G до 1G. Итого имеем, что буферизация производится на AGG2, AGG1, CSR2.
Хорошо, теперь надо посчитать λ и µ. Где их взять? Да очень просто. λ – это скорость, с какой идет трафик, а µ – это скорость на которой работают интерфейсы. Единственный момент, надо это дело перевести из мегабит/с в пакеты/с. Ну просто потому, что по сети у нас летают именно пакеты. Что ж, просто заходим на порт AGG1 делаем sh int X и получаем готовенький результат. Либо берем график с пиковыми значениями и идем считать.
Здесь мы видим, что интенсивность поступления в ЧНН:
λ = 1,17 Mpps.
А еще обратите внимание, что я беру график со всего порта без деления на очереди, где вместе с голосом может летать домашний интернет. Все верно, до приведения QoS’ов на всей сети до желаемой модели трафик голоса, синхронизации, управления и всего остального может попадать совсем не в те очереди, где им место. В нашем случае он оказался в нулевой.
Такс, а еще нам нужно вычислить средний размер пакета. Делается просто: делим скорость в мегабитах на скорость в пакетах, и на 8 не забываем, чтобы обратить биты в байты:
11,52Gbps / 8 / 1,17Mpps = 1230 байт.
Теперь мы можем посчитать скорость обработки интерфейса 20G в pps для усредненных 1230 байтных пакетов:
µ = 20Gbps / 8 / 1230B = 2 032 520 pps.
А теперь просто возьмем и посчитаем средний джиттер, который возникает при передаче пакетов через AGG1 при передаче через интерфейс по формуле
T = 1/(2032520pps-1170000pps)=1 / 862520 pps=1,16*10-6с= 1,16мкс
Вроде бы немного. Но мы посмотрели только на один линк, и он уже выбрал 30% от бюджета в 3мкс необходимого для запуска LTE TDD. А еще не будем забывать, что мы увидели среднюю задержку буферизации. Распределение Пуассона говорит нам о том, что может прийти 1 Mpps, а может прийти и 1,5 Mpps (всплеск), пусть и с меньшей вероятностью. Мы на графике или счетчике видим оооочень усредненные значения, т. к. фактически джиттер плавает в значительно бОльших пределах. Так, при всплеске до 80% от емкости порта (это ~16G или ~1,6 Mpps) джиттер на линке составит
T = 1/(2032520pps-1600000pps)=1 / 862520 pps=2,3*10-6с= 2,3мкс
И все, давай G.8275.2, до свидания.
Но пока не будем о грустном, считаем трассу дальше. Берем график с AGG2, на порту xe-1/1/0 которого происходит понижение скорости с 20G до 10G.
Средний размер пакета:
607,62Mbps / 8 / 107kpps = 709B
Скорость 10G интерфейса в pps:
µ = 10Gbps / 8 / 709B = 1763000 Трафик в ЧНН поступает со скоростью:
λ = 107 kpps.
pps
Джиттер:
T = 1/(1763000pps-107000pps)=1 / 1656000 pps=6*10-7с= 0,6мкс
И посчитаем последний из интересных линков уже на CSR2, где происходит понижение с 10G до 1G непосредственно в базовую станцию. Также берем картиночку, стираем с нее отпечатки пальцев и смотрим, что выходит.
Трафик идет со скоростью:
λ = 6,7 kpps
Средний размер пакета:
56,32Mbps / 8 / 6,7kpps = 1050B
Скорость 10G интерфейса в pps:
µ = 1Gbps / 8 / 1050B = 119000 pps
Джиттер:
T = 1/(119000 pps-6700pps) =1 / 112300 pps=8,9*10-6с= 8,9мкс
А вот это уже интересно. Фактически на пустом гиговом порту, где в ЧНН 50М трафика (загрузка 5%) набежало джиттера сразу на 9 мкс. Ни о каком LTE TDD и 3мкс говорить больше не приходится. Вот оно – то место, которое нам гарантированно всю малину испортило. Какая бы классная сеть у нас не была, на гигабитном порту возникает крайне неприятный эффект накопления времени буферизации. Помните, мы ранее считали сериализацию. Так вот здесь, на медленном интерфейсе, она начинает влиять на время буферизации. Такой вот замкнутый круг.
Для очистки совести давайте еще просуммируем джиттеры по всей трассе AGG1-AGG2-CSR2:
1,16 мкс + 0,6 мкс + 8,9 мкс = 10,66 мкс
И заметьте, это только в одну сторону от PS Core до БС. Этот джиттер будет воздействовать на сообщения Sync в PTPv2 G.8275.2. От БС до PS Core тоже есть разные линки, и там будет накапливаться свой джиттер (немного меньше, но порядок тот же), который будет ломать нам сообщения DelayReq. А еще мы не учитывали (потому что не умеем), что поиск выходного порта (маршрутизация/коммутация) все-таки занимает какое-то время.
Такие дела. Только что мы с вами своими руками посчитали и нашли место (и не одно), где вся наша синхронизация сыпется.
Что делать?
Проблему нашли, дело за малым - ответить на извечный вопрос. Томить не буду, перед нами стоит две решаемые задачи:
Обеспечить одинаковую задержку (delay) пакетов по направления PS Core – БС (для сообщений Sync) и БС — PS Core (для сообщений DelayReq). Делается с помощью ISIS/OSPF (а у кого-то и RSVP, и BGP).
Уменьшить задержку буферизации (jitter) хотя бы на порядок. Тут только QoS.
Пойдем по порядку. Для правильного расчета фазовой синхронизации необходимо, чтобы задержка в обе стороны была как можно более одинакова. Даже, наверное, нет так. Внутри одной БС постоянная ассиметричность маршрута ни на что влиять не должна. Но вот для правильного расчета фазовой синхронизации двух соседних секторов, между которыми осуществляется handover (передача абонента с одной БС на другую) - по логике симметричность совершенно необходима. Достигается это симметричностью трассы. И в самом деле, давайте глянем на нашу схему с немного вывернутой метрикой на участке CSR1-CSR2.
Как видим, из-за некорректно проставленных метрик сигнальный пакет Sync от сервера к БС пойдет короткой дорогой по красной линии, а вот пакет DelayReq побежит по длинной трассе (синяя линия), легко намотав сотню-другую километров оптики. А мы помним, что 100 км / 280000 км/с = 357 мкс. И вот так легко мы внесем непоправимую ошибку в расчеты PTPv2 для абсолютного времени и фазы. Поэтому необходимо перелопатить всю сеть, обеспечив абсолютную симметрию всех метрик. И этот минимум мы сделали.
Для донов, которые используют RSVP, задачка может оказаться посложнее (а местами и вовсе нерешаемой без редизайна). Во-первых, в старых HLD некоторые производители рекомендовали использовать explicit-path для решения всяких разных проблем (например, неумения софта рассчитывать резервные lsp при частичном пересечении путей до появления опции overlap). И вот, когда инженеры вручную пишут эксплиситы, а потом через год что-то куда-то переносят, то прямые и обратные туннели легко разъезжаются по разным трассам, потому что сначала тут забыли исправить, потом там.
Во-вторых, есть великолепный функционал RSVP Auto-bandwidth, который позволяет строить lsp из расчета загрузки линков. Очень помогает избежать ручного администрирования, но на больмень загруженной сети прямой и обратный туннели с изрядной доли вероятности в ЧНН скорее всего разойдутся по разным направлениям. И еще учитывайте, что синхронизация в принципе крайне нервно, даже истерично, относится к изменению физической трассы и, как следствие, задержки. Для синхронизации лучше использовать постоянные туннели.
В-третьих, есть и еще проблемка для сетей, где используется иерархический VPN (особо касается случаев с OSPF, где используется нулевая и номерные зоны). Не углядев за master/slave на транзитных железках, куда приземляются vpls (t-ldp) или l3vpn (mp-bgp opt B), возникнет еще одно место, где задержка поплывет. В общем, вариантов как сделать сеть хуже — масса, обращайтесь )).
Нас бог миловал, сеть по HLD запроектирована максимально простой на IGP+LDP, а проблемы емкости и прочего трафик-инжиниринга решаются выделением лямбды в хорошо развитом DWDM. Мы полностью переделывали только метрики в IGP, практически гарантировав симметрию (на самом деле мы полностью все переписали заново на сотнях маршрутизаторов). Остаются, конечно, нюансики, когда на пути есть ECMP. С одной стороны Juniper, с другой Cisco и скорее всего они посчитают хэш совершенно по-разному, но благо разница по расстояниям будет в пару километров, что приемлемо.
Теперь давайте заборим джиттер. Здесь, конечно, сильно сложнее, потому что требуется внедрение QoS. Там большая теория, у меня на эту тему рассказать на 2-3 дня есть что. Начать ознакомление стоит, конечно же, с СДСМ. Наверное, без общего понимания как оно работает и какого-никакого опыта, сложно советовать залазить в эту тематику, потому что, скорее всего, получится сделать только хуже. Но объяснить попробую.
QoS, как и все остальное в этих наших сетях состоит из данных, переносимых в пакетах и обработчике на маршрутизаторах/коммутаторах. В зависимости от выполненных настроек, можно вкладывать разный смысл и философию:
гарантировать разным видам трафика минимальную полосу
приоритезировать один вид трафика на другим
обеспечить моментальное обслуживание высокоприоритетному трафику
не дать кому-то больше, чем нужно, или как раз дать больше, чем нужно, но ненадолго
и т. д.
Все это можно миксовать между собой, запуская в придачу HQoS, который так-то сильно аппаратно зависим даже в рамках одного вендора. Тема QoS крайне обширная, включает в себя классификацию, полисинг, входную перемаркировку, маркировку (цветовую), управление перегрузками (RED/WRED), работу с очередями (PQ/WRR/DWRR-CBWFQ), шейпинг, выходную перемаркировку, настройку размера очереди (в секундах или байтах) — сложно и много короче. А еще это должно быть одинаково на всей сети, вплоть до каждого порта и саб-интерфейса. Это называется единая политика QoS оператора или DiffServ-домен.
Мы настраиваем оператора связи, у него бегает трафик домашнего интернета с торрентами (b2c), iptv, трафик абонентов юр. лиц (b2b), протоколов маршрутизации, голоса и сигналки и мобильной и фиксированной телефонной связи и много чего еще — в общем полный набор. И здесь главная задача – определить, что важно, а что не очень. Вообще, как и все в сетях, умные люди постарались это дело стандартизировать. Например, нарисовали такую табличку
Где разным видам трафика назначили разные приоритеты. И все - живи с этим как хочешь.
Доны из 3GPP пошли чуть дальше и дополнили таблицу типов трафика требования к задержкам и потерям (причем это чисто мобильный QoS).
Стандартизация получилась не очень, надо сказать, потому что не только лишь все понимают, что с этим делать. Нет единой таблицы, которая бы связала воедино классификацию и настройки планировщика, слишком много места для безудержного полета фантазии, и, что хуже, реализации в железе. Так что это все рекомендации, а потому не имеют особого значения, потому что каждый оператор — Художник. Вот как он видит, такой QoS у него и будет.
Хватит бесполезно растекаться мыслью. Имея опыт работы с операторами, мы выделили (классифицировали) голосовой и сигнальный трафик (включая синхронизацию) в отдельный класс (условно назовем его VoIP) и поместили в очередь PQ (Priority Queue или SP – Strict Priority). Другие типы трафика поместим в другие очереди, которые обрабатываются по другим правилам. В целом это выглядит примерно как на этой картинке из статьи (у нас очередей только побольше и они по-другому называются).
Особенность очереди VoIP (кстати, если из VoIP выкинуть букву «o», то станет VIP)) настроенной в режиме PQ в том, что пакеты из нее вынимаются, как только они там появляются, в то время как остальные обслуживаются по очереди, да еще и с отведенным лимитом, чтобы всем досталось времени обслуживания. Допустим, идем сверху вниз по картинке, сначала достали все пакеты из очереди VoIP, потом сколько-то Call-Signalling, потом несколько из Critical Data. Тут снова с ноги врывается появляется пакет в очереди VoIP. Бросаем все и сломя голову c криком БАНЗАЙ несемся обрабатывать пакеты VoIP. Вот в этот самый момент другие пакеты в очередях накапливают задержку (джиттер) сидя на лавке в поликлинике буфере, а наш дерзкий и быстрый приоритетный пакетик синхронизации залетает почти без задержки, чисто на харизме со словами
Но это лирика. Что дает нам приоритетное обслуживание в очереди PQ с т.з. математики и ненавистных формул? Во-первых, ожидаемо мы сильно уменьшаем интенсивность поступления трафика. Отделив мух от котлет, а голос от торрентов, скорость λ уменьшается на порядок, а то и два. Хоть это и не принципиально на незагруженных линках.
Во-вторых, мы всю пропускную способность порта отдаем в распоряжение нашей очереди с синхронизацией. Параметр µ будет использоваться нами без ограничений (в реальной сети, конечно, нужно ограничивать очереди PQ шейпером, чтобы при шторме он не убил всю сеть, но на расчеты это не влияет)
В-третьих, что более неожиданно и вообще-то является залогом успеха, мы уменьшаем средний размер пакета. Если домашний интернет бегает с пакетами по 1200 байт, то голос/сигнализация/синхронизация по 100-135 байт. В 10 раз меньше. Просто потому, что эти виды трафика так устроены. Вот, например, дамп пакета PTPv2.
А вот соседствующего с ним голосовой пакетик в технологии 3G.
Добавляем сюда пару заголовков mpls по 4 байта, накидываем 14 байт Ethernet, 4 байта 802.1q, можно еще преамбулу и контрольную сумму байт на 12. Короче то на то и выходит.
И вот это уже заявочка на победу. Помните, как в прошлой главе наши мечты расслабленно запустить синхронизацию на гиговом линке разбились о суровую реальность? При средней длине пакета в ~1200Б мы получили джиттер 8,9мкс. А коли мы уменьшим пакет в 10 раз до 120Б, то и джиттер упадет примерно в 10 раз до 0,89 мкс. И вот же оно!
А, ну и излишне, наверное, говорить, что разработав модель QoS, учитывающую профили трафика Заказчика, мы вновь бессонными ночами прошлись по этим же сотням маршрутизаторов, перенастроив их фактически с нуля.
Посчитаем заново
Берем нашу же сеть, и, даже не дожидаясь стандартного ЧНН в 20:00-22:00, идем по железкам собирать выводы счетчиков очередей (можно было бы и по графикам посчитать, да там очереди не рисуются, но заодно покажу другой метод расчета). Почему ЧНН ждать не обязательно? Потому что трафика в очереди VoIP несколько мегабит, что днем, что ночью. На расчеты это не влияет
На Juniper AGG1 это будет так
sh int queue ae10 forwarding-class VoIP
…
Egress queues: 8 supported, 8 in use
Queue: 5, Forwarding classes: VoIP
Queued:
Packets : 28304481228 10656 pps
Bytes : 3505717139707 11136896 bps
…
На линке 20G трафика 11 мегабит, ну правда, оно не изменится на порядок. А если изменится, то это некритично. Напомню, что когда деления на очереди не было, то мы считали для 11 гигов, а не 11 мегабит.
Итак, здесь у нас интенсивность поступления трафика
λ = 10656 pps
Средний размер пакета здесь и сейчас
11136896 bps / 8 / 10656 pps = 130 Байт
Скорость работы интерфейса с пакетами размером 130 Байт
µ = 20Gbps / 8 / 130B = 19 230 769 pps (понятно, что такой скорости на практике вряд ли добиться)
Джиттер
T = 1/(19230769 pps-10656 pps)=1 / 19 220 113 pps=5,2*10-8с= 0,05мкс
А до косов был 1,16 мкс. На этой железке уменьшили на порядок, точнее в 23 раза.
Идем дальше, считаем AGG2
show interfaces queue xe-1/1/0 forwarding-class VoIP
…
Egress queues: 8 supported, 8 in use
Queue: 5, Forwarding classes: VoIP
Queued:
Packets : 32217685641 11089 pps
Bytes : 4696632048800 11856768 bps
…
Интенсивность
λ = 11089 pps
Внимательный читатель может спросить – WTF? Почему на нижестоящей железке трафика стало больше? Потому что у нее два аплинка и трафик между ними делится примерно поровну. 5,5М залетает с разных сторон.
Средний размер пакета здесь и сейчас
11856768 bps / 8 / 11089 pps = 133 Байта
Скорость работы интерфейса с пакетами размером 133 Байт
µ = 10Gbps / 8 / 133B = 9 398 496 pps
Джиттер
T = 1/(9 398 496 pps-11089 pps)=1 / 9 387 407 pps=1*10-7с= 0,1мкс
А до косов был 0,6 мкс. На этой железке уменьшили всего в 6 раз.
В оконцовке считаем CSR2, где была самая боль из-за гигового интерфейса.
На Huawei это выглядит
dis port-queue statistics interface gi0/2/20 ef outbound
GigabitEthernet0/2/20 outbound traffic statistics:
[ef]
Pass: 844,167,975 packets, 103,921,473,916 bytes
Discard: 0 packets, 0 bytes
Last 5 seconds pass rate:
368 pps, 324,328 bps
Last 5 seconds discard rate:
0 pps, 0 bps
Интенсивность
λ = 368 pps
Средний размер пакета здесь и сейчас
324328 bps / 8 / 368 pps = 110 Байт (такое ощущение, что Хуавей не учитывает l2 заголовок)
Скорость работы интерфейса с пакетами размером 110 Байт
µ = 1Gbps / 8 / 110B = 1 136 363 pps
Джиттер
T = 1/(1 136 363 pps-368 pps)=1 / 1 135 995 pps=8,8*10-7с= 0,88мкс
А до косов был 8,6 мкс. На этой железке уменьшили на порядок, в 10 раз.
И давайте насладимся результатом, сложив все джиттеры по дороге AGG1-AGG2-CSR2
0,05 + 0,1 + 0,88 = 1 мкс
Вуаля, мы уложились! Не забываем добавить еще 1 мкс в обратную сторону (хотя ее бы неплохо посчитать таким же образом, но мне лень). И получается, что мы остались в рамках бюджета 3 мкс. На тоненького конечно, но пролазим же! Натурные эксперименты показали, что все работает. Пока не сломается).
Доверяй, но проверяй
У читателя из нашей проф. среды ко всем этим выкладкам может возникнуть законный вопрос.
Право, у самого были сомнения. Одно дело, что пробные базы LTE TDD заработали, но никто ж не может проверить, что там происходит в буфере с джиттерами. Расчеты расчетами, но хочется чего-то более осязаемого. И их есть у нас! Оказывается, в системе управления базовыми станциями можно запускать тесты качества синхронизации. Условно раз в секунду система залазит в стек PTPv2 и анализирует время.
Скомпилированная таблица выгрузки по 9 тестовым базовым станциям в разных точках сети с разным количеством маршрутизаторов по дороге (от 3 до 10) выглядит следующим образом:
В ней представлены максимальные отклонения от… а вот не знаю от чего. Либо от первого значения. Либо... да кто его знает. У меня документации на эту тему нет. В последней строчке данные по среднему значению задержки. Очень интересно, но кроме того, что некие результаты идут в ± микросекундах ничего не дает. Но, вот дальше по каждой БС есть своя статистика. Выглядит следующим образом:
В этой табличке видно, что проводится некий тест Phase Discrimination, что на русский переводится как изменение фазы или дрожание фазы, ну а на нашем пакетном языке — тот самый джиттер. И тут не совсем понятно что это за значения и почему часть из них имеет отрицательное значение. Либо система накапливает статистику двусторонних задержек за секунду и считает среднее. Либо берет какое-то случайное значение раз в секунду. Я склонен думать, что истина где-то посередине. Но главное, что в колонке G показан тот самый джиттер. Мы пытаемся попасть в ±1,5мкс (или ± 1500нс) и результат в колонке G радует глаз. А главное совпадает с расчетами. Можно задавать разную длительность теста. У нас он шел 2500 секунд (~40 минут). Естественно, результаты такого количества измерение приятнее смотреть на графике. Можно так
Можно этак
Что мы тут наблюдаем? Для БС3 основная масса значений находится в коридоре ± 1000нс. Есть случаи единичных выбросов за +2000нс и -3000нс. Что это означает, судить без документации не берусь. Могу лишь констатировать факт, что как и было рассчитано, джиттер плавает в зависимости от заполненности буферов на маршрутизаторах и в целом не особо зависит от количества железок в трассе. Как говорилось ранее, на джиттер в основном влияет понижение скорости по трассе типа 100G→10G, 10G→1G и несколько аплинков у железки. Для всех БС количество маршрутизаторов в трассе разное, но количество девайсов, где проводится понижение скорости или есть несколько аплинков — одинаковое: в ядре (несколько аплинков и понижение), на агрегации на входе в кольцо (несколько аплинков) и на конечном маршрутизаторе (понижение скорости). В итоге значения джиттера для БС в разных конца сети построенной по нашему дизайну похожи как братья близнецы. С чем нас и поздравляем.
Аппаратная vs программная синхронизация
Отличия качества синхронизации G.8275.1 с аппаратной поддержкой от G.8275.2 запущенного правильным дизайном, QoS’ом и божьей помощью можно оценить по той же самой скомпилированной табличке измерений джиттера из системы управления базовыми станциями. И видны они невооруженным взглядом .
Смотрите. Желтым цветом это БС живущие на программном G.8275.2. Зеленым и синим — на аппаратном G.8275.1. Если для желтых БС1-БС9 джиттер (для примера выделен красный прямоугольник) измеряется в тысячах наносекунд, то для БС10-БС15 (зеленые) в единицах и десятках. А для БС16-БС18 (синие) в сотнях. Почему есть разница между желтыми и синими однозначно не скажу, скорее всего проблема в том, что синие живут на Juniper ACX2100, а там есть какие-то проблемки с простановкой timestamp в режиме boundary clock. Но тут интересно другое. На аппаратном профиле среднее значение задержки (фиолетовый прямоугольник) в районе 0 нс (это взяли и сложили все 2500 измерений). А на программном втором профиле оно болтается в районе микросекунды. И именно что болтается — никакой стабильности. Вот вам и разница, вот вам и ответ — аппаратный профиль точнее на целый порядок, а то и три, не зависит от загрузки на сети и позволяет без всяких QoS’ов и дизайнов запустить хоть LTE TDD, хоть LTE Advanced MIMO. Правда требуется заплатить денюжки за аппаратную часть и лицензии. Но это уже тема другого разговора.
Что это было?
Но вообще мы с вами скрестили магию воды и огня теории вероятностей и QoS’ов, чтобы посмотреть, как же оно там работает и что можно сделать. Если очень кратко, то разобравшись, как работает протокол PTPv2 (а именно вычисляет фазу и частоту), поняли, что для счастья нужно:
1. обеспечить симметрию прямых и обратных путей
2. уменьшить джиттер
Первый пункт мы решили исправлением метрик с сопутствующей перенастройкой ISIS. А вот второй решали через QoS, поместив пакеты синхронизации в отдельную очередь с приоритетным обслуживанием. Но фокус состоял не в приоритетности обслуживания пакетов синхронизации как таковой, а в том, что в этой очереди мы собрали маленькие пакеты, уменьшив их среднюю длину в 10 раз, из-за чего джиттер также упал на один порядок. Я же говорю, что QoS крайне плохо стандартизирован и каждый художник вертит им как хочет в самую неожиданную сторону. На мой взгляд QoS – это крайне расплывчатая и даже не технология, а набор каких-то магических заклинаний, комбинируя которые можно гибко подходить к решению разных задач. Играть можно не только настройками классификатора и планировщика, но и разными метками (dscp/802.1p/exp) в пакетах, но это как-нибудь в другой статье.
Успешный успех?
Пытливый читатель, домотав досюда все 45 листов А4, возможно спросит: «И че? В чем новизна? Что ты хотел сказать этой статьей? Отвечаю. Во-первых, получай 3GPP! Что вы там у себя думали, мы тут не сможем на коленке микросекунды собрать? А во-вторых, просто рассказать, как не случайно съеденная оливьешка взмахнула крылом случайно привела к формуле вычисления джиттера и ее практическому применению. Ну и вообще – еще одно подтверждение, что сеть надо не просто купить, но и как следует приготовить. А QoS он как мазик для оливьешки — серьезному блюду серьезный ингредиент, без которого даже докторская колбаса не вывезет.
Заказчик получил возможность запустить сотни простаивающих секторов LTE TDD на врЕменном решении. Почему временном? Потому что при данной реализации без промежуточной коррекции и с подачей PTPv2 G.8275.2 поверх MPLS, а не IP с аппаратной поддержкой (как завещано стандартом) есть зависимость от количества трафика на сети. Достаточно кому-то очень упорному или клиентоориентированному прописать толстый канал для абонента и раскрасить его realtime qos’ом, как синхронизация может посыпаться, унося в небытие радость интернета для мобильных абонентов. С другой стороны, никто не мешает написать скрипт, который будет укладывать отдельные сектора LTE TDD при потере/ухудшении качества синхронизации, чтобы они не доставляли проблемы на сети, после чего идти оперативно разбираться с происходящим. В общем, заказчику вернули веру в счастливое будущее и возможность запустить сотни секторов, пока где-то едут платы с аппаратной поддержкой G.8275.1, чтоб уж точно не зависеть от геополитических раскладов на карте мира.
Всем оливье, мира и сетей. Встретимся в других статьях.
Список сопутствующей литературы использованной при изысканиях:
https://habr.com/ru/companies/yandex/articles/861538/ - проблемы с NTP
https://habr.com/ru/articles/163253/ - про PTPv2
https://tf.zone/solutions/architecture-and-testing-of-network-synchronization-systems/ - про синхронизацию в мобильных сетях
https://tf.nist.gov/seminars/WSTS/PDFs/2-2_Ericsson_Ruffini_Sync_in_MobileStandards_ruffini-rev3-tot.pdf — 3GPP TS36.133 про требования к LTE сетям
https://packetpushers.net/blog/average-network-delay/ - про вычисление джиттера
https://real-statistics.com/probability-functions/queueing-theory/m-m-1-queueing-model/ - теория вероятностей в экселичке
https://habr.com/ru/articles/420525/ - СДСМ QoS
https://habr.com/ru/articles/246791/ - еще про QoS
И еще множество полезного прочитанного
https://www.elec.ru/publications/tsifrovye‑tekhnologii‑svjaz‑izmerenija/6015/
https://russianelectronics.ru/ieee1588/
https://habr.com/ru/companies/phoenix_contact/articles/495 920/
https://www.design‑reuse.com/articles/49 934/delivering‑timing‑accuracy‑in-5g‑networks.html