[-Ars-]

Как у iperf поменять размер пакета?

"-l" ;)

rfc обеспечивает повторяемость результата

Эээ... Если использовать специальное железо, то - да. А если тазики, то - не очень. И главное - зачем? RFC2544 придумали, чтобы была хоть какая-то общая методика измерения производительности сетевых устройств. Чтобы производитель мог написать, мол, "я тут намерял - вот!". И, соответственно, потенциальный клиент мог сравнить, впечатлиться. Или не впечатлиться ;)

[yakov2000]

Эээ... Если использовать специальное железо, то - да. А если тазики, то - не очень. И главное - зачем? RFC2544 придумали, чтобы была хоть какая-то общая методика измерения производительности сетевых устройств. Чтобы производитель мог написать, мол, "я тут намерял - вот!". И, соответственно, потенциальный клиент мог сравнить, впечатлиться. Или не впечатлиться ;)

-l, --len n[KM]

set length read/write buffer to n (default 8 KB) ?

и с каких пор буфер стал размером пакета ?

И давно пакеты стали по 8КB в Ethernete ?

 

Эээ... Если использовать специальное железо, то - да. А если тазики, то - не очень. И главное - зачем? RFC2544 придумали, чтобы была хоть какая-то общая методика измерения производительности сетевых устройств. Чтобы производитель мог написать, мол, "я тут намерял - вот!". И, соответственно, потенциальный клиент мог сравнить, впечатлиться. Или не впечатлиться ;)

И с тазика и не с тазиками, одинаково хорошо показывает.Есть такая штука - стандарты, но iperf под него не попадает. Когда к тебе придет клиент и скажет, что у него низкая скорость, ему что показывать ? а может лучше графики которые построены по RFC2544 ?

 

Вот тебе пример, что по RFC2544 измеряют пропускную способность каналов:

http://radikom.ru/t_723746_berkut-et_bercut-et_tester-analizator_ethernet_i_gigabit_ethernet.html

Тестер-анализатор Ethernet/Gigabit Ethernet BERcut-ET (Беркут-ET) предназначен для проведения анализа и диагностического тестирования сетевого оборудования по методике RFC-2544 для оценки состояния кабеля, контроля связности канала.

[-Ars-]

-l, --len n[KM] set length read/write buffer to n (default 8 KB) ? и с каких пор буфер стал размером пакета ? И давно пакеты стали по 8КB в Ethernete ?

Не цитируй хелп. Попробуй ;) -l в байтах + 42.

Есть такая штука - стандарты, но iperf под него не попадает.

iperf - стандарт де-факто в тестировании и более чем приемлем для приблизительной начальной оценки производительности. Я, например, не буду возиться с подключением и проверкой гигабитного СРЕ по RFC2544 если с дефолтными настройками iperf у меня не прожевывается , скажем, 200 Mbps.

Когда к тебе придет клиент и скажет, что у него низкая скорость, ему что показывать ? а может лучше графики которые построены по RFC2544 ?

В зависимости от того, чего именно этот клиент. Мои клиенты - это интернет-провайдеры. Для них я, действительно, делаю в частности, тесты по RFC2544 с помощью соответствуюшего оборудования. Но если речь идет про домашнего пользователя, который жалуется на низкую скорость у себя дома - ему этот RFC до фени. Тормоза - у него дома. Кто именно тормозит - пес его знает. Комп, роутер, перегревшись от того, что стоит на верхней одежной полке, закрытый 2-мя меховыми шапками, или еще что. Всё это RFC не учтёт ;)

Вот тебе пример, что по RFC2544 измеряют пропускную способность каналов:http://radikom.ru/t_...t_ethernet.htmlТестер-анализатор Ethernet/Gigabit Ethernet BERcut-ET (Беркут-ET) предназначен для проведения анализа и диагностического тестирования сетевого оборудования по методике RFC-2544 для оценки состояния кабеля, контроля связности канала.

Выделено мной ;) Опять же: RFC2544 включает в себя не только тесты на производительность но и, скажем, latency tests. Я не вижу смысла делать эти тесты для домашнего СРЕ для оценки его исправности. На стадии разработки - ладно. Но для оценки исправности - э! ;)

Не пойми меня неправильно. Я пишу не чтобы постебаться, а именно ищу "что бы еще проверить", потому, что как бы мы не проверяли, а всё-равно у клиента всплывет какой-нибудь "нежданчик". Делюсь своими мыслями и принимаю к сведению чужие ;)

[s.lobanov]

Поддерживаю Ars. Ссылаться на RFC2544 при тестировании аппаратных неисправностей это как минимум странно и вообще говоря совершенно ничем не обоснованно

[yakov2000]

Поддерживаю Ars. Ссылаться на RFC2544 при тестировании аппаратных неисправностей это как минимум странно и вообще говоря совершенно ничем не обоснованно

на что ссылаться тогда ? И какими методиками тестировать ?

[-Ars-]

на что ссылаться тогда ? И какими методиками тестировать ?

 

Предлагаю разделить вопрос на 3 подпункта:

1) Тестирование абонентского оборудования, приобретённого абонентом самостоятельно.

2) Тестирование потенциально неисправного абонентского оборудования, приобретенного (арендованного и т.п.) у провайдера.

3) Тестирование провайдером потенциально приобретаемого оборудования предназначенного для абонентов.

 

Исходим из того, что в п.п. 1-2 на первый взгляд железо работает, компьютеры в LAN получают адрес, GUI открывается.

 

По п.1 - самое непонятное, потому, как чёрт его знает, какие глюки там могут быть. Во времена оны, когда я работал в ТП, у нас большинство проблем возникало от железок, которые не умели поднимать или плохо держали под нагрузкой PPTP/L2TP соединения.

Наверное имеет смысл как минимум проверить, способен ли борд прокачать скорость, предоставляемую абоненту на его подключении и устроить стресс-тест с большим количеством соединений+нагрузкой траффиком на протяжении, скажем, 24 часов. Отследить были ли отключения WAN, были ли потери пакетов, были ли проблемы с открытием новых соединений. Есть смысл сделать отдельный схожий тест для WiFi с одним-двумя-пятью-десятью wifi-клиентами.

Это всё надо как-то мониторить. Соответственно, после 24 часов будет какой-то отчёт, который можно будет предоставить клиенту и сказать: так и так, под нагрузкой А получили результат Б. Наши СРЕ дают результат С, который лучше вашего по следующим параметрам. Ну, или нет.

 

По п. 2 - то же самое, что и выше, только там уже есть результаты тестирования из п.3. Поэтому есть с чем сравнить.

 

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

[yakov2000]

iperf - стандарт де-факто в тестировании и более чем приемлем для приблизительной начальной оценки производительности. Я, например, не буду возиться с подключением и проверкой гигабитного СРЕ по RFC2544 если с дефолтными настройками iperf у меня не прожевывается , скажем, 200 Mbps.

Мне больше нравится nuttcp, если брать софтовое решение для быстрой оценки.В целом rfc и iperf/nuttcp показывают близкие цифры. Но от iperf я отказался, так как разные версии iperf показывали разные цифры, это показалось мне странным.

Так же я не уверен, что iperf сможет сгенерировать тот же 1Gps, он работает в юзерспейсе.

 

 

В зависимости от того, чего именно этот клиент. Мои клиенты - это интернет-провайдеры. Для них я, действительно, делаю в частности, тесты по RFC2544 с помощью соответствуюшего оборудования. Но если речь идет про домашнего пользователя, который жалуется на низкую скорость у себя дома - ему этот RFC до фени. Тормоза - у него дома. Кто именно тормозит - пес его знает. Комп, роутер, перегревшись от того, что стоит на верхней одежной полке, закрытый 2-мя меховыми шапками, или еще что. Всё это RFC не учтёт ;)

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

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

 

Опять же: RFC2544 включает в себя не только тесты на производительность но и, скажем, latency tests. Я не вижу смысла делать эти тесты для домашнего СРЕ для оценки его исправности. На стадии разработки - ладно. Но для оценки исправности - э! ;)[/size]

Предложи, какие тесты нужно/можно делать для cpe. В том же rfc написано, что можно не все тесты проводить, а выборочно.В любом случае для тестирования нужна методика, я использовал этот rfc так как считал и считаю, что он в полной мере подходит для этой задачи. Пока ничего другого не предложено, тот же JTAG вымер наглухо из печатных плат, хотя чипы его поддерживают и возможности его огромны. Но и возьни с ним больше, чем с rfc2544.

Не пойми меня неправильно. Я пишу не чтобы постебаться, а именно ищу "что бы еще проверить", потому, что как бы мы не проверяли, а всё-равно у клиента всплывет какой-нибудь "нежданчик". Делюсь своими мыслями и принимаю к сведению чужие ;)

Таже ситуация и у меня.Однако если в "тепличных" условиях наблюдаются проблемы с cpe, то ему дорога в ремонт.

Вообще есть смысл использовать tr-069 для диагностики прямо у клиента, с удаленным съемом инфы. Ту же температуру cpu можно снимать, уровень wifi сигнала, ошибки на L2 уровне, все можно контролировать и уже делать некоторые выводы.

При исправном железе и жалобах пользователей я начинал искать проблемы выше по модели оси, вплоть до тестирования протоколов и функций. Для тестирования протоколов есть методики брать тут - http://www.ixiacom.com/pdfs/test_plans/agilent_journal_of_internet_test_methodologies.pdf

В различном пользовательском функционале тоже глюков хватает.Был забавный случай, когда при клонировании мак адреса, брался не мак ПК, а мак lan интерфейса роутера и такой же назначался на WAN интерфейс, у пользователя всё переставало работать. Писал разработчикам девайса, исправили в следующей прошивке.

[yakov2000]

Наверное имеет смысл как минимум проверить, способен ли борд прокачать скорость, предоставляемую абоненту на его подключении и устроить стресс-тест с большим количеством соединений+нагрузкой траффиком на протяжении, скажем, 24 часов. Отследить были ли отключения WAN, были ли потери пакетов, были ли проблемы с открытием новых соединений. Есть смысл сделать отдельный схожий тест для WiFi с одним-двумя-пятью-десятью wifi-клиентами.

Я так и делал, только за основу был взят rfc.

[-Ars-]

есть смысл использовать tr-069 для диагностики прямо у клиента, с удаленным съемом инфы. Ту же температуру cpu можно снимать, уровень wifi сигнала, ошибки на L2 уровне, все можно контролировать и уже делать некоторые выводы.

И тут я тоже не совсем соглашусь. Далеко не факт, что TR-069 на клиентском борде будет поддерживать все эти хотелки, или давать правильную инфу по. Даже исходя из того, что ACS умный и умеет считывать всяческие vendor extensions. Хотя помониторить издали может быть очень интересно.

 

Предложи, какие тесты нужно/можно делать для cpe.

Для какой из трех перечисленных выше целей? ;)

[vn555]

Сорри но в презентации Дмитрия Самоделко файлик с расчетом не открывается, а должен?

Мне показалось не совсем информативно, хотел дополнить расчет..

[Navu]

vn555, Вы имеет ввиду презентацию?

[vn555]

vn555, Вы имеет ввиду презентацию?

 

Да, в самой презентации перед табличками расчетов бизнес плана вставлена иконка excel, а в тексте слайда автор ссылается на файл. Вот я и подумал, а должен быть файл вложен в презентации?

Спасибо

[D^2]

http://data.nag.ru/%21Academy_NAG_2014_May/