Irvy 1 дек 2014 в 11:10

Измерение пропускной способности Ethernet канала

4 мин

142K

Сетевые технологии*

Из песочницы

Комментарии 24

evg_krsk 1 дек 2014 в 11:44

Надеялся, что будет про программную/аппаратную реализацию RFC2544/Y.1564. iperf это грустно.

Подскажите, если кто знает, программные реализации этих стандартов под Linux.

evg_krsk 1 дек 2014 в 12:01

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

archim 1 дек 2014 в 12:06

C наскоку нашел вот это, не пробовал. Мне интереснее как раз на Layer3 проверять пропускную способность.

evg_krsk 1 дек 2014 в 12:20

Спасибо, интересно будет глянуть.

vvpoloskin 1 дек 2014 в 12:34

RFC2544 указывает список тестов (6 позиций). Их можно выполнить средствами iperf и ping. С другой стороны, результаты измерений будут обладать некоторой погрешностью (где-то встречал, что 10%), особенно на больших каналах. Впрочем, погрешность будет на всех софтовых средствах измерения.

evg_krsk 1 дек 2014 в 12:46

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

vvpoloskin 1 дек 2014 в 13:50

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

evg_krsk 1 дек 2014 в 14:22

Ну софт хотя бы можно а) запатчить б) залить по сети. С железом и разнесённой географически сетью аппаратные решения не очень удобны.

dmineev 1 дек 2014 в 12:18

Возможно оффтоп, но раз уж упомянули сервис speedtest.net, то во фразе «не подходит так как данный сервис меряет не конкретный канал связи, а всю линию до определенного сервера, так же измеряемый канал связи не имеет выхода в Интернет» есть нет неточность, так как есть Ookla Speedtest Mini, что позволяет вам самим развернуть свой speedtest внутри сети и меряйте хоть конкретный канал, в том числе.

archim 1 дек 2014 в 12:35

Вот официальный ответ от Ookla:

Speedtest mini is not really designed for today broadband speeds. It is primarily used for hosts that want to become a host, as hosts are required to have the legacy http content.
…
NetGauge was designed for much higher speed networks than our legacy tests. NetGauge will now test over the TCP Socket Layer vs HTTP as our legacy test did, and can now test up to 1G.

Но NetGauge стоит не маленьких денег.

dmineev 1 дек 2014 в 12:47

Та да, но и Iperf на широком канале будет выдавать не совсем точные результаты. И если погрешность результата должна быть минимальной, то соглашусь Speedtest mini не подойдет. Впрочем это не отменяет вышеуказанной неточности в статье. Стоило упомянуть, что таки можно, и указать, что и это так же не подходит, по указанным причинам.

archim 1 дек 2014 в 13:01

Да, Iperf тоже нужно уметь готовить.
Вообще на сколько-нибудь значимых задержках TCP ведет себя не лучшим образом.
Для проверки пропускной способности p2p ethernet линка с помощью iperf я бы наверное лучше генерировал по UDP заранее завышенный поток и смотрел сколько «пролезло».
Хотя, может, я не прав.

evg_krsk 1 дек 2014 в 14:21

Мы пытались приспособить для ступниковой задержки. Это был адок для программиста, насколько я вижу по патчу, плюс ещё столько же осталось незапатченным. Для двойного скачка и больше даже не пытались.

dummy2002 1 дек 2014 в 15:32

Думаю, Вы абсолютно правы. Хотя при такой методике измерений «полезное» использование данного канала невозможно: дополнительно уже мало что пролезет. Предполагаю, что данный метод ориентирован больше на краткосрочную оценку ширины канала. Для постоянного мониторинга канала «для бедных» я бы смотрел в сторону следующего решения:
1) программный сетевой шлюз на UNIX
2) настроенный шейпер для приоритизации траффика
3) трафик iperf имеет самый низкий приоритет и забивает всю свободную часть канала
4) что-то типа vnstat снимает характеристики интерфейсов на шлюзе

НЛО прилетело и опубликовало эту надпись здесь

vvpoloskin 1 дек 2014 в 12:38

Iperf — решение для «бедных». Было бы интереснее рассмотреть платные аппаратные средства. Кроме того, попробуйте замерить им каналы шириной, например 1Gbit, да хотя бы 600M, увидите его очень интересные результаты. А еще можно 4-8Kbit померить…

evg_krsk 1 дек 2014 в 12:47

Аппаратных средств как раз хоть попой жуй, только вот пробовать их пока не найдёшь удовлетворительное не для бедных удовольствие :-)

archim 1 дек 2014 в 13:03

Было бы интереснее рассмотреть решение для бедных, но получше чем iPerf =)

phprus 1 дек 2014 в 17:03

А в чем проблема замерять каналы больше гигабита? Если учитывать поправку на ветер — особенности работы алгоритмов TCP на широких/длинных/с потерями каналах связи, то можно и с гигабитами работать с некоторыми оговорками.

Более того, в некоторых случаях эти особенности TCP в тесте будут даже на руку тестирующему, так как бывает нужно узнать, а сколько, например, TCP вытянет при различных комбинациях параметров.

Hanggard 1 дек 2014 в 21:52

Пока Вы все это ставили, писали скрипты и прочее, можно было, например, Cacti поставить.

Irvy 4 дек 2014 в 10:42

Cacti — open-source веб-приложение, система позволяет строить графики при помощи RRDtool. Cacti собирает статистические данные за определённые временные интервалы и позволяет отобразить их в графическом виде. Преимущественно используются стандартные шаблоны для отображения статистики по загрузке процессора, выделению оперативной памяти, количеству запущенных процессов, использованию входящего/исходящего трафика.

Оно умеет нагружать канал для теста?
И написание скриптов (всего двух) не больше времени на установку и настройку Cacti.
Тем более что скилл писания скриптов, сбора статистики, рисования графиков нужен не только в этом случае. Иногда проще и быстрее написать простое решение самому чем искать готовое, разбираться в нем, плодить на компьютере разношерстный софт.
Но за Cacti спасибо, не знал о этой программе.

Я как-то услышал мнение что инструмент Gnuplot «не нужен» и Excel отлично справляется с рисованием диаграмм. В ответ на это предложил нарисовать график из статистического файла (text format) в 100тыс строк и сохранить график в eps формате для вставки в LaTeX документ. Gnuplot с этим справляется за секунду (не преувеличиваю).