Учебник по мониторингу Интернет & Pinger в SLAC

Введение

Для обеспечения лучшего ожидание производительности сети между сайтами, что сотрудничает с SLAC в мае 1996 проект Pinger (начат в 1995 Janary) мониторинг о 100 хостов по всему миру от SLAC. С 2000 года основной упор делается больше на измерении цифрового разрыва. В настоящее время (апрель 2007 года) насчитывается более 35 площадок мониторинга , более 700 удаленных объектах контролируется более чем в 120 странах (содержащие более 99% из миров, подключенного к Интернету населения) и более 3000 монитор месте удаленных узлов пар включены. Подробнее о размещении Pinger можно найти в Pinger развертывания и есть карта из сайтов.

Механизм

Основной механизм используется управляющих сообщений Internet Protocol (ICMP) Эхо механизм, известный также как пинг объекте. Это позволяет отправлять пакеты выбранного пользователем длины к удаленному узлу и он возвращается обратно. В настоящее время она обычно поставляется с предварительно установленной почти на всех платформах, так что нет ничего, чтобы установить на клиентах. Сервер (т.е. эхо reponder) работает с высоким приоритетом (например, в ядро ​​Unix), и поэтому, скорее всего, обеспечит хороший показатель производительности сети, чем пользователь приложения. Это очень скромны в своих требований к пропускной способности сети (~ 100 бит в секунду на одно-мониторинг удаленных хост-пар за то, как мы используем его).

Метод измерения

В проекте Пингер, каждые 30 минут крон от контроля узла (Измерение Point – MP), то эхо-набора удаленных узлов 11 пинг из 100 байтов (число 8 байт ICMP, но не IP-заголовок). Пинги разделены по крайней мере, одно второе, и тайм-аут по умолчанию пинг 20 секунд используется. Первый пинг выбрасывается (предполагается, будет медленным, поскольку она является основным фактором развития кэши и т.д. (Martin Horneffer в http://www.advanced.org/IPPM/archive/0246.html сообщает, что использование UDP-пакеты и эхо между поступлениями времени около 12,5 секунд первого пакета занимает около 20% больше времени, чтобы вернуться)). Минимальное / среднее / максимальное время отклика для каждого набора 10 пинг записывается. Это повторяется в течение десяти пинги 1000 байтов данных. Использование двух размеров пинг пакетов позволяет сделать оценки пинг скорость передачи данных, а также обнаружить поведения, которые отличаются между малыми и крупными пакетами (например, ограничение скорости). См. Большая по сравнению с мелкими пакетами , сроках пинг измерений для более подробной информации. В общем мс пропорциональна л (где л длина пакета) до максимального размера дейтаграмм (обычно 1472 байт, включая восемь байт ICMP эхо). Поведение за что не определено (некоторые сети фрагментировать пакеты, другие выбывают их). Документация по рекомендованной сценарий измерений, которая работает на каждом мониторинге сайт доступен. Пинг раз реагирования построены для каждого получаса для каждого узла. В основном это используется для устранения неисправностей (см., например, если это стало резко хуже, в последние несколько часов).

Набор удаленных хостов пинг обеспечивается файл с именем pinger.xml (подробнее об этом см. pinger2.pl документации ). Этот файл состоит из двух частей: Beacon хозяева , которые автоматически подается ежедневно с SLAC и контролируются все депутаты, другие хосты, которые представляют особый интерес к администратору депутат. Beacon хостов (и конкретных хостов контролируется SLAC MP) хранятся в базе данных Oracle содержащие их имена, IP-адреса сайта, имя, местонахождение, контактные и т.д. Beacon списка (перечень конкретных хостов СЛАКа) и копии базы данных, в формате, который упростит доступ Perl для анализа сценарии, которые автоматически генерируются из базы данных на ежедневной основе.

Сбор данных

Архитектура мониторинга включает в себя 3 компонента:

  • Удаленный мониторинг сайтов. Они просто обеспечивают пассивную встроенным интерфейсом с соответствующими требованиями.
  • Мониторинг сайта. Pinger инструменты мониторинга должна быть установлена ​​и настроена на хост на каждом из этих сайтов. Кроме того, данные, собранные пинг должна быть доступна для архиве хранятся с помощью HyperText Tansport Protocol (HTTP) (то есть должны быть веб-сервер для предоставления данных по требованию через Интернет). Есть также Pinger инструменты, позволяющие мониторинг сайт, чтобы быть в состоянии обеспечить короткие сроки и анализ отчетов о данных, которые он имеет в своем локальном кэше.
  • Архив и анализа сайтов. Там должно быть по крайней мере, по одному из них для каждого проекта Pinger. Архив и анализа сайтов, может быть расположен в одном месте, или даже одного хозяина, или они могут быть разделены. HENP & ESnet Проект состоит из двух таких сайтов, по одному HEPNRC на ФНАЛ , другой в SLAC . HEPNRC сайт является основным arcive сайта и SLAC основным местом анализа. Они дополняют друг друга, обеспечивая доступ к различным отчетам получить, анализируя данные, собранные, например HEPNRC предоставляет карты временем отклика и потерь в зависимости от времени на спрос на отдельных участках и временные окна, в то время SLAC содержит таблицы более обширных метрики возвращаюсь в течение более длительного период. Проект XIWT имеет свой ​​архив / монитора сайте CNRI.

Архив сайтов собирать информацию, используя HTTP, от монитора сайтов на регулярной основе и архиве. Они обеспечивают архивных данных к анализу сайт (ы), что в свою очередь предоставляют отчеты, доступные через Интернет.

Данные собираются собираются на регулярной основе (как правило, ежедневно) от мониторинга узлов двумя архиве хранятся, по одному за другим SLAC ФНАЛ (HEPNRC), которые хранят, анализируют анализ , подготовить и через Интернет предоставляет отчеты pingtable на результаты (см. рисунок ниже).

Архитектура Pinger показана ниже:

1

Gotchas

Некоторые осторожность необходима при выборе узла для проверки связи (см. Требования к WAN Хосты контролируется ).

Мы также наблюдаются различные патологии с различными удаленными узлами при использовании пинг. Они описаны в Патологии
Pinger измерения.

Калибровки и контекст, в котором круглый метрики поездки измеряются описаны в Pinger Калибровка и контекст , и некоторые примеры того, как результаты пинг смотреть, когда принято с высокой статистикой, и как они связаны с маршрутизацией, можно найти в высокий пинг статистику результатов.

Утверждение

Мы подтвердили ценность пинг, продемонстрировав, что измерения, проведенные с ним коррелируют с отклика приложений. Корреляция между нижней границ Web и пинг ответов видно на рисунке ниже. Измерения проводились 18 декабря 1996 года, с SLAC около 1760 объектов, определенных в NLANR кэшей . Для получения дополнительной информации см. влиянии интернета на Таймс Производительность веб ответ , Леся Коттреллом Гальперина и Джона, неопубликованные, январь 1997 года.

Замечательно ясное нижней границей видел вокруг у = 2х не удивительно, так: наклон 2 соответствует HTTP получает, что уйдет в два раза пинг время, время минимальное время отклика составляет примерно время прохождения, а также минимальные сделки TCP включает две поездки , одной поездки для обмена секунду для отправки запроса и получения ответа. Завершения соединения делается асинхронной работы и поэтому не отображаются в сроках.

Точечная диаграмма мин HTTP GET против мин Пинг (30951 байт)

2

Нижняя граница также может быть визуализированы отображения распределение остатков между измерениями и прямой у = 2 х (где у = HTTP GET время отклика и х = минимальное время отклика Ping). Такое распределение показано ниже. Круто в складку в частотных измерений по мере приближения нуля остаточной стоимости (у = 2х) очевидна. Интер Квартиль Range (МКР), остаточный пробег между тем, где 25% и 75% измерений падать, составляет около 220 мс, и указывается на участке красной линией.

Остатков для HTTP = 2 * Мин пинг реагирования (37218 байт)

3

Альтернативный способ демонстрации того, что пинг связан с веб-производительности, чтобы показать, что пинг могут быть использованы для прогнозирования который из набора репликации веб-серверов, чтобы получить веб-страницу из. Более подробно об этом см. динамического выбора сервера в Интернете , Марк Э. Crovella и Роберт Л. Картер.

Firehunter Case Study веб-сервера Уайтхаус показал, что, хотя пинг ответа не отслеживает нарушений в работе веб-Ну, в этой потере пакетов пинг случай сделал гораздо лучше.

Интернет качеством обслуживания оценку христианскими Huitema, обеспечивает измерения различных компонентов, которые способствуют веб ответ. Эти компоненты включают: время отклика, скорость передачи данных, DNS задержки, задержки связи, серверов задержки, задержки передачи. Это показывает, что задержки между отправкой команды GET URL и приемом первого байта Reponse является оценкой сервере задержкой (“во многих серверов, хотя и не обязательно все, эта задержка соответствует времени, необходимого для планирования запросов страниц , подготовки страницы в памяти и начать посылать данные “) и представляет между 30 и 40% от продолжительности средней транзакции. Чтобы облегчить это, вы, вероятно, нужны более мощные серверы. Получение быстрого соединения, очевидно, помочь другим 60% просрочки.

Также см. ниже раздел, посвященный Номера пинг инструментов для некоторых корреляций с пропускной время прохождения и потери пакетов.

Что мы измеряем

Мы используем пинг для измерения времени отклика (время передачи миллисекунд (мс)), процент потери пакетов, изменчивость времени реакции как краткосрочные (временной масштаб секунд), и дольше, и отсутствие достижимости , то есть не ответ для последовательности пинг. Для обсуждения и определения доступности и доступности см. Интернет Производительность: анализ данных и визуализации Белая книга по XIWT . Также см. NIST документ о Концепции системы Fault Tolerance для больше на различие между надежностью и доступностью. Мы также записать информацию на не в порядке дублировать пакеты и пакеты.

С данными измерений, мы можем создать долгосрочные исходные данные для ожидания на средства / медианы и изменчивости время отклика , пропускная способность , и потери пакетов . С помощью этих исходных показателей в месте мы можем установить ожидания, обеспечить планирование информации, сделать экстраполяцию и отыскать исключениями (например, время отклика, более, чем на 3 стандартных отклонения больше, чем в среднем за последние 50 рабочих дней) и выдавать предупреждения.

Потеря

Потеря является хорошим показателем качества связи (с точки зрения его количества пропущенных пакетов) для многих приложений на основе TCP. Потери как правило, вызваны перегрузкой которая в свою очередь вызывает очереди (например, в маршрутизаторах), чтобы заполнить и пакетов, которые будут сняты. Потери могут быть также вызваны сеть доставки несовершенный копию пакета. Это обычно вызвано битных ошибок в ссылки или сетевых устройств. Paxson (см. впритык Динамика пакетов ) из измерений, проведенных в 1994 и 1995 годах к выводу, что большинство ошибок коррупцией пришли из каналов T1, а типичная скорость составила 1 случай на 5000 пакетов. Это соответствует частота ошибок по битам для 300byte среднем пакете примерно 1 из 12 миллионов бит. ИС имеет 16 бит контрольной суммы, так что вероятность не обнаружения ошибки в поврежденный пакет составляет 1 к 65 536, или примерно 1 300 000 000 пакетов.

Более позднее исследование на Когда CRC контрольной суммы TCP и согласен опубликован в августе 2000 года, показывает, что следов интернет-пакеты в течение последних двух лет показывают, что 1 из 30 000 пакетов TCP не проходит контрольную сумму, даже на ссылки, где канального уровня ЗПК должны поймать всех но в 1 4000000000 ошибок. Эти TCP контрольной суммы ошибки более высокого уровня (например, они могут быть вызваны шины ошибки в сетевых устройств или компьютеров, или с ошибками стек TCP), чем ссылка уровень ошибок, которые должны быть пойманным проверки CRC.

Время отклика

Время отклика или Туда и обратно Time (RTT), когда заговор против размер пакета может дать представление о том, пинг скорость передачи данных (кило байт / с (кб / с)) – см., например, ТРИУМФ в Visual-Пинг утилиты. Это становится более трудным при переходе к высоким ссылки производительность, поскольку пакет диапазон является относительно небольшой (обычно <1500bytes), и сроки resoltion ограничено. RTT связано с расстоянием между узлами плюс задержка на каждом переходе на пути между сайтами. Расстояние эффекта можно условно характеризуется скоростью света в волокне, и примерно задается расстояние / (0,6 * C), где с-скорость света (ITU G.144 в документе, таблице A.1 рекомендует множитель 0,005 мс / км, или 0.66c). Подставляя это вместе с задержками хоп, R RTT грубо определяется по формуле:

R = 2 * (расстояние / (0,6 * C) + хмель * задержка)

где фактор 2, так как мы измеряем туда и обратно раз за туда-обратно. Это показано на рисунке ниже, которая показывает измеренный отклик пинг как функция расстояния между парами 16 участков, расположенных в США, Европе и Японии (Болонья-Флоренция, Женева-Лион, Чикаго U-Нотр-Дам, Токио -Осака, Гамбург-Дрезден, Болонья-Лионе, Женеве, Майнц, Питтсбург-Cincinnatti, Женева-Копенгаген, Чикаго-Остин, Женева-Лунд, Чикаго-Сан-Франциско, Чикаго, Гамбурге, Сан-Франциско, Токио, Сан-Франциско и Женева Женева-Осака). Синие треугольники для измеряемого отклика (в миллисекундах), черная линия соответствует данным, зеленая линия для у = х (расстояние) / (0,6 * С), а красные точки раза в хопа задержки с задержкой / прыгать около 2,25 мс для каждого направления (т.е. красными точками являются теоретические подходят RTT). Мы использовали Как далеко это? веб-страницу, чтобы получить “по прямой” расстояния между основными точками вдоль каждого маршрута. В последнее время Measuremet сделал Марк Шпиллер в марте 2001 года до примерно 10 университетов из Калифорнийского университета в Беркли измеренной задержки маршрутизатора 500-700 мкс с несколькими шипами в диапазоне 800-900 мкс.

4

Протяженность маршрута (R км) может быть использована в местах расстояние для некоторой задержки передачи кадра (FTD) целей деятельности. Если D является км воздушных маршрутов расстояния между границами, то длина маршрута рассчитывается следующим образом (это те же вычисления, которые содержатся в документе ITU G.826).

  • Если D км
  • Если 1000 км <= D км <= 1200 км, то R = 1500 км км
  • Если D км> 1200 км, то R = 1,25 км * D км

Это правило не применяется, если есть спутниковое в маршруте. Если спутник присутствует в любой части маршрута, эта часть выделяется фиксированный FTD 320 мс. Значение 320 мс учитывает такие факторы, как низкий земной станции углы обзора, и прямого исправления ошибок кодирования. Большинство частей, которые содержат спутника ожидается, не превысит 290 мс задержки. Если это геостационарный спутник то нижний предел на геостационарной орбите находится между 22 000 и 23 000 миль, скорость света ~ 186 000 миль, подсчитывать и обратно 45 000, а туда-обратно составляет 90 000 миль, так что мы получаем 500 мс тут .
Это минимальное время отклика удлиненные вызвано геостационарных спутников обеспечивает полезную подпись на идентичность ТАГТ маршрут между монитором и включает в себя целевую гео-staionary спутник. Пример можно увидеть на рисунке 5 из 2011 – 2012 года Доклад ICFA-SCIC мониторинга рабочая группа.

Задержки на каждом транзитном являются функцией из 3 основных составляющих: скорость маршрутизатор, интерфейс синхронизации Цены и очереди в маршрутизаторе. Первые два являются постоянными на короткие (несколько дней) периодов времени. Таким образом, минимальный RTTs дать мера расстояния / (0,6 * с) + хмель * ((скорость интерфейса / размер пакета) + минимальное время пересылки маршрутизатору). Это число должно быть линейной функцией от размера пакета. Эффекты маршрутизатор очереди, с другой стороны, являются зависимыми от более случайным очереди процессов и поперечное движение и поэтому более переменных. Это проиллюстрировано на MRTG участке ниже, которая показывает очень стабильные минимальные RTT (зеленая зона) и более случайным максимальной RTTs (синие линии) измеряется от SLAC находятся Университет Висконсина от воскресенье 25 февраля 2001 года на понедельник 5 апреля 2001. Маленький всплеск в RTT около полудня вторника, вероятно, вызвана изменением маршрута.

5

Номера пинг инструментов

SLAC также Surveyor сайта. Инспектор делает один из способов измерения задержки (без использования ICMP) с использованием системы глобального позиционирования (GPS) устройства для синхронизации времени, и выделенные мониторинга / удаленными хостами. Мы работаем над сравнением Pinger и Surveyor данные сравнить и сопоставить эти два метода и проверить действительность ICMP эхо. Одна из проблем, поднятых с ICMP эхо возможности Интернет-провайдеры (ISP) скорость limititing ICMP эхо и тем самым вызывая недействительным измерения потерь пакетов, подробнее об этом см. раздел о Gotchas выше.

Мы также использовать более сложные инструменты, такие как FTP (для измерения объемной скорости передачи) и Traceroute (для измерения пути и количество прыжков). Однако, помимо того, что сложнее в настройке и автоматизации, FTP является более навязчивым в сети и более зависимыми от конца загрузки узла. Таким образом, мы используем FTP в основном в ручном режиме и получить представление о том, насколько хорошо работа пинг тесты (например Корреляция между FTP и пинг и корреляции между FTP пропускную, хмель и потери пакетов ). Мы также сравнили Pinger предсказания с пропускной Netperf измерений . Другой способ измерения пропускной коррелируют с потерей пакетов является пропускная Моделирование TCP.

Расчет среднего балла мнения (MOS)

Телекоммуникационная отрасль использует средний балл мнения (MOS) в качестве показателя качества голоса. Значения MOS: 1 = плохо, 2 = плохо, 3 = удовлетворительно, 4 = хорошо, 5 = отлично. Типичный диапазон для передачи голоса по IP-от 3,5 до 4,2 (см. VoIPtroubleshooter.com ). На самом деле, даже идеальное соединение влияние алгоритмы сжатия этого кодека, поэтому наибольшее количество очков Большинство кодеков может достичь в 4,2 до 4,4 диапазон. Для G.711 лучших является 4.4 (или фактор R (см. Рекомендацию МСЭ-Т G.107, “E-модели, вычислительная модель для использования в планировании передачи.”) 94,3) и G.729, который выполняет значительное сжатие это 4.1 (или фактор R 84,3).

Есть три фактора, которые существенно влияют на качество связи: задержки, потери пакетов, джиттер. Другие факторы включают тип кодека, телефон (аналоговый против цифровой), АТС и т.д.) мы увидели, как рассчитать джиттера позже в этом учебнике. Большинство инструментов решения на основе расчета так называемого “R” значение, а затем применить формулу для преобразования, что оценка MOS. Мы делаем то же самое. Это R для расчета MOS относительно стандарта (см., например, МСЭ – Сектор стандартизации электросвязи временный документ XX WP-E 2/12 для нового метода). Счет R значения от 0 до 100, где более высокое количество, тем лучше. Типичные для R MOS значения: R = 90-100 => MOS = 4.3-5.0 (очень довольны), R = 80-90 => MOS = 4,0-4,3 (удовлетворен), R = 70-80 => MOS = 3,6 -4,0 (некоторые неудовлетворенность), R = 60-70 => MOS = 3,1-3,6 (более неудовлетворенность), R = 50-60 => MOS = 2,6-3,1 (Большинство неудовлетворенность), R = 0-50 => MOS = 1.0-2.6 (не рекомендуется). Чтобы преобразовать задержки, потери, джиттера MOS мы следуем методу Nessoft автора . Они используют (в псевдо-код):

# Возьмите среднюю круглые Задержка поездки (в миллисекундах), добавить
# Путешествие туда и обратно джиттера, но два раза сильнее влияет на задержку
# Затем добавить 10 для задержки протоколов (в миллисекундах).
EffectiveLatency = (AverageLatency джиттера + * 2 + 10)
# Реализация основной кривой – отнимите по 4 для значения R на 160 мс латентности
# (Туда и обратно). Все, что свыше, которое получает гораздо более агрессивным вычет.

Если EffectiveLatency <160, то
R = 93,2 – (EffectiveLatency / 40)
еще
R = 93,2 – (EffectiveLatency – 120) / 10

# Теперь давайте вычесть 2,5 R значений на процент потери пакетов (т.е.
# Потере 5% будет введена как 5).
R = R – (потерянные пакеты * 2,5)

# Конвертируем в R значения MOS. (Это известная формула)
Если R <0, то
MOS = 1
еще
MOS = 1 + (0,035) * R + (0,000007) * R * (R-60) * (100-R)

Расчет вклада сети времени транзакций

МСЭ придумали метод для расчета вклада сети транзакции время в МСЭ-Т Rec.G1040 “вклада сети время транзакции” . Вклад зависит от RTT, вероятность потерь (P), повторная передача Time Out (RTO) и количество циклов участвуют (N) в транзакции. Вклада сети транзакцию время (NCTT) определяется как:
Неплохо (NCTT) = (N * RTT) + (P * N * RTO)

Типичные значения п 8, МРК мы берем 2,5 секунды, мы берем время отклика и вероятность потери (р) из измерений Pinger.

Получение TCP пропускную от пинг измерений

Макроскопического поведения во избежание заторов TCP алгоритм по Матис, Семке, Mahdavi & Ott в связи компьютера Обзор, 27 (3), июль 1997 г., содержит краткое и полезную формулу для верхней границы на скорость передачи данных:

Оцените <(MSS / RTT) * (1 / SQRT (P))
где:

Оценить: это скорость передачи TCP
MSS: максимальный размер сегмента (устанавливается для каждого Интернет путем, обычно 1460 байт)
Время отклика: является время прохождения (по данным ПТС)
р: это скорость потери пакетов.

Строго говоря, потери TCP убытки, которые могут не совпадать с пинг потерь (например, стандартное TCP вызывает потери в рамках своей оценке заторов). Также пинг RTTs отличаются от того, как TCP оценивает RTT (см., например, улучшение туда и обратно в оценках Время надежного транспортного протокола.) Тем не менее, особенно для низкой производительностью ссылки это разумная оценка.

Улучшенная форма этого уравнения можно найти в: пропускная способность TCP моделирования: простые модели и ее эмпирической проверки Дж. Padhye, В. Firoiu, Д. и Дж. Townsley Kurose, в Proc. SIGCOMM симпозиума. Связь архитектуры и протоколы августа 1998, стр. 304-314.

Поведение пропускная способность в виде функции потерь и RTT можно увидеть, глядя на Пропускная против мс и потери . Мы использовали приведенной выше формуле для сравнения Pinger и Netperf измерения пропускной способности.

Нормализация производный пропускная

Для уменьшения эффекта 1/RTT в формуле Mathis для производных пропускной способности, нормировать пропускной помощью
norm_throughput = расход * min_RTT (дистанционной) / min_rtt (monitoring_region)

Непосредственность связи

Это метрическая определить непосредственность связи berween 2 узла при известных местах. Непосредственность значений, близких к одному виду путь между узлами примерно следующим большим кругом маршрута. Значения намного меньше, чем 1 означает путь очень косвенным. Вывод прямотой коэффициент дается здесь .

RTD = круглый пройденный путь,
RTD [км] = Альфа “* min_RTT [мс] * 200 [км / мс]
Альфа позволяет за задержки в сетевом оборудовании и опосредованности фактического маршрута.
D = 1 способ расстоянии
Альфа = D (км) / (min_RTT [мс] * 100 [км / мс])

Макс (Alpha) = 1 = прямой (большой круг) маршрут и не время задержки в сети
Альфа обычно ~ 0,45
Низкие значения как правило, означает очень косвенным путем, или спутниковый или медленного соединения (например, беспроводной)
Альфа> 1, вероятно, определяет неправильные координаты для хостов.

Доступ к данным

Необработанные данные пинг публично доступна, см. Доступ к Pinger данных о том, как получить данные и формат. Сводных данных также доступна из Интернета в Excel разделенными табуляцией-значение (. TSV) формат отчетов Pinger подробно .
Pinging узлов коллаборационистов

Анализ данных и презентации

Ежедневно участков
Раз пинг ответа построены для каждого получаса для каждого узла, чтобы увидеть некоторые современные примеры пойти создавать графики производительности сети . В основном это используется для устранения неисправностей (см., например, если это стало резко хуже, в последние несколько часов).

6

Построив 3D участок узла в зависимости от времени по сравнению с ответом мы можем искать корреляции нескольких узлов, имеющих плохую работу или быть недоступным в то же время (возможно из-за общего дела), или данного узла, имеющего слабую реакцию или быть недоступным для длительного времени. Слева пример, показывающий несколько хостов (в черном) все бытие недоступных приблизительно 12 полудня.

Последние 180 дней участков:

Долгосрочные графики, показывающие время отклика, потери пакетов и недоступности за последние 180 дней можно также указать, является ли услуга становится все хуже (или лучше).

Ежемесячные Ответ пинг и потеря средние возвращаемся в течение года:

Таблицы ежемесячно медианы в прайм-тайм (7 утра до 7 вечера буднего) 1000 байт пинг время отклика и 100 байт пинг потери пакетов позволяет просмотреть данные за более длительный срок. Это табличные данные можно экспортировать в Excel и диаграмм сделаны из длинных производительности пинг термин потери пакетов.

7

Покоя частоты сети

Когда мы получаем нулевую потерю пакетов образца (образец относится к набору пингов N), мы обращаемся к сети как покоя (или не занят). Затем можно измерить процент частоты, как часто сети было обнаружено, что покоя. Высокий процент является показателем хорошего (в состоянии покоя или не сильно загружена) сети. Например, что сеть занята 8 рабочих часов в день недели, и покоя в другое время будет иметь покоя процент около 75% ~ (total_hours / неделя – 5 рабочих дней / неделю * 8 часов / день) / (total_hours / неделю) . Этот способ представления дэ потерь похожа на намерение телефону метрики безошибочную секунд.

Покоя частот сети таблица показывает процент (частота) образцов (где образец представляет собой набор из 10 100 пинг байт), измеренной нулевой потерей пакетов. Образцы, включенных в каждый процент сообщает все образцы для каждого участка каждого месяца (то есть порядка 30 дней * 48 (30 периодов мин) или около 1440 проб) на сайте / месяц.

Джиттера, см. также джиттера,

Краткосрочная изменчивость или “дрожание” время реакции очень важно для приложений реального времени, таких как телефония. Просмотр веб-страниц и почты довольно устойчивы к дрожанию, но любые потоковые медиа (голос, видео, музыка) вполне suceptible джиттера. Дрожание является симптомом, что есть заторы, или не хватает Полоса пропускания для обработки трафика. Джиттера определяет длину VoIP кодеков буфера устранения дрожания для предотвращения чрезмерного или недостаточного потока. Целью могло бы указать, что говорят 95% вариаций задержки пакетов должна быть в интервале [-30msec, +30 мс].

МСЭ имеет Предлагаемый метод измерения вариации задержки пакета . Это требует инъекционного пакеты через регулярные промежутки времени в сети и измерения изменчивости времени прибытия. IETF имеет IP вариация задержки пакета метрика для IP показатели эффективности (IPPM) (см. также RTP: Транспортный протокол для приложений реального времени и RFC 2679).

Мы измеряем мгновенной изменчивости или “дрожание” в двух направлениях.

  • Пусть I-го измерения время прохождения (RTT) быть R I, то возьмем “дрожание”, как Интер Квартиль Range (МКР) частоты распределения R. См. СЛАК <=> CERN задержки на двустороннее распространение в качестве примера такого распределения.
  • Во втором методе расширить IETF Проект на мгновенные вариации задержки пакетов метрика для IPPM , которая является односторонней метрики для двусторонней пинг. Возьмем IQR частотного распределения ДР, где д-р I = R-R я I-1. Следует отметить, что при расчете DR пакеты не должны быть смежными. См. СЛАК <=> CERN двусторонний мгновенное изменение задержки пакета для примера такого распределения.

Оба указанных выше распределения можно рассматривать как негауссову именно поэтому мы используем IQR вместо стандартного отклонения в качестве меры “дрожания”.

Просматривая Ping “дрожания” между SLAC и ЦЕРН, DESY и ФНАЛ видно, что два метода расчета джиттера трек хорошо друг друга (первый метод помечен IQR и второго меченого IPD на рисунке). Они различаются на два порядка magntitude в течение дня. Джиттера между SLAC и ФНАЛ значительно ниже, чем между DESY и SLAC или ЦЕРН. Следует также отметить, что CERN имеет большее дрожание во время европейской дневное время DESY имеет большее дрожание в дневное время США.

Мы также получены мерой дрожание посредством получения абсолютного значения DR, т.е. | Д |. Это иногда называют “метод скользящего диапазона” (см. Статистические Проектирование и анализ экспериментов, Роберт Л. Мейсон, Ричард Ф. гость и Джеймс Л. Гесса. John Wiley & Sons, 1989). Он также используется в RFC 2598 в качестве определения дрожания ( RFC 1889 имеет другое определение джиттера для реального использования времени и расчета) См. Гистограмма Диапазон перемещения для примера. На этом рисунке, пурпурной линии находится в общей сложности, на синей линии, exponentail соответствует данным, а зеленая линия подходит степенных рядов данных. Отметим, что все 3 строчки хит-парадов в этом разделе на джиттера представлений идентичными данными.

8

Для того, чтобы более точно понять требования к VoIP и, в частности последствия применения качества обслуживания (QoS) меры, мы создали тестовую VoIP между SLAC и LBNL. Грубая схема показана с правой стороны. Только СЛАК схема половина показана в схематическом, LBNL конец аналогично. Пользователь может поднять телефон, подключенный к УАТС в SLAC конца и позвонить другому пользователю на телефон в LBNL через маршрутизатор Cisco VoIP шлюз. Шлюз кодирует, компрессы и т.д. голосовой поток в пакеты IP (с использованием G.729 стандарт) создание примерно 24kbps трафика. Поток VoIP включают в себя как TCP (для сигнализации) и UDP пакеты.

Подсоединение маршрутизатора ESnet в облако банкомата 3,5 Mbps ATM постоянный виртуальный канал (PVC). При отсутствии конкурирующих транспортных потоков на ссылку, установления соединения и разговор протекает нормально с хорошим качеством. Затем мы вводим 4 Мбит трафика на общий 10 Mbps Ethernet, что маршрутизатор VoIP подключен. На данном этапе, связь VoIP нарушается, и Никаких дополнительных соединений могут быть сделаны. Затем мы использовали совершенные доступа граничного маршрутизатора Тариф (CAR) функцию, чтобы маркировать пакеты VoIP “, установив в Hop Behavior (PHB) бит. Маршрутизатор ESnet затем устанавливается использовать Weighted Fair Queuing (WFQ) функция ускорить VoIP пакетов. В этой установке голосовых соединений может быть снова сделал, и разговор снова хорошего качества.

Служба Предсказуемость

Мера изменчивости службы (или пинг предсказуемость ) могут быть получены с помощью точечной диаграммы безразмерных переменных среднесуточной пинг скорость передачи данных / максимальная скорость передачи данных пинг против среднесуточной успеха Ping / максимальный успех пинг (где% успеха = ( Всего пакетов – потерянных пакетов) / Всего пакетов). Здесь пинг скорость передачи данных определяется как (2 * байт пинг пакета) / время отклика. 2, так как пакет должен выйти и вернуться обратно. Еще один взгляд на отношения в том, что рядом с номерами 1, показывают, что средняя производительность близка к лучшей производительности. Числа не близка к 1, как правило, вызвано большим изменениям в пинг время между работой и нерабочие часы работы, см., например, ответ на пинг УКД 3 октября 1996 для примера суточных вариаций. Некоторые примеры пинг предсказуемость разброс участков для различных частей Интернета при измерении от SLAC в Июль 1995 по март 1996 года можно увидеть ниже.

Дата Все хосты ESnet Северной Америке Международный

Дата Все хосты ESnet Северной Америке Международный
Июль ’95 все jul95 ЭСВТ jul95 Северной Америки jul95 международные jul95
Мар ’96 все mar96 ЭСВТ mar96 Северной Америки mar96 международные mar96

Можно уменьшить эту диаграмму рассеяния дальнейшей информации, откладывая ежемесячно Средний пинг пакетов успеха / максимальный успех пинг пакетов по сравнению с среднемесячной пинг thruput / максимальный пинг thruput для различных месяцев, чтобы увидеть изменения. Такой график в течение нескольких N. Американский узлов в Июль 1995 по март 1996 года показывает большие изменения во всех случаях бытие в худшую сторону (последнее более пунктов к нижней левой части участка).

Непредсказуемость

Можно вычислить и расстояние до каждого предсказуемость точки от начала координат (1,1). Мы нормализовать к максимальному значению 1 путем деления расстояния от SQRT (2). Я называю это пинг непредсказуемости, так как он дает процентный показатель непредсказуемости пинг производительности.

Достижимости

Глядя на пинг данных для выявления 30-минутных периодов, когда ни пинг не было получено ответов от данного хоста, можно определить, когда хозяин был вниз. Используя эту информацию, можно вычислить пинг недоступности = (# периодов с узлом вниз / общее количество периодов), # периодов простоя, среднее время наработки на отказ (MTBF или среднее время Failue MTTF)) и среднее время ремонта (MTTR). Обратите внимание, что MTBF = sample_time / ping_unreachability где за время Pinger образца составляет 30 минут. Достижимости очень зависит от удаленного хоста, например, если удаленный хост переименовать или удалить, хозяин появится недоступным все же не может быть ничего плохого в сети. Таким образом, прежде чем использовать эти данные, чтобы обеспечить долгосрочные тенденции сети данные должны быть тщательно удалено для не-сетевые эффекты. Примеры достижимости пинг и вниз докладов.

Можно также измерять частоту отключения длины с использованием активных зондов и отмечая продолжительность времени, для которого последовательное зонды не пройти.

Другой показатель, который иногда используется для указания наличия телефона схема не содержит ошибок секунд. Некоторые измерения на этом можно найти в ошибках бесплатных секунд между SLAC, FNAL, КМУ и ЦЕРН.

Существует также IETF RFC на измерение подключения и документ о современной таксономии высокой доступности , которые могут быть полезны.

Не в порядке пакеты

Pinger использует очень простой алгоритм для идентификации и отчетности в порядке пакетов. Для каждого образца из 10 пакетов, он посмотрит, если порядковые номера ответы получены в том же порядке, что и были направлены запросы. Если нет, чем у образца, помеченного как имеющий одну или более из строя ответов. Для данного интервала (скажем, за месяц) значение для НУ сообщил порядка есть доля образцов, которые были отмечены из ответов порядке пинг. Так как пинг пакеты посылаются интервалом в одну секунду, ожидается, что доля из заказа образцов будет очень мал, и может быть стоит расследование всякий раз, когда это не так.

Дублированных пакетов

Дубликат пинг ответы могут быть вызваны:

Более одного хоста имеет тот же адрес IP, так что все эти хозяева ответят на ICMP эхо-запроса.
IP-адрес может быть пингуется широковещательный адрес.
Хоста несколько стеков TCP связан с адаптером Ethernet (см. http://www.doxpara.com/read.php/tcp_chorusing.html).
Маршрутизатор считает, что есть два пути, по которым он может дойти до конца хозяина и (по-видимому ошибочно) вперед ICMP эхо-запросы по обоим маршрутам, таким образом, к концу хозяин видит два эхо-запросы и отвечает дважды.
Там, может быть два или более (без маршрутизации) путями к хосту конца и каждый запрос передается более чем один путь.
Неправильно NAT коробки.

Некоторые тесты, которые могут помочь включают в себя:

Pinging маршрутизаторов по маршруту, чтобы увидеть, если любой из них ответит дубликатов.
Захват пинг пакеты и посмотрите, если все пакеты возвращаются с того же адреса Ethernet.

Идея prvalence дублированных пакетов пинг происходит от Pinger измерений 31-го марта 2012 года по 703 хостов в более чем 600 странах. Из них 15 ответили хозяева с повторяющимися пинг. Для 13 из 15 хостов это происходило на 100 и 1000 байт пинги. Из 10 пакетами, переданными 6 хозяева 1 пинг дублированы, 5 было 2 пингует дублируется, 2 было 4 пинги дублируются, 1 было 3 пинги дублируются и возвращается 1 12 пинги для каждого Пинг отправлен. Сайтов из хозяев варьироваться от National Labs (ЦЕРН, ИФВЭ SU), развитые страны (Израиль), развивающихся стран (Буркина-Фасо, Маврикий, Малави, Сьерра-Леоне, Свазиленд, Замбия), и образовательные сайты (SDSC).

Pinger просто сообщает Wheter были дубликаты или нет. Полезная метрика сообщить количество пингов получено / количество пакетами, переданными. Номер, полученный может зависеть от варианта команды Ping. Один вариант позволяет отсылать заданного числа пинги, пока не получит, что многие спине или тайм-ауту. Другим вариантом будет отправить 10 пинги и ждать (или тайм-аут), пока они не получили. Таким образом, значение метрики может также зависеть от пинг команду.

Сочетание всех мер пинг

Можно собрать участок все вышеупомянутые меры пинг (убыток, реагирования, недоступности и непредсказуемости), чтобы попытаться показать сочетание измерений для набора компьютеров, на данный период времени. На графике ниже для 1-11 марта 1997 года, группы хостов в логические группы (ESnet, N. America West, …) и в группах занимает хостов,% 100 байт потери пакетов пинг СЛАКа прайм-тайм (7 утра – 7 вечера по рабочим дням), а также показано синей линией в прайм-тайм пинг время отклика, и отрицательное его недостижимости пинг% и непредсказуемости.

9

В приведенном выше участке, потеря и времени отклика измеряются в SLAC прайм-тайм (7 утра – 7 вечера, в будни), другие меры для всех время.

Степень потерь приведены в виде гистограммы выше у = 0 оси и на 100 байтов полезной нагрузки пакетов Ping. Горизонтальные линии обозначены на потери пакетов на 1%, 5% и 12% на границах качества связи определено выше.
Время отклика на графике как синяя линия на бревне оси, обозначенные вправо, и время прохождения пакетов 1000 байт пинг полезной нагрузки.

Хозяин недоступности построена в виде гистограммы негативно простирается от оси у = 0. Хост считается недоступным на 30 минутный интервал, если он не отвечает на любое из 21 пинг сделаны в то 30-минутного интервала.
Хозяин непредсказуемость показана на зеленый здесь как отрицательное значение, может быть в диапазоне от 0 (полностью непредсказуемые) до 1 (весьма предсказуемым) и является мерой изменчивости время пинг-ответа и потери в течение каждых 24 часов в день. Это определено более подробно в пинг непредсказуемость.

Следующие наблюдения также необходимо:

ESnet хостов в целом имеют хорошие потери пакетов (в среднем 0,79%). Средние потери пакета для других групп составляет от около 4,5% (Северная Америка Восток) до 7,7% (International). Обычно 25% -35% от хозяев в не-ESnet группы находятся в бедных плохо диапазоне.

Время отклика для ESnet хостов в среднем составляет около 50 мс, для Северной Америки Уэс она составляет около 80 мс, для Северной Америки Востоке около 150 мс и международных проживает около 200 мс.
Большинство из недоступных проблемы ограничивается несколькими хозяевами в основном в группе International (Дрезден, Новосибирск, Флоренция).

Непредсказуемость наиболее выражено в течение нескольких хостов и Международный примерно отслеживает потери пакетов.

Качество

Для того чтобы иметь возможность суммировать данные поэтому значение может быть быстро поняли, мы попытались характеризующих качество исполнения ссылки.
Задержка
Самый редкий и самый ценный товар является время. Исследования, проведенные в конце 1970-х и начале 1980-х Walt Доэрти из IBM и другие показали экономическую ценность Быстрое время отклика:
0-0.4s Высокая производительность Interactive Response
0,4-2S Полностью интерактивный режим
2-12 Спорадически интерактивном режиме
12S-600S Перерыв в контакте режима
600S Пакетный режим
Более подробную информацию о влиянии времени отклика см. Психология взаимодействия человека и компьютера, Стюарт К. Карты, Томас П. Моран и Аллен Ньюэлл, ISBN 0-89859-243-7, опубликованной Лоуренс Erlbaum Associates (1983).

Существует порог около 4-5, где жалобы быстро увеличиваться. Для некоторых новых Интернет-приложений существуют другие пороговые значения, например, для голосовой порог в одну сторону задержки появляется при температуре около 150 мс (см. Рекомендации G.114 МСЭ в одну сторону времени передачи, февраль 1996 г.) – ниже этого можно иметь звонки потери качества и выше этой точки, задержка вызывает трудности для людей, пытающихся вести разговор и разочарование растет.

Для слежения за временем в музыке, Стэнфорд исследователи обнаружили, что оптимальное количество Задержка составляет 11 миллисекунд. Ниже этой задержке и люди, как правило, чтобы ускорить. Выше этой задержки, и они, как правило, замедляется. Примерно через 50 миллисекунд (или 70), как правило, выступления полностью развалиться.

В режиме реального времени мультимедийных (H.323) Измерение и анализ трафика H.323 дает задержку в одну сторону (примерно фактора два, чтобы получить, RTT), из: 0-150 мс = хорошо, 150-300 мс = Accceptable и> 300 мс = плохо.

Для реального контроля времени и тактильной обратной связи для медицинских операций, Стэнфорд исследователи (см. Шах, А., Харрис Д., и Гутьеррес, D. (2002). “Выполнение удаленного Анатомия и хирургического применения обучения в различных условиях сети.” Мир Образовательная конференция по мультимедиа, гипермедиа и телекоммуникации 2002 (1), 662-667 ) обнаружили, что один из способов задержки <= 80msec. было необходимо.

Потеря

Для характеристики качества мы сосредоточили в основном на потери пакетов. Наши наблюдения в том, что выше 4-6% потери пакетов видеоконференций становится раздражающим, и не родным языком стал не в состоянии общаться. Вхождение длительные задержки не менее 4 секунд при частоте 4-5% или более также раздражающее для интерактивных мероприятий, таких как Telnet и X Windows. Выше 10-12% потерь пакетов существует неприемлемый уровень спина к спине потери пакетов и чрезвычайно длинным тайм-ауты, соединения начинают ломаются, и видеоконференций является непригодным для использования (см. также вопрос о передаче пакета бесполезным для мультимедиа через Интернет , где они говорят, на странице 10 “мы заключаем, что для этого видео потока, качество видео непонятно, когда ставки потери пакетов превышает 12%».

С другой стороны MSF (Глобальный форум обслуживания) заявили в результате тестов на следующий поколения для сетей IPTV “Тестирование показало, что даже половина 1% потери пакетов в видеопотоке может сделать качество видео неприемлемым для конечных пользователей» (см. Computerworld, 29 октября 2008).

Первоначально уровни качества для потери пакетов были установлены на уровне 0-1% = хорошо, 1-5% = приемлемо, 5-12% = плохо, и больше чем на 12% = плохо. Совсем недавно мы усовершенствовали уровней 0-0,1% превосходны, 0,1-1% = хорошо, 1-2.5% = приемлемо, 2,5-5% = плохо, 5% -12% = очень плохо, и больше чем на 12% = плохо. Изменение порогов отражает изменения в наш акцент, то есть в 1995 году мы были в первую очередь иметь дело с электронной почтой и FTP. Эта цитата из Верн Paxson подводит итог основной проблемой в то время: Здравый смысл среди исследователей TCP считает, что потери в размере 5% оказывает значительное негативное влияние на производительность TCP, потому что она будет в значительной степени ограничить размер окна насыщения и, следовательно, Скорость передачи, в то время как 3%, часто существенно менее серьезными. Другими словами, сложного поведения Интернет приводит к значительному изменению, когда потеря пакетов поднимается выше 3%. В 2000 году мы были также обеспокоены X-окна приложений, веб-производительности и конференций видео пакет.

К 2005 году мы были заинтересованы в реальном времени требований VoIP и начинают смотреть на голос поверх IP. Как правило, потеря пакетов в VoIP (и VoFi) не должна превышать 1 процент, который по существу означает один голос Пропустить каждые три минуты. DSP алгоритмы могут компенсировать до 30 мс недостающих данных; не больше, чем это, и отсутствие звука будет заметно для слушателей. Автомобильная сеть обмена (ANX) устанавливает порог для скорости потери пакетов (см. ANX / Авто Linx Метрики) будет меньше, чем 0,1%.

МСЭ Тифона рабочей группы (см. Общие аспекты качества обслуживания (QoS), DTR/TIPHON-05001 V1.2.5 (1998-09) технический доклад) также определил <3% потерь пакетов как хорошее,> 15% для средних деградации, и 25% для бедных деградации, для интернет-телефонии. Это очень трудно дать одно значение, ниже которого потеря пакетов дает удовлетворительные / приемлемое / хорошее качество интерактивного голосового. Есть много других переменных факторов, в том числе: задержка, джиттер, потеря пакетов Сокрытие (ПЛК), будь то случайные потери или пульсирующий, алгоритм сжатия (тяжелее сжатие использует меньше пропускной способности, но есть больше чувствительность к потере пакетов, так как больше данных содержится / потеряли в одном пакете). См., например, доклад первого ETSI VoIP качества речи Test Event , 21-18 марта 2001 года, или речь обработки, передачи и аспекты качества (ОСТ); Анонимные протокола испытаний от 2-й Речи качества Test Event 2002 ETSI TR 102 251 v1.1.1 (2003-10) или ETSI третьей качества речи Test Event Сводный отчет, разговорный качества речи для VoIP шлюзов и IP-телефонии.

Джонатан Розенберг из Lucent Технология и Колумбийского университета в G.729 Error Recovery для интернет-телефонии представлен на конференции VON 9/1997 дал следующую таблицу, показывающую соотношение между средним баллом мнения (MOS) и последовательных пакетов потеряно.
Последовательных потерь пакетов ухудшить качество голоса

Последовательные кадры потеряны 1 2 3 4 5
MOS 4,2 3,2 2,4 2.1 1,7

где:

Среднее число мнений

Рейтинг Качества передачи речи Уровень искажений
5 Отлично Незаметный
4 Хорошо Едва заметный, не раздражает
3 Ярмарка Чувственное, немного раздражающая
2 Бедные Раздражает, но не objectionale
1 Неудовлетворительный Очень раздражает, нежелательные

Если VoIP-пакета разнесены на 20 мс, то 10% потерь (при условии, случайное распределение потерь) эквивалентна виде 2 последовательных кадров потеряли примерно каждые 2 секунды, а 2,5% потерь эквивалентно два последовательных кадра теряется каждый 30 секунд.

Поэтому мы задаем “приемлемо” потери пакетов при <2,5%. Бумага Измерение и анализ трафика H.323 дает следующее для VoIP (H.323): Потеря = 0% -0,5% Хорошо, = 0,5% -1,5% Приемлемые и> = 1,5% Плохо.

Выше порогов предполагает плоскую случайного распределения потерь пакетов. Однако часто бывают потери пакетов. Для количественной последовательных потерь пакетов мы использовали, среди прочего, условная вероятность потери (CLP), определенные в Характеризуя впритык задержка пакетов и убытках в Интернете Дж. Болот в журнале высокоскоростных сетей, Том 2, нет. 3 п.п. 305-323 декабря 1993 года (она также доступна в Интернете ). Основном CLP является probablility, что, если один пакет потерян следующего пакета также теряется. Более формально Conditional_loss_probability Вероятность = (убыток (пакет N +1) = True | убыток (пакет N) = TRUE). Причины таких всплесков включают время сходимости требуется после изменения маршрутизации (10s к 100s секунд), потеря и восстановление синхронизации в сети DSL (10-20 секунд), и мост связующего дерева повторной конфигурации (~ 30 секунд).

Подробнее о воздействии пульсирующего потерь пакетов можно найти качества речи Влияние случайных против Bursty потери пакетов К. Дворжака, внутренние МСЭ-Т документа. Эта статья показывает, что в то время как для случайных потерь уходят в МОП линейна% потери пакетов, для пульсирующего потерь упасть гораздо быстрее. См. также пакетирование потери пакетов . Высадка в МОП составляет от 5 до 3,25 к изменению потерь пакетов от 0 до 1%, а затем оно линейно падает до MOS около 2,5 потерей 5%.

Другая деятельность в области мониторинга может выбрать различные пороги возможно потому, что они связаны с разными приложениями. компании MCI Страница трафика этикетки ссылки, как зеленый цвет, если у них есть потери пакетов <5%, красный, если> 10% и оранжевые между ними. Интернета Прогноз погоды цветов <6% Потеря, как зеленый и> 12%, как красный, оранжевый и в противном случае. Так что они оба более либерален, чем мы, или по крайней мере, имеют меньше детализации. Гэри Нортоном в Network World декабря 2000 (P 40), говорит: “Если более 98% пакетов поставляются, пользователи должны испытывать лишь в незначительной степени время отклика, и сессии не должно тайм-аут”.

На рисунке ниже показано распределение частот для средней ежемесячной потери пакетов около 70 сайтов видно из SLAC в период с января 1995 года и ноябре 1997 года.

Качество частоты

10

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

Дрожание

МСЭ Тифона рабочей группы (см. Общие аспекты качества обслуживания (QoS) DTR/TIPHON-05001 V1.2.5 (1998-09) технический отчет) определяет четыре категории деградации сети на основе односторонней джиттера. К ним относятся:
Уровни деградации сети на основе джиттера

Деградация категории Пик джиттера
Идеальный 0 мс.
Хорошо 75 мсек.
Среда 125 мс.
Бедные 225 мс.

Мы изучаем, как относятся односторонние пороги джиттера на пинг (в оба конца или двусторонняя) измерения джиттера. Мы использовали инспектором одностороннего измерения задержки (см. ниже) и измеряли IQRs из односторонняя задержка (J => б и б J =>, где индекс => б показывает мониторинг узел находится и мониторинг удаленного узла в В) и разницу между задержка пакетов (J => B и B = J>). Затем мы добавляем два пути одной задержки для эквивалентных Марки время вместе и получить IQRs для задержки прохождения сигнала (J <=> B) и между задержки пакетов разница (J <=> B). Просмотр Сравнение первого и второго пути джиттера можно увидеть, что распределение не Gaussianly распределенной (будучи еще острее и с более широкими хвостами), джиттер измеряется в одном направлении может быть очень отличается от измеренных в другом направлении, и что для этого случае выше приближение для круглых IQR поездки работает достаточно хорошо (в пределах двух процентов соглашения).

Просмотр веб-страниц и почты довольно устойчивы к дрожанию, но любые потоковые медиа (голос, видео, музыка) вполне suceptible джиттера. Дрожание является симптомом, что есть заторы, или не хватает пропускной способности для обработки трафика.

Джиттера задает длину буфера воспроизведения VoIP кодеков для предотвращения чрезмерного или недостаточного потока. Целью могло бы указать, что говорят 95% вариаций задержки пакетов должна быть в интервале [-30msec, +30 мс].

В режиме реального времени мультимедийных (H.323) Измерение и анализ трафика H.323 дает в одну сторону: дрожание = 0-20мс = хорошо, дрожание = 20-50мс = приемлемо,> 50 мс = плохо. Мы измеряем туда-обратно джиттера, что примерно в два раза в одну сторону джиттера.

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

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

Требования к эксплуатационным характеристикам (от AT & T)

768k – 1.5Mbps: обмен фотографиями, скачивание музыки, электронной почты, веб-серфинга.
3.0Mbps – 6.0Mbps – потоковое видео, онлайн-игр, домашние сети.
> 6 Мбит – хостинг веб-сайтов, просмотра ТВ онлайн, скачивание фильмов.

Использование

Эффективность использования канала может быть считаны с помощью маршрутизаторов SNMP MIB, (при условии, у которого есть разрешение считывать такую ​​информацию). “Около 90% использования типичной сети будет отбрасывать 2% от пакетов, но это меняется. Низкая пропускная способность ссылки имеют меньшую ширину для обработки очередей, часто отбрасывает пакеты только на 80% утилизации … полная проверка исправности сети должны измерять . пропускную способность канала еженедельную Вот предложили цветовой код:

RED: Пакет сброса> 2%, пока не будут использовать никакие новые приложения.
AMBER: Использование> 60%. Рассмотрим модернизации сети.
ЗЕЛЕНЫЙ: Использование <60%. Приемлемая для развертывания новых приложений. ”

Высокоскоростной спад, Гэри Нортон, Network Magazine, декабрь 2000 года. Выше не означает, в течение какого периода использования измеряется. В другом месте в статье Нортона, он говорит: “Пропускная способность сети … рассчитывается как среднее busiets часов в течение 5 рабочих дней”.

“Очередь теория предполагает, что изменение периода кругового обращения, о, изменяется пропорционально 1 / (1-L), где L является текущей нагрузки на сеть, 0 <= L <= 1. Если Интернет работает на 50% мощности, мы ожидаем, что задержки прохождения сигнала изменяется на коэффициент + -. 2O, или 4 Когда нагрузка достигает 80%, мы ожидаем, что при изменении на 10 “межсетевого с TCP / IP, принцип, протоколы и архитектура, Дуглас встречному, Прентис. Холл. Это говорит о том, можно иметь возможность получить меру использования, глядя на изменчивость в мс. Мы не прошли контроль это предложение в настоящее время.

Достижимости

Общие требования Bellcore 929 (GR-929-CORE Надежность и качество измерений для систем телекоммуникаций (RQMS) (проводной), активно используется поставщиками товаров и услуг как основы поставщиком отчетности квартальный результат сопоставления целей. Каждый год, после Публикация самую последнюю версию GR-929-CORE, таких пересмотренных целей производительности реализованы) означает, что ядро ​​телефонной сети направлена ​​на 99,999%, Это составляет менее 5,3 минут простоя в год. Как написано измерение не включает отключения менее 30 секунд. Это направлено на текущие переключатели цифровых PSTN (например, электронная коммутационная система 5 (5ESS) и Nortel DMS250), используя сегодняшние передачи голоса по технологии АТМ.

Общественные системы коммутации требует ограничить общее время отключения в течение 40-летнего периода до менее чем за два часа, или менее чем за три минуты в год, число эквивалентно наличие 99,99943%. С конвергенцию технологий передачи данных и голоса, это означает, что сети передачи данных, которые будут нести несколько услуг, включая голос должен начинаться с аналогичной или лучшей доступности или конечные пользователи будут раздражаться и разочарования.

Уровня доступности часто приводятся в соглашения об уровне обслуживания. В приведенной ниже таблице (на основе Cahners In-Stat исследование образца провайдеров прикладных услуг (ASP)) показывает уровни доступности предлагаемых ВРУ и уровни выбраны клиентами.

Уровни предлагаемых По выбору клиента
Менее 99% 26% 19%
99% готовности 39% 24%
99,9% готовности 24% 15%
99,99% готовности 15% 5%
99,999% 18% 5%
Более 99,999% 13% 15%
Не знаю 13% 18%
Средневзвешенный наличии предлагаемых 99,5% 99,4%

Более подробную информацию о наличии и т.д., см.: Cisco белая бумага на Always-On Доступность для мультисервисных сетей операторского класса для того, как Cisco стремится к высокой доступности на сетях передачи данных; NIST документ о Концепции системы отказоустойчивости (подробнее об различие между надежностью и доступностью); современной таксономии высокой доступности , и IETF документе RFC 2498: IPPM показатели для оценки подключения.

Группировка

По мере увеличения числа хостов пар контролируется увеличился она становится все более необходимым для агрегирования данных в группы, представляющие областях, представляющих интерес. Мы нашли следующие категории группировку, чтобы быть полезным:

  • по площади (например, Северная Америка, Западная Европа, Япония, Азия, страны, домен верхнего уровня);
  • принимающими пары разделения (например трансокеанских связей, межконтинентальных связей, точек обмена );
  • Провайдера сетевых услуг позвоночника, что удаленный узел подключен к (например ESnet , vBNS / Интернет 2 , TEN-34 CALREN2 …);
  • простой принадлежности интерес (например XIWT , HENP , эксперимент совместной работы, такие как BaBar , европейских или национальных лабораторий Министерства энергетики, интересы ESnet программы, мониторинг сайтов Surveyor)
    по мониторингу сайта;
  • на одном удаленном участке видно из многих мест мониторинга. Мы должны иметь возможность выбрать Чет группировки
  • по мониторингу сайтов и удаленных объектов. Кроме того, мы должны возможностью включает в себя все члены группы, присоединиться к группам и исключить членов группы.

Некоторые примеры того, как много ~ 1100 Пингер мониторинга удаленных хост-сайта пары были в глобальные группы области и сродство групп можно найти в распределения Пингер пара группировки.

В то же время она имеет решающее значение для выбора удаленного сайтов и хост-пар так тщательно, что они являются представителями одного информации надеется узнать. Поэтому мы выбрали набор около 50 “Маяк сайтов” , которые контролируются всех участках мониторинга и имеющие типичные для различных групп сродства мы заинтересованы пример график, показывающий раз пинг ответ для групп сайтов видно ниже:

11

12

Процентные показатели, показанные справа от легенды о потерянных пакетов диаграмме улучшения (снижение потерь пакетов) в месяц за линию тренда экспоненциальной подходит к пакету данных потерь. Следует отметить, что на 5% / месяц улучшение эквивалентно 44% / год улучшение (например, 10% потерь упадет до 5,6% в год).

One Way Измерения

SLAC также сотрудничает в Surveyor проекта, чтобы сделать один путь, и задержки измерения потерь между Surveyor сайтов. Каждый сайт имеет Surveyor точке измерения, состоящие из интернет-пользователей компьютера с приемником GPS. Это позволяет точно синхронизированные временные метки пакетов, которые позволяют одним способом измерения задержки. Более подробную информацию можно найти в презентации сотрудниками Surveyor и результатов выборки . Оценки, получаемые с задержкой являются более подробными, чем Pinger и уточнить асимметрии от Интернета пути в двух направлениях. Более подробную информацию о сравнении этих двух методов см. Сравнение Pinger и Surveyor.

RIPE также есть тестовый трафик проект, чтобы сделать независимыми измерениями параметров подключения, таких как задержки и маршрутизации-векторов в Интернете. RIPE хоста устанавливается на SLAC.

NLANR активная программа измерений (AMP) для HPC награжденных направлена ​​на улучшение понимания того, как высокопроизводительных сетей выполняют, как видно, участвуя сайтов и пользователей, а также помочь в диагностике проблем как для пользователей сети и ее поставщиков. Они устанавливают стойку машины FreeBSD на участках и в полной сеткой активные измерения пинг между их машинами, с пинги быть запущен примерно в 1 минуту. AMP машина установлена ​​в СЛАКе.

Более полные сравнительные Surveyor, спелый, Pinger и AMP можно найти на Сравнение некоторых интернет-активность впритык

Измерение эффективности проектов.

SLAC также НИМИ (Национальный интернет-измерений Infrastructure) сайта. Этот проект можно рассматривать в качестве дополнения к проекту Surveyor, тем, что она (НИМИ) более сфокусированной на предоставлении инфраструктуры для поддержки многих методик измерений, таких как один из способов пинги, TRENO, трассировки, Pinger т.д.

Университета Вайкато в Новой Зеландии также развертывание Linux хостов в каждой с приемником GPS и сделать одним из способов измерения задержки. Более подробно об этом см. в Вайкато задержки Выводы странице. В отличие от AMP, спелые и Surveyor проектов, проект Вайкато делает пассивные измерения, нормального трафика между существующей пары, используя CRC на основе подписей пакетов для идентификации пакетов записан на 2 концах.

Жало TCP-инструмент сети измерения способно активно измерения потери пакета в прямом и обратном пути между парами узлов. Это имеет то преимущество, что они не требуют GPS, и не подлежащие ICMP ограничения скорости или блокирование (согласно исследования ISI ~ 61% хостов в сети Интернет не Repond на пинги), однако это требует небольшой модификации ядра.

Если один способ задержки (D), как известно, для обоих направлений Интернет пара узлов (а, б), то задержки на двустороннее R может быть вычислен следующим образом:
R = D => B + B = D>
где D => В является одним из способов задержки измеряется от узла к узлу B, и наоборот.
Эти два способа потери пакетов Р может быть получено из той потерь (р) следующим образом:
P = P => P B + B => – P => B * P B =>
где P => B является одним из способов потери пакетов от узла А в пункт Б, и наоборот.
Есть некоторые IETF RFC, связанных с задержкой измерения одного пути и потерь , а также задержки прохождения сигнала метрические .

Traceroute

Еще один очень мощный инструмент для диагностики проблем в сети является трассировку. Это позволяет найти количество переходов на удаленный сайт и насколько хорошо работает маршрут.

Джон Макаллистеру в Оксфорде разработал Traceping Route Monitoring статистику на основе стандартных трассировку и пинг-коммунальные услуги. Статистика собирается на регулярной основе в течение 24-часового периода и предоставить информацию о конфигурации маршрутизации, качество маршрута и стабильность. Мы (проект Pinger) находятся в процессе расширения traceping и установить его на крупных сайтах, в частности, мониторинг сайтов Pinger (см. Интерес к Traceping для получения дополнительной информации).

ТРИУМФ также есть очень хорошая карта Traceroute инструмент, который показывает карту маршрутов от ТРИУМФ до многих других достопримечательностей. Мы смотрим на упрощение предоставления таких карт использовать автономные системы (AS) проходил через, а не маршрутизаторами.

Можно также построить FTP пропускной способности от количества Traceroute хоп , а также ответ пинг и потери пакетов для поиска корреляций.

Многие сайты появляются, которые работают серверы Traceroute ( исходный код (в Perl) доступна), которые помогают в отладке и в понимании топологии Интернета, см., например, в BNL Путь Проверить полезности.

Некоторые сайты предоставляют доступ к сети утилиты, такие как Nslookup , чтобы позволить одному, чтобы узнать больше о том или ином узле. Пару примеров SLAC и ТРИУМФ .

Глоссарий

DSCP Дифференцированные Codepoint услуги. Дифференцированного обслуживания Codepoint составляет 6 битов в поле заголовка IP, которые используются выберите Per-Hop-поведение пакета. 6 бит для DSCP и 2 неиспользуемые биты направлены на замену существующих определений октета IPv4 TOS см. RFC 2474 для более подробной информации.
MTU Максимальный Блок переноса. Максимальная единица передачи является крупнейшим размер IP-дейтаграммы, которая может быть передана с помощью специального канала передачи данных соединение.

MSS Максимальный размер сегмента. МТУ-40.

QBSS Услуги QBone мусорщик. Услуги QBone поглотитель дополнительного класса максимальных усилий службы. Небольшое количество пропускной способности сети выделяется (в нежесткой пути) за эту услугу, а когда по умолчанию максимальных усилий мощностей недостаточно, QBSS может расширить потреблять неиспользуемых мощностей.
Окна приема (Rwin) размер буфера TCP, количество пакетов, ваша машина будет посылать без получения ACK.

Ресурс: Les Cottrell

Comments are closed.

Post Navigation