Как повысить скорость работы по сети AT91SAM7X256 Опции

[OlegHmt]

Некоторое время назад я разрабатывал прошивку для этого процесора в которой была добавлена функциональность обмена данными по сети и USB. В качестве операционной системы использована FreeRTOS, TCP/IP стека - uIP. Сейчас потребовалось повысить скорость обработки событий устройством и оказалось, что по сети обмен данными идёт медленно. Так как я разбирался со всеми нюансами процесора и внутренностями сети самостоятельно, то мог пропустить какие-то важные моменты. Может кто увидит какие-то недостатки приведённого ниже алгоритма и подскажет как увеличить скорость работы устройства.
Итак, в устройство периодически по сети передаются данные блоком размером приблизительно в 16-20 кБ. Эти данные записываются в масив памяти и по таймеру процесора обрабатываются.
Когда я програмировал работу с сетью то передачу данных сделал блоками по 1500 Байт. Может я что-то не учёл, а может тогда вылезали другие ошибки, но при передачи блока большей длины у меня подвисал процесор (приёмный буфер установлен приблизительно на 2кБ), поэтому сделать так как в USB, когда я пишу в порт всё одним куском, на уровне USB контролера масив разбивается на части, а в процесоре я уже собираю данные (гарантированно доставленные), мне не удалось. Сейчас я смотрю, что похоже можно в обработчике прерываний от сети поставить свой код анализа входных данных и сделать похоже как в USB но не уверен - не буду ли я получать повреждённые даные, которые долго нужно будет перефрагментировать, проверять и т.д.
Сейчас у меня скорость передачи данных приблизительно 2Мб/с по 100 мегабитной сети. Выглядит это приблизительно так (результат теперешнего анализа с помощью Ethereal): отсылается пакет размером в 1500 байт в процесор, приблизительно через 4мс (время работы стека и моего копирования порции в нужное место памяти) процесор отсылает однобайтный пакет-подтверждения о приёме данных (чтобы внешняя программа не начала посылать данные пока я не обработал предыдущую порцию - правильно ли?), приблизительно через (дома забыл логи поэтому тут цыфру не помню) толи 1, толи 0,1мс, отсылается следующая порция данных. В результате 16кБ передаётся приблизительно за 50мс. Долго, было бы хорошо хотя бы в 2 раза быстрее. Можно ли улучшить скорость? Я смотрел, что при обработке стек копирует данные из буфера контролера в память, а потом я копирую куда мне нужно. Может можно сразу копировать без промежуточного буфера, но не будут ли проблемы с проверкой ошибок при передаче?
Может в стеке uIP можно убрать лишнюю обработку?

Пока что я в процессе анализа кода, может ещё что и сам найду, но за любые советы и предложения буду искренне благодарен.

[prottoss]

Закончил примерно с месяц встраиваемый HTTP-сервер + SNMP-агент на AT91SAM7X256. Стек использовал свой - давным-давно переделанный OpenTCP. Самый большой тормоз, ИМХО, в таких приложениях - использование memcpy, хотя МК распологает возможностью не использовать данную функцию. Код выложить не могу, ибо мое. Идея относительно простая:

1. Пишем свой менеджер памяти для работы с блоками по 128 байт (размерность для принимаемых блоков EMAC SAM7X).

2. Выделяем драйверу EMAC и стеку TCP/IP блоки.

3. При получении данных драйвер отдает список блоков с принятым пакетом а стек драйверу взамен свободные блоки. При этом производится обмен только указателями. Как такового не нужного копирования данных не происходит.

4. Соответсвенно, приложения(задачи) верхнего уровня (могут быть) тоже заточены под такой обмен данными.

При отправке данных опять происходит обмен указателями между драйвером и стеком(приложением).



Скорость, честно говоря не мерял, но работает довольно шустро - сетка прнимерно из 3-х сотен машин

[OlegHmt]

Закончил примерно с месяц встраиваемый HTTP-сервер + SNMP-агент на AT91SAM7X256. Стек использовал свой - давным-давно переделанный OpenTCP. Самый большой тормоз, ИМХО, в таких приложениях - использование memcpy, хотя МК распологает возможностью не использовать данную функцию. Код выложить не могу, ибо мое. Идея относительно простая:

1. Пишем свой менеджер памяти для работы с блоками по 128 байт (размерность для принимаемых блоков EMAC SAM7X).

2. Выделяем драйверу EMAC и стеку TCP/IP блоки.

3. При получении данных драйвер отдает список блоков с принятым пакетом а стек драйверу взамен свободные блоки. При этом производится обмен только указателями. Как такового не нужного копирования данных не происходит.

4. Соответсвенно, приложения(задачи) верхнего уровня (могут быть) тоже заточены под такой обмен данными.

При отправке данных опять происходит обмен указателями между драйвером и стеком(приложением).



Скорость, честно говоря не мерял, но работает довольно шустро - сетка прнимерно из 3-х сотен машин

Очень хороша идея.
Главное, что сам похожие вещи делал, при чём в этом же проекте, а тут использовать не догадался. Попробую

[defunct]

в таких приложениях - использование memcpy

Да от memcpy надо уходить.
Но даже с копированием, если сразу по 4 байта, и без проверок на выход за границы скорость значительно возрастет.

e.g.:

Код

static void memcpy_burst( U32 *pDest, U32 *pSrc, U32 size )
{
    U32  wCnt = (size + 3) >> 2; // words count to be copied
    do
    {
        *pDest++ = *pSrc++;
    } while (--wCnt);
}

данные обязательно должны быть 32bit-aligned.

[aaarrr]

Да от memcpy надо уходить.

Не надо уходить от memcpy! Стандартные библиотеки писаны далеко не дураками, и не на C.
Ссылка.

[prottoss]

Не надо уходить от memcpy! Стандартные библиотеки писаны далеко не дураками, и не на C.
Ссылка.

Ну тогда объясните, чем memcpy лучше обмена списками вида

Код

typedef struct __DATALIST
{
   struct __DATALIST *next;  /* next datalist */
   void  *data;  /* adress for data */
   UINT data_len; /* lenght for this data in bytes */
   UINT total_len; /* total lenght for all data in datalist */

} DATALIST;

Вернее указателями на списки

Писать свой менеджер памяти, пока для меня будет сложно, поэтому разбираюсь с lwIP. Правда ещё попробую копировать по 4 байта. А пока такой вопрос - прошивка у меня компилируется в Thumb виде, согласно документации - использование ARM команд повышает быстродействие по сравнению с Thumb режимом. Пока что, при компиляции в ARM у меня система перестаёт работать - запускается нормально, но при попытке объявить (или запустить, ещё не разобрался) какую-либо задачу (использую FreeRTOS) - виснет. Соответсвенно вопрос - стоит ли этим баловаться (в смысле компиляцией в ARM) и в чём может быть проблема, что у меня подвисает система (может я не учёл что-либо общеизвестное)?

FreeRTOS не лучшая ОСь для повышения скорости. Если с lwIP более-менее разобрались, почему бы не выбрать что-нить (OS) побыстрее и посеръезнее? Попробуйте перевести проект на ucOS-II. Наверняка получите еще несколько десятков попугаев, а возможно и исчезнут проблемы при компиляции в ARM-режиме, хотя как уже сказали выше, толку не будет из за пакетов-венегретов

Сообщение отредактировал prottoss - May 4 2008, 13:04

[zltigo]

FreeRTOS не лучшая ОСь для повышения скорости.

Глупость какая

почему бы не выбрать что-нить (OS) побыстрее и посеръезнее?
Попробуйте перевести проект на ucOS-II.

uCOS-II одна из самых простых и "несерьезных" осей. За счет экстремально примитивного шедулера потециально чуть быстее перепланирует задачи при их малом количестве. Это очень далеко от способностей "ускорить" IP стек.

а возможно и исчезнут проблемы при компиляции в ARM-режиме...

И еще шерсть возможно станет мягкой и щелковистой . Ну нет проблем с ARM режимом. Совсем нет.

По объему кода?

По быстродействию, естественно. На объемы кода в подавляющем большинстве случаеев наплевать. Да и по обьему не обещанные 30% а около 15.

[prottoss]

Мне следовало добавить ИМХО . Так как останусь при своем мнении не смотря на глупости.