Ранее...

Поскольку при полнодуплексном трафике теста итоговые метрики зависят от типа применяемого протокола и от его фактической реализации, мы будем вводить в определения данного раздела некоторые уточнения. В отличие от отраслевых стандартов, где этот важный вопрос пущен на самотёк, мы постараемся быть научно корректными.

Вначале понятия о времени:

Определение 48.

абсолютное время начала отправки пакета с номером i от стороны приёма.

Определение 49.

абсолютное время окончания приёма пакета с номером i на стороне генератора.

«О ужас! Вновь страшные математические сложности!» — слышим мы. Не согласны. Всё просто. Вспомним, что в зависимом генераторе на стороне приёма совсем не обязан быть фиксатор числа принятых пакетов. Ведь программное обеспечение может просто реализовать эхо‑протокол. Кто сказал ping? Да, там именно так всё и сделано. Поэтому и приходится уточнять определения с тем, чтобы они были универсальны.

Теперь вновь сладкая парочка, только для стороны начала сессии:

Определение 50.

число пакетов теста, успешно принятых на стороне генератора за время Tp.

Определение 51.

период времени приёма теста на стороне генератора.

«Да как же так! Вы же только что сами писали, что N_r может существовать, а может и нет. А в последнем определении про это уже забыли?» — скажет наш любимый читатель. Нет, не забыли. Мы помним о поведении стороны приёма. Но тут, как в известном анекдоте, есть нюанс: дело в том, что на приёме генератор ожидает прихода не N_r пакетов, ему эта информация станет видна только в процессе теста, причём чаще всего по итогам. Если реализация вообще это поддерживает, к слову говоря. А ждёт он N_s пакетов, то есть такого же числа, как он и передал, а точнее всё ещё передаёт.

Вот теперь и можно начинать определять сами метрики для двунаправленного трафика. Потери:

Определение 52.

процент потерянных пакетов в тесте на стороне генератора за время Tp.

Несложно видеть, что при существовании на стороне приёма N_r потери от стороны генератора до стороны приёма описываются уже введённым в разделе 1.6 LR_r, а обратные потери — LR_p. В случае же отсутствия на стороне приёма N_r потери по каждому отдельному направлению невозможно определить, а вот круговые потери от генератора до приёма и обратно описываются LR_p. Иллюстрировать поведение сети здесь будет излишним, так как рисунок 7 всего лишь зеркалится.

Теперь перекраска:

Определение 53.

число пакетов теста, успешно принятых на стороне генератора за время Tp, однако доставленных с классом сервиса, отличным от Cs.

Определение 54.

процент пакетов в тесте, доставленных с изменённым классом сервиса от приёма до генератора (процент перекраски).

Здесь всё проще, поскольку процент считается не от общего числа переданных пакетов, а только от доставленных. Как и в случае с потерями, при существовании на стороне приёма N_rr перекраска от стороны генератора до стороны приёма описывается уже введённым в разделе 1.6 RR_r, а обратная перекраска — RR_p. Если же N_rr отсутствует на стороне приёма, то RR_p описывает круговую перекраску трафика без выделения направления.

Переходим к скорости:

Определение 55.

измеренная скорость среди успешно принятых пакетов на стороне генератора за время Tp.

Что является важным для измеренной на стороне генератора скорости? Ведь с первого взгляда это весьма простая метрика, понятная даже младенцу. Мы, правда, за всю свою практику ещё не видели младенца, проверяющего сети TCP/IP, так что это всего лишь одна из тех гипербол, которыми славятся связисты в реальной, недостаточно документированной жизни. Но всё-таки, рядовой пользователь сети, пусть и возрастом давно не младенец, понимает это в полсекунды. Все те ограничения, про которые мы говорил в разделе 1.6 о метрике BW_r применимы, конечно, и к BW_p. Но есть и новое: измеренная скорость весьма зависима от вида применяемого протокола. В случае, когда для проверки мы используем протокол TP, есть существенная особенность. А именно:

Причём, отметим, что именно за счёт выбора протокола с зависимым генератором на стороне приёма, мы не можем получить скорость передачи от него в сторону инициатора, большую, чем ту, на которой он сам получил трафик.

Представьте, что ваш любимый ping шлёт пакеты достаточно быстро (такие реализации есть, мы же общаемся с опытными специалистами, не забыли?) и развивает скорость передачи B_s, нужную вам, однако, вот загвоздка, от генератора к стороне приёма есть 1% потерь пакетов, такая досталась нам сеть. Каким получится в итоге результат на приёме? Правильно, близким к формуле BW_r = 0,99 × B_s. И отправить трафик обратно сторона, которую так сказать «пингуют», никак не сможет быстрее, чем BW_r, даже если приёмник вывернется наизнанку. У него же нет информации о B_s, ведь он зависим! А теперь представим, что от приёмника до генератора тоже есть потери, к примеру 2%. Релейка глючит, птицы перелётные пошли на взлёт. Что получится в измеренной скорости на стороне инициатора? Верно, значение близкое к формуле BW_p = 0,98 × BW_r = 0,9702 × B_s. Прилагательным «близкий» мы тут формулируем ту неопределённость, которая характерна для всех статистических величин, так как в реальной сети могут быть, разумеется, отличия.

Из указанного неравенства, особенно после нашего несложного примера, становится очевидно, что проверять реальную пропускную способность сети использованием метрики BW_p при использовании протокола TP можно, когда нет иного выхода. И полученное числовое значение можно считать корректным условно. Точные ограничения мы пока опустим, здесь важен сам факт.

А вот в случае использования протоколов TNP или TAP, всё становится более корректным. Так как они независимо создают поток от стороны приёма, что позволяет использовать BW_p уже всерьёз.

Простой параметр, правда? Вот так начнёшь изучать фамильные портреты и, пожалуй, уверуешь, что ты знаешь лишь то, что ничего не знаешь, впрочем, другие не знают и этого. Мы сами не стесняемся учиться и вам рекомендуем не забывать ни латыни, ни древнегреческого.

Вот так, невидимыми семимильными шагами мы вернулись к задержкам, только на этот раз в другую сторону.

Определение 56.

минимальная задержка успешной доставки пакетов от стороны приёма до стороны генератора, измеренная за время Tp.

Определение 57.

максимальная задержка успешной доставки пакетов от стороны приёма до стороны генератора, измеренная за время Tp.

Определение 58.

среднее арифметическое задержек успешной доставки пакетов от стороны приёма до стороны генератора, измеренных за время Tp.

Про задержки в целом всё было сказано в прошлый раз, здесь мы только отметим, что если в протоколах TP нет поддержки T3_i, то данные метрики измерить не представляется возможным. Этой особенностью, например, обладают все эхо‑протоколы, как ICMP, так и UDP. Ну и не забудем именно здесь отметить, что для корректного расчёта как mD_p, MD_p, AD_p, так и mD_r, MD_r, AD_r обе стороны должны быть синхронизированы по времени. Вопросы точности синхронизации — отдельная интересная проблема, здесь мы её пока отложим.

Что же делать, если задержки хочется получать, а синхронизации нет и не предвидится? Вспомнив Платона «Хорошее начало — половина дела», мы обнаружим, что на помощь приходит наш старинный добрый друг:

Определение 59.

минимальная круговая задержка измеренная за время Tp.

Определение 60.

максимальная круговая задержка, измеренная за время Tp.

Определение 61.

среднее арифметическое круговых задержек, измеренных за время Tp.

Неожиданно сложные определения, скажете? «Мы не смеем не потому, что задача трудна. Это задача трудна, оттого что мы не смеем» - так говорили в античности, вот и возьмём на вооружение.

Опустим вырожденные случаи, когда принятых пакетов нет. Понятно, что в этом случае будут нулевые метрики. Займёмся вторыми и третьими случаями. Во вторых мы видим суммирование двух односторонних задержек от генератора к приёмнику (T2_i - T1_i) и от приёмника к генератору(T4_i - T3_i) (см. выше определения mD_p, MD_p, AD_p, mD_r, MD_r, AD_r). Затем проводятся либо выборки минимального или максимального, либо дальнейшее суммирование для получения среднего арифметического. Сложность уменьшилась, всё ясно. Теперь разбираемся, зачем написаны условия справа. Всё дело в том, что при использовании протокола TP приёмник совсем не обязан реализовывать работу с метками T3_i и T2_i, например, если он работает как простое эхо, то этих меток просто нет. Поэтому нужен третий случай, который описывает круговые задержки в случае отсутствия в реализации меток T3_i и T2_i. Хорошо было бы конечно, выбрасывать время обработки пакета на приёмнике всегда, чтобы получать более корректные значения круговых задержек, но коль скоро реализация не поддерживает, лучше получить хотя бы неточное значение, чем вовсе ничего. Именно про это третий случай.

Ну и в финале заметим, что для расчёта круговых задержек синхронизация времени между генератором и приёмником не нужна. Оставим нашим дорогим читателям доказательство этого несложного факта в качестве домашнего задания. А сами же отметим, что в крайнем случае, когда генератор и приёмник умеют мало, а хочется всё‑таки получить односторонние задержки, вы можете просто разделить круговую задержку на два, поскольку это лучше, чем ничего. Не верите? Проверьте на досуге, если он у вас есть, как происходит синхронизация времени в широко известных программных пакетах ntpd и ptpd и удивитесь повторно. Мы в процессе своей профессиональной деятельности наблюдали, как большое число коллег из нашей важной отрасли копируют из устройство в устройство настройки синхронизации, но даже не задумываются, почему у одного из широко известных производителей в документации написана фраза «...assumes a NTP accuracy that is 10% of the latency between the end point», хотя вообще-то это достаточно важно. Впрочем, об этом мы ещё напишем.

cc: lj, telegraph, vk, telegram: 1,2, zen, AT, MMM

Далее...