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

Мне интересно, как Вы в целом решили свою задачу, сколько задействовано FSM, какие их размеры, какие тактовые частоты, применяются ли PLL и DLL? Как организован вычислительный процесс, есть ли конвейеры, т.е. хотелось бы оценить сложность такого мероприятия. Ведь у Вас все это действительно вышло не слабо.

А вот еще вопрос, понятно, что в компьютерах стек TCP/IP в основном реализован программно, а есть ли высокоскоростные чисто аппаратные решения стеков для 1G и 10G? В чем их специфика?


к Enthusiast спасибо за ссылку, скачал.
к Stewart Little надеюсь, не откажете в помощи.

Кому-нибудь пригодится техническое описание микросхемы Marvell 88E1111? На всякий случай я добавил его сюда: /upload/DOCs/Marvell88E1111/88E1111 datasheet.pdf. Туда же положил схемы для использования этой микросхемы с оптикой.

это не так. ниос тут ортогонален. можно и на системе под его управлением такие проценты получить

Ну когда ж я отказывал Пишите в личку.

Согласен ровно до того момента, когда пытаются организовать толстый поток данных в/из сети. А как вспомогательный девайс, MCU конечно не помешает.
В самом младшем EP3C5xxxx проект занял 35% LE, 40% памяти, PLL c 25 на 125MHz - 1шт. вычислительного процесса как такового нет. Вместо него два независимых канала Прием и Передача, построенных исключительно, как вы говорите, на конвеерах. Канал приема имеет интерпретатор заголовков пакетов чтобы выделять только нужные пакеты. Ненужные игнорируются. Из нужных ARP запросы и UDP с заданными параметрами. Соответственно идет перенаправление этих пакетов, часть на управление устройством в качестве UDP-сервера, а часть на преобразование в выходной поток данных пользователя, например на видео выход. Канал передачи много проще.

Я занимался поиском готовых решений довольно давно. Тогда ничего подходящего для указанного вами диапазона не нашел. Как сейчас обстоят дела с чисто аппаратными делами не знаю, но думаю, что TCP протокол по-прежнему не реализован аппаратно. Просто потому, что он практически не нужен для 1G и 10G.

Stewart Little, Огромное спасибо!

Сообщение отредактировал bark - Aug 19 2010, 11:15

Ай да молодца микрософт но это не совсем беда XP - это больше беда гигабит карт совсем уж бюджетного уровня - те которые впринципе не могут переварить гигабит и сидят на PCI - переходите на PCI-E или старенький PCI-X-100 там все хорошо. Хотя XP и вносит свою посильную лепту, когда ей позволяют.



а почему так мало? 86%, в смысле, а не 100%? или вы утилизируете гигабит на все 100%, а полезные данные занимают 86%?

Вполне возможно, что все так и есть. Я использовал сетевые карты от "Длинка" и "Интела" в разъеме PCI. Однако при передаче пакетов с ПЛИСа в режиме 100 Мб/с компьютер с XP также начинает очень сильно тормозить. Под Линуксом проверять тоже самое я пока не пробовал.

Именно полезные данные в UDP-пакетах стандартного размера. И с учетом межфреймового промежутка.



Если использовать PCAP в обход драйверов виндов, да еще и работать с Jambo пакетами по UDP, то даже в XP наблюдаются очень непложие результаты по производительности приема данных с указанных вами сетевых карт.

А программа-перехватчик сетевых пакетов Wireshark использует не такие драйвера по умолчанию? Или их надо как-то включать? В списке установленных программ у меня стоит WinPCAP 4.1. При уменьшении частоты передачи сетевых пакетов (значительном увеличении задержки между пакетами) компьютер начинает приходить в себя.

Вот как раз использовал Jumbo UDP пакеты размером ~3000-4000.
достигал 620Мбит/с потока без особых проблем. загрузка компа 10-30%. (intel E8400)
без Джумбы тоже летает, но загрузка проца уже под 60%
как я понимаю можно было бы и больше передавать, но используемая тогда железяка больше просто нге могла в силу аппаратных причин.

Да, это то самое. И может использоваться в любых программах, не только в снифере Wireshark
Если в снифере отключить текущие прорисовки экрана, которыми занимается винда и тормозит, то Wireshark работает достаточно шустро и не пропускает пакеты.

Схожая тема: " FPGA - Ethernet - PC, Как лучше организовать?"
http://electronix.ru/forum/index.php?showt...=46452&st=0

Да это просто супер. Огромное спасибо Enthusiast



Может быть эти ссылки (Nios Community Wiki) на работающие проекты для Altera 3C120 development board будут полезны для bark:
NiosII3C120DesignExample, SimpleSocketServerPlus, SuperloopSimpleSocketServerPlus

Привет всем!
Так уж получилось, что в данный момент тоже работаю над тем, чтобы пропустить толстый поток по 1G.
Читал-читал тему. Делал кой-чего свое и в голову пришла безумная идея - если мак в плисе, а тем более если свой, то можно организовать перед выдачей на PHY мультиплексор и поставить два MACа. (Ну не просто тупой мультиплексор, а различать кадры, приоритеты и т.п.)
Тогда можно быстрый поток оборачивать в UDP+IP и гнать дальше куда надо.
А другими вещами может заняться процессор.

MACи могут быть и с одинаковыми адресами, это понятно.
Демультиплексировать принятые от PHY данные смысла нет. Просто подавать на оба MACа, а дальше в какой-то момент не нужные просто уйдут в никуда.

Вот

P.S. но если вам нужно еще только ARP и ICMP - то городить такой огород конечно нет смысла

Сообщение отредактировал Gothard - Aug 24 2010, 05:24