|
Ранее...
Аналогично описанию метрик из раздела 1.7, мы начнём с порядка следования:
Определение 62.
|
число пакетов теста, успешно принятых на стороне генератора за время Tp, однако доставленных с изменением порядка следования.
|
Определение 63.
|
процент пакетов в тесте, доставленных к генератору с изменением порядка следования (процент нарушения очерёдности)
|
Как и в случае с перекрашенным трафиком, процент здесь считается не от общего числа переданных пакетов, а только от доставленных, чтобы купировать потери. При существовании на стороне приёма Nro нарушение порядка от стороны генератора до стороны приёма описывается уже введённым в разделе 1.7 ORr, а обратное — ORp. Если же Nro отсутствует на стороне приёма, то ORp описывает круговое нарушение порядка без выделения направления.
Ну и не забываем определить наше новое изобретение:
Определение 64.
|
число пакетов теста, успешно принятых на стороне генератора за время Tp, доставленных с минимально возможным полем TTL (Hop Limit)
|
Определение 65.
|
процент пакетов в тесте, доставленных к генератору со значительным сдвигом в пути следования (процент сдвига пути)
|
Важно отметить, что в связи с особенностями стека TCP/IP, метрика SRp будет всегда описывать трафик от приёмника к генератору! Здесь информация о прохождении трафика от генератора к приёмнику в случае использования протоколов без поддержки Nrl будет утрачена сразу после приёма. Увы! Поэтому, если процент сдвига пути важен, следует использовать правильное программное обеспечение.
Не забываем о проценте потерянной скорости:
Определение 66.
|
процент потерянной полосы пропускания при приёме теста на стороне генератора (потерянная скорость)
|
В последнем определении нет ничего сложного, несмотря на кажущуюся громоздкость. Несколько вариантов указаны в связи с тем, что при использовании протокола TAP в качестве ста процентов скорости используется не Bs, а Br. Поэтому и появляются дополнительные варианты по сравнению с определением в разделе 1.7. Всё же остальное, сказанное про LBWr относится и к LBWp.
Не будем забывать, что при использовании протокола TP скорость генерации будет зависеть от скорости приёма (см. комментарии к определению 55), поэтому LBWp следует использовать в этом случае с аккуратностью, ниже мы поговорим об этом подробнее.
Ну и дрожание у задержек доставки трафика от стороны приёма до стороны генератора тоже случается, поэтому слегка модифицируем уже известные определения.
Определение 67.
|
дрожание задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму RFC-3550
|
Определение 68.
|
минимальное ненулевое дрожание задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму Y.1540 с использованием в качестве базиса минимальной задержки
|
Определение 69.
|
максимальное дрожание задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму Y.1540 с использованием в качестве базиса минимальной задержки
|
Определение 70.
|
среднее арифметическое дрожания задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму Y.1540 с использованием в качестве базиса минимальной задержки
|
Определение 71.
|
минимальное дрожание задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму G.1020
|
Определение 72.
|
максимальное дрожание задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму G.1020
|
Определение 73.
|
среднее арифметическое дрожания задержки доставки пакетов от стороны приёма до стороны генератора, измеренное за время Tp по алгоритму G.1020
|
В случае использования протоколов TP, все виды дрожания на приёме у генератора будут описывать круговое дрожание, а не одностороннее. Сомневаетесь? Проверьте поведение зависимого генератора и убедитесь в этом сами. Умный читатель уже говорит нам, что у одного калифорнийского производителя сетевого оборудования написано иначе, и что дескать их широко известный в узких кругах responder это учитывает? «Ну-ну» - скажем мы. Включите отладку в оборудовании (естественно, в лаборатории, а не на реальной сети!) и убедитесь в том, что мы вначале думаем, потом разрабатываем свою гипотезу, строим теорию, обкатываем её на практике, а только потом выдаём итоговые рекомендации, как и положено у научно мыслящих людей. И никак иначе!
Ну что, коллеги?! Кажется с определениями метрик покончено и можно начинать более пристально заниматься описанием самих технологий тестирования. Остаётся только напомнить, что все описанные метрики являются статистическими величинами. И для них не может быть создан эталон! Важно понимать, что на сетях TCP/IP любое достаточно производительное устройство с операционной системой общего типа пригодно как для генератора, так и для приёмника. Неважно, есть ли на устройстве голографическая метка, полученная от государственных органов или нет, так как в статистике мы оперируем не физическими величинами, а результатами наблюдений.
cc: lj, telegraph, vk, telegram: 1,2, zen, AT, MMM
Далее...
|
