Реально Fast Ethernet, Использование RAW-пакетов Опции

[Aprox]

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

[Raimis]

Периодически вспыхивают дискуссии о реальной скорости передачи данных по Ethernet...
Для известных конструкций на микроконтроллерах, реальная скорость не превышает 20..25 Mbps...

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

Вот первые результаты натурных испытания на модуле MMstr912 от Propox получена максимальная скорость передачи данных- 96 Mbps

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

[AlexandrY]

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

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



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

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

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

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

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

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

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

[Aprox]

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

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

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

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

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

[Aprox]

Нет 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. Сэкономили людям очень много времени.