Перейти к содержанию
    

TCP/IP на Альтере (1Гбит/с)

Ваше дело верить или нет - убеждать мне кого-либо уже давно влом. Тот кому нужно - сам померяет и убедится, а кому не нужно - просто забьет на все это. Просто речь о том, что банальная тачка с Linux давным давно перешагнула порог в 100 Mb/s и ничего заоблачного здесь нет и быть не может. Не думаю что марка свитча может иметь хоть какое-либо влияние на скорость TCP/IP стека операционной системы, ну так ради Бога, извольте - switch D-Link DGS1005D. Файрвол - iptables, с десяток правил, включая маскарадные :

 

..........

[inglier]:root:~ # iptables -L -vn
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source
destination
1321 85434 ACCEPT     all  --  lo     *       0.0.0.0/0
0.0.0.0/0
  97  7839 ACCEPT     all  --  eth1   *       0.0.0.0/0
0.0.0.0/0
1726  758K ACCEPT     all  --  wlan0  *       0.0.0.0/0
85.238.113.239      state RELATED,ESTABLISHED
   0     0 syn-flood  tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x17/0x02
   0     0 DROP       tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
   0     0 ACCEPT     icmp --  wlan0  *       0.0.0.0/0
0.0.0.0/0           icmp type 8
   0     0 ACCEPT     icmp --  wlan0  *       0.0.0.0/0
0.0.0.0/0           icmp type 0
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:53
   0     0 ACCEPT     udp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED udp dpt:53
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:80
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:443
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:21
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:25
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:465
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:995
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:9418
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           state NEW,RELATED,ESTABLISHED tcp dpt:22
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp dpt:43205
   0     0 ACCEPT     udp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           udp dpt:43205
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp dpt:55555
   0     0 ACCEPT     udp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           udp dpt:55555
   0     0 ACCEPT     tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp dpt:4444
   0     0 ACCEPT     udp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           udp dpt:4444
   0     0 DROP       tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp dpts:0:1023
  68 20762 DROP       udp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           udp dpts:0:1023
   0     0 DROP       tcp  --  wlan0  *       0.0.0.0/0
0.0.0.0/0           tcp flags:0x17/0x02

Chain FORWARD (policy ACCEPT 882K packets, 682M bytes)
pkts bytes target     prot opt in     out     source
destination

Chain OUTPUT (policy ACCEPT 3346K packets, 4492M bytes)
pkts bytes target     prot opt in     out     source
destination

Chain syn-flood (1 references)
pkts bytes target     prot opt in     out     source
destination
   0     0 RETURN     all  --  *      *       0.0.0.0/0
0.0.0.0/0           limit: avg 30/sec burst 30
   0     0 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0

.....................

 

Сетевухи на первой и второй тачке - обычные встроенные в мамки, первая:

 

Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)

 

вторая тачка :

 

Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)

 

wlan на второй :

Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

 

Дык после всех дел, что значит топология ? Как кабеля по полу разложены что-ли ? Это уже слишком ... ;)

 

UDP будет еще быстрее, если не верите - сами соберите стендик из двух тачек. А драйвера, батенька, если честно, тут до спины.

Изменено пользователем Omen_13

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я конечно дико извиняюсь, но вы что, прокачали 1 гигабит через AR5212 Wireless Card !?

 

Сетевухи на первой и второй тачке - обычные встроенные в мамки, первая:

 

Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)

 

вторая тачка :

 

Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)

 

wlan на второй :

Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

 

Дык после всех дел, что значит топология ? Как кабеля по полу разложены что-ли ? Это уже слишком ... ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не через, а от, 85.238.113.239 есть ip'шник моего wlan, на котором собственно и висел сервер iperf. Вы невнимательно прочитали мое предыдущее сообщение, в котором был описан путь пакета через интерфейсы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

iperf сервис роутинга линукса даже не пытается использовать.

Вы лучше на одном компе сделайте iperf и клиента и сервер, а у другого сделайте два IP адреса с роутингом.

Боюсь результат будет сильно грустнее.

Впрочем и этот не вызывает доверия, размер пакета то какой? 1514 небось или вообще Jumbo Frame.

Я порылся в интернете и нашел вот это

http://www.zti-telecom.com/brochuresN/LanT...easurements.pdf

возможно Harbour прав

Видимо обычные тесты замеряются на скорость прокачки файлов - и этот подход очень грязный и взаимодействие

с application layer тормозит

Если application layer не затронут то пакеты что ethernet что IP ну даже если и дважды вынимаются и копируются в памяти через DMA

разница будет небольшая

И программный оверхед TCP уровня может тоже быть небольшим

Спасибо харбору за интересную информацию

Про аппаратный TCP я уже тож что то видел в инете

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Господа! По-моему Линукс (так же как и Д-Линк) и Стратикс это сомсем разные вещи. Давайте вернемся к начальной теме. Как лучше на Стратиксе сделать TCP/IP и с какими трудностями можно столкнуться при самостоятельной аппаратной реализации?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все очень зависит от задачи. При подаче, данной в исходном в посте я бы поднял nios+lwip и порешал бы вопрос, но если у задачи есть ньюансы, требующие таки-да OS, вот-тут могут быть грабельки

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все очень зависит от задачи. При подаче, данной в исходном в посте я бы поднял nios+lwip и порешал бы вопрос, но если у задачи есть ньюансы, требующие таки-да OS, вот-тут могут быть грабельки

Хочется понять что у авторов оригинального вопроса приоритетно - их приложение или принцип

Если приложение - то мне сложно понять как они с ним будут работать без процессора

если только они не делают какой нибудь тупой loopback или файрволл-роутинг

Если процессор есть - например NIOS - то дещевле TCP засунуть туда вместе с каким нибудь Linux

 

Если вопрос из принципа как закомпилить TCP IP стек в хардварь то мне интересны хоть какие нибудь детали

того как это будут использовать - принципиально закомпилировать C в hardware наверное несложно - вот кто и как

пакеты со стека снимать будет

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

имелось ввиду следуещее : если задача стоит обрабатывать и перекачивать один поток на хост - ОС не нужна, если нужно на устройстве перключать задачи - то нужна. Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так к чему вы тогда пудрили всем этим iperf-ом? Linux же такой реактивный у вас.

Иль засомневались? :biggrin:

 

имелось ввиду следуещее : если задача стоит обрабатывать и перекачивать один поток на хост - ОС не нужна, если нужно на устройстве перключать задачи - то нужна. Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зачем tcp вообще здесь.

Плис с синтезированным Gigabit MAC (2-3 тыс LUT4) сделает вам поток UDP по 1 Гбит в обе стороны.

Совместимость с другими узлами сети (как изначально требовалось) обеспечивается реализацией сетевых протоколов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зачем tcp вообще здесь.

Плис с синтезированным Gigabit MAC (2-3 тыс LUT4) сделает вам поток UDP по 1 Гбит в обе стороны.

Совместимость с другими узлами сети (как изначально требовалось) обеспечивается реализацией сетевых протоколов.

Гигабит по помему полудуплекс. И не понятно какая именно скорость нужна. Пакеты-то будут теряться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ...

А можно отсюда поподробнее - видимо есть опыт из личной жизни - пытались на Nios и такой то версией Linux сделать то-то - и получили вот такой результат

Оч интересно

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

NIOS для этого мучать совсем не обязательно.

Прописная истина, что синтезированные процы сильно медленнее хардварных.

Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.

Тут только десяток или сотня NIOS-ов справится.

Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение.

 

 

А можно отсюда поподробнее - видимо есть опыт из личной жизни - пытались на Nios и такой то версией Linux сделать то-то - и получили вот такой результат

Оч интересно

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

NIOS для этого мучать совсем не обязательно.

Прописная истина, что синтезированные процы сильно медленнее хардварных.

Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.

Тут только десяток или сотня NIOS-ов справится.

Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение.

Самое правильное, это будет сборку пакетов, подсчет CRC в плисину вынести. А НИОС пусть получает готовый, и собранный TCP или UDP пакет, с подсчитанной контрольной суммой итд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...