Качество сетей передачи данных. Программные и аппаратные измерения

Не часто используемая метрика с коммерческой точки зрения, но актуальная в некоторых случаях. Опять же, стоит отметить, что при асимметричном пути следования пакетов, возможен различный MTU в разных направлениях.

Наверняка многим известен факт, что количество переданной полезной информации в единицу времени зависит от размера фрейма. Связано это с тем, что фрейм содержит довольно много служебной информации — заголовков, размер которых не меняется при изменении размера фрейма, а изменяется поле “полезной” части (payload). Это значит, что несмотря на то, что даже если мы передаем данные на скорости линка, количество полезной информации переданной за тот же период времени может сильно варьироваться. Поэтому несмотря на то, что существуют утилиты для измерения пропускной способности канала (например iperf), часто невозможно получить достоверные данные о пропускной способности сети. Все дело в том, что iperf анализирует данные о трафике на основе подсчета той самой «полезной» части, окруженной заголовками протокола (как правило UDP, но возможен и TCP), следовательно нагрузка на сеть (L1,L2) не соответствует подсчитанной (L4). При использовании аппаратных измерителей скорость генерации трафика устанавливается в величинах L1, т.к. иначе было бы не очевидно для пользователя почему при измерении размера кадра меняется и нагрузка, это не так заметно, при задании ее в %% от пропускной способности, но очень бросается в глаза при указании в единицах скорости (Mbps, Gbps). В результатах теста, как правило, указывается скорость для каждого уровня (L1,L2,L3,L4). Например, так (можно переключать L2, L3 в выводе):

Если говорить о сети или системе связи как о комплексе линий связи и активного оборудования, обеспечивающего нормальное функционирование, то эффективность работы такой системы зависит от каждого составляющего ее звена. Линии связи должны обеспечивать работу на заявленных скоростях (линейная скорость), а активное оборудование должно успевать обрабатывать всю поступающую информацию. 

У всех производителей оборудования заявляется параметр PPS (packets per second), прямо указывающий сколько пакетов способно «переварить» оборудование. Ранее этот параметр был очень важен, поскольку подавляющее число техники просто не могло обработать огромное количество “мелких” пакетов, сейчас же все больше производители заявляют о wirespeed. Например, если передаются малые пакеты, то времени на обработку тратится, как правило, столько же, сколько и на большие. Поскольку содержимое пакета оборудованию не интересно, но важна информация из заголовков — от кого пришло и кому передать. 

Сейчас все большее распространение в коммутирующем оборудовании получают ASIC (application-specific integrated circuit) — специально спроектированные для конкретных целей микросхемы, обладающие очень высокой производительностью, в то время как раньше довольно часто использовались FPGA (field-programmable gate array) — подробнее об их применении можно прочитать у моих коллег здесь и послушать здесь.

Стоит отметить, что ряд производителей экономит на компонентах и использует малые буферы для пакетов. Например заявлена работа на скорости линка (wirespeed), а по факту происходят потери пакетов, связанные с тем, что буфер порта не может вместить в себя больше данных. Т.е. процессор еще не обработал скопившуюся очередь пакетов, а новые продолжают идти. Часто такое поведение может наблюдаться на различных фильтрах или конвертерах интерфейсов. Например предполагается, что фильтр принимает 1Gbps поток и направляет результаты обработки в 100Mbps интерфейс, если известно, что отфильтрованный трафик заведомо меньше 100Mbps. Но в реальной жизни случается так, что в какой-то момент времени может возникнуть «всплеск» трафика более 100Mbps и в этой ситуации пакеты выстраиваются в очередь. Если величина буфера достаточна, то все они уйдут в сеть без потерь, если же нет, то просто потеряются. Чем больше буфер, тем дольше может быть выдержана избыточная нагрузка.

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

• программа замеряет время, формирует пакет с данными, и отдает его ОС для «спуска» по OSI;
• OC ставит пакет в очередь, затем обрабатывает, при необходимости надевая недостающие инкапсуляции, дергает контекст, кладет пакет в буфер сетевой карты через драйвер, который тоже имеет, как правило кольцевой буфер;
• пакет путешествует по сети, пока не дойдет до получателя;
• сетевая карта получателя, приняв пакет и положив в буфер порождает прерывание;
• ОС получателя, остановив другие обработки, читает пакет и ставит в очередь на обработку, обрабатывает, отсылает назад (если говорим о ping), либо дергает контекст и отдает программе на обработку (если обработка не “ядерная”), т.е. повторяются пункты 1-2 только на стороне получателя;
• пакет снова путешествует по сети, только в обратном направлении (и не факт что точно соответствующему прямому);
• повторяются пункты 4-5 для отправителя;
• программа отправителя вычисляет время между началом 1 и завершением 7.

Таким образом, мы получили время от формирования программой пакета до времени получения ей же ответного пакета, вместо того, чтобы получить сумму по пунктам 3 и 6, т.е. в задержке учтены «паразитные» участки. Решением проблемы подобного рода будет вставка в пакет временной метки как можно ближе к выходу в сеть, т.е. хотя бы буфере сетевой карты. Это позволит отсечь “паразитное” влияние пунктов 1-2, но остается еще 4-5. На получателе следует возвращать пакет без обработки в операционной системе, например просто свопнув MAC получателя и отправителя. Получивший такой пакет начальный отправитель может сравнить начальную метку, установленную на выходе в сеть с текущей меткой на входе из сети и сделать намного более точный расчет задержки. Наглядный пример можно увидеть измеряя задержку в режиме эхо-запроса и в режиме сертифицированного теста на нашем  «Беркут-ET» или  «Беркут-ETX». В некоторых системах, в силу особенностей архитектуры, эхо-запрос может показать значения в районе 30-60 мс в прямом соединении (cross-connect), в то время как сертифицированный тест покажет 8-16 нс, т.е. разница на порядок. Два компьютера, скорее всего, покажут лучший результат, но внесенная ими погрешность в измерение задержки не может быть учтена. А эхо-запрос в нашем приборе присутствует не для измерения задержки как таковой, а в качестве стандартного инструмента проверки доступности какого-либо узла в сети.

Следующие метрики являются основными и опорными для оценки качества сетей и систем связи:

пропускная способность:

• пакетная пропускная способность
• потери фреймов
• задержка
• one-trip
• round-trip
• jitter
• delay variation
• минимальный MTU
• бёрстность

Общим принципом измерений — генерация (или оценка) тестовых пакетов как можно ближе к выходу (или ко входу) измеряемого участка, в противном случае невозможно обеспечить точность из-за возрастания числа факторов, влияющих на измерения. На данный момент распространены и применяются такие методики тестирования как RFC2544 и Y.1564. 

Купить качественное сетевое оборудование в Казахстане по лучшей цене можно в магазине Ruba Technology. Мы предлагаем только высоконадежные, сертифицированные продукты для обеспечения скоростного соединения в условиях коммерческого сектора. Все сетевое оборудование прошло необходимые тестовые испытания, чтобы максимально соответствовать требованиям бизнес-среды.