|
|
  |
Ethernet контроллер, современный и быстрый |
|
|
|
Sep 10 2013, 16:02
|
Участник

Группа: Участник
Сообщений: 24
Регистрация: 21-03-11
Пользователь №: 63 743

|
Посоветуйте современный быстрый Ethernet контроллер. До этого использовался LAN91c111 в связке с ПЛИС (cyclone3) с процессором NiOSII. Максимальная скорость обмена ПЛИС--компьютер, которой удалось достичь 15-20 Мбит/с (со стандартными драйверами под ниос). Хотелось бы приблизиться к скоростям 80-100 Мбит/с. Какую микросхему выбрать, желательно, чтобы потом не возникло проблем с поиском или написанием драйверов, ну и цена чтобы не заоблачная была...
|
|
|
|
|
Sep 10 2013, 17:13
|
Участник

Группа: Участник
Сообщений: 24
Регистрация: 21-03-11
Пользователь №: 63 743

|
Цитата(ZASADA @ Sep 10 2013, 20:35)  постановка вопроса не корректная. любая внешняя физика + МАС в ПЛИС позволяют забить хоть гигабит. А реальная скорость будет ограничена только способностями вашего процессора разгребать кадры. Да, конечно, Вы правы. Но все-таки от размеров буфера микросхемы тоже кое-что зависит. Я привел пример каких скоростей можно добиться используя ниосовский иниш стек и микруху Lan91. Хотелось бы узнать какие сейчас микрухи используются.? И возможно ли добиться бОльших скоростей, используя существующий стек и сменив микруху.?
|
|
|
|
|
Sep 10 2013, 18:56
|
Профессионал
    
Группа: Свой
Сообщений: 1 700
Регистрация: 2-07-12
Из: дефолт-сити
Пользователь №: 72 596

|
Цитата(TamRazZ @ Sep 10 2013, 21:13)  Но все-таки от размеров буфера микросхемы тоже кое-что зависит. увеличение размеров буферов отрицательно сказывается на TCP/IP. Можете погуглить ключевое слово bufferbloat. Цитата(TamRazZ @ Sep 10 2013, 21:13)  Я привел пример каких скоростей можно добиться используя ниосовский иниш стек и микруху Lan91. Хотелось бы узнать какие сейчас микрухи используются.? если нужен PHY к ПЛИС - то Marvell 88E1111. Получится wirespeed. Цитата(TamRazZ @ Sep 10 2013, 21:13)  И возможно ли добиться бОльших скоростей, используя существующий стек и сменив микруху.? нет. Вы должны понимать - какой вопрос такой и ответ. Если вы манагер и вам нужен ответ прямо здесь и сейчас - то для вас правильным ответом будет сделать реализацию Ethernet на самом новом и самом мощном Intel Core, или ещё лучше если это будет Xeon. Если вы инженегр и понимаете что Ethernet это не только TCP/IP, то решением может быть полностью аппаратный UDP, без каких бы то ни было процессоров вообще.
--------------------
провоцируем неудовлетворенных провокаторов с удовольствием.
|
|
|
|
|
Sep 11 2013, 14:23
|
Участник

Группа: Участник
Сообщений: 24
Регистрация: 21-03-11
Пользователь №: 63 743

|
Цитата(Swup @ Sep 11 2013, 10:36)  Так вот просто на ниосе в циклоне 2 у меня работало все на скорости 40-45 мбит/с. Вы использовали стандартный иниш стек или писали полностью свой, чтобы добиться таких скоростей.?
|
|
|
|
|
Sep 11 2013, 14:39
|
Местный
  
Группа: Свой
Сообщений: 491
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987

|
Как уже правильно говрили выше, вопрос поставлен неточно. При проворачивании какого стека коммуникационных протоколов вы хотите добиться data rate >= 80 Mbps @ FastEthernet? Варианты: 1) Eth PHY - Eth MAC - все, что выше - свое (свои network layer / transport layer - по мере надобности). +: можно добиться наивысшей скорости передачи. -: все проблемы реализации собственных уровней ;-) 2) Eth PHY - Eth MAC - IP - TCP/UDP. Надо применять наработанные реализации TCP/IP стеков, а они будут кушать процессорный и системный ресурс, и их проворачивание будет иметь на данной платформе вполне определенную latency, приводящую к некоему максимальному для платформы кол-ву обрабатываемых пакетов в секунду (сетевая производительность). Рассмотрим вариант 2, как более реалистичный. Составляющие обработки (если грубо): обработка PHY/MAC (tMAC) + обработка TCP/IP (tTCP). В использовавшемся вами до сих пор варианте (LAN91С111 + NiosII + lite weight TCP (по-видимому)) обе составляющие выполнялись при плотном задействовании CPU, к тому же природа LAN91C111 ограничивает его предельную пропускную способность числами существенно ниже теоретически возможных 90-95 % от 100Mbps. Все вместе и дало наблюдаемый результат - 15-20 Mbps (для данной комбинации, кстати, весьма хороший). Путь улучшения - разгрузка CPU от сетевых задач, насколько возможно => перенос функциональности на HW где только можно. Рассмотрим отдельно реализацию этого для PHY/MAC и TCP/IP. PHY/MACВ части MAC имеются хорошо наработанные решения, основанные на следующих идеях (еще со времен присной памяти NE2000 сетевых карт, как минимум): 1) МАС работает мастером и сам забирает-складывает содержимое пакетов, помещаемых в выделяемые буфера (в основной памяти данных); 2) драйвер (читай - CPU) в основном имеет дело с дескрипторами Rx и Tx буферов, которые он заполняет (для Tx) и проверяет (Rx); дескрипторы, как правило, объединеные в кольцевые списки; 3) MAC также работает с дескрипторами (узнает, откуда брать TxData, и куда класть RxData, и помечает отработанное). Думаю, конкретный MAC-PHY чип, работающий по такому принципу, народ вам скоро насоветует. Ну, и сами теперь знаете, что искать надо. В качестве суб-варианта: {внешний PHY} + {MAC in FPGA} (у Altera же есть соответствующие ядра, да на OpenCores тоже). TCP/IPТеперь уже и в этой части есть аппаратные наработки. Например, WizNet - накрывает сразу все - PHY/MAC/TCP. Но вот насчет его производительности не могу ничего сказать - не имел дела непостредственно. Наверняка, есть и аппаратные ускорители для работы с TCP/IP стеком - только поискать надо. А вообще, вполне возможно, что и аппаратные улучшения на MAC уровне (см. выше) уже дадут вам желаемое (или сильно к нему приблизят).
|
|
|
|
|
Sep 11 2013, 16:55
|
Участник

Группа: Участник
Сообщений: 24
Регистрация: 21-03-11
Пользователь №: 63 743

|
Цитата(Raven @ Sep 11 2013, 18:39)  PHY/MAC
В части MAC имеются хорошо наработанные решения, основанные на следующих идеях (еще со времен присной памяти NE2000 сетевых карт, как минимум): 1) МАС работает мастером и сам забирает-складывает содержимое пакетов, помещаемых в выделяемые буфера (в основной памяти данных); 2) драйвер (читай - CPU) в основном имеет дело с дескрипторами Rx и Tx буферов, которые он заполняет (для Tx) и проверяет (Rx); дескрипторы, как правило, объединеные в кольцевые списки; 3) MAC также работает с дескрипторами (узнает, откуда брать TxData, и куда класть RxData, и помечает отработанное). Спасибо, за полезную информацию. Как раз хотел спросить про микросхемы с готовым Phy и Mac. Может, кто имеет опыт работы с конкретными микрухами и может что-то посоветовать.?
|
|
|
|
|
Sep 12 2013, 06:14
|
Местный
  
Группа: Свой
Сообщений: 491
Регистрация: 16-01-05
Из: Санкт-Петербург
Пользователь №: 1 987

|
Цитата(ZASADA @ Sep 12 2013, 00:05)  WizNet не вариант. Вы его щупали на предмет производительности? Что может дать, какого порядка? Похоже, что его целевая аудитория другая (просто дать окно в TCP/IP мир для всего, что только можно), но все же интересно - для понимания расклада.
|
|
|
|
|
Sep 12 2013, 06:42
|
Частый гость
 
Группа: Свой
Сообщений: 127
Регистрация: 2-09-11
Из: Москва
Пользователь №: 66 970

|
Цитата(TamRazZ @ Sep 11 2013, 18:23)  Вы использовали стандартный иниш стек или писали полностью свой, чтобы добиться таких скоростей.? Приращивание заголовка ethernet, IP, UDP и выход этого дела на микруху, никакого стека сверху. Просто не было потребности в стеке.
Сообщение отредактировал Swup - Sep 12 2013, 06:42
|
|
|
|
|
Sep 12 2013, 07:25
|

Знающий
   
Группа: Свой
Сообщений: 738
Регистрация: 13-01-11
Из: Минск
Пользователь №: 62 210

|
Цитата(Raven @ Sep 12 2013, 09:14)  Вы его щупали на предмет производительности? Что может дать, какого порядка? Похоже, что его целевая аудитория другая (просто дать окно в TCP/IP мир для всего, что только можно), но все же интересно - для понимания расклада. WizNet щупали, разные версии, поначалу модули даже в серийные изделия ставили. но у всех были свои аппаратные проблемы - то буфера переполняются и зависает, то двойное тегирование VLAN не пропускает. В итоге создали свой модуль в том же конструктиве и везде заменили. И да, предназначение WizNet - неспешное окошко в Ethernet , замена RS.
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|