Я воспользовался данной версией LwIP, но со значениями всех констант по умолчанию скорость обмен данными tcp-клиента (из папки examples) с сервером на ПК составила лишь ок. 550 Кб/с (~4Мбит/с). Тестировал ли кто-нибудь данную реализацию tcp-клиента и с какими параметрами (константами)? Какая получена скорость? Можете ли что-нибудь посоветовать мне для увеличения скорости (с ethernet работаю недавно)? Стоит ли использовать другие реализации TCP/IP (требуется скорость >60-80Мбит/с)?

Мое железо:
DK-NIOS-2S60N
LAN91C111
NIOSII без ОС

Спасибо.

Сообщение отредактировал Veg@ - Feb 1 2010, 17:12

Не могу сказать конкретно про NIOS. Но есть несколько общих рекомендаций увеличения быстродействия LwIP.
1. Ethernet контроллер должен быть сконфигурирован в режиме DMA.
2. Процессор должен иметь кэш данных и кэш инструкций, часть инструкций желательно разместить в блочной памяти FPGA.

Да, не уточнил: использую стандартную сборку niosII_stratixII_2s60_RoHS.
1. а где (в SOPC или прямо в коде) и как настроить контроллер на режим DMA?
2. ок, попробую NiosII/f

это довольно много для чисто софтовой реализации. тут как уже упоминалось не помешают кэши и частота повыше, но скорее всего и это не спасет. нужно делать tcp offload, т.е. всякие заголовки, контрольные суммы и т.п. муть генерить аппаратно. задача вполне реализуемая на этом железе.

Действительно, программный подсчет CRC занимает очень много времени. Как реализовать это аппаратно ? Т.е. вычисление может производить сам ethernet-контроллер либо необходимо написать собственную реализацию на verilog (vhdl) и соединить ее с LwIP ? Прошу поделиться опытом и, если возможно, примером кода. Спасибо.

Как подсчитана скорость? Расскажите немного о Вашей системе, тогда можно говорить об оптимизации вычислительных процессов. Может, хватит и UDP-пакетов.
У меня Nios/f на 100МГц, с аппаратным вычислением контрольной суммы для UDP. Причем, в нем два поочередно переключаемых блока памяти, пока из одного выдается пакет в LAN через NiosII, второй заполняется аппаратно и для него вычисляется контрольная сумма, т.е. здесь распараллеливание. Потом, работа идет 32-разрядными кодами, а как в LwIP?

Может, поможет это «Nios II Ethernet Acceleration Design Example» в http://www.altera.com/support/examples/nio...celeration.html
и здесь "Nios II CRC Acceleration Design Example "http://www.altera.com/support/examples/nio...celeration.html

2-й вариант предложен выше, там и примеры кода есть. один минус - дополнительные транзакции из памяти в память + канал DMA. но выигрыш уже будет большой. в идеале - запихать весь функционал в MAC, но он у вас железный, так что вариант один. еще всякие ip-шники, MAC-адреса тоже лучше на свой блок скинуть.
тут еще гляньте http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.htm - от этой всей фигни проц можно избавить, пусть логика молотит.

В ПЛИС зашит демонстрационный пример TCP-клиента, отсылающий байты в ПК, на котором имеется написанный на C# TCP-сервер, работающий через сокеты и подсчитывающий количество принятых байт за определенное время.
На ПЛИС временные задержки измерялись с использованием Perfomance counter.

В ПЛИС зашита стандартная сборка Nios - Full featured (NiosII/f, кэш инструкций и данных, DMA-контроллер). Данная конфигурация позволяет передавать TCP-пакеты на скорости ~13Мбит/с. По всей видимости (link) это предел чисто программной реализации LwIP. По Ethernet-каналу планируется передача видеопотока с частотой 25 кадров/сек (про качество картинки и ее размер пока ничего сказать не могу, но скорости ~55-60Мбит/с должно быть вполне достаточно), поэтому выбор сделан в сторону TCP, хотя и он неоднозначен (думаю, выбор будет сделан исходя из полученных скоростей передачи).
О разрядности кодов ничего сказать не могу, т.к. с CRC начал разбираться недавно.

Благодарю за предоставленные ссылки - полезный материал. Буду разбираться.

Сообщение отредактировал Veg@ - Feb 4 2010, 15:16

Думаю, Вашей системе хватило бы и UDP-пакетов, а это даст существенное увеличение скорости в сравнении с TCP-пакетами, где на каждый пакет ожидается подтверждение о его получении.
Да и аппаратное вычисление контрольной суммы здесь само напрашивается.
Моя система чем-то сходна, тоже видеосигнал, оцифровка, и тоже реальный масштаб времени. В пике получается до 70 Мбит/с, а реально после сжатия хватает и 30 Мбит/с. Правда, без DMA, так как NiosII/f достаточно для этих задач LAN. В основном идет выдача, а во встречном направлении, время от времени, поступают команды управления, которые сразу обрабатываются и квитируются. Обошелся набором: UDP, ARP. RARP, ICMP (для ping).
По поводу LwIP – хорошо, что она освоена Вами и работает, может когда-то и нам пригодится. Ее я просматривал пока только в качестве примера для некоторых функций в LAN91C111.

С помощью Perfomance Counter мной было подсчитано, что вся процедура отправки пакета объемом 1400Б по протоколу UDP занимает 0.37мс, из которых на подсчет контрольной суммы UDP и IP пакетов затрачивается 0.07мс и менее 0.00мс соответственно. Отключение подсчета контрольной суммы для UDP-пакета уменьшает время отправки до 0.30мс.
Выходит, что аппаратный подсчет не даст никакого выигрыша в скорости ?

Сообщение отредактировал Veg@ - Feb 22 2010, 11:28

Аппаратный подсчет обязательно дает выигрыш, хотя, согласен, можно и без него и контрольной суммы.
Время 0.30мс - это многовато. Хотя, для LwIP, это может и хороший результат.
В приложении осциллограммы по оценке времени, там это время 0.19мс с аппаратной контрольной суммой. Но это не предел, еще не задействован DMA и др.

AVR32. ~50МГц ~3 мегабайта в секунду. Свой протокол поверх UDP.

А можно, пожалуйста поподробнее, на каком AVR32? У меня на UC3 при 66МГц получилось 16Мбит/с чистый трафик UDP на lwIP. lwIP оптимизтировался слабо и мало.

AVR32 UC3. Направление PC->UC3. Тактовая кажись 48 мегагерц. Делал так - послал три посылки по не помню сколько, потом дождался ответа от UC3, в котором он высылал состояние буфера в SDRAM. Я посылал те пакеты которые не дошли. Снова ждал ответа от UC3 итд. Там главное забить ему буфер в который он фреймы принимает из Ethernet, потом дать время разгрести данные. И там баг был не большой при приеме фрагментированных UDP. Судя по всему пофиксили.