Дано:
DevBoard, которая формирует UDP пакеты размерностью Data=1024. DevBoard соединен с ПК кроссовым кабелем напрямую. На ПК установлена ОС Linux и по сокетам идет прием UDP пакетов. В каждом пакете идет номер с инкрементом, тем самым можно отслеживать потерю пакетов.
Цель - добиться максимальной пропускной способности при 100% доставки пакетов.

Как видно потери возникают при 100Мбит/линке, когда загрузка сети близется к 100%.
А 1G линк не дает скорости более 12%, далее начинают терятся покеты.

Вопросы
1. Где происходит потеря пакетов ?
2. Как повысить надежность доставки пакетов ?
3. Может ли размер пакета влиять на надежность доставки ? Возможно стоит уменьшить до 128 или 256

UDP не гарантирует доставку. UDP гарантирует, что пакет будет передан. т.е. уйдёт. всё. Изначально ставить не выполнимую цель = мягко говоря не корректно.
это типа раз...
где происходит потеря? либо помеха, либо не успевает приёмник.
надёжность повысить? кхм... выкинуть льюникс, написать свою заточку. два девайса и кабель в свинцовые наряды и прочую мурню...и всё равно это не 100% по определению...
размер пакета может влиять на оптимальность обработки на приёмной стороне. т.е. если вы заглянете в код приёмника на предмет "А какой тебе лучше размер скормить зараза?" то Вы ответите на свой вопрос сами.
по поводу размеров - тут думаю будет просче тупо прогнать разные тесты, которые смогут дать средний по больнице результат...который можно принять за основу - дескать этот размер получше...


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

если Вам актуально надёжность доставки - то тогда протокол не подходит.
если пропускная способность - то тут надо считать и смотреть на возможности канала, приёмника, оси...

где то так
(круглый)

помеха исключена. ошибки были бы тогда при малой загрузке сети.
Почти уверен ,что не успевает ОС считать данные.
Но здесь непонятка. На сетевую карточку приходят пакеты , куда она их девает ? Хранит в своих фифошках или отсылает в ОЗУ ?


думаю на скоростях до 1Гбит/с эти два пункта можно совместить.

может быть
- драйвер сетевой карты (а если запуститься под Win ?)
- настройки сетевой карты (кол-во дескрипторов, буфер приема, частота прерываний)
- разница в клоках DevBrd и чипа сетевой карты
- софт приемника не успевает обрабатывать заголовки пакетов (скипает счетчики)

готовлю тест.


попробую


хм...а как это может влиять на потери ?



тоже возможно, но как повысить скорость обработки ? отказаться от стандартной ОС и переходить на RTOS?



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

пропуск-вставка лишнего бита в чипе приемника, если тактирующие генераторы имеют номиналы, отличающиеся на проценты. Соотв. произойдет отбрасывание пакета UDP.
для начала нужно выяснить, где ошибка. Для этого надо обрабатывать данные после их накопления в большом буфере ОЗУ, а не в процессе приема. И писать чем-то проверенным, например, wireshark

на скоростях близких 100 мбит/c он еще как теряет пакеты, а на 1 Гб/с так вобще надо в тачку 16 гб ОЗУ и SSD raid, так что забудьте.

подтверждаю. wireshark прилично вешает машину, когда поток даже на 100Мбит/линк более 50%. При этом кол-во потерянных пакетов от 3%.


так то оно так, но как это сделать под ОС ?
И еще раз повторю вопрос. На сетевую карточку приходят пакеты , куда она их девает ? Хранит в своих фифошках или отсылает в ОЗУ ? Если в ОЗУ, то по какому адрессу и кто задает размер буфера?

есть мнение, что просто Вы не умеете его готовить. Коллеги, сидящие рядом, подтверждают полноту и целостность приема при записи в ОЗУ (почти 1 Гб/с) и на HDD не SSD raid (около 800 Мб/с).
может дело в конфигурации железа, версиях софта ?

Пришел кадр Ethernet, картой обработался и положился во внутренний буфер карты. После заполнения внутреннего буфера до определенного уровня карта выставляет запрос на прерывание, ОС реагирует, настраивает DMA, и данные из внутреннего буфера передаются в системное ОЗУ ПК. Ну а дальше софт стека протоколов разбирает кадры.

Вот мои соображения:

- Постоянным (!) потоком данных под 100 Mbps можно положить любую ширпотребныю сетевуху.

- Какая сетевая карта используется? Есть подозрение что использование карты на последних сетевых чипах Intel c PCIe и с различными аппаратными ускорениями (хотя бы расчет Ethernet CRC и контрольной суммы UDP) может улучшить ситуацию.

- А если выкинуть ПК и соединить два девайса напрямую? По крайней мере не будет зависимости от ОС.

- Если вдруг есть доступ к чему-нибудь такому: http://www.smartechconsulting.com/SMB-200-...ortable-chassis то все можно протестить досконально

спасибо. примерно так и представлял. Насколько трудоемко и возможно ли будет сделать следующее:
1. Выделить память в ОЗУ
2. Настроить сетевую как master и напрямую слать данные из внутреннего буфера в в выделенную память в ОЗУ.
Насколько я понимаю, нужен новый драйвер для сетевой.



Сетевая интегрированная в чипсет Intel P67. UDP CRC отключена (шлю нули).


В том то и соль, что нужно соеденить устройство и тупой ПК.


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

а есть ли смысл попробывать внешную сетевую типа ?
http://www.stikc.com/Intel-PRO-1000-PT-DUA...3959-EXPI9402PT

Ага, надо будет самому драйвер писать.



Думаю, что есть.

попробуйте JumboFrame. У нас тоже UDP со счетчиком длинна пакетов 8К. На хороший комп с WinXP поток в 300 Мбит запросто проходит, а то и больше. Свой драйвер тоже писали, но это уже когда по 10 GbE поток заводили.

Попробуйте два компа по сетке соединить и большие файлы по сети гонять, какая будет скорость? И это при хреновых встроенных сетевухах.
=> Нужен протокол TCP или его аналог.
У нас тоже были проблемы с потерей пакетов под виндой - вылечилось самопальным транспортным протоколом (на полный TCP слишком много ресурсов надо, а ПЛИС не резиновая).


P.S. jumbo фреймы конечно сильно уменьшали потери пакетов, а если мышкой не шевелить и все остальные программы в винде закрыть и не дышать - то работало практически на максимуме скорости. Однако, заказчик сказал что его сетевая инфраструктура не поддерживает jumbo фреймы.

1. Длина пакета 8K у Вас не разбивалась на отдельные пакеты меньшей длины ?
2. Драйвер свой писали, а где брали документацию на контретную сетевую плату ?


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


спасибо, посмотрю

Подытожим. Из всего выше сказаного следует, что нужно увеличивать длину пакета. Верно я понимаю ?