Как стать автором
Обновить

Замеры скорости сети — о чём умалчивают создатели Bandwidth Meter'ов

Время на прочтение 3 мин
Количество просмотров 959
Может пригодится кому-то из сисадминов/сетевиков. Понадобилось замерить характеристики загруженного канала от провайдера, понять где проблема и, если действительно в канале, предоставить объективные данные для дальнейших разговоров с провайдером.

Канал гигабитный. Пиковые нагрузки, если верить роутеру, около 480Мбит / 70 000 пакетов/с. Пользователи жалуются что «подтормаживает» и что всяческие замерялки скорости доступные онлайн регулярно дают всякие ужасающие результаты.

Сделал пачку тестов разными онлайн Bandwidth Meter'ами и всякими утилитами. Первое, что бросилось в глаза — совершенно неправдоподобный разброс результатов. Мало того, что каждый инструмент давал свои «уникальные» результаты, так ещё и запуск одного и того же инструмента давал в корне различные результаты в течение нескольким минут. Как следствие — единственный вывод, который удалось сделать из этих замеров: все они врут, при чём врут не чуть-чуть, а на сотни процентов в плюс или минус.

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

И вот тут, похоже и нашёлся «корень зла» — scheduler процессов в системе. В большинстве операционных систем процессы не имеют возможности пользоваться процессором сколько угодно долго, ибо не одни они в системе, другим тоже надо. А посему время процессора достаеётся им по порциям, всем по очереди (ну если немного упростить), и с некоторыми интервалами времени. И чем более загружена система — тем больше эти интервалы.

Как я понял из документации на функцию nanosleep() (для Linux), если интервал менее 2 мсек. и процесс запущен с нужным уровнем привелегий — она выполняет задержку посредством некого цикла внутри себя самой, не отдавая управления системе, ибо получить обратно иначе уже всё равно не успеет, а если привелегий не хватает — то просит систему «разбудить вовремя» но реально на это надеяться не стоит, потому как интервал будет скорее всего не меньше, а как правило значительно больше чем 2 мсек.

Исходя из этого, можно предположить, что обычное пользовательское приложение, не являющееся частью ядра системы и как следствие не имеющее возможности «остановить мир» пока оно занято, может отмерять интервалы времени не точнее ~2 мсек.
Далее немного математики: за 2 мсек на 1-Гбитном линке может успеть поступить как минимум порядка 160 пакетов (1 гигабит / 1500 байтный пакет (12 000 бит) / 1000 миллисекунд * 2), ато и намного больше, если они маленькие.

То есть с момента, когда программа, пытающаяся отследить момент прихода пакета, была прервана системой и до момента, когда у неё появится возможность продолжить свою работу, в буфере может накопиться примерно 160 пакетов, которые с точки зрения этой самой программы появились там ОДНОВРЕМЕННО.

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

На большей же скорости, не имея возможности достоверно отслеживать времена движения пакетов, мы можем померить только 2 вещи:
— как быстро через канал пролезает некий относительно большой блок информации (файл), достаточно большой, чтобы сделать погрешности замера времени незначительными — то есть доступная свободная полоса пропускания на данный момент времени,
— а так же какой процент этого блока информации пропадёт по пути — то есть потери пакетов на данный момент времени.

Ни то ни другое, думаю, нельза назвать объективной оценкой качества канала как такового, если в канале в данный момент присутствует так же некий траффик других пользователей — на оба этих параметра слишком сильно может повлиять загрузка канала другими пользователями.

Пока всё, копаю дальше. Ежели кому будет интересно — с удовольствием поделюсь результатами дальнейших поисков.
Теги:
Хабы:
+15
Комментарии 24
Комментарии Комментарии 24

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн