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

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

Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.

Есть development board для экспериментов (PCIe с Stratix II GX).

Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?

Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI

 

Спасибо всем

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


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

Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.

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

 

Есть development board для экспериментов (PCIe с Stratix II GX).

Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?

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

 

Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI

 

Спасибо всем

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

 

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

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


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

Физ уровень оптика (как его там - 1000BASE-X ?) Возможен внешний преобразователь в 1000BASE-T (витая пара)

Уровнем Ethernet обойтись нельзя. К этой же сети подключены другие абоненты.

Данные будут как из сети в девайс, так и наоборот.

Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.

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


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

Физ уровень оптика (как его там - 1000BASE-X ?) Возможен внешний преобразователь в 1000BASE-T (витая пара)

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

 

Уровнем Ethernet обойтись нельзя. К этой же сети подключены другие абоненты.

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

 

Данные будут как из сети в девайс, так и наоборот.

Если прогноз 2 МБ для Ethernet, то сколько же, если еще и TCP/IP ? Зарывайте стюардессу.

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

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


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

Есть вариант поднять на ниосе приложение simple web server. Но есть и подозрения о том, что ниос не потянет такое приложение. У кого какие мысли, сколько Мбайт/сек можно прокачать через ниос?

Какие еще варианты сделать такую систему? Может есть готовое ядро (возможность покупки есть) ? Применить внешний проц ? Но сильно сложные прожекты отметаются, так как чем делать черезчур сложную новую плату, можно купить небольшую промышленную ЭВМ с 1G Ethernet на борту и подключиться к ней по PCI

 

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

2. гигабитный свитч на 2 порта гигабита и порт 100 мегабит в фпга.

 

1 ое проще и быстрее,

2 ое рациональнее

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


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

Возникла необходимость сделать на альтере сетевой девайс (1Гбит/с). Основное назначение - прием и передача по сети команд управления и потоков данных (данные поставляет железо, обработка не требуется). Необходим именно TCP/IP, так как устройство будет делить сетевую магистраль с другими. Прошу поделиться у кого есть - опытом, у кого нет - мыслями о том, как это делать.

 

Спасибо всем

2 копейки. "так как устройство будет делить сетевую магистраль с другими"

Это чтож - мы в коллизионный домен что-ли? На гигабитной скорости коллизионный домен не будет работать - там точка точка соединение и свичинг на L2 работает

Если действительно нужно делить физический канал - то технология называется PON - passive optical network - но это тож первый и второй уровень

и никакого IP

"Необходим именно TCP/IP"

а TCP то зачем - приложения с TCP используются "на скорости провода" только для фильтрации пакетов по портам

До конца пакет никто не читает

В общем первые две фразы плохо сформулированы и недодуманы

А устройство которое умеет такие вещи делать леи десять как называется L3 Switch или switch-роутер

 

 

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

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

Там куча констант сидит

Разгребать чтобы быстро работало можно только фильтрацией пакетов на втором уровне проверяя заголовок IP и TCP аппаратно

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


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

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

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


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

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

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

 

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

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


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

Для одного соединения по TCP это совершенно дикая цифра.

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

 

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

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

 

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

А после переполнения окна в обычном TCP идет длительный процесс восстановления скорости и ретрансмиты.

Вообщем TCP на такой скорости слабо годится, нужна технология не коммутации пакетов, а каналов типа ATM

 

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

 

Пропускная способность нужна по максимуму. В идеале ~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 выжать.

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


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

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

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

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

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

 

 

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

 

[Gate]root:~ # iperf -c Dao

------------------------------------------------------------

Client connecting to dao, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.1.0.1 port 48592 connected with 10.1.0.100 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 976 MBytes 819 Mbits/sec

 

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

 

[Dao]:rus:~ # iperf -c localhost

------------------------------------------------------------

Client connecting to localhost, TCP port 5001

TCP window size: 49.5 KByte (default)

------------------------------------------------------------

[ 3] local 127.0.0.1 port 52231 connected with 127.0.0.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 11.4 GBytes 9.82 Gbits/sec

 

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

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


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

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

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

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

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

 

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

 

Dao]:root:~ # iperf -c 85.238.113.239

------------------------------------------------------------

Client connecting to 85.238.113.239, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 10.1.0.100 port 47539 connected with 85.238.113.239 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 993 MBytes 833 Mbits/sec

[Dao]:root:~ #

 

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

 

[inglier]:root:~ # route -n |wc

45 356 3335

[inglier]:root:~ # iptables -L -vn|wc

39 393 3718

 

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

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


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

Расскажите о реальном маршруте пакетов.

Они хоть один роутер проходят или свитчер и какой?

А iperf вообще-то не приложение.

Там чтоб ускорить обработку пакетов их вообще ни в какое окно могут не сохранять.

Т.е. полная бутафория, от TCP там только формат заголовков остается.

Естественно что ни до какого файрвола ничего не доходит.

Покажите реальную статистику SNMP агента по MIB2 на ваших интерфейсах или чего другого заслуживающего большего доверия.

 

 

А что другие 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. Еще вопросы будут ;) ?

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


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

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

 

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 совсем не тупая утилита ;)

 

 

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

 

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 например, но там придется добавить задержки на реализацию протокола + скорость чтения/записи файловой системы

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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