Когда-то я встречал такую информацию, но сейчас не смог найти - вроде бы много таких тем, но разобраться я так и не смог. Вообщем не бейте очень сильно если повторяюсь.

Собственно вопрос: какую скорость обмена данными по сети можно получить используя такую связку: AT91SAM7X256, rtl8201bl, FreeRTOS, uIP? Ядро процесора работает на 48 МГц. Программа исполняется из флеша.

Собственно мне нужно где-то 4-5Мбит/с (а если можно то и больше). Пока что реализовав програму и используя TCP обмен (буфер на приём 2к, данные передаются в процесор и просто записываются во внутреннюю память) у меня получается приблизительно 1,3Мбит/с (Связь установлена на 100Мбит/с). Это предел или нет? Может нужно оптимизировать стек или переходить на UDP?

Спасибо

Сообщение отредактировал OlegHmt - Jan 16 2007, 01:00

А почему uIP а не lwIP, просто uIP то для 8разрядных МКУ оптимизирована.. а в каком-то релизе в обработке IP все операции с 32 разрядными числами были сделаны через 16 разрядные в инструкциях С. И при компиляции под arm такое прироста скорости уж никак не даст, где есть нативная поддержка 32..

У меня когда-то на AT91R40807 + CS8900 довольно легко получалось 8Мбит/с на своем стеке. Так что не предел далеко.

Начало пакета в сети Ethernet привязано к импульсам линка, идущим с частотой 60Гц.
Поэтому при обмене короткими пакетами будет получаться меньшая скорость, чем при обмене длинными.

Пусть ты обмениваешься пакетами длиной 1500 байт. На скорости 100Мбит/сек это занимает 1500*8/100=120 микросекунд.
Импульсы линка идут с частотой 60Гц, то есть с периодом 15миллисекунд. Предполагая, что процесс случайный и равновероятный, ты будещь
ожидать начала очередного импульса линка в течении 15/2=7.5 миллисекунд. При этом средняя скорость передачи составит
1500байт/(120микросекунд+7.5миллисекунд)=196Кбайт/сек = 1.54Мбит/сек.
То есть тобой получена предельная сторость обмена.

Микросхема CS8900 имела скорость 10Мбит/сек и была снята с производства в 2004 году.
Среднюю скорость обмена 8Мбит/с на ней получить нельзя, учитывая доступ к каналу других абонентов и задержек на принимающей/передающей стороне.
Особенно, если эти абоненты работают под Windows.
http://www.cirrus.com/en/products/eol/index.html

Неправда !
Кадры никак не привязаны к импульсам FLP.
Между кадрами в Ethernet есть зазор в 96 бит (9,6us для 10MBit 0,96us для 100Mbit). Для HalfDuplex еще добавляется случайный временной интервал.

Все это подробно описано в стандарте IEEE 802.3 глава 4 Media Access Control


Опять НЕПРАВДА. Я получал около 7-8 Мбит

Сообщение отредактировал Mc_off - Jan 16 2007, 09:34

На страницах №37,38 даташита на CS8900 описано выравнивание начала пакета на границу импульса линка.

Вообще я говорил о стандарте.

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

Я сейчас эту микросхему не использую. Я использую, как и автор, RTL8201BL.
И никаких выравниваний там нет. Скорость у меня ограничивается доступом к памяти. Получается около 50Мбит. Собираюсь ставить 16битную память, тогда огрничения будут только на канале связи.
Информацию я обрабатываю с использованием FPGA...

Насколько я понял читая информацию об этих двух стеках uIP меньше потребляет оперативки и кода. А так, как оперативной памяти маловато, то было решено выбрать именно этот стек.
Конечно можно попробовать lwIP, но мне кажется (возможно я ошибаюсь), что это не очень увеличит скорость работы стека. Похоже проблема немного в другом.


Кстати, о том как я передаю данные: с компьютера в процесор я шлю данные блоком в 1500 байт и после каждого блока жду двухбайтового подтверждения от процесора о том, что он успел данные обработать (Перебросить в нужное место памяти). Возможно в этом задержка?

Mc_off
А на каком уровне у Вас идут данные? Когда я искал по форуму эту информацию, где-то проскочила тема где было написано, что кто-то получал на 100Мбитной сети 60-70 Мбит, но он запихивал данные напрямую в Ethernet пакет и на компьютере для работы использовал WinPcap. А у меня данные вставляются на уровне TCP протокола. (Возможно я неправильно пользуюсь терминологией, так как читал о сетевом взаимодействии но не занимался сетями на професиональном уровне, поэтому извините, если что за ошибки )

В который раз приходиться извиняться за свои ошибки
Нашёл небольшую задержку которую сам и вводил когда разбирался почему у меня не работает стек (проблема была в ошибках работы компилятора при оптимизации).
В результате (правда тестировал на другой - более сильной машине) получил приблизительно 2.2Мбит/с.

Это уже лучше, но всё равно чуть маловато. Ещё бы в раза 2 ускорить - и было бы в самый раз. Буду пробовать оптимизировать код стека.

Я работаю на уровне Ethernet. Т.е. без протоколов верхнего уровня. Однако у меня есть пример (Evalution Board) где работа идет на уровне TCP. Там применялся WizNET с RTL8201 и AVR.

Mc_off

При переходе от работы на уровне TCP к работе на уровне Ethernet насколько большим может быть прирост производительности?

И насколько тяжело организовать работу на уровне Ethernet (какие проблемы могут проявиться на стороне микроконтролера, а также на PC)?

Протокол Ethernet - без гарантированной доставки (почти как UDP), кроме того он отличается от UDP еще и тем, что кадры не маршрутизируются в отличие от пакетов.

В моей задаче собственно говоря не происходит генерации данных для передачи, т.е. то, что делаю я - не каналообразующее оборудование. Я делаю преобразователи форматов. Грубо говоря. Запихиваю Ethernet в E1, E2, E3, xDSL и т.п. Процессоров я не использую вообще. Использую FPGA и SRAM.

Теперь по поводу впроса.
Если ваш задача позволяет не использовать протоколы UDP, TCP и другие. Если вам не нужна мршрутизация вашего потока и его гарантированная доставка не обязательна, то можно переходить на низкий уровень Ethernet.

Выигрыши: не надо разварачивать заголовки пакетов; возможно не надо сшивать датограммы; не нужно отрабатывать ARP запросы и ответы; и пр.

Мне не очень понятна схема взаимодействия вашего контроллера и компа. Через что данные передаются между компом и контроллером ? Через Ethernet ? Через PCI, ISA ?

2 OlegHmt
uIP не лучший выбор, там с ходу больше десятков килобайт не получить, экспериментировал на SAM7X256 под FreeRTOS.

Понятно. Спасибо. Посмотрю может и я спущусь к работе на уровне Ethernet.

У меня внешнее устройство, которое подключается к компу или через USB, или через Ethernet интерфейс. Комп управляет устройством конфигурируя его, сбрасывая ему данные и иногда получая информацию о статусе устройства.

Ещё такой вопрос:
С помощью каких инструментов происходит формированние запросов на ПК? Вы просто используете какие-то стандартные API функции ОС или стандартные компоненты пакетов програмирования? Я никогда на низком уровне не работал, а просто в делфи открывал сокет с задаными параметрами и бросал туда данные.



Извините, не совсем понял - десятков килобайт чего?
Точно не помню, но сейчас у меня оперативной памяти работа с сетью занимает где-то 2-2,5 кБайта под нужды uIP и 3-4 кБайта под буфер для EMAC. При этом я получаю приблизительно 2,2МБит/с при передаче данных от ПК к процесору, когда я посылаю данные пачками по 1440 байт и процесор каждую пачку подтверждает двумя байтами. Я работаю с протоколом TCP.

Не спорю, возможно что стек действительно далёк от оптимальности, но, фактически, на момент начала работы у меня был выбор lwIP или uIP, и я выбрал второй, так как по описаниях он требует гораздо меньше оперативной памяти.
Возможно в дальнейшем, если будет время и желание я поищу и буду использовать другую реализацию стека, а может даже напишу свою, заточеную под мою задачу, но это будет в будущем

Трафик от Вашего устройства к PC, из-за организации стека, хотя вроде имеется какой-то патч ...