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

[evg_krsk]

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

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

[evg_krsk]

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

[archim]

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

[evg_krsk]

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

[vvpoloskin]

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

[evg_krsk]

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

[vvpoloskin]

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

[evg_krsk]

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

[dmineev]

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

[archim]

Вот официальный ответ от 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]

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

[archim]

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

[evg_krsk]

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

[dummy2002]

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

[vvpoloskin]

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

[evg_krsk]

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

[archim]

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

[phprus]

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

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

[Hanggard]

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

[Irvy]

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

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

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

[kvo]

Есть еще jperf, который сам рисует график, но он на яве.

[evg_krsk]

Это ява-морда к консольному iperf.exe, как помнится.

[skullodrom]

А как померить канал между роутером и компом? Я не могу запустить на роутере iperf -s или могу как-то?