Приветствую.

Необходимо реализовать оценку Ethernet линка по ряду критиериев и назначить линку вес. Критерии видятся следующие:
- пропускная способность
- RX/TX rate
- задержки
- потери (packet loss)
- загрузка канала
...

Поправьте если ошибаюсь.

Есть ли какие-то готовые алгоритмы или идеи?

Спасибо!

см в сторону ping [-f] и bing

а какая связь между PING и ETHERNET?

а что касаемо оценки - надо определиться что вы имеете ввиду под линк?
это точка точка или это соединение в сети (логическая точка точка)?

вообще вопрос мутный какойто - видимо нужно уточнить что вы называете ETHERNET ?

Приветствую.

2Harbour
спасибо за bing. Видимо то что мне нужно.


В моем случае это point-to-multipoint.


Скорее всего то, что определяется стандартом 802.3

Человека инетересуют потери - ping выдает статистику прохождения пакетов по каналу, что ж тут непонятного ...

ping вовсе не обязан работать при наличии ethernet - он настолько далек от etehrnet что ничего характеризовать не может .

что касаемо ответов romez777

ведь в ETHERNET - контролируется только уход пакета- а его правильность приема возлагается на надстроенные протоколы
кроме того если вы начтенете посылать пакеты для проверки канала то вы измените режим работы сети - и например можете просто обрущить канал - если же вы посылаете пакеты редко - то вероятность обнаружение битого пакета при приеме резко уменьшается и вы опять ничего не можете проверить


возможно вам надо посмотреть в сторону сетевых анализаторов - например observer он многое что позволяет делать

например смотреть время реакции на пакеты tcp/ip когда пакет ушел и когда пришел
но это не имеет отношение к ETHERNET!!!!!!!

поэтому высказываю свое мнение по поводу мутности вопроса - вы задаете его в некорректной форме

если стоит вопрос протестировать физический уровень - когда канал только ваш - то и эта задача не из простых
чт касаемо вашей точки мультиточки - то тут вообще одни вопросы - например 10 машин шлют пакеты со скоротью 10 мбит в одну машину сидящем на канале 100 мбит - что это вам скажет о вашем ethernet. что он не работает? или что?

всетаки попробуйте ответить на вопрос что вы хотите проверять?
в моем понимании ваш вопрос мутный

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

Тестировать физический уровень не представляется возможным, поэтому я смотрю в сторону верхнего уровня - tcp/ip (поскольку используем именно его), и взять за основу ICMP и расчет round-trip time, как это делает ping/bing. Практически я представляю это себе как периодическую посылку N пакетов длины L1, и M пакетов длины L2 (где N и M достаточно малы, L2>L1), получение RTT и вычисление на основе RTT пропускной способности.

Вероятней всего это не даст правдивой картины состояния канала, а лишь весьма приближенный анализ.

ICMP реализуется программно и его временные издержки зависят от настроек и реализации и прочих приблуд по маршруту
и время реакции там измеряются плюс минус лапоть
если погонять например пинг с разной длиной пакета получите много замечательных непредсказуемых результатов

кроме того если вы переходите от ethernet на tcp/ip это вообще уже другая задача выходит

Хорошо, давайте немного упростим задачу: оценить скорость между двумя хостами в одном Ethernet (если это еще принципиально?) сегменте на TCP/IP уровне. Надеюсь так звучит более правильно?

Если вы считаете использование ICMP для оценки скорости неприемлимой, то какой метод можете порекомендовать? (Напомню: это нужно реализовать в моем приложении).

Спасибо.

не знаю что вы хотите получить
но могу сказать только что мы пробовали- может вам поможет
1 через самопальный драйвер на уровне пакетов ethernet мы смогли загрузить 100 TX на полную катушку. 1000 TX мы смогли загрузить только на 350 (принимали и передавали на одном компе через 2 сетевые карты(таким образом мы тестируем нашу внешнюю аппаратуру подключенную по ethernet)
2 посылали UDP пакеты на машину и машина возвращала эти UDP пакеты обратно- после прихода ответа процесс повторялся - в результате такого эксперимента сеть грузилась на 20-30 % запуская 4-5 задач загружали сеть на 100 %
3 заметил еще такую особенность - что некоторые сетевые карты могут загрузить канал на передачу только на 50 % но по приему все карты могут принять 100 % загрузку сети

всетаки мне не нравится ваш термин СКОРОСТЬ. мы говорим о пропускной способности канала. для примера тестированием UDP с прохождением туда обратно как я уже написал выше канал грузился только на 20 %- и что таком случае понимать под скоростью?
попробуйте дать определение СКОРОСТЬ в вашем понимании - может станет более понятно

добалю еще что в observere который я вам рекомендовал - есть средства анализа как загрузки канала так и времени реакции на прохождение пакетов TCP(время ACK отвтов) так и анализ времени реакции на некоторые службы - например реакцию службы DNS и тд и тп - посмотрите эту программу - может появятся какие то идеи для обсуждения

Приветствую.

Постараюсь пояснить свою ситуацию еще раз: есть устройство CMTS (cable moadem termination system, что-то вроде DSLAM, но для кабельных модемов) с 4 RF каналами, каждый канал на своей частоте. Каждый канал способен держать до 30 клиентов, с максимальной скоростью до 140Mbps.
С точки зрения ОС (встроенный linux 2.6.16) каждый канала представлен как Ethernet устройство (это осуществляется посредством драйвера). Кроме этого на девайсе есть "настоящий" гигабитный ethernet, а сам девайс осуществляет бриджевание трафика между этими интерфейсами (coax RF и ethernet).

Так вот мне нужно "оценить" (по какому-либо критерию: скорость, задержки, пропускная способность и пр.) каждый из каналов и назначить ему вес.

Извиняюсь, что сразу подробно не обрисовал ситуацию. Думал слова Ethernet будет достаточно


Я считаю, что пропускная способность канала характеризуется главным образом СКОРОСТЬЮ передачи пакетов по этому каналу. При этом для разных протоколов, скорость может быть разной - Вы на это намекаете?


Observer поставил, на графики посмотрел но не нашел ни слова описания методики измерений.

Для чего вес нужен ? Не для load balancing случайно ? Непонятна конечная цель, может ничего мерять и не нужно

Да, именно load balancing. Кроме того, чип в CMTS девайсе, реализующий бриджинг между RF линком и оптикой, не имеет никаких QoS/CoS фич, таким образом приходится это мастерить самому.

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

Епсль, а чем то родной линуксовый load balancing не угодил (их кажись даже 2 там) ? На крайний случай поставить еще linux с той стороны