Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Скорость обмена данными используя Ethernet
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
OlegHmt
Когда-то я встречал такую информацию, но сейчас не смог найти - вроде бы много таких тем, но разобраться я так и не смог. Вообщем не бейте очень сильно если повторяюсь. smile.gif

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

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

Спасибо
sff
Цитата(OlegHmt @ Jan 16 2007, 00:59) *
Когда-то я встречал такую информацию, но сейчас не смог найти - вроде бы много таких тем, но разобраться я так и не смог. Вообщем не бейте очень сильно если повторяюсь. smile.gif

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

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

Спасибо

А почему uIP а не lwIP, просто uIP то для 8разрядных МКУ оптимизирована.. а в каком-то релизе в обработке IP все операции с 32 разрядными числами были сделаны через 16 разрядные в инструкциях С. И при компиляции под arm такое прироста скорости уж никак не даст, где есть нативная поддержка 32..
aaarrr
Цитата(OlegHmt @ Jan 16 2007, 00:59) *
...у меня получается приблизительно 1,3Мбит/с (Связь установлена на 100Мбит/с). Это предел или нет? Может нужно оптимизировать стек или переходить на UDP?

У меня когда-то на AT91R40807 + CS8900 довольно легко получалось 8Мбит/с на своем стеке. Так что не предел далеко.
etoja
Начало пакета в сети 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
Mc_off
Цитата(etoja @ Jan 16 2007, 07:40) *
Начало пакета в сети Ethernet привязано к импульсам линка, идущим с частотой 60Гц.

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

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

Цитата(etoja @ Jan 16 2007, 07:40) *
Среднюю скорость обмена 8Мбит/с на ней получить нельзя, учитывая доступ к каналу других абонентов и задержек на принимающей/передающей стороне.

Опять НЕПРАВДА. Я получал около 7-8 Мбит
etoja
На страницах №37,38 даташита на CS8900 описано выравнивание начала пакета на границу импульса линка.
Mc_off
Цитата(etoja @ Jan 16 2007, 09:41) *
На страницах №37,38 даташита на CS8900 описано выравнивание начала пакета на границу импульса линка.

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

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

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

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


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

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

Это уже лучше, но всё равно чуть маловато. Ещё бы в раза 2 ускорить - и было бы в самый раз. Буду пробовать оптимизировать код стека.
Mc_off
Цитата(OlegHmt @ Jan 16 2007, 11:19) *
Mc_off
А на каком уровне у Вас идут данные?

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

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

И насколько тяжело организовать работу на уровне Ethernet (какие проблемы могут проявиться на стороне микроконтролера, а также на PC)?
Mc_off
Цитата(OlegHmt @ Jan 16 2007, 13:05) *
Mc_off

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

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


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

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

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

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

Мне не очень понятна схема взаимодействия вашего контроллера и компа. Через что данные передаются между компом и контроллером ? Через Ethernet ? Через PCI, ISA ?
3.14
2 OlegHmt
uIP не лучший выбор, там с ходу больше десятков килобайт не получить, экспериментировал на SAM7X256 под FreeRTOS.
OlegHmt
Понятно. Спасибо. Посмотрю может и я спущусь к работе на уровне Ethernet.

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

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

Цитата(3.14 @ Jan 17 2007, 08:46) *
2 OlegHmt
uIP не лучший выбор, там с ходу больше десятков килобайт не получить, экспериментировал на SAM7X256 под FreeRTOS.


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

Не спорю, возможно что стек действительно далёк от оптимальности, но, фактически, на момент начала работы у меня был выбор lwIP или uIP, и я выбрал второй, так как по описаниях он требует гораздо меньше оперативной памяти.
Возможно в дальнейшем, если будет время и желание я поищу и буду использовать другую реализацию стека, а может даже напишу свою, заточеную под мою задачу, но это будет в будущем smile.gif
3.14
Цитата
Извините, не совсем понял - десятков килобайт чего?
Трафик от Вашего устройства к PC, из-за организации стека, хотя вроде имеется какой-то патч ...
OlegHmt
Цитата(3.14 @ Jan 17 2007, 09:01) *
Трафик от Вашего устройства к PC, из-за организации стека, хотя вроде имеется какой-то патч ...


Собственно говоря у меня и выходит немного - где-то 280кБайт/с
А что за патч такой?
3.14
Про этов его доке (v1.1) написано.
OlegHmt
Цитата(3.14 @ Jan 17 2007, 09:13) *
Про этов его доке (v1.1) написано.


смотрел на сайте - последняя версия 1.0, таже, что и у меня
3.14
Cори, попутал, смотрите "TCP throughput booster hack".
там же где-то приводились прикидки максимальной пропускной способности, в памяти мелькают цифры на порядок меньше Вами полученых ...
Rinat86
мне надо разработать устройство-мост CAN-Ethernet на базе микроконтроллера AT91SAM7X256(дипломный проект). Не могли бы Вы выслать исходники по формированию пакетов,кадров,передачи информации,.И если есть описание на русском работы микроконтроллера с Ethernet-ом.Будут очень признателен.(в общем самую полезную на Ваш взгляд информацию о микроконтроллере и Ethetnet-е в целом)
rinatkhamzin@yandex.ru
OlegHmt
Смог поднять скорость передачи даных на уровне TCP приблизитель в 1,5 раза где-то до 3,4 Мбит/с включив в RowleyCrossWorks оптимизацию по размеру кода для некоторых файлов IP стека. А именно для своего файла обработки данных, файлов uip_arch.c, uip_arp.c. Думаю, что можно ещё больше поднять скорость если включить оптимизацию uip.c, но при любой включенной оптимизации этого файла система подвисает при передаче данных. Что-то там компилятор неправильно оптимизирует. Жаль пока что нету времени искать места, где происходит сбой и корректировать их
boez
Цитата(OlegHmt @ Jan 22 2007, 09:51) *
Смог поднять скорость передачи даных на уровне TCP приблизитель в 1,5 раза где-то до 3,4 Мбит/с включив в RowleyCrossWorks оптимизацию по размеру кода для некоторых файлов IP стека. А именно для своего файла обработки данных, файлов uip_arch.c, uip_arp.c. Думаю, что можно ещё больше поднять скорость если включить оптимизацию uip.c, но при любой включенной оптимизации этого файла система подвисает при передаче данных. Что-то там компилятор неправильно оптимизирует. Жаль пока что нету времени искать места, где происходит сбой и корректировать их


Какая версия CW? Советую обновить до 1.6, лучше build 3. Помогает. При уровне О1 тоже падает?
OlegHmt
Цитата(boez @ Jan 22 2007, 11:46) *
Какая версия CW? Советую обновить до 1.6, лучше build 3. Помогает. При уровне О1 тоже падает?

1.6 build 3, но после лечения стало build 2.
Но как я понимаю gcc там осталось из пакета build 3.
Падает при всех уровнях оптимизации. Одну из ошибок я когда нашёл (когда первый раз с этим столкнулся). Затыкалось на такой конструкции:

Код
if((uip_connr->tcpstateflags != CLOSED) &&
       (BUF->destport == uip_connr->lport) &&
       (BUF->srcport == uip_connr->rport) &&
       (BUF->srcipaddr[0] == uip_connr->ripaddr[0]) &&
       (BUF->srcipaddr[1] == uip_connr->ripaddr[1])) {
      goto found;
    }

Когда я каждое сравнение сделал отдельно в отдельные переменные, а потом их сравнил и поставил в if система у меня прошла эту конструкцию (тогда я пробовал только на уровне оптимизации 1).
Когда дойдут руки, надо будет поискать ещё куски кода где затыкается

Цитата(boez @ Jan 22 2007, 11:46) *
Какая версия CW? Советую обновить до 1.6, лучше build 3. Помогает. При уровне О1 тоже падает?

1.6 build 3, но после лечения стало build 2.
Но как я понимаю gcc там осталось из пакета build 3.
Падает при всех уровнях оптимизации. Одну из ошибок я когда нашёл (когда первый раз с этим столкнулся). Затыкалось на такой конструкции:

Код
if((uip_connr->tcpstateflags != CLOSED) &&
       (BUF->destport == uip_connr->lport) &&
       (BUF->srcport == uip_connr->rport) &&
       (BUF->srcipaddr[0] == uip_connr->ripaddr[0]) &&
       (BUF->srcipaddr[1] == uip_connr->ripaddr[1])) {
      goto found;
    }

Когда я каждое сравнение сделал отдельно в отдельные переменные, а потом их сравнил и поставил в if система у меня прошла эту конструкцию (тогда я пробовал только на уровне оптимизации 1).
Когда дойдут руки, надо будет поискать ещё куски кода где затыкается
Alex03
Цитата(OlegHmt @ Jan 22 2007, 16:55) *
1.6 build 3, но после лечения стало build 2.
Но как я понимаю gcc там осталось из пакета build 3.

Есть ж лекарство для b3.
Цитата
Падает при всех уровнях оптимизации.

__attribute__ ((interrupt ("IRQ"))) нигде не пользуете?
OlegHmt
Цитата
Есть ж лекарство для b3.

На тот момент нашёл только для b2. Сейчас поищу может поновее найду

Цитата
__attribute__ ((interrupt ("IRQ"))) нигде не пользуете?

да нет, там прерываний никаких нету. Стандартный файл из библиотеки uIP, я там кажется ничего не переделывал. Кстати в оригинальном примере от FreeRTOS, откуда взят стек все файлы относящиеся к стеку компилируются без какой-либо оптимизации.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.