| |
|
  |
 TCP/IP на Альтере (1Гбит/с), Кто-нибудь делал ? |
|
|
|
|
 Feb 28 2009, 16:34
|
Местами Гуру
Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323
|
Ваше дело верить или нет - убеждать мне кого-либо уже давно влом. Тот кому нужно - сам померяет и убедится, а кому не нужно - просто забьет на все это. Просто речь о том, что банальная тачка с Linux давным давно перешагнула порог в 100 Mb/s и ничего заоблачного здесь нет и быть не может. Не думаю что марка свитча может иметь хоть какое-либо влияние на скорость TCP/IP стека операционной системы, ну так ради Бога, извольте - switch D-Link DGS1005D. Файрвол - iptables, с десяток правил, включая маскарадные : .......... CODE [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 - Feb 28 2009, 19:17
|
|
|
|
|
|
|
|
Feb 28 2009, 17:12
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Я конечно дико извиняюсь, но вы что, прокачали 1 гигабит через AR5212 Wireless Card !? Цитата(Harbour @ Feb 28 2009, 18:34)  Сетевухи на первой и второй тачке - обычные встроенные в мамки, первая: 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) Дык после всех дел, что значит топология ? Как кабеля по полу разложены что-ли ? Это уже слишком ... |
|
|
|
|
|
|
|
Mar 1 2009, 16:41
|
Участник
Группа: Участник
Сообщений: 61
Регистрация: 11-11-08
Пользователь №: 41 522
|
Цитата(AlexandrY @ Feb 28 2009, 11:30) 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 я уже тож что то видел в инете
|
|
|
|
|
|
|
|
Mar 4 2009, 03:51
|
Участник
Группа: Участник
Сообщений: 61
Регистрация: 11-11-08
Пользователь №: 41 522
|
Цитата(Harbour @ Mar 2 2009, 10:42) Все очень зависит от задачи. При подаче, данной в исходном в посте я бы поднял nios+lwip и порешал бы вопрос, но если у задачи есть ньюансы, требующие таки-да OS, вот-тут могут быть грабельки Хочется понять что у авторов оригинального вопроса приоритетно - их приложение или принцип Если приложение - то мне сложно понять как они с ним будут работать без процессора если только они не делают какой нибудь тупой loopback или файрволл-роутинг Если процессор есть - например NIOS - то дещевле TCP засунуть туда вместе с каким нибудь Linux Если вопрос из принципа как закомпилить TCP IP стек в хардварь то мне интересны хоть какие нибудь детали того как это будут использовать - принципиально закомпилировать C в hardware наверное несложно - вот кто и как пакеты со стека снимать будет
|
|
|
|
|
|
|
|
Mar 4 2009, 14:44
|
Участник
Группа: Участник
Сообщений: 61
Регистрация: 11-11-08
Пользователь №: 41 522
|
Цитата(Harbour @ Mar 4 2009, 13:28) Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ... А можно отсюда поподробнее - видимо есть опыт из личной жизни - пытались на Nios и такой то версией Linux сделать то-то - и получили вот такой результат Оч интересно
|
|
|
|
|
|
|
|
Mar 4 2009, 15:29
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
NIOS для этого мучать совсем не обязательно. Прописная истина, что синтезированные процы сильно медленнее хардварных. Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать. Тут только десяток или сотня NIOS-ов справится. Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение. Цитата(islavv @ Mar 4 2009, 16:44) А можно отсюда поподробнее - видимо есть опыт из личной жизни - пытались на Nios и такой то версией Linux сделать то-то - и получили вот такой результат
Оч интересно
|
|
|
|
|
|
|
|
Mar 4 2009, 16:22
|
Гуру
Группа: Свой
Сообщений: 3 615
Регистрация: 12-01-09
Из: США, Главное разведовательное управление
Пользователь №: 43 230
|
Цитата(AlexandrY @ Mar 4 2009, 17:29) NIOS для этого мучать совсем не обязательно.
Прописная истина, что синтезированные процы сильно медленнее хардварных.
Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.
Тут только десяток или сотня NIOS-ов справится.
Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение. Самое правильное, это будет сборку пакетов, подсчет CRC в плисину вынести. А НИОС пусть получает готовый, и собранный TCP или UDP пакет, с подсчитанной контрольной суммой итд.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
