1.10 Двунаправленные дополнительные метрики
Аналогично описанию метрик из раздела 1.7, мы начнём с порядка следования:
Определение 62
![число пакетов теста, успешно принятых на стороне генератора за время T[p], однако доставленных с изменением порядка следования](https://avatars.dzeninfra.ru/get-zen_doc/9529784/pub_6427165913022e2e7bb6005a_64271690282bdf49f5c0a8c0/scale_1200)
Определение 63
Как и в случае с перекрашенным трафиком, процент здесь считается не от общего числа переданных пакетов, а только от доставленных, чтобы купировать потери. При существовании на стороне приёма N[ro] нарушение порядка от стороны генератора до стороны приёма описывается уже введённым в разделе 1.7 OR[r], а обратное — OR[p]. Если же N[ro] отсутствует на стороне приёма, то OR[p] описывает круговое нарушение порядка без выделения направления.
Ну и не забываем определить наше новое изобретение:
Определение 64
Определение 65
Важно отметить, что в связи с особенностями стека TCP/IP, метрика SR[p] будет всегда описывать трафик от приёмника к генератору! Здесь информация о прохождении трафика от генератора к приёмнику в случае использования протоколов без поддержки N[rl] будет утрачена сразу после приёма. Увы! Поэтому, если процент сдвига пути важен, следует использовать правильное программное обеспечение.
Не забываем о проценте потерянной скорости:
Определение 66
В последнем определении нет ничего сложного, несмотря на кажущуюся громоздкость. Несколько вариантов указаны в связи с тем, что при использовании протокола TAP в качестве ста процентов скорости используется не B[s], а B[r]. Поэтому и появляются дополнительные варианты по сравнению с определением в разделе 1.7. Всё же остальное, сказанное про LBW[r] относится и к LBW[p].
Не будем забывать, что при использовании протокола TP скорость генерации будет зависеть от скорости приёма (см. комментарии к определению 55), поэтому LBW[p] следует использовать в этом случае с аккуратностью, ниже мы поговорим об этом подробнее.
Ну и дрожание у задержек доставки трафика от стороны приёма до стороны генератора тоже случается, поэтому слегка модифицируем уже известные определения.
Определение 67
Определение 68
Определение 69
Определение 70
Определение 71
Определение 72
Определение 73
В случае использования протоколов TP, все виды дрожания на приёме у генератора будут описывать круговое дрожание, а не одностороннее. Сомневаетесь? Проверьте поведение зависимого генератора и убедитесь в этом сами. Умный читатель уже говорит нам, что у одного калифорнийского производителя сетевого оборудования написано иначе, и что дескать их широко известный в узких кругах responder это учитывает? «Ну-ну» - скажем мы. Включите отладку в оборудовании (естественно, в лаборатории, а не на реальной сети!) и убедитесь в том, что мы вначале думаем, потом разрабатываем свою гипотезу, строим теорию, обкатываем её на практике, а только потом выдаём итоговые рекомендации, как и положено у научно мыслящих людей. И никак иначе!
Ну что, коллеги?! Кажется с определениями метрик покончено и можно начинать более пристально заниматься описанием самих технологий тестирования. Остаётся только напомнить, что все описанные метрики являются статистическими величинами. И для них не может быть создан эталон! Важно понимать, что на сетях TCP/IP любое достаточно производительное устройство с операционной системой общего типа пригодно как для генератора, так и для приёмника. Неважно, есть ли на устройстве голографическая метка, полученная от государственных органов или нет, так как в статистике мы оперируем не физическими величинами, а результатами наблюдений.
сс: net-probe, lj, telegraph, vk, telegram: 1,2
Далее...