Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.
Есть development board для экспериментов (PCIe с Stratix II GX).
Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?
Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI
Спасибо всем
Полная версия этой страницы: TCP/IP на Альтере (1Гбит/с)
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Цитата(murmel1 @ Feb 2 2009, 20:51) 
Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.
Какой физический уровень? Может можно только ethernet фреймы гнать?
Цитата
Есть development board для экспериментов (PCIe с Stratix II GX).
Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?
Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?
Не много. Пара мегабайт в секунду, по аналогии с другими 32х разрядками. И то если на UDP спустится.
Цитата
Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI
Спасибо всем
Спасибо всем
Я не сильно понял что именно нужно. Откуда и куда данные идти будут?
Может вам можно обойтись ethernet фреймами?
Физ уровень оптика (как его там - 1000BASE-X ?) Возможен внешний преобразователь в 1000BASE-T (витая пара)
Уровнем Ethernet обойтись нельзя. К этой же сети подключены другие абоненты.
Данные будут как из сети в девайс, так и наоборот.
Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.
Уровнем Ethernet обойтись нельзя. К этой же сети подключены другие абоненты.
Данные будут как из сети в девайс, так и наоборот.
Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.
Цитата(murmel1 @ Feb 2 2009, 22:41)
Физ уровень оптика (как его там - 1000BASE-X ?) Возможен внешний преобразователь в 1000BASE-T (витая пара)
Дли плисины в общем фигня.
Цитата
Уровнем Ethernet обойтись нельзя. К этой же сети подключены другие абоненты.
Ну и что? Гоняйте просто Ethernet фреймы по мак адресу.
Цитата
Данные будут как из сети в девайс, так и наоборот.
Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.
Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.
Я для UDP говорил. Может быть и меньше. Фишка в том, что нужен очень приличный процессор чтобы разгребать то, что валится из erthernet. Несколько десятков мипсов это очень мало. Стек будет просто захлебываться, пакеты дропаться, полезут таймауты итд.
Цитата(murmel1 @ Feb 2 2009, 12:51)
Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?
Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI
Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI
1. гигбитный свитч на 3 порта, проц с гигабитом на борту, и фпга. Проц рулит, фпга качает. Свитч разруливает.
2. гигабитный свитч на 2 порта гигабита и порт 100 мегабит в фпга.
1 ое проще и быстрее,
2 ое рациональнее
Цитата(murmel1 @ Feb 2 2009, 21:51)
Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.
Спасибо всем
Спасибо всем
2 копейки. "так как устройство будет делить сетевую магистраль с другими"
Это чтож - мы в коллизионный домен что-ли? На гигабитной скорости коллизионный домен не будет работать - там точка точка соединение и свичинг на L2 работает
Если действительно нужно делить физический канал - то технология называется PON - passive optical network - но это тож первый и второй уровень
и никакого IP
"Необходим именно TCP/IP"
а TCP то зачем - приложения с TCP используются "на скорости провода" только для фильтрации пакетов по портам
До конца пакет никто не читает
В общем первые две фразы плохо сформулированы и недодуманы
А устройство которое умеет такие вещи делать леи десять как называется L3 Switch или switch-роутер
Цитата(Methane @ Feb 2 2009, 23:56)
Я для UDP говорил. Может быть и меньше. Фишка в том, что нужен очень приличный процессор чтобы разгребать то, что валится из erthernet. Несколько десятков мипсов это очень мало. Стек будет просто захлебываться, пакеты дропаться, полезут таймауты итд.
Наверное обычный TCP/IP стек хоть программный хоть аппаратный без специальной настройки не потянет больше 30 Mбайт/c
Там куча констант сидит
Разгребать чтобы быстро работало можно только фильтрацией пакетов на втором уровне проверяя заголовок IP и TCP аппаратно
Сколько Мб/с требуется и в чем именно трудность аппаратной реализация TCP/IP в ПЛИС?
Цитата(Sefo @ Feb 27 2009, 22:21)
и в чем именно трудность аппаратной реализация TCP/IP в ПЛИС?
Именно этот вопрос меня и интересует
Может сложностей никаких нет, я пока еще не дошел до поля, где грабли лежат.Пропускная способность нужна по максимуму. В идеале ~80 МБайт/сек
Для одного соединения по TCP это совершенно дикая цифра.
Такой трафик может набраться только если работает одновременно 10-20 TCP соединений.
В TCP соединении существует понятие окна которое содержит столько данных
сколько проходит за время задержки прохождения данных от одного конца к другому.
Так любой обычный свитчер или роутер на пути какого TCP коннекта может создать такую задержку, что любое разумное окно будет переполнено.
А после переполнения окна в обычном TCP идет длительный процесс восстановления скорости и ретрансмиты.
Вообщем TCP на такой скорости слабо годится, нужна технология не коммутации пакетов, а каналов типа ATM
Такой трафик может набраться только если работает одновременно 10-20 TCP соединений.
В TCP соединении существует понятие окна которое содержит столько данных
сколько проходит за время задержки прохождения данных от одного конца к другому.
Так любой обычный свитчер или роутер на пути какого TCP коннекта может создать такую задержку, что любое разумное окно будет переполнено.
А после переполнения окна в обычном TCP идет длительный процесс восстановления скорости и ретрансмиты.
Вообщем TCP на такой скорости слабо годится, нужна технология не коммутации пакетов, а каналов типа ATM
Цитата(murmel1 @ Feb 27 2009, 21:39)
Именно этот вопрос меня и интересует Может сложностей никаких нет, я пока еще не дошел до поля, где грабли лежат.
Пропускная способность нужна по максимуму. В идеале ~80 МБайт/сек
Может сложностей никаких нет, я пока еще не дошел до поля, где грабли лежат.Пропускная способность нужна по максимуму. В идеале ~80 МБайт/сек
Ну как-бы 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 выжать.
[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.
Вы лучше на одном компе сделайте iperf и клиента и сервер, а у другого сделайте два IP адреса с роутингом.
Боюсь результат будет сильно грустнее.
Впрочем и этот не вызывает доверия, размер пакета то какой? 1514 небось или вообще Jumbo Frame.
Цитата(Harbour @ Feb 28 2009, 09:12)
Ну как-бы 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 выжать.
[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.
Вы лучше на одном компе сделайте 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 на ваших интерфейсах или чего другого заслуживающего большего доверия.
Они хоть один роутер проходят или свитчер и какой?
А iperf вообще-то не приложение.
Там чтоб ускорить обработку пакетов их вообще ни в какое окно могут не сохранять.
Т.е. полная бутафория, от TCP там только формат заголовков остается.
Естественно что ни до какого файрвола ничего не доходит.
Покажите реальную статистику SNMP агента по MIB2 на ваших интерфейсах или чего другого заслуживающего большего доверия.
Цитата(Harbour @ Feb 28 2009, 14:25)
А что другие 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. Еще вопросы будут ?
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. Еще вопросы будут
?
реальный маршрут :
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 например, но там придется добавить задержки на реализацию протокола + скорость чтения/записи файловой системы
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 совсем не тупая утилита
Я сам компилировал прогу типа iperf работающую на стандартных сокетах.
Ну не тянет интерфейс сокетов такие скорости даже если пакеты отбрасывать сразу.
А вы пока не назвали ни марки своего свитчера ни что за файрвол ни какие фильтры в нем были включены ни тип сетевых карт ни топологию физической связи.
Понимаю что вопросы затяжелые для такой легкой темы, но и долго толковать тут не о чем тогда.
Пока мне кажеться мы просто крутимся вокруг особенностей драйверов сетевых карт.
Сделайте простой опыт: включите порт на прием на компе и пошлите туда просто UDP поток без всякого iperf на приемной стороне.
Скорость упадет драматически.
Т.е. iperf совсем не тупая утилита
Цитата(Harbour @ Feb 28 2009, 15:49)
реальный маршрут :
eth0 первый комп -> китайский switch -> eth0 второй комп -> firewall -> route table -> wlan
мерялось от eth0 IP первого компа до wlan IP второго компа
Вы меня пугаете - iperf это тупой TCP/IP демон/клиент для измерения скорости. По поводу окна есть вполне вменяемая опция, из мана по iperf :
.......
-w, --window n[KM]
TCP window size (socket buffer size)
.......
В приведенном мною логе использовалось окно размером 16kb. Насчет "до фаервола не доходит", просьба как-то подкрепить фактами - как-то немного похоже на бред - без firewall'а (не забываем еще и про маскарад) TCP/IP пакет из внутренней сетки ну никак не выйдет наружу - хоть тресни. snmp на домашнем рутере я не использую - думаю понятно почему. И потом непонятна разница - snmp их тех же счетчиков внутри ядра данные берет - в чем сокровенный смысл ? Реальная статистика - это конкретная скорость измеренная в конечном приложении, а вот все остальное действительно бутафория. Собственно iperf и ему подобные программы и являются такими приложениями. Иногда можно мерять с помощью клиентов каких либо служб - FTP например, но там придется добавить задержки на реализацию протокола + скорость чтения/записи файловой системы
eth0 первый комп -> китайский switch -> eth0 второй комп -> firewall -> route table -> wlan
мерялось от eth0 IP первого компа до wlan IP второго компа
Вы меня пугаете - iperf это тупой TCP/IP демон/клиент для измерения скорости. По поводу окна есть вполне вменяемая опция, из мана по iperf :
.......
-w, --window n[KM]
TCP window size (socket buffer size)
.......
В приведенном мною логе использовалось окно размером 16kb. Насчет "до фаервола не доходит", просьба как-то подкрепить фактами - как-то немного похоже на бред - без firewall'а (не забываем еще и про маскарад) TCP/IP пакет из внутренней сетки ну никак не выйдет наружу - хоть тресни. snmp на домашнем рутере я не использую - думаю понятно почему. И потом непонятна разница - snmp их тех же счетчиков внутри ядра данные берет - в чем сокровенный смысл ? Реальная статистика - это конкретная скорость измеренная в конечном приложении, а вот все остальное действительно бутафория. Собственно iperf и ему подобные программы и являются такими приложениями. Иногда можно мерять с помощью клиентов каких либо служб - FTP например, но там придется добавить задержки на реализацию протокола + скорость чтения/записи файловой системы
Ваше дело верить или нет - убеждать мне кого-либо уже давно влом. Тот кому нужно - сам померяет и убедится, а кому не нужно - просто забьет на все это. Просто речь о том, что банальная тачка с Linux давным давно перешагнула порог в 100 Mb/s и ничего заоблачного здесь нет и быть не может. Не думаю что марка свитча может иметь хоть какое-либо влияние на скорость TCP/IP стека операционной системы, ну так ради Бога, извольте - switch D-Link DGS1005D. Файрвол - iptables, с десяток правил, включая маскарадные :
..........
Сетевухи на первой и второй тачке - обычные встроенные в мамки, первая:
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 будет еще быстрее, если не верите - сами соберите стендик из двух тачек. А драйвера, батенька, если честно, тут до спины.
..........
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
.....................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 будет еще быстрее, если не верите - сами соберите стендик из двух тачек. А драйвера, батенька, если честно, тут до спины.
Я конечно дико извиняюсь, но вы что, прокачали 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)
Дык после всех дел, что значит топология ? Как кабеля по полу разложены что-ли ? Это уже слишком ...
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. Вы невнимательно прочитали мое предыдущее сообщение, в котором был описан путь пакета через интерфейсы.
Цитата(AlexandrY @ Feb 28 2009, 11:30)
iperf сервис роутинга линукса даже не пытается использовать.
Вы лучше на одном компе сделайте iperf и клиента и сервер, а у другого сделайте два IP адреса с роутингом.
Боюсь результат будет сильно грустнее.
Впрочем и этот не вызывает доверия, размер пакета то какой? 1514 небось или вообще Jumbo Frame.
Вы лучше на одном компе сделайте 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, вот-тут могут быть грабельки
Цитата(Harbour @ Mar 2 2009, 10:42)
Все очень зависит от задачи. При подаче, данной в исходном в посте я бы поднял nios+lwip и порешал бы вопрос, но если у задачи есть ньюансы, требующие таки-да OS, вот-тут могут быть грабельки
Хочется понять что у авторов оригинального вопроса приоритетно - их приложение или принцип
Если приложение - то мне сложно понять как они с ним будут работать без процессора
если только они не делают какой нибудь тупой loopback или файрволл-роутинг
Если процессор есть - например NIOS - то дещевле TCP засунуть туда вместе с каким нибудь Linux
Если вопрос из принципа как закомпилить TCP IP стек в хардварь то мне интересны хоть какие нибудь детали
того как это будут использовать - принципиально закомпилировать C в hardware наверное несложно - вот кто и как
пакеты со стека снимать будет
имелось ввиду следуещее : если задача стоит обрабатывать и перекачивать один поток на хост - ОС не нужна, если нужно на устройстве перключать задачи - то нужна. Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ...
Так к чему вы тогда пудрили всем этим iperf-ом? Linux же такой реактивный у вас.
Иль засомневались?
Иль засомневались?
Цитата(Harbour @ Mar 4 2009, 11:28)
имелось ввиду следуещее : если задача стоит обрабатывать и перекачивать один поток на хост - ОС не нужна, если нужно на устройстве перключать задачи - то нужна. Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ...
Зачем tcp вообще здесь.
Плис с синтезированным Gigabit MAC (2-3 тыс LUT4) сделает вам поток UDP по 1 Гбит в обе стороны.
Совместимость с другими узлами сети (как изначально требовалось) обеспечивается реализацией сетевых протоколов.
Плис с синтезированным Gigabit MAC (2-3 тыс LUT4) сделает вам поток UDP по 1 Гбит в обе стороны.
Совместимость с другими узлами сети (как изначально требовалось) обеспечивается реализацией сетевых протоколов.
Цитата(jojo @ Mar 4 2009, 13:37)
Зачем tcp вообще здесь.
Плис с синтезированным Gigabit MAC (2-3 тыс LUT4) сделает вам поток UDP по 1 Гбит в обе стороны.
Совместимость с другими узлами сети (как изначально требовалось) обеспечивается реализацией сетевых протоколов.
Плис с синтезированным Gigabit MAC (2-3 тыс LUT4) сделает вам поток UDP по 1 Гбит в обе стороны.
Совместимость с другими узлами сети (как изначально требовалось) обеспечивается реализацией сетевых протоколов.
Гигабит по помему полудуплекс. И не понятно какая именно скорость нужна. Пакеты-то будут теряться.
Да, эт я загнул.
Цитата(Harbour @ Mar 4 2009, 13:28)
Linux + Nios - это непомерные накладные расходы - Nios и так тормоз ...
А можно отсюда поподробнее - видимо есть опыт из личной жизни - пытались на Nios и такой то версией Linux сделать то-то - и получили вот такой результат
Оч интересно
NIOS для этого мучать совсем не обязательно.
Прописная истина, что синтезированные процы сильно медленнее хардварных.
Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.
Тут только десяток или сотня NIOS-ов справится.
Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение.
Прописная истина, что синтезированные процы сильно медленнее хардварных.
Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.
Тут только десяток или сотня NIOS-ов справится.
Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение.
Цитата(islavv @ Mar 4 2009, 16:44)
А можно отсюда поподробнее - видимо есть опыт из личной жизни - пытались на Nios и такой то версией Linux сделать то-то - и получили вот такой результат
Оч интересно
Оч интересно
Цитата(AlexandrY @ Mar 4 2009, 17:29)
NIOS для этого мучать совсем не обязательно.
Прописная истина, что синтезированные процы сильно медленнее хардварных.
Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.
Тут только десяток или сотня NIOS-ов справится.
Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение.
Прописная истина, что синтезированные процы сильно медленнее хардварных.
Если ни у кого не получилось на ARM-ах до 400 МГц! занять всю полосу даже 100Base-T вменяемым TCP трафиком, то NIOS может отдыхать.
Тут только десяток или сотня NIOS-ов справится.
Кстати, не ирония. Думаю реально запряч на задачу с десяток NIOS-ов, а TCP потоки поделить. Это будет самое реальное решение.
Самое правильное, это будет сборку пакетов, подсчет CRC в плисину вынести. А НИОС пусть получает готовый, и собранный TCP или UDP пакет, с подсчитанной контрольной суммой итд.
Не потянет все равно.
В ARM-ах также используется аппаратных CRC на MAC уровне. Суммирование на IP уровне - даст мизер.
При этом еще есть хитрый RISC управляющий отправкой составных IP пакетов на основе дескрипторов и DMA. По сути та самая сборка.
Ниче не помогает.
Масштабирование - единственный выход.
В ARM-ах также используется аппаратных CRC на MAC уровне. Суммирование на IP уровне - даст мизер.
При этом еще есть хитрый RISC управляющий отправкой составных IP пакетов на основе дескрипторов и DMA. По сути та самая сборка.
Ниче не помогает.
Масштабирование - единственный выход.
Цитата(Methane @ Mar 4 2009, 18:22)
Самое правильное, это будет сборку пакетов, подсчет CRC в плисину вынести. А НИОС пусть получает готовый, и собранный TCP или UDP пакет, с подсчитанной контрольной суммой итд.
Цитата(AlexandrY @ Mar 4 2009, 18:34)
Не потянет все равно.
В ARM-ах также используется аппаратных CRC на MAC уровне. Суммирование на IP уровне - даст мизер.
При этом еще есть хитрый RISC управляющий отправкой составных IP пакетов на основе дескрипторов и DMA. По сути та самая сборка.
Ниче не помогает.
Масштабирование - единственный выход.
В ARM-ах также используется аппаратных CRC на MAC уровне. Суммирование на IP уровне - даст мизер.
При этом еще есть хитрый RISC управляющий отправкой составных IP пакетов на основе дескрипторов и DMA. По сути та самая сборка.
Ниче не помогает.
Масштабирование - единственный выход.
Недавно гонял UDP на AVR32, дофига даст. Нужно собрать IP пакеты, подсчитать им CRC, собрать UDP пакеты, им посчитать CRC, одновременно нужно выкидывать старые IP пакеты, проводить дефрагментацию IP пакетов итд.
Тот CRC в маке - фигня. Еще много чего есть.
Меньше 30% даст на коротких пакетах если умудритесь делать аппаратное суммирование всех заголовков,
операции пересылки памяти все равно преобладают.
Да , и называть простое суммирование как CRC немного неточно.
операции пересылки памяти все равно преобладают.
Да , и называть простое суммирование как CRC немного неточно.
Цитата(Methane @ Mar 4 2009, 18:39)
Недавно гонял UDP на AVR32, дофига даст. Нужно собрать IP пакеты, подсчитать им CRC, собрать UDP пакеты, им посчитать CRC, одновременно нужно выкидывать старые IP пакеты, проводить дефрагментацию IP пакетов итд.
Тот CRC в маке - фигня. Еще много чего есть.
Тот CRC в маке - фигня. Еще много чего есть.
Цитата(AlexandrY @ Mar 4 2009, 18:50)
Меньше 30% даст на коротких пакетах если умудритесь делать аппаратное суммирование всех заголовков,
операции пересылки памяти все равно преобладают.
Да , и называть простое суммирование как CRC немного неточно.
операции пересылки памяти все равно преобладают.
Да , и называть простое суммирование как CRC немного неточно.
Вот операции с памятью тоже. Можно в общем сделать практически все в FPGA - получаем пакеты и сваливаем в большой циклический буфер это один автомат. Еще один автомат выгребает из буфера и дешает готовые IP пакеты, с дефрагментацией, подсчетом, суммы, выбраковкой старых и итд. Третий автомат - из IP собирает уже готовые UDP, тоже считает что нужно и отдает ниосу. В этом случае НИОС может и успеть, если UDP пакеты будут и они будут достаточно большие. К примеру по 60 килобайт.
Цитата(Methane @ Mar 4 2009, 20:09)
Вот операции с памятью тоже. Можно в общем сделать практически все в FPGA - получаем пакеты и сваливаем в большой циклический буфер это один автомат. Еще один автомат выгребает из буфера и дешает готовые IP пакеты, с дефрагментацией, подсчетом, суммы, выбраковкой старых и итд. Третий автомат - из IP собирает уже готовые UDP, тоже считает что нужно и отдает ниосу. В этом случае НИОС может и успеть, если UDP пакеты будут и они будут достаточно большие. К примеру по 60 килобайт.
а кто нибудь пробовал NicheStack TCP/IP stack NIOS II edition?
http://www.altera.com/literature/hb/nios2/n2sw_nii52013.pdf
Цитата(AlexandrY @ Mar 4 2009, 11:59)
Так к чему вы тогда пудрили всем этим iperf-ом? Linux же такой реактивный у вас.
Иль засомневались?
Иль засомневались?
Во-первых, чтобы иметь моральное право меня подкалывать, нужно хотя бы быть адекватным в своих постах, например как минимум ответить на мои вопросы к Вам в данном треде. Пока я вижу лишь голословные утверждения не подкрепленные какими-либо фактами, логикой или кодом.
Во-вторых я и не предлагал связку Linux + Nios - а просто отметил что даже такое кривое и непредсказуемое железо как x86, с набортным Linux легко выдает на гора нужную скорость. Сильная сторона Nios - его возможность работать с on-chip RAM, программируемая периферия и неплохая скорость DMA. Т.е. грамотно портированный стек типа lwip займет несколько кил ОЗУ и легко даст нужную скорость. Ставить же Linux на Nios, задача бестолковая и малоперспективная, как по мне необходимость в ней обычно вызвана серьезными архитектурными просчетами.
И в-третьих - Linux у меня таки-да реактивный, или Вас опять грызут сомнения ? Так не стесняйтесь, повторите подвиг Матросова.
Цитата(islavv @ Mar 4 2009, 20:04)
а кто нибудь пробовал NicheStack TCP/IP stack NIOS II edition?
http://www.altera.com/literature/hb/nios2/n2sw_nii52013.pdf
http://www.altera.com/literature/hb/nios2/n2sw_nii52013.pdf
Он как-бы идет в комплекте с nios2, начиная с версии квартуса 7.1 :
/opt/altera/nios2eds/components/altera_iniche
подразумевает использование uCOSII, но добрые люди эту гадость из него благополучно выкусили:
http://www.nioswiki.com/User:Admin/"S...uot;_NicheStack
Сам этот стек я не пробовал.
Если бы не поленились и не ставили целью провоцировать бесполезный не относящийся к теме шум,
то посмотрели бы мои проекты где я неоднократно давал порты стека TCP для uCOS под разные платформы
и просто тесты прямой генерации Ethernet трафика без всяких стеков.
Изобразите сами сначала хоть что нибудь на NIOS-е и перестаните даже мечтать о гигабитах.
то посмотрели бы мои проекты где я неоднократно давал порты стека TCP для uCOS под разные платформы
и просто тесты прямой генерации Ethernet трафика без всяких стеков.
Изобразите сами сначала хоть что нибудь на NIOS-е и перестаните даже мечтать о гигабитах.
Цитата(Harbour @ Mar 5 2009, 06:00)
Во-первых, чтобы иметь моральное право меня подкалывать, нужно хотя бы быть адекватным в своих постах, например как минимум ответить на мои вопросы к Вам в данном треде. Пока я вижу лишь голословные утверждения не подкрепленные какими-либо фактами, логикой или кодом.
Во-вторых я и не предлагал связку Linux + Nios - а просто отметил что даже такое кривое и непредсказуемое железо как x86, с набортным Linux легко выдает на гора нужную скорость. Сильная сторона Nios - его возможность работать с on-chip RAM, программируемая периферия и неплохая скорость DMA. Т.е. грамотно портированный стек типа lwip займет несколько кил ОЗУ и легко даст нужную скорость. Ставить же Linux на Nios, задача бестолковая и малоперспективная, как по мне необходимость в ней обычно вызвана серьезными архитектурными просчетами.
И в-третьих - Linux у меня таки-да реактивный, или Вас опять грызут сомнения ? Так не стесняйтесь, повторите подвиг Матросова.
Он как-бы идет в комплекте с nios2, начиная с версии квартуса 7.1 :
/opt/altera/nios2eds/components/altera_iniche
подразумевает использование uCOSII, но добрые люди эту гадость из него благополучно выкусили:
http://www.nioswiki.com/User:Admin/"S...uot;_NicheStack
Сам этот стек я не пробовал.
Во-вторых я и не предлагал связку Linux + Nios - а просто отметил что даже такое кривое и непредсказуемое железо как x86, с набортным Linux легко выдает на гора нужную скорость. Сильная сторона Nios - его возможность работать с on-chip RAM, программируемая периферия и неплохая скорость DMA. Т.е. грамотно портированный стек типа lwip займет несколько кил ОЗУ и легко даст нужную скорость. Ставить же Linux на Nios, задача бестолковая и малоперспективная, как по мне необходимость в ней обычно вызвана серьезными архитектурными просчетами.
И в-третьих - Linux у меня таки-да реактивный, или Вас опять грызут сомнения ? Так не стесняйтесь, повторите подвиг Матросова.
Он как-бы идет в комплекте с nios2, начиная с версии квартуса 7.1 :
/opt/altera/nios2eds/components/altera_iniche
подразумевает использование uCOSII, но добрые люди эту гадость из него благополучно выкусили:
http://www.nioswiki.com/User:Admin/"S...uot;_NicheStack
Сам этот стек я не пробовал.
Цитата
:Если бы не поленились и не ставили целью провоцировать бесполезный не
:относящийся к теме шум,
:относящийся к теме шум,
Дык, к теме треда вопрос и результаты измерения производительности стека
TCP/IP очень даже относятся - отталкиваться нужно от печки. Особенно когда
слышим одно а видим и меряем совершенно другое. А вот удары пятками себя в грудь,
они, действительно, к теме ни фига не относятся.
Цитата
:то посмотрели бы мои проекты где я неоднократно давал порты стека TCP для
:uCOS под разные платформы
:и просто тесты прямой генерации Ethernet трафика без всяких стеков.
:uCOS под разные платформы
:и просто тесты прямой генерации Ethernet трафика без всяких стеков.
Тем более мне интересно услышать разьяснение заявлений такого
знающего <grin> человека по следующим утверждениям в данном треде :
1. Почему же "iperf вообще-то не приложение" ?
2. Как приложение может не "сохранить в окно" ?
3. И как пакет проходя от интерфейса до интерфейса "ни до какого файрвола"
не доходит ?
Вобще-то наблюдается острая нехватка базовых знаний, купили бы что-ли книжечку
"TCP/IP для чайников" и не мучили бы больше форум своими перлами
Цитата
:Изобразите сами сначала хоть что нибудь на NIOS-е и перестаните даже мечтать
:о гигабитах.
:о гигабитах.
На Nios'е я изображал еще в 2004 году на квартусе 3.0SP2, небось тогда о нем
и не слышали ? Просто с быстрой сетью задач не попадалось.
Цитата(islavv @ Mar 4 2009, 21:04)
а кто нибудь пробовал NicheStack TCP/IP stack NIOS II edition?
http://www.altera.com/literature/hb/nios2/n2sw_nii52013.pdf
http://www.altera.com/literature/hb/nios2/n2sw_nii52013.pdf
Сначала хотел, потом отказался: проблема с уже упоминавшейся здесь uCOSII.
Сделал на NiosII свои драйвера для LAN91C111, потом написал под ARP, ICMP и UDP, более раскрывать стек пока не нужно.
Но LAN91C111 работает на Ethernet-100, а требуется уже и Ethernet-1000.
Для последнего у меня есть 88E1111, но проблемы с нормальным описанием: достать его не возможно, из-за политики Marwell.
Может, у кого есть подробное описание 88E1111, то поделитесь или укажите, где все это добро есть. На фирму не ссылаться, там одни футболисты.
Если кому-то интересно, то вычисление контрольных сумм для UDP делал аппаратно, по ходу работы внешней FSM, т.е. ресурс NiosII на это не тратил. А воообще, ускоряться там можно много, хватало бы идей.
Цитата(Serhiy_UA @ Mar 5 2009, 17:29)
Сначала хотел, потом отказался: проблема с уже упоминавшейся здесь uCOSII.
Сделал на NiosII свои драйвера для LAN91C111, потом написал под ARP, ICMP и UDP, более раскрывать стек пока не нужно.
Но LAN91C111 работает на Ethernet-100, а требуется уже и Ethernet-1000.
Для последнего у меня есть 88E1111, но проблемы с нормальным описанием: достать его не возможно, из-за политики Marwell.
Может, у кого есть подробное описание 88E1111, то поделитесь или укажите, где все это добро есть. На фирму не ссылаться, там одни футболисты.
Сделал на NiosII свои драйвера для LAN91C111, потом написал под ARP, ICMP и UDP, более раскрывать стек пока не нужно.
Но LAN91C111 работает на Ethernet-100, а требуется уже и Ethernet-1000.
Для последнего у меня есть 88E1111, но проблемы с нормальным описанием: достать его не возможно, из-за политики Marwell.
Может, у кого есть подробное описание 88E1111, то поделитесь или укажите, где все это добро есть. На фирму не ссылаться, там одни футболисты.
Так uCOSII при этом у вас задействована или свое однозадачное приложение написано?
Цитата(islavv @ Mar 5 2009, 17:12)
Так uCOSII при этом у вас задействована или свое однозадачное приложение написано?
Ось не применял.
Задач несколько. Обошелся программным конечным автоматом-распределителем.
Главная задача с UDP, другие попроще.
Цитата(Serhiy_UA @ Mar 5 2009, 18:21)
Ось не применял.
Задач несколько. Обошелся программным конечным автоматом-распределителем.
Главная задача с UDP, другие попроще.
Задач несколько. Обошелся программным конечным автоматом-распределителем.
Главная задача с UDP, другие попроще.
Оч Интересное решение - хотя я бы попытался обойтись одной задачей
вот вопрос как и какие при этом обрабатываются прерывания
и самое главное - вам удалось успешно использовать Niche TCP/IP?
Он аппаратно реализован?
Цитата(Serhiy_UA @ Mar 5 2009, 18:21)
Ось не применял.
Задач несколько. Обошелся программным конечным автоматом-распределителем.
Главная задача с UDP, другие попроще.
Задач несколько. Обошелся программным конечным автоматом-распределителем.
Главная задача с UDP, другие попроще.
Или просто вместо написания стека вы вписываете TCP хедеры и обходитесь без стека?
Цитата(islavv @ Mar 5 2009, 18:54)
вам удалось успешно использовать Niche TCP/IP?
Niche TCP/IP не применял, он для меня оказался сложен и избыточен, по этому предпочел писать все свое.
Мое устройство оцифровывает сигналы от радара с частотой 25 МГц, выполняет первичную обработку и делает следующее:
- Непрерывно выдает на компьютеры для вторичной обработки UDP пакеты. Это все на NiosII, только контрольная сумма аппаратно.
- Принимает и отрабатывает ARP, ICMP и UDP пакеты c командами управления, которые поступают достаточно редко, то же NiosII.
- Контролирует клавиатуру и управляет знаковым LCD-дисплеем, собираюсь выводить еще на графику.
- Обрабатывает команды и обменивается по UART на RS232
Все это выполняется с главным циклом в 500мкс, это для выдачи UDP пакетов.
Остальные задачи мене приоритетные и растягиваются по циклам с помощь программного конечного автомата на NiosII. Здесь все события, в том числе LAN91C111, контролируются опросом, прерываний нет. Это один из путей, согласен, что возможны и другие, на основе прерываний, но они сложнее.
В аппаратуре много арифметики и несколько FSM, однако и NiosII (fast) нагружен, он работает с тактом в 100МГц.
Все это на StratixII.
У меня стоит задача Ethernet на 1Гбит, но на 88E1111. Нормальной документации нет, а та, что есть, не помогает. Может кто поделится?
Цитата(Serhiy_UA @ Mar 5 2009, 23:06)
Niche TCP/IP не применял, он для меня оказался сложен и избыточен, по этому предпочел писать все свое.
Мое устройство оцифровывает сигналы от радара с частотой 25 МГц, выполняет первичную обработку и делает следующее:
- Непрерывно выдает на компьютеры для вторичной обработки UDP пакеты. Это все на NiosII, только контрольная сумма аппаратно.
- Принимает и отрабатывает ARP, ICMP и UDP пакеты c командами управления, которые поступают достаточно редко, то же NiosII.
- Контролирует клавиатуру и управляет знаковым LCD-дисплеем, собираюсь выводить еще на графику.
- Обрабатывает команды и обменивается по UART на RS232
Все это выполняется с главным циклом в 500мкс, это для выдачи UDP пакетов.
Остальные задачи мене приоритетные и растягиваются по циклам с помощь программного конечного автомата на NiosII. Здесь все события, в том числе LAN91C111, контролируются опросом, прерываний нет. Это один из путей, согласен, что возможны и другие, на основе прерываний, но они сложнее.
В аппаратуре много арифметики и несколько FSM, однако и NiosII (fast) нагружен, он работает с тактом в 100МГц.
Все это на StratixII.
У меня стоит задача Ethernet на 1Гбит, но на 88E1111. Нормальной документации нет, а та, что есть, не помогает. Может кто поделится?
Мое устройство оцифровывает сигналы от радара с частотой 25 МГц, выполняет первичную обработку и делает следующее:
- Непрерывно выдает на компьютеры для вторичной обработки UDP пакеты. Это все на NiosII, только контрольная сумма аппаратно.
- Принимает и отрабатывает ARP, ICMP и UDP пакеты c командами управления, которые поступают достаточно редко, то же NiosII.
- Контролирует клавиатуру и управляет знаковым LCD-дисплеем, собираюсь выводить еще на графику.
- Обрабатывает команды и обменивается по UART на RS232
Все это выполняется с главным циклом в 500мкс, это для выдачи UDP пакетов.
Остальные задачи мене приоритетные и растягиваются по циклам с помощь программного конечного автомата на NiosII. Здесь все события, в том числе LAN91C111, контролируются опросом, прерываний нет. Это один из путей, согласен, что возможны и другие, на основе прерываний, но они сложнее.
В аппаратуре много арифметики и несколько FSM, однако и NiosII (fast) нагружен, он работает с тактом в 100МГц.
Все это на StratixII.
У меня стоит задача Ethernet на 1Гбит, но на 88E1111. Нормальной документации нет, а та, что есть, не помогает. Может кто поделится?
Если вам не в 10 раз больше нужен поток данных поставьте второй Fast Ethernet и воткните в свич - 4FE - GigE на выходе свича поимеете гигабитный трафик
с полосой 200Мбит
Не хватит - поставьте 3 Ethernet
в свиче теряться ничего не будет
Вообще, конечно, впечатляет
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.
Цитата(Serhiy_UA @ Mar 5 2009, 21:06)
В аппаратуре много арифметики и несколько FSM, однако и NiosII (fast) нагружен, он работает с тактом в 100МГц.
Все это на StratixII.
Все это на StratixII.
Цитата(AlexandrY @ Mar 6 2009, 01:12)
Вообще, конечно, впечатляет
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.
Stratix II PCI $2600 без таксов и доставки
не забывайте что при этом никаких линуксов и почти никакого софта
зато при этом кастомное сопряжение с неизвестными аппаратными устройствами
наверное весьма эффективно
я почти уверен что в эту задачу TCP здесь притянут за уши - вставки UDP заголовков и обычного IP уровня вполне хватило бы
Цитата(AlexandrY @ Mar 6 2009, 01:12)
Вообще, конечно, впечатляет
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.
Взять Stratix II где-то за 1000$ и выжать из него процессор с тактовой всего 100 МГц!
Это когда ARM-ы на 600 МГц с втроенным 1 Gbit MAC стоят 15$ и портированных TCP стеков на них скоро десятками пойдет счет.
После такого яркого примера у любого должно отбить охоту делать TCP стек на софт процессорах.
Да, все так и стоит - 1000 USD. Это дивелопер кит DK-NIOS-2S60N, включающий:
Flash - 16MB, SRAM - 2MB, SDRAM - 32 MB, LAN91C111 - Ethernet10/100, PCI на PMC connector и другое, в том числе TSE 88E1111.
Основа этого Stratix II FPGA EP2S60F672C3N, кстати, ее нынешняя загрузка со всем что описал - 15%. Там много аппаратной математики, уверен, что программируемый вычислитель не справится бы с математикой.
При этом, требования по обработке растут, математики нужно еще добавить столько же и еще столько. Ну и открыть 88E1111. Возможно придется добавить еще несколько NiosII... В моих условиях подобное решение близко к оптимальному, для Вас оптимум может выглядеть иначе... Такова селява.
Но все равно меня заинтересовала цена Вашего вычислителя ARM, дайте ссылку, плз.
К islavv. По поводу свича, мысль интересная.
Это не смешно, от таких решений пахнет нафталином.
TCP был придуман для надежного канала в сложно структурированных сетях.
Большая часть его фичей предназначена для борьбы с прерывающимся трафиком и кучей bottleneck-ов на пути.
Если не предполагать, что человек задавший вопрос совершенно не понимает что он разрабатывает, то TCP на UDP никак не заменить.
В вашем же случае где надо просто соединить комп с дивайсом гораздо проще применить HS USB.
Вот уж где все хардварно решается без всяких усилий и трафик с гарантированной доставкой в 50-40 Мбайт можно изобразить даже имея только один 100 МГц проц.
TCP был придуман для надежного канала в сложно структурированных сетях.
Большая часть его фичей предназначена для борьбы с прерывающимся трафиком и кучей bottleneck-ов на пути.
Если не предполагать, что человек задавший вопрос совершенно не понимает что он разрабатывает, то TCP на UDP никак не заменить.
В вашем же случае где надо просто соединить комп с дивайсом гораздо проще применить HS USB.
Вот уж где все хардварно решается без всяких усилий и трафик с гарантированной доставкой в 50-40 Мбайт можно изобразить даже имея только один 100 МГц проц.
Цитата(islavv @ Mar 6 2009, 01:31)
Stratix II PCI $2600 без таксов и доставки
не забывайте что при этом никаких линуксов и почти никакого софта
зато при этом кастомное сопряжение с неизвестными аппаратными устройствами
наверное весьма эффективно
я почти уверен что в эту задачу TCP здесь притянут за уши - вставки UDP заголовков и обычного IP уровня вполне хватило бы
не забывайте что при этом никаких линуксов и почти никакого софта
зато при этом кастомное сопряжение с неизвестными аппаратными устройствами
наверное весьма эффективно
я почти уверен что в эту задачу TCP здесь притянут за уши - вставки UDP заголовков и обычного IP уровня вполне хватило бы
Цитата(Serhiy_UA @ Mar 6 2009, 08:26)
Но все равно меня заинтересовала цена Вашего вычислителя ARM, дайте ссылку, плз.
Я тоже с удовольствием посмотрел бы на 600MHz ARM с GMAC на борту за 15$. Знаю про новую серию от Марвелл - плиз, не предлагать, даже с подписанными NDA наелся с ними уже. Из не-ARM есть фрискейловкие PowerPC MPC831x за те же 15$ (btw, на 8347 при первой же попытке TCP дал 30Мбайт/сек - с отладкой, с тормозным echo-сервером Windows XP, суммы считаются программно, 831x уже умеют суммы считать аппаратно) . На этом с набортным GMAC - все. Остальные одночиповые решения начинаются от $100-150. Пару лет назад эта тема поднималась - ничего за вменяемые деньги кроме MPC так пока и не нашлось.
Цитата(Serhiy_UA @ Mar 5 2009, 23:06)
У меня стоит задача Ethernet на 1Гбит, но на 88E1111. Нормальной документации нет, а та, что есть, не помогает. Может кто поделится?
/тот чип стоит например на DLINK NAS-323 и для него есть GPL и там должны быть драйверы в сорсах
Цитата(VslavX @ Mar 6 2009, 11:41)
Я тоже с удовольствием посмотрел бы на 600MHz ARM с GMAC на борту за 15$. Знаю про новую серию от Марвелл - плиз, не предлагать, даже с подписанными NDA наелся с ними уже. Из не-ARM есть фрискейловкие PowerPC MPC831x за те же 15$ (btw, на 8347 при первой же попытке TCP дал 30Мбайт/сек - с отладкой, с тормозным echo-сервером Windows XP, суммы считаются программно, 831x уже умеют суммы считать аппаратно) . На этом с набортным GMAC - все. Остальные одночиповые решения начинаются от $100-150. Пару лет назад эта тема поднималась - ничего за вменяемые деньги кроме MPC так пока и не нашлось.
случайно обнаружил что эта Marvel серия стоит на NAS D-Link-323 и там есть Gigabit Ethernet стоит меньше $150
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.