Jump to content
Поиск
    

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

Reply to this topic

Harbour    0

Harbour
Posted (edited) · Report post

Ваше дело верить или нет - убеждать мне кого-либо уже давно влом. Тот кому нужно - сам померяет и убедится, а кому не нужно - просто забьет на все это. Просто речь о том, что банальная тачка с 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 будет еще быстрее, если не верите - сами соберите стендик из двух тачек. А драйвера, батенька, если честно, тут до спины.

Edited by Omen_13

Share this post

Link to post
Share on other sites

AlexandrY    4

AlexandrY
Posted · Report post

Я конечно дико извиняюсь, но вы что, прокачали 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)

 

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

Share this post

Link to post
Share on other sites

Harbour    0

Harbour
Posted · Report post

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

Share this post

Link to post
Share on other sites

islavv    0

islavv
Posted · Report post
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 я уже тож что то видел в инете

Share this post

Link to post
Share on other sites

Sefo    0

Sefo
Posted · Report post

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

Share this post

Link to post
Share on other sites

Harbour    0

Harbour
Posted · Report post

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

Share this post

Link to post
Share on other sites

islavv    0

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

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

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

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

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

 

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

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

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

Share this post

Link to post
Share on other sites

Harbour    0

Harbour
Posted · Report post

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

Share this post

Link to post
Share on other sites

AlexandrY    4

AlexandrY
Posted · Report post

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

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

 

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

Share this post

Link to post
Share on other sites

jojo    0

jojo
Posted · Report post

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

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

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

Share this post

Link to post
Share on other sites

Methane    0

Methane
Posted · Report post
Зачем tcp вообще здесь.

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

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

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

Share this post

Link to post
Share on other sites

islavv    0

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

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

Оч интересно

Share this post

Link to post
Share on other sites

AlexandrY    4

AlexandrY
Posted · Report post

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

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

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

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

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

 

 

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

Оч интересно

Share this post

Link to post
Share on other sites

Methane    0

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

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

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

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

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

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

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
×
  • Create New...