Все понятно, так и думал, что не представляете - это проблема TCP/IP протокола и возможного упирания в ширину канала, а отнюдь не затрат времени uC-MAC и мантра "DMA DMA.." тут ни причем.

Ага, народ даже не подозревает, что в большинстве случаев DMA работает медленнее программной пересылки.
И действительную пользу от DMA можно получить только в многозадачных решениях под управлением RTOS.
А если думать о масштабировании и разделении потоков, то однозначно надо использовать многозадачный многинтерфейсный стек с мощным процессором сделанным не на FPGA
В данной теме я уверен человек просто никуда не денется и ему придется заниматься масштабированием с расчеплением TCP потоков если надо сделать в сумме больше 100 MBit/s

Никакой самопал на UDP не спасет ситуацию. Сетевая карта перегруженного компа просто молча отбрасывает UDP пакеты.
UDP уровень в стеке TCP/IP нужен для протоколов которые обеспечивают целостность данных на более верхних уровнях, например SNMP или L2TP тоннели.
В данном случае переносить контроль целостности на еще более верхний уровень будет нетривиальной задачей хотя в некоторых случаях есть интересные решения, как тоннель с мultilink PPP поверх UDP делающий один логический канал на нескольких физических Ethernet линиях.
Эта фишка реализована в PowerQUICC на аппаратном уровне! Ваще кода писать не надо!

"Инвайт?" "Просто добавь воды?"

Применение Jumbo- пакетов сильно уменьшают вероятность отбрасывания UDP-пакетов в перегруженном компе.

В нормальных процессорах DMA таки ускоряет пересылку данных. Особенно в синхронных шинах.
Пересылка - последовательность операций ввода-вывода.

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

>И действительную пользу от DMA можно получить только в многозадачных решениях под управлением RTOS

Её успешно получают и в однозадачной среде без РТОС.


>UDP уровень в стеке TCP/IP нужен для протоколов которые обеспечивают целостность данных на более верхних уровнях, например SNMP или L2TP тоннели

Целостность данных в своем протоколе в ПЛИС реализовать можно оптимальным для себя образом, а не так, как в TCP.

Кто хочет, сделает перезапрос потерянных блоков, кто не хочет - блоки потеряет.
У ПЛИС буфер в DDR памяти на весь массив данных спокойно можно сделать.

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

У автора всё оборудование в одной комнате. Глобально-сетевые навороты здесь не требуются.

Лучше расскажите где вы этот миф прочитали.


Эта логика не работает в коммуникационных процессорах. Надо знать и учитывать правила шинного арбитража.


Не представляю как. Но не будем здесь об этом, а то основная тема погибнет



У этой системы два конца и было сказано о затыках на стороне PC. Значит задача должна облегчаться для PC. Один из реальных стандартных вариантов - multilink


Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.
На таких скоростях и с цепочкой буферов на всех устройствах от сетевой карты до CPU и диска может не быть возможности переповторов на уровне приложения.


Такую скорость только iperf умеет показывать на обычном десктопе.


Неплохая комната в 40 м да еще с гальванической развязкой.
Тут суровое пром. применение проглядывает.

Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)?
А то что-то когда доходит до поиска, ничего не нахожу. Заманчиво поставить некий комуникационный проц и не иметь гемора с
реализацией всёго самому на FPGA, но что-то не находится проца, который может взять у моего устройства по локальной шине 100 МБАЙТ и передать по гигабиту с гарантией доставки (не голый UDP).
А то помнится все говорили что ARM за 15$ есть решение, только вот где тот ARM...
Да, и хотелось-бы не что-то абстрактное, а то что реально купить можно. Думаю будет не только мне интересно.

>Лучше расскажите где вы этот миф прочитали

В этот миф смотрю осциллографом и сетевым анализатором. Процессоры DSP и синтезируемый Nios2.
В мире DSP и ПЛИС то, что я говорю о пересылке DMA, никого не смутит.

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

У нас есть примерно два варианта - Nios/Microblaze или готовый процессор. Применительно к ним эта логика работает.


>У этой системы два конца и было сказано о затыках на стороне PC. Значит задача должна облегчаться для PC. Один из реальных стандартных вариантов - multilink

Сколько PC и сколько линков нужно, чтобы передать 125 Мбайт в секунду? 1 и 1. Сам передавал.
Блин, заболтали. 114 МБ пользовательских данных. 125, если голый сокет.

>Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.
На таких скоростях и с цепочкой буферов на всех устройствах от сетевой карты до CPU и диска может не быть возможности переповторов на уровне приложения.

Как может не быть, если приложение всегда способно перезапросить блок данных. Разве что дисковая система не справится, что зависит о потребностей автора. А тогда вопрос не в передаче.

Меня это вообще удивляет, пропускная способность нутра компьютера достигла десятка гигабайт в секунду, а поток опять не лезет.

На точкеNet, конечно, это может и не заработать.

>Такую скорость только iperf умеет показывать на обычном десктопе.

WinSocket + приемный поток + увеличенный буфер сокета (!) показывает такую скорость


> комната
пусть 40 м. Гигабитный Ethernet, пусть и в двух экземплярах, спасет отца русской демократии (с).



>Может предложите конкретно, на чём можно сделать кроме FPGA пересылку потока 100 МБАЙТ по гигабиту с гарантией доставки (не голый UDP)?

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

>но что-то не находится проца, который может взять у моего устройства по локальной шине 100 МБАЙТ и передать по гигабиту с гарантией доставки (не голый UDP).

Проц такой есть. У AD это TigerSharc TS20x, у Техаса что-нибудь в духе C64xx. Главное, чтобы была внешняя шина 100-125 МГц в синхронном режиме. Наличие последовательных портов с LVDS у процессора тоже сособствует.

Арм за 15 долл здесь не катит.

И не найдете. Поскольку 100 МБАЙТ по гигабиту получали только в лабораторных условиях с голыми Jumbo-пакетами размером до 16К.
Про ARM за 15$ говорили в контексте скорости 86 МБИТ/СЕК на голых UDP пакетах.

Так хоть что близкое найти. Только PowerPC вот советовали, но там проц 400MHZ, явно не хватит.
Про максимум, вы тесили или как? Слышал что 2 компа выжимают под 100мбайт без напряга. Сам ещё не тестил, но проверю.


Да тут в соседней ветке AlexandrY советовал ARM с Гиг MAC-ом, но как-то напряг с такими.
Вот и хотел узнать, где такие берут.

Народ, вы все позабывали то, откуда берутся данные. Собрать их оттуда без ПЛИС решения вообще не видно.

Точно.

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п. Но архитектура уже более или менее определилась: две груды LVPECL линий заходят на Spartan-3AN (благо, хоть это и не документированно для этой ПЛИС, но при желании, можно собрать LVPECL выходы аналогичные "Virtex-E LVPECL"), благополучно преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).
Также не может не радовать и то, что выступившим удалось передать более 100МБайт/с по Gigabit Ethernet, мне же всего-то требуется только 15МБайт/с (или, если очень захочется заказчику увеличить количество датчиков - ну никак не более 30МБайт/с - только для меня остается загадной: нафига ставить еще больше датчиков - их и так в полноценной системе их дофига, а обычно заказывают с 50%-60% каналов сбора данных).

Один из плюсов UDP - стандартные возможности програмирования, например в винде стандартно можно работать только с TCP и UDP, если ниже, придётся использовать WinPCap: http://netgroup-serv.polito.it/winpcap/
Если WinPCap допустим, можно и без UDP попробовать.


И к чему склоняетесь?


Кстати, как-то пролистал стандарт на TCP, и меня терзают смутные мысли, что если начать делать такой протокол, получится почти тот-же TCP, только без уровня функций пользователя. Ни кто не пробовал, насколько это так?

Есть ещё древний RDP (rfc908+rfc1151):

На самом деле все не так сложно и ограничено в выборе. Стандартные возможности программирования позволяют без проблем написать свой любой протокол, который будет работать с NDIS-уровнем, и представляться в юзермоде хоть через те же обычные сокеты, что и TCP/IP, хоть как-то по своему. Тоже мне сверхзадача. И никакие пкапы не нужны.

Я в общем тоже считаю, что никакие UDP там не нужны. Голый Eth уровень, и своя удобная лично для себя система контроля доставки и ретрансмитов (на UDP ее кстати тоже реализовывать, так что UDP это просто лишняя возня в ПЛИС)