[zltigo 1]

Представляю. Нисколько, если настроить все на работу по DMA.

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

[AlexandrY 3]

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

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

А если думать о масштабировании и разделении потоков, то однозначно надо использовать многозадачный многинтерфейсный стек с мощным процессором сделанным не на FPGA

В данной теме я уверен человек просто никуда не денется и ему придется заниматься масштабированием с расчеплением TCP потоков если надо сделать в сумме больше 100 MBit/s

 

Никакой самопал на UDP не спасет ситуацию. Сетевая карта перегруженного компа просто молча отбрасывает UDP пакеты.

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

В данном случае переносить контроль целостности на еще более верхний уровень будет нетривиальной задачей хотя в некоторых случаях есть интересные решения, как тоннель с мultilink PPP поверх UDP делающий один логический канал на нескольких физических Ethernet линиях.

Эта фишка реализована в PowerQUICC на аппаратном уровне! Ваще кода писать не надо! ;)

 

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

[blackfin 25]

Эта фишка реализована в PowerQUICC на аппаратном уровне! Ваще кода писать не надо! ;)

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

[aprox 0]

Никакой самопал на UDP не спасет ситуацию. Сетевая карта перегруженного компа просто молча отбрасывает UDP пакеты.

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

[jojo 0]

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

Пересылка - последовательность операций ввода-вывода.

 

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

 

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

 

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

 

 

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

 

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

 

Кто хочет, сделает перезапрос потерянных блоков, кто не хочет - блоки потеряет.

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

 

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

 

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

[AlexandrY 3]

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

Пересылка - последовательность операций ввода-вывода.

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

 

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

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

 

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

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

 

 

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

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

 

Кто хочет, сделает перезапрос потерянных блоков, кто не хочет - блоки потеряет.

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

Здесь вы в фантазиях ограничены. Поскольку все диктуется механизмом сохранения данных в PC.

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

 

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

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

 

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

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

Тут суровое пром. применение проглядывает.

[Builder 1]

CUT

А если думать о масштабировании и разделении потоков, то однозначно надо использовать многозадачный многинтерфейсный стек с мощным процессором сделанным не на FPGA

CUT

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

А то что-то когда доходит до поиска, ничего не нахожу. Заманчиво поставить некий комуникационный проц и не иметь гемора с

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

А то помнится все говорили что ARM за 15$ есть решение, только вот где тот ARM...

Да, и хотелось-бы не что-то абстрактное, а то что реально купить можно. Думаю будет не только мне интересно.

[jojo 0]

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

 

В этот миф смотрю осциллографом и сетевым анализатором. Процессоры 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 долл здесь не катит.

[aprox 0]

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

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

А то помнится все говорили что ARM за 15$ есть решение, только вот где тот ARM...

Да, и хотелось-бы не что-то абстрактное, а то что реально купить можно. Думаю будет не только мне интересно.

Про ARM за 15$ говорили в контексте скорости 86 МБИТ/СЕК на голых UDP пакетах.

[Builder 1]

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

Так хоть что близкое найти. Только PowerPC вот советовали, но там проц 400MHZ, явно не хватит.

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

 

Про ARM за 15$ говорили в контексте скорости 86 МБИТ/СЕК на голых UDP пакетах.

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

Вот и хотел узнать, где такие берут.

[SM 0]

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

[Beby 8]

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

Точно.

 

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

 

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).

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

[Builder 1]

Еще раз напомню, т.к. не прозвучало достаточных (для меня) доводов: почему надо пухнуть с поддержкой UDP/IP, то предполагаю обойтись голым Ethernet'ом и соединение сделать по меди аппаратно точно-точка (без коммутаторов и прочей дряни).

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

Если WinPCap допустим, можно и без UDP попробовать.

 

Сейчас прорабатываю варианты реализации - какую Eth PHY проще купить (и использовать), какое внешнее ОЗУ легче достать и т.п.

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

 

преобразуются в 2 потока (данных и команд), далее запихиваются во внешнее ОЗУ. При освобождении Eth Gigabit MAC, данные из ОЗУ заталкиваются в MAC, и в служебном массивчике метятся как переданные (но пока еще без подтверждения о получении), после получения такого подтверждения для конкретного пакета, место, занимаемое в ОЗУ этим пакетом, считается свободным. Ну и в таком духе дальше принимать/передавать данные.

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

[blackfin 25]

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

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

The Reliable Data Protocol (RDP) is designed to provide a

reliable data transport service for packet-based applications

such as remote loading and debugging. The protocol is intended

to be simple to implement but still be efficient in environments

where there may be long transmission delays and loss or non-

sequential delivery of message segments.

[SM 0]

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

Если WinPCap допустим, можно и без UDP попробовать.

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

 

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