Стандартный тест RFC2544

    imageВсем привет!

    В этот раз подошло время рассмотреть стандартный тест RFC2544: для чего используется, как проводится, его достоинства и недостатки.

    Disclaimer
    Со времени прошлой статьи ко мне поступили отзывы коллег с предложением писать ближе к делу: меньше воды — больше специфики. Так что предлагаю эту статью считать экспериментальной. В конце материала небольшой опрос.



    Введение


    Рекомендация RFC2544 была разработана в 1999 году и принята IETF. Существует перевод на русский язык. Сейчас эта рекомендация практически стандарт де-факто, благодаря широкому распространению и свободному доступу. Рекомендация “описывает и определяет набор тестов для определения характеристик устройств межсетевых соединений”, описывает форматы представления результатов тестирования.

    Структура методики


    Тестирование по методике RFC2544 сводится к выполнению набора тестов, четыре из которых присутствуют у большинства производителей измерительного оборудования, а два встречаются довольно редко (последние в списке).

    • Throughput
      • определяет пропускную способность DUT, по рекомендации RFC1242
      • определяет нагрузку, при которой нет потерь пакетов

    • Latency
      • определяет задержку, по рекомендации RFC1242
      • измеряет задержку по кадрам выборочно

    • Frame Loss
      • определяет частоту потери кадров, по рекомендации RFC1242, во всем диапазоне скоростей данных и размеров кадра
      • определяет зависимость потерь от нагрузки

    • Back-To-Back
      • определяет возможность DUT по обработке кадров back-to-back, по рекомендации RFC1242
      • измеряет длительность работы при заданной нагрузке

    • Восстановление системы
      • определяет скорость восстановления DUT после перегрузки трафиком

    • Перезагрузка
      • определяет скорость восстановления DUT после программного или аппаратного сброса



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

    Определяется максимальное количество кадров в секунду, которое может передать устройство без ошибок. Скорость определяется методом бисекции. Тест начинается на максимальной скорости. В случае потерь, скорость уменьшается в два раза. Если потерь нет, то скорость увеличивается в два раза, по сравнению с предыдущей. И так далее. Максимальная скорость определяется по стабильности работы (нет потерь) на протяжении 60 секунд. Тестирование проводится для каждого размера кадра. Размеры задаются в параметрах теста RFC2544 перед запуском.

    Задержка

    Тест опирается на предыдущее измерение пропускной способности. Для каждого размера пакета с соответствующей ему максимальной скоростью генерируется поток данных. Поток должен иметь длительность минимум 120 секунд. В 1 пакет по прошествии 60 секунд вставляется метка времени. На передающей стороне записывается время отправки пакета. На приемной стороне определяется метка отправителя и записывается время приема пакета. Задержка — это разница времени получения и времени отправки. Тест должен повторяться минимум 20 раз. По результатам измерений вычисляется средняя задержка.

    Потеря пакетов

    Подсчитывается процент потери пакетов (отношение потерянных к отправленным). Измерение начинается на максимальной скорости и с каждой следующей попыткой уменьшается на 10% (или меньше). Скорость понижается до тех пор, пока два измерения подряд не пройдут без потерь.

    Back-to-back

    Тест заключается в проверке оборудования обработать кадры, идущие с минимальным межкадровым интервалом, т.е. спиной к спине (back-to-back). Начинается с установленного в параметрах теста RFC2544 количества кадров. Если потери не наблюдаются (на протяжении не менее 2 секунд), то количество кадров увеличивается, если присутствуют, то уменьшается. По итогам не менее 50 измерений вычисляется среднее значение.

    Недостатки методики


    Методика тестирования стара (разработана в 1999 году) и сегодня уже не соответствует требованиям рынка. Из недостатков выделяются:
    невозможно постоянно измерять задержку (Frame Transfer Delay, FTD)
    отсутствует измерение вариации задержки (Frame Delay Variation, FDV)
    нет многопоточности, все выполняется по очереди
    тест долгий (исходя из предыдущего пункта)

    Дополнения к методике


    Чтобы расширить функциональность и компенсировать недостатки разработаны дополнения:
    • измерение jitter
    • complex traffic


    Jitter

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

    Complex traffic

    Тест позволяет генерировать и принимать несколько потоков тестового трафика.
    Измеряет пропускную способность и величину потерь кадров (Frame Loss Rate, FLR), но не позволяет измерять постоянно задержку (FTD) и вариацию задержки (FDV).

    Заключение


    Методика RFC2544 сейчас присутствует в оборудовании большинства производителей, в первую очередь исторически, и можно сказать что сегодня она — такой же базовый тест для пакетных сетей Ethernet, как BERT для сетей TDM. Но стоит помнить, что RFC2544 не проводит всестороннее тестирование и даже при успешном прохождении всех тестов может возникнуть ситуация, что сеть не будет функционировать как ожидалось.
    На смену методике RFC2544 приходит Y1564, которой собираюсь посвятить следующую статью.

    Другие мои статьи

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

    Only registered users can participate in poll. Log in, please.

    Ваше мнение о всех статьях

    • 50.9%Материал полезный и интересный, продолжай дальше57
    • 9.8%Материал полезный, но скучный (прошу подробности указать комментариях)11
    • 7.1%Надо дополнить, т.к. мало теории8
    • 18.8%Надо дополнить, т.к. мало практики21
    • 10.7%Ничего не понятно, даешь больше картинок12
    • 2.7%Такой материал не нужен, не интересно (прошу указать на то, что было бы интересно)3

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 11

      0
      Круто, восполнил некоторое количество пробелов в своем образовании. Интересно сколько же реально времени занимает прохождение RFC2544. Понятно что там есть вариативность, но можт есть какие-нибудь типовые/грубые примеры
        +1
        Можно сказать так, что самый влиятельный параметр — это время теста, задаваемое пользователем, что очевидно. Если вы задаете какое-то время, то для каждого выбранного размера фрейма будет выполнятся сове тестирование, что увеличивает общее время тестирования пропорционально количеству фреймов.
        Полагаю, что вопрос не ограничивается желанием пользователя установить время тестирования, так что можно рассмотреть зависимость от других параметров.
        Возьмем для примера, пропускную способность. Поскольку она измеряется так
        1. изначально проверяется заданная скорость
        2. если есть потери, то скорость тестового потока уменьшается в половину
        3. если потерь нет, то увеличивается на половину текущей
        4. если снова потери, то снова уменьшается и так далее

        то задача нахождения «обеспеченной» скорости фактически решается численным методом за полиномиальное время, т.е. временные затраты на ее решение определяются достаточной для нас точностью этого измерения.
        Для тестов задержки и back-to-back фактором времени будет необходимая повторяемость (для задержки 1 тест в 60 сек, а для back-to-back требуется не менее 50 измерений)

        Если интересна реальная цифра — могу без проблем запустить настоящий тест и приложить скриншоты с параметрами теста и результатами.
        0
        Главный недостаток — мало пользы при тестировании беспроводных соединений.
          +1
          Что вы имеете ввиду? Ведь если рассматривать беспроводные мосты, радиодоступ и даже wifi всего лишь как транспортную среду, то тестирование канала ничем не отличается. Я имею ввиду, что если вы покупаете канал с определенными параметрами и для вас это «черный» ящик, то тестируя его на соответствие параметрам, для вас как наблюдателя нет никакой разницы «а что в черном ящике?». Если же имеется ввиду wifi сети и тестирование с уклоном на их топологию, например эмуляции 20..200..2000 клиентов, то конечно же этот тест не показателен.
            0
            Да, зачем эмуляция. Просто если это беспроводной канал точка-точка, то еще возможно как-то измерять.
            А если это базовая станция с 20 клиентами, настроенными приоритетами и адаптивным маркерным доступом, тестирование теряет всяческий смысл. Это будет гадание на кофейной гуще. Либо нужно будет тестировать раз 10 с разными параметрами на разных клиентах и бегать от точки к точке. Собственно, я так и делал.
              0
              Совершенно верно. Методология предполагает тестирование каналов, а не базовой станции все таки, для этого существуют другие системы, в том числе распределенные. Например, когда в нужных точках устанавливаются сенсоры, а управляются они из центра. Из самого простого что приходит в голову — TWAMP во всех его проявлениях.
                0
                Напишите про него)))
                Могу посодействовать)
                  0
                  Он тоже в планах =)
          0
          Спасибо, буду ждать пост про Y1564 :)
            0
            Было бы здорово, если бы заинтересованные хабражители написали бы сюда, в личку или на почту (для тех кто не зарегистрирован) какие практические аспекты хотели бы видеть. Т.е. я могу конечно сделать «ванильный» тест и приложить сриншоты, но это будет не многим лучше чем текущий формат. Хотелось бы несколько оживить материал, придать ему динамики.
            –1
            > “описывает и определяет набор тестов для определения характеристик устройств межсетевых соединений”,
            не согласен, в оригинале «Network Interconnection Devices», т.е. что-то вроде «связующих сетевых устройств».
            межсетевые, это традиционно — «internetworking» — шлюзы/маршрутизаторы, а тут речь везде про кадры, т.е. явный Л2.

            Only users with full accounts can post comments. Log in, please.