Периодически вспыхивают дискуссии о реальной скорости передачи данных по Ethernet. У меня именно такая задача - в сенменте Ethernet-100 обеспечить передачу потока данных со скоростью не менее 80 Мbps. Как я уже докладывал, существующие стеки TCP/IP не обеспечивают такой скорости, даже в протоколе UDP. Для известных конструкций на микроконтроллерах, реальная скорость не превышает 20..25 Mbps. Поэтому было решено отойти от стандартов TCP/IP и максимально сократить программное вмешательство процессора в процесс отсылки пакетов. Городить FPGA для ENET-100 тоже не показалось оправданным. В результате, поиск остановился на кристалле STR912FAxx c ARM9 и Ethernet контроллером на борту. Почему именно на нем. Потому, что в нем так организована периферия, AHB шина, контроллер внешней шины и DMA-MAC, что позволяет заполнять FIFO MAC-контроллера внешними данными автономно, минуя шину процессора и минуя шину FLASH и SRAM. Т.е. процессор практически не тормозится, а закачка данных идет на максимальной скорости. Я реализовал простейший вид RAW-пакетов в формате Ethernet-II: <Dst><Src><FrameId><...Data...>. Где FrameId мне любезно предоставил наш уважаемый гуру. Вот первые результаты натурных испытания на модуле MMstr912 от Propox получена максимальная скорость передачи данных- 96 Mbps. Использование 100M сети на 96%. Это скорость, когда процессор ничем не занят. В реале же, я ожидаю незначительного снижения производительности из-за того, что подготовка и отсылка пакетов практически полностью осуществляется аппаратными средствами кристалла. Было проверено также прохождение такого потока данных через свитч. Нареканий нет. Также проверена возможность WinPCAP капчурить поток пакетов такой скорости поступления и записывать их в файл. Работает исправно на Windows XP c обычным пентиумом 800MHz. Сейчас я полон оптимизма и приступаю к реализации WEB-сервера на RAW-пакетах.

На ARM9 200MHz под Linux'ом получается скорость 93.9МБит/с для TCP соединения. Измерялось iperf'ом.


Какие же тут RAW-пакеты, если WEB-сервер предполагает использование TCP/IP?

Мой выбор конструкции- все на одном кристалле, в корпусе LQFP-128, стоимостью $14. Ваш вариант ARM9 200MHz с Linux сопоставим по простоте и стоимости?



Точно такой же, как делают WEB-сервер в сети на RS-485. Через шлюз CGI.

По стоимости сопоставим, по простоте - не очень

Если не секрет, какой кристалл используете, какая вокруг обвязка, сколько потребляет все вместе. И самый главный вопрос, ваш процессор кроме прокачки по TCP может заниматься еще чем-нибудь, например, управлением моторами, DSP обработкой речи?

Скорость измерялась на платформе EP9312, но он уже старенький и потому дорогой. За $20 можно поставить AT91SAM9260+SDRAM+Flash.


Может, но "прокачка" при этом пострадает. Только зачем контроллеру мотора иметь 100Мбит Ethernet на полной скорости? Жевать полноценно такие потоки он все равно не сможет.

Я приглядывался к подобным вариантам, и показались они слишком громоздкими для моих задач. Раньше вся система WEB-управления прибором умещалась в однокристаллке с разумной тактовой частотой. Потом было поставлена задача, параллельно с уже существующем, создать канал перекачки внешних потоков данных в компьютер по Ethernet. Порывшись в вариантах, я понял, что однокристаллкой с существующим TCP/IP программным стеком тут делать нечего. А переходить на монстрообразные конструкции с дополнительными SDRAM, Flash, высокой тактовой частотой, BGA корпусами и многослойной печатной платой- сильно не хотелось. Очень обрадовался, когда узнал про однокристаллку STR912F, что там можно устроить практически аппаратную перекачку потока из внешней параллельной шины в MAC контроллер. Процессор не тормозится и спокойно может вести прежнюю задачу управления. Это было решающим пунктом в выборе решения. Этим же обстоятельством продиктован переход на RAW-пакеты и отказ от IP. Только в этом случае обеспечивается минимальное вмешательство процессора в перекачку данных, отсюда скорость.


"Жевать" не требуется, надо тупо брать данные с EMI шины в виде готовых Raw-пакетов и пулять наружу через ENET. Если суда вклиниваются программные действия процессора, то скорость падает и тем больше, чем хуже написан софт TCP/IP стека. Кстати, какой использовали стек в своих испытаниях? GNU, opensource или покупной? Кроме того, задача управления прибором имеет высший приоритет, что в случае программного TCP/IP, потребует организации больших буферов в оперативной памяти на случай паузы из-за отвлечения процессора на управление. Крайне нежелательно для однокристальных ARM-ов, у которых довольно сильная напряженка именно со встроенной SRAM. Короче, чем меньше процессор участвует в тупой перекачке данных, тем лучше.

Понятно. У меня тоже в одной разработке используется AT91SAM7X128 в качестве дешевой замены ПЛИС Но там немного другая специфика - нужно из очень толстого внешнего потока выхватывать свои данные и делать минимальную обработку.

Мы тоже начали городить что-то подобное, но испугались что нехватит мощности ST912xx процессора и выбрали проц помощенее - iMX27 от freescale ( мощности небывает слишком много .

Как я понимаю тесты делались со стандартным ST MAC/DMA (ENET) фирмваром? Генерились готовые пакеты (в FPGA?) и передавались в FIFO MAC-контролера? А какой размер был тестовых пакетов? Максимальный? А есть возможность повторить тест, но с маленькими пакетами? Могут в таком тесте возникнуть сложности с пакетами размером до 100Б? Есть узкое место?

91x_enet.c библиотеку переделал, выкинул все лишнее, что было нужно для TCP/IP.

Да, готовый RAW-пакет, кроме CRC, выдает FPGA. ST MAC/DMA читает напрямую из 16-бит внешней шины. Процессор в заполнении пакета данными не задействован.

Да, 1500.

Я пробовал с пакетами 80 байт. Загрузка сети уменьшалась с 96% до 94%. Узкое место в этом случае предполагаю в большем участии процессора для пересылки. Hо это еще не проверялось. Hе знаю.

А как Ваше устройство отреагирует на сеть, где multicast разливается? Или оно только передает, но не принимает данные?

Как раз сейчас налаживаю прием данных на фоне непрерывной передачи пакетов. Устройство подключено к отдельному сегменту Ethernet в полном дуплексе и по идее передача мешать приему не должна. Однако, столкнулся с багами встроеного MAC контроллера кристалла STR912FA. А может, плохо разобрался в доках, или очередной баг в стандартной библиотеке... Короче, пока не получается одновременно передавать и принимать пакеты. Буду разбираться.

это очень хорошая новость!
А невозможно хотябы по косвенными признаками прикинуть насколько загружает процессор поток до потолка 80-ти байтовых пакет?

Процессор для каждой передачи пакета задействуется на четыре С-строки инициализации дескриптора MAC-DMA, что займет где-то порядка 0,5мкс. Далее передача пакета происходит без участия процессора.
Hа пакете в 1500 загрузка процессора составляет 0.5ukc/120ukc=0.5% всего времени. При пакете в 80 байт будет примерно 0.5/6,4= 15% всего времени.

Сейчас получилось. Как и ожидалось, все баги нашлись в библиотеке от STM, заведующей ENET. Пришлось заново переписать. Теперь устройство передает и принимает данные одновременно со скоростью 96MBсек и на прием, и на передачу. Полный дуплекс.