Периодически вспыхивают дискуссии о реальной скорости передачи данных по 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сек и на прием, и на передачу. Полный дуплекс.

Решил я тут проверить эти утверждения.
Картина немного не такая.

Я сделал чистый эксперимент и вообще не использовал програмную поддержку для передачи данных в Ethernet.
Я сделал цепочку из 1000 дескрипторов для DMA и запускал пересылку при разных длинах пакетов.
Причем пересылались данные из внутренней RAM.
Привожу графики реальных замеров.



Как видно скорость можно получить и 98 Mbit/s
В плюс также полное отсутствие ошибок при приеме пакетов на PC.
Но при коротких пакетах сделать 90 Mbit не реально даже из внутренного RAM
Хуже того, при коротких пакетах начинаются флуктуации, вероятно обусловленные коллизиями на AHB шине. Т.е. шина у STR91 явно не предназначена для толстого трафика.

Еще надо помнить, что внешний порт у STR91 идет через шины APB и AHB, т.е. этот трафик конфликтует со всеми другими каналами DMA и обращениями к периферии и пропускная способность ограничена где-то 20 Mbyte/s т.е. критическая граница слишком близко.

Также серьезно тормозится выполнение програмного кода. Этот анализ есть на моем сайте.

Ну и на конец серьезное приложение на STR91 обязательно потребует операционки, а там такие финты с DMA не пройдут, будет много накладных для обеспечения межзадачной синхронизации.

iMX в этом плане значительно лучше, у него и системные шины быстрее и внеший порт минимум в 4-е раза быстрее и есть коммутатор на внутренней шине чтобы разделять потоки данных.

Сегодня я тоже решил проверить реально работу своего варианта на коротких пакетах. Действительно, для коротких пакетов я ошибся в оценках. Для пакетов в 64 байта у меня получилось даже хуже, чем в вашем эксперименте. Если данные брались из SRAM, то 55Mbit/s. Если MAC-DMA брал пакет из EMI, то 59Mbit/s. Мои результаты хуже по производительности потому, что я использовал всего один дескриптор и программу для периодического его старта. Это программная часть дает нагрузку в виде дополнительных 3.3 мкс к чистому времени отсылки короткого пакета 5.1мкс. Как видно, КПД сети действительно около 60% на пакетах в 64 байта. Hо ситуация еще хуже, потому что я обнаружил PAUSE пакеты, которые вдруг стал посылать PC, и именно когда короткие пакеты. Игнорировать такие сигналы чревато потерей пакетов.

Флуктуации объясняются скорей всего именно PAUSE пакетами, компьютер пропускает часть входящего трафика. На пакетах максимальной длины я PAUSE пакеты и флуктуации не обнаружил. И скорость передачи данных, даже в моем однодискрипторном варианте и участии короткой программы, равна 96Mbit/s. Вывод- будем работать с большими пакетами. Тем более, что никаких требований с практической стороны на размер пакета в моем случае не существует.

По опыту работы в embedded system у меня сложилось впечатление, что для большинства практических конструкций необходим только один скоростной канал, требования по производительности к остальной периферии незначительны. Hапример, трудно ожидать, чтобы устройство одновременно качало данные и по Ethernet и по USB-2. Именно поэтому замечание о перегрузке шин APB и AHB по DMA-периферии носит скорей академический характер из сферы компьютеров общего назначения.

Правильно, обязательно будет тормозиться, если за данными MAC-DMA обращается к SRAM. Потому что через AHB лезет на шину, связывающую ядро ARM с памятью. В моем случае MAC-DMA обращается за данными к внешней шине EMI, которая также принадлежит AHB. Т.е. по-идее процесс обмена не выходит за рамки AHB и никого вокруг тормозить не должен. Практически это мною не проверялось. И и наверное не буду проверять за второстепенностью вопроса.

"Обязательность операционки" относится к разряду религиозных канонов. В embedded совсем не очевидно. Как-то удавалось всегда обходится без RTOS, хотя реальные приложения никак не могу назвать простенькими. Только один раз сподобился на использование uCOS-II и только потому, что она шла в составе пакета разработки, куда входил также TCP/IP стек и WEB-сервер. Стек был заточен под операционку и поэтому пришлось поневоле. Теперь же, поскольку никаких TCP/IP нет, то однозначно отпала всякая необходимость и в операционках.

Зато возникает много конструктивных и технологических проблем: BGA корпус, многослойная плата, Flash снаружи, DDRAM снаружи, разводка шин с тактом 200MHz, что-нибудь обязательно еще в довесок этим 200MHz.... Hет, я предпочитаю однокристальные варианты.

Нет PAUSE пакетов никаких не было.
Во первых карта гигабитная, во вторых ускореный режим с автоматическим расчетом CRC.
А самое главное при отключенном flow control со стороны карты и со стороны моей платы.
При этом была насильно отключена поддержка PAUSE и на MAC уровне и на PHY и вдобавок включен Half duplex
Результаты те же.
Испытавалось на вот этой платформе: http://aly.ogmis.lt/OpenProjects/ARMDominator4/ARMD4.htm

Я провожу испытания на платформе MMstr912 от фирмы Propox
Сетевая карта в компьютер самая обычная D-Link 100Мег. И я не влезал в ее настройки. Вероятнее всего они по умолчанию от Windows-XP. Плата посылает PAUSE пакеты, когда к ней на вход валом идут короткие пакеты по 64-байт. При каком размере они исчезают я не проверял, но при 1500- их точно не наблюдается. Интересный момент, значение времени паузы в этих пакетах стоит всегда 0xFFFF, т.е. по максимуму. В моем эксперименте я никак не реагирую на эти PAUSE и продолжаю слать пакеты. Регистрирую пакеты на PC с помощью снифера WireSharck, по существу использую известный драйвер WinPCap для сниферов. Странно, но но в дампе снифера я не вижу пропусков пакетов из-за команды PAUSE. Видимо это фокусы винды, которыеWinPCap каким-то образом обходит. И поскольку прием своих RAW-пакетов я так и планирую осуществлять с помощью WinPCap, то на PAUSE пакеты скорей всего плюну.

У снифера, тем не менее, замечены странности в фиксации timestamp-ов пакетов. Так например, по логическому анализатору я вижу совершенно ровный выходящий поток пакетов, следующих с периодом 8,4мкс (это для коротких 64 байта пакетов). А в снифере регистрируется приход пакетов через 3мкс ! Через десяток пришедших пакетов вдруг возникает интервал в 70мкс! В среднем же действительно где-то 8мкс. Какая-то сложная жизнь внутри происходит, не очень понятно. Впрочем, использовать на практике можно.

PS. Большой вам респект за опубликование мытарств с багами периферии STR912F. Сэкономили людям очень много времени.