1.6. Первичные метрики
И вот, когда рассказано очень многое, можно начать наконец-то описание метрик качества, про которые мы так долго говорили, прямо как большевики на втором съезде Советов. Вначале упомянем основные. Первый из них очевиден:
Определение 24.
Памятуя, что нельзя быть математиком, не будучи в то же время и поэтом в душе, зная что формулы воспринимаются многими людьми хуже, чем наглядные примеры, покажем на рисунке откуда берётся эта метрика.
Рисунок 3.
где
На рисунке 3, конечно, число изображённых пакетов условное, в реальности их намного больше даже для тестового трафика (см. условие применимости 3), что уж говорить про пользовательский — их там без счёта. Тем не менее, даже если посчитать по рисунку, поставив N[s] в 4, а N[r] в 3, получим LR[r] равным 25%. Нормальное же значение конечно должно быть 0%, что очевидно, как из рисунка, так и из логики. Впрочем, это в идеальном мире. О реальных нормах мы ещё поговорим.
Теперь упомянем то, что на практике слишком редко проверяется, однако на самом деле имеет очень большое значение в рабочих сетях с разделением трафика по классам сервиса:
Определение 25.
Определение 26.
Тут уже точно не обойтись без наглядности. Рекомендуем внимательно изучить весь рисунок, не зря же мы его создавали!
Рисунок 4.
где
На рисунке 4, вновь число изображённых пакетов условное. Но мы всё-таки для наглядности посчитаем с карандашом в руках, что N[rr] равно 1, а N[r] , как и прежде 3, и получим RR[r] равным 33,(3)%. Нормальное же значение конечно должно быть 0%. По крайней мере на сети оператора связи, который себя и клиентов уважает.
Почему данная метрика настолько важна, что мы её упоминаем второй? У тех операторов связи, которые борются за качество услуг, несомненно, уже внедрён на рабочих сетях пропуск трафика с учётом приоритетов. Иначе говоря, важнейший трафик обрабатывается P‑устройствами в первую очередь, менее важный во вторую, а трафик любимой социальной сети простого жителя Красного города‑сада — только тогда, когда для него есть свободная канальная ёмкость. Операторам же, которые ещё только думают, не сделать ли этот шаг, мы настоятельно рекомендуем шагнуть навстречу будущему быстрее.
Когда происходит разделение трафика по приоритетам, в политике контроля обычно указано, какая доступная полоса пропускания выделяется в канале для трафика определённого класса. Это может делаться как в абсолютных цифрах, путём указания максимальной скорости в битах в секунду, так и в относительных — установкой процентов об общей полосы. Дополнительно к этому, для каждого класса в политике указывается, что делать, если очередной пакет при подсчёте уже занятой полосы превышает порог. Его можно либо отбросить, как это делается при нехватке канала стеком TCP/IP (см. выше в разделе 1.2), либо понизить приоритет, и попытаться пакет всё-таки доставить, если, конечно, для более низких классов есть нужная ёмкость канала.
В тех случаях, когда на сети фиксируется перекраска трафика, значит где-то есть узкое место в политиках профилирования. На рисунке 4 это место отмечено фиолетовым цветом. Пользователь пока ещё не видит проблемы и это логично, ведь пакеты‑то доставлены, однако служба эксплуатации на появление ненулевой метрики RR[r] обязана реагировать, тем более, если этот факт уже не первый раз повторяется. Он может свидетельствовать как минимум о трёх вещах: либо пользователь выбрал заказанную полосу пропускания в классе сервис C[s], и ему требуется дополнительная, либо пользователь по недосмотру или намеренно пропускает неверный трафик, надеясь, что оператор добрый за свой счёт, либо на одном из транзитных каналов политика профилирования исчерпала свою ёмкость и тут уже оператору пора решать, что делать на данном участке. Как вы видите, метрика очень важная, но среди многочисленных сетевых администраторов, которых встречали на своём жизненном пути авторы, к сожалению, только у некоторых было понимание аналогичное нашему, поэтому мы и делаем на этом акцент. Надеемся подвижничеством добиться правильного, как сказано у Мф.7:7.
Отойдём от нетривиального и упомянем уже очевидное:
Определение 27.
Этой характеристикой пользуются все, даже рядовые пользователи, поэтому она не должна вызывать вопросов. Но рисунок мы всё-таки приведём. Ибо связист в России больше, чем поэт!
Рисунок 5.
где
Мы не зря использовали в качестве символа измерителя стилизованное изображение прибора. Поскольку, как в скоростемере локомотива, так и в спидометре автомобиля стрелка заметно подрагивает, отражая своим поведением неточности в измерениях. На сети связи происходит так же, хотя физические причины здесь конечно иные!
Поэтому, хотя данная метрика и понятна большинству пользователей без перевода, что уж говорить о службах эксплуатации, на наш взгляд измеренная скорость обладает ценностью, только когда проводится нагрузочное тестирование (см. ниже). Без этого параметр, разумеется, не окончательно бесполезный, поскольку сравнивая BW[r] с B[s] можно получить небольшую дополнительную информацию по итогам теста.
Однако, заметим, скорость на приёме явно будет зависеть от количества потерь по пути следования пакетов. Более того, мы ожидаем, что на хорошо отстроенной сети должна быть корреляция между LR[r] и (B[s]-BW[r])/B[s]. Разумеется, с учётом некоторой неопределённости, вносимой периодом T[max] и распределением потерь.Что же касается нормального значения для скорости, мы более внятно погорим об этом, обсуждая нагрузочное тестирование.
Из основных метрик остались задержки, их тоже знают все:
Определение 28.
Определение 29.
Определение 30.
Не откажем себе в удовольствии проиллюстрировать и эти метрики наглядным рисунком.
Рисунок 6.
где
В качестве символа измерителей времени выбрано условное изображение часов, так как в реальности именно с помощью внутренних часов (точнее таймера) и происходят измерения. Мнениям иных авторов, что следует использовать только специализированное оборудование, так как якобы внутренние часы устройств недостаточно верны, мы бы не доверяли. В определении 6 мы сказали практически всё необходимое на эту тему и повторять аргументы смысла не видим.
А вот вопрос стоит ли измерять все указанные задержки или следует ограничиться только средним, вопрос интересный, дискуссионный и для кого-то, возможно, даже пахнет кандидатской. Пока мы полагаем, что стоит измерять все указанные виды задержек. Информации много не бывает при поиске причин неисправностей. Вот среднее квадратичное мы хотя и могли бы ввести, но пока не знаем, как его правильно применить. Поэтому полагаем излишним. А вот минимальное, среднее арифметическое и максимальное — это основа статистики, они нам пригодятся в любом случае. Ну и дискуссия о «нормальных» значениях тоже будет.
Ну и в финале определения первичных метрик не откажем себе в удовольствии устроить заочную полемику с отраслевым стандартом Y.1540. Ему многие поклоняются, как божеству, но писали его люди, они склонны ошибаться, а на ошибках надо учиться, а не поклоняться им без страха и упрёка. Итак, IPER или Internet Protocol packet Error Ratio. Кто‑то решил, что будет полезно измерять процент IP‑пакетов, доставленных с ошибкой. Не отрицая, что на каналах связи ошибки встречаются (см. выше в разделе 1.1), более того, подчёркивая, что эти события на некоторых физических средах являются более‑менее естественным явлением, мы тем не менее всегда помним, что эксплуатируем‑то мы всю сеть, как единое целое. А на сети TCP/IP ошибки купируются после приёма на коммутатор или маршрутизатор и дальше в исходящий интерфейс или в процесс, открывший сокет, не передаются! Странно, что вроде бы грамотные люди, писавшие Y.1540, не увидели очевидного: За пределами одного канала измерять процент ошибочно доставленных IP‑пакетов не имеет смысла! Ошибки по сети TCP/IP не транслируются в отличие от сетей с коммутацией каналов. Поэтому даже если на измерительном устройстве вы подмените своим приложением стек TCP/IP и доведёте ошибку в пакете до подпрограммы, способной увеличить счётчик на один, вы получите только ошибки «последнего дюйма». Это точно то, что вы ожидали? Жизненный опыт связистов подсказывает, что нет.
Именно по этой причине, хотя и зная, что ошибки на каналах есть, мы тем не менее вводить метрику, аналогичную Y.1540 IPER, не будем, считая этот увлекательный процесс стрельбой из единорогов Шувалова по воробьям.
cc: net-probe, telegraph, vk, telegram: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16, lj
Далее...