Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.
Есть development board для экспериментов (PCIe с Stratix II GX).
Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?
Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI

Спасибо всем

Какой физический уровень? Может можно только ethernet фреймы гнать?


Не много. Пара мегабайт в секунду, по аналогии с другими 32х разрядками. И то если на UDP спустится.


Я не сильно понял что именно нужно. Откуда и куда данные идти будут?

Может вам можно обойтись ethernet фреймами?

Физ уровень оптика (как его там - 1000BASE-X ?) Возможен внешний преобразователь в 1000BASE-T (витая пара)
Уровнем Ethernet обойтись нельзя. К этой же сети подключены другие абоненты.
Данные будут как из сети в девайс, так и наоборот.
Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.

Дли плисины в общем фигня.


Ну и что? Гоняйте просто Ethernet фреймы по мак адресу.


Я для UDP говорил. Может быть и меньше. Фишка в том, что нужен очень приличный процессор чтобы разгребать то, что валится из erthernet. Несколько десятков мипсов это очень мало. Стек будет просто захлебываться, пакеты дропаться, полезут таймауты итд.

1. гигбитный свитч на 3 порта, проц с гигабитом на борту, и фпга. Проц рулит, фпга качает. Свитч разруливает.
2. гигабитный свитч на 2 порта гигабита и порт 100 мегабит в фпга.

1 ое проще и быстрее,
2 ое рациональнее

2 копейки. "так как устройство будет делить сетевую магистраль с другими"
Это чтож - мы в коллизионный домен что-ли? На гигабитной скорости коллизионный домен не будет работать - там точка точка соединение и свичинг на L2 работает
Если действительно нужно делить физический канал - то технология называется PON - passive optical network - но это тож первый и второй уровень
и никакого IP
"Необходим именно TCP/IP"
а TCP то зачем - приложения с TCP используются "на скорости провода" только для фильтрации пакетов по портам
До конца пакет никто не читает
В общем первые две фразы плохо сформулированы и недодуманы
А устройство которое умеет такие вещи делать леи десять как называется L3 Switch или switch-роутер



Наверное обычный TCP/IP стек хоть программный хоть аппаратный без специальной настройки не потянет больше 30 Mбайт/c
Там куча констант сидит
Разгребать чтобы быстро работало можно только фильтрацией пакетов на втором уровне проверяя заголовок IP и TCP аппаратно

Сколько Мб/с требуется и в чем именно трудность аппаратной реализация TCP/IP в ПЛИС?

Именно этот вопрос меня и интересует Может сложностей никаких нет, я пока еще не дошел до поля, где грабли лежат.

Пропускная способность нужна по максимуму. В идеале ~80 МБайт/сек

Для одного соединения по TCP это совершенно дикая цифра.
Такой трафик может набраться только если работает одновременно 10-20 TCP соединений.

В TCP соединении существует понятие окна которое содержит столько данных
сколько проходит за время задержки прохождения данных от одного конца к другому.

Так любой обычный свитчер или роутер на пути какого TCP коннекта может создать такую задержку, что любое разумное окно будет переполнено.
А после переполнения окна в обычном TCP идет длительный процесс восстановления скорости и ретрансмиты.
Вообщем TCP на такой скорости слабо годится, нужна технология не коммутации пакетов, а каналов типа ATM

Ну как-бы 100 Mb/sec легко дает любой задрыпаный Linux (ниже 2 тачки включены через 1GB Ethernet в китайский хаб + ребенок со страшной силой что-то качает из торрента через тот-же хаб) :

[Gate]root:~ # iperf -c Dao
------------------------------------------------------------
Client connecting to dao, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.0.1 port 48592 connected with 10.1.0.100 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 976 MBytes 819 Mbits/sec

По localhost конечно прикольней :

[Dao]:rus:~ # iperf -c localhost
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size: 49.5 KByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 52231 connected with 127.0.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.4 GBytes 9.82 Gbits/sec

Если поднастроить системку, то легко можно еще 100 Mbits/sec выжать.

iperf сервис роутинга линукса даже не пытается использовать.
Вы лучше на одном компе сделайте iperf и клиента и сервер, а у другого сделайте два IP адреса с роутингом.
Боюсь результат будет сильно грустнее.
Впрочем и этот не вызывает доверия, размер пакета то какой? 1514 небось или вообще Jumbo Frame.

А что другие TCP/IP приложения как-то "используют" роутинг ? Они даже не знают о нем, и собственно знать не должны. Вот iperf из внутренней сети на внешнюю - проходит 3 интерфейса :

Dao]:root:~ # iperf -c 85.238.113.239
------------------------------------------------------------
Client connecting to 85.238.113.239, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.0.100 port 47539 connected with 85.238.113.239 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 993 MBytes 833 Mbits/sec
[Dao]:root:~ #

Увы, кроме конкретной таблицы рутинга, у меня еще там firewall :

[Inglier]:root:~ # route -n |wc
45 356 3335
[Inglier]:root:~ # iptables -L -vn|wc
39 393 3718

MTU, стандартный 1500. Еще вопросы будут ?

Расскажите о реальном маршруте пакетов.
Они хоть один роутер проходят или свитчер и какой?
А iperf вообще-то не приложение.
Там чтоб ускорить обработку пакетов их вообще ни в какое окно могут не сохранять.
Т.е. полная бутафория, от TCP там только формат заголовков остается.
Естественно что ни до какого файрвола ничего не доходит.
Покажите реальную статистику SNMP агента по MIB2 на ваших интерфейсах или чего другого заслуживающего большего доверия.

реальный маршрут :

eth0 первый комп -> китайский switch -> eth0 второй комп -> firewall -> route table -> wlan

мерялось от eth0 IP первого компа до wlan IP второго компа

Вы меня пугаете, и что же по Вашему iperf ? По поводу окна есть вполне вменяемая опция, из мана по iperf :

.......
-w, --window n[KM]
TCP window size (socket buffer size)
.......

В приведенном мною логе использовалось окно размером 16kb. Также интересно услышать каким образом приложение может "не сохранить в окно" ?
Насчет "до фаервола не доходит", просьба как-то подкрепить фактами - а то немного похоже на бред - без firewall'а (не забываем еще и про маскарад) TCP/IP пакет из внутренней сетки ну никак не выйдет наружу - хоть тресни. snmp на домашнем рутере я не использую - думаю понятно почему. И потом непонятна разница - snmp их тех же счетчиков внутри ядра данные берет - в чем сокровенный смысл ? Реальная статистика - это конкретная скорость измеренная в конечном приложении, а вот все остальное действительно бутафория. Собственно iperf и ему подобные программы и являются такими приложениями. Иногда можно мерять с помощью клиентов каких либо служб - FTP например, но там придется добавить задержки на реализацию протокола + скорость чтения/записи файловой системы

Ну не верю я iperf.
Я сам компилировал прогу типа iperf работающую на стандартных сокетах.
Ну не тянет интерфейс сокетов такие скорости даже если пакеты отбрасывать сразу.
А вы пока не назвали ни марки своего свитчера ни что за файрвол ни какие фильтры в нем были включены ни тип сетевых карт ни топологию физической связи.
Понимаю что вопросы затяжелые для такой легкой темы, но и долго толковать тут не о чем тогда.
Пока мне кажеться мы просто крутимся вокруг особенностей драйверов сетевых карт.
Сделайте простой опыт: включите порт на прием на компе и пошлите туда просто UDP поток без всякого iperf на приемной стороне.
Скорость упадет драматически.
Т.е. iperf совсем не тупая утилита