Не потянет все равно.
В ARM-ах также используется аппаратных CRC на MAC уровне. Суммирование на IP уровне - даст мизер.
При этом еще есть хитрый RISC управляющий отправкой составных IP пакетов на основе дескрипторов и DMA. По сути та самая сборка.
Ниче не помогает.
Масштабирование - единственный выход.

Недавно гонял UDP на AVR32, дофига даст. Нужно собрать IP пакеты, подсчитать им CRC, собрать UDP пакеты, им посчитать CRC, одновременно нужно выкидывать старые IP пакеты, проводить дефрагментацию IP пакетов итд.

Тот CRC в маке - фигня. Еще много чего есть.

Сообщение отредактировал Methane - Mar 4 2009, 16:40

Меньше 30% даст на коротких пакетах если умудритесь делать аппаратное суммирование всех заголовков,
операции пересылки памяти все равно преобладают.
Да , и называть простое суммирование как CRC немного неточно.

Вот операции с памятью тоже. Можно в общем сделать практически все в FPGA - получаем пакеты и сваливаем в большой циклический буфер это один автомат. Еще один автомат выгребает из буфера и дешает готовые IP пакеты, с дефрагментацией, подсчетом, суммы, выбраковкой старых и итд. Третий автомат - из IP собирает уже готовые UDP, тоже считает что нужно и отдает ниосу. В этом случае НИОС может и успеть, если UDP пакеты будут и они будут достаточно большие. К примеру по 60 килобайт.

а кто нибудь пробовал NicheStack TCP/IP stack NIOS II edition?
http://www.altera.com/literature/hb/nios2/n2sw_nii52013.pdf

Во-первых, чтобы иметь моральное право меня подкалывать, нужно хотя бы быть адекватным в своих постах, например как минимум ответить на мои вопросы к Вам в данном треде. Пока я вижу лишь голословные утверждения не подкрепленные какими-либо фактами, логикой или кодом.
Во-вторых я и не предлагал связку Linux + Nios - а просто отметил что даже такое кривое и непредсказуемое железо как x86, с набортным Linux легко выдает на гора нужную скорость. Сильная сторона Nios - его возможность работать с on-chip RAM, программируемая периферия и неплохая скорость DMA. Т.е. грамотно портированный стек типа lwip займет несколько кил ОЗУ и легко даст нужную скорость. Ставить же Linux на Nios, задача бестолковая и малоперспективная, как по мне необходимость в ней обычно вызвана серьезными архитектурными просчетами.
И в-третьих - Linux у меня таки-да реактивный, или Вас опять грызут сомнения ? Так не стесняйтесь, повторите подвиг Матросова.



Он как-бы идет в комплекте с nios2, начиная с версии квартуса 7.1 :

/opt/altera/nios2eds/components/altera_iniche

подразумевает использование uCOSII, но добрые люди эту гадость из него благополучно выкусили:

http://www.nioswiki.com/User:Admin/"S...uot;_NicheStack

Сам этот стек я не пробовал.

Если бы не поленились и не ставили целью провоцировать бесполезный не относящийся к теме шум,
то посмотрели бы мои проекты где я неоднократно давал порты стека TCP для uCOS под разные платформы
и просто тесты прямой генерации Ethernet трафика без всяких стеков.

Изобразите сами сначала хоть что нибудь на NIOS-е и перестаните даже мечтать о гигабитах.

Дык, к теме треда вопрос и результаты измерения производительности стека
TCP/IP очень даже относятся - отталкиваться нужно от печки. Особенно когда
слышим одно а видим и меряем совершенно другое. А вот удары пятками себя в грудь,
они, действительно, к теме ни фига не относятся.



Тем более мне интересно услышать разьяснение заявлений такого
знающего <grin> человека по следующим утверждениям в данном треде :

1. Почему же "iperf вообще-то не приложение" ?
2. Как приложение может не "сохранить в окно" ?
3. И как пакет проходя от интерфейса до интерфейса "ни до какого файрвола"
не доходит ?

Вобще-то наблюдается острая нехватка базовых знаний, купили бы что-ли книжечку
"TCP/IP для чайников" и не мучили бы больше форум своими перлами



На Nios'е я изображал еще в 2004 году на квартусе 3.0SP2, небось тогда о нем
и не слышали ? Просто с быстрой сетью задач не попадалось.

Сначала хотел, потом отказался: проблема с уже упоминавшейся здесь uCOSII.
Сделал на NiosII свои драйвера для LAN91C111, потом написал под ARP, ICMP и UDP, более раскрывать стек пока не нужно.
Но LAN91C111 работает на Ethernet-100, а требуется уже и Ethernet-1000.
Для последнего у меня есть 88E1111, но проблемы с нормальным описанием: достать его не возможно, из-за политики Marwell.
Может, у кого есть подробное описание 88E1111, то поделитесь или укажите, где все это добро есть. На фирму не ссылаться, там одни футболисты.

Если кому-то интересно, то вычисление контрольных сумм для UDP делал аппаратно, по ходу работы внешней FSM, т.е. ресурс NiosII на это не тратил. А воообще, ускоряться там можно много, хватало бы идей.

Сообщение отредактировал Serhiy_UA - Mar 5 2009, 13:38

Так uCOSII при этом у вас задействована или свое однозадачное приложение написано?

Ось не применял.
Задач несколько. Обошелся программным конечным автоматом-распределителем.
Главная задача с UDP, другие попроще.

Оч Интересное решение - хотя я бы попытался обойтись одной задачей
вот вопрос как и какие при этом обрабатываются прерывания
и самое главное - вам удалось успешно использовать Niche TCP/IP?
Он аппаратно реализован?


Или просто вместо написания стека вы вписываете TCP хедеры и обходитесь без стека?

Niche TCP/IP не применял, он для меня оказался сложен и избыточен, по этому предпочел писать все свое.
Мое устройство оцифровывает сигналы от радара с частотой 25 МГц, выполняет первичную обработку и делает следующее:
- Непрерывно выдает на компьютеры для вторичной обработки UDP пакеты. Это все на NiosII, только контрольная сумма аппаратно.
- Принимает и отрабатывает ARP, ICMP и UDP пакеты c командами управления, которые поступают достаточно редко, то же NiosII.
- Контролирует клавиатуру и управляет знаковым LCD-дисплеем, собираюсь выводить еще на графику.
- Обрабатывает команды и обменивается по UART на RS232
Все это выполняется с главным циклом в 500мкс, это для выдачи UDP пакетов.
Остальные задачи мене приоритетные и растягиваются по циклам с помощь программного конечного автомата на NiosII. Здесь все события, в том числе LAN91C111, контролируются опросом, прерываний нет. Это один из путей, согласен, что возможны и другие, на основе прерываний, но они сложнее.
В аппаратуре много арифметики и несколько FSM, однако и NiosII (fast) нагружен, он работает с тактом в 100МГц.
Все это на StratixII.

У меня стоит задача Ethernet на 1Гбит, но на 88E1111. Нормальной документации нет, а та, что есть, не помогает. Может кто поделится?

Если вам не в 10 раз больше нужен поток данных поставьте второй Fast Ethernet и воткните в свич - 4FE - GigE на выходе свича поимеете гигабитный трафик
с полосой 200Мбит
Не хватит - поставьте 3 Ethernet
в свиче теряться ничего не будет

Вообще, конечно, впечатляет
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.