Как повысить скорость работы по сети 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.
Ссылка.

[zltigo]

Не надо уходить от memcpy!

Обойти можно только наложив дополнительные ограничения, например ввиде обязательной выровненности даннных.... А так сложно.. memcpy() не вовсех либах хороши у 4 IAR - отвратительные, а в 5 резко улучшили, даже отдельно хвастались, что дескать самый быстрый стал..
При испытаниях действительно в некоторых условиях превосходил ранее мной используемый для старых IAR:

CODE

NAME memcpy

RSEG CSTACK:DATA:NOROOT(2)

MULTWEAK ??memcpy??rT
MULTWEAK ??memmove??rT
PUBLIC memcpy
PUBLIC memmove

memcpy SYMBOL "memcpy"
??memcpy??rT SYMBOL "??rT", memcpy

memmove SYMBOL "memmove"
??memmove??rT SYMBOL "??rT", memmove


RSEG CODE:CODE:NOROOT(2)
THUMB
??memcpy??rT:
BX PC
Nop
REQUIRE memcpy


RSEG CODE:CODE:NOROOT(2)
ARM

#ifndef configUSE_MEMCPY8W
#define WORDS8_TRANSFER 0
#else
#if configUSE_MEMCPY8W == 1
#define WORDS8_TRANSFER 1
#else
#define WORDS8_TRANSFER 0
#endif
#endif

//---------------------------------------------------------------------------
// void *(memcpy)(void *p1, const void *p2, size_t n)
// Copy char p2[n] to p1[n]
//---------------------------------------------------------------------------
memcpy:
teq r2,#0 // Is p1 == 0 ?
bxeq lr // If p1 == 0, return

stmdb sp!,{lr} // Push return address
mov r12,r0 // Copy pointer p1
cmp r2,#8 // Is buffer long or short?
ble byteserial // Jump if n <= 8

sub r3,r0,r1 // Compare pointers p1, p2
tst r3,#3 // Strings aligned same?
bne byteserial // Jump if buffers not aligned


// Both strings are similarly aligned WRT word boundaries.
// At least a portion of the data can be copied an entire
// word at a time, which is faster than copying bytes.
wordserial:
ands r3,r0,#3 // Check byte alignment
beq wordaligned // Jump if p1, p2 word-aligned

rsb r3,r3,#4 // m = no. of odd initial bytes
sub r2,r2,r3 // n = n - m


// If the two buffers do not begin on word boundaries, begin
// by copying the odd bytes that precede the first full word.
preloop:
ldrb lr,[r1],#1 // Read byte from source
subs r3,r3,#1 // --m (decrement loop count)
strb lr,[r12],#1 // Write byte to destination
bne preloop // Loop if more bytes to move


wordaligned:
#if WORDS8_TRANSFER == 1
movs r3,r2,asr #5 // Any chunks of 8 words?
beq octsdone // Jump if no 8-word chunks

and r2,r2,#0x1F // Subtract chunks from n
stmdb sp!,{r4-r10} // Save registers on stack


// The strings are long enough that we can transfer at least
// some portion of the data in 8-word chunks.
octloop:
ldmia r1!,{r4-r10,lr} // Load 8 words from source
subs r3,r3,#1 // More 8-word chunks to move?
stmia r12!,{r4-r10,lr} // Write 8 words to destination
bne octloop // Loop if more chunks

ldmia sp!,{r4-r10} // Restore registers from stack

octsdone:
#endif
movs r3,r2,asr #2 // Any more whole words to move?
beq wordsdone // Jump if no more whole words


// Copy as much of the remaining data as possible one word at
// a time.
wordloop2:
ldr lr,[r1],#4 // Read next word from source
subs r3,r3,#1 // Decrement word count
str lr,[r12],#4 // Write next word to destination
bne wordloop2 // Loop while more words to move

wordsdone:
ands r2,r2,#3 // Any last bytes to transfer?
beq theend // Return if already done


// The two strings do not end on word boundaries.
// Copy the remaining data one byte at a time.
byteserial:
ldrb lr,[r1],#1 // Read byte from source
subs r2,r2,#1 // --n (decrement loop count)
strb lr,[r12],#1 // Write byte to destination
bne byteserial // Loop if more bytes to move

theend:
ldmia sp!,{lr} // Return
bx lr

//---------------------------------------------------------------------------
RSEG CODE:CODE:NOROOT(2)
THUMB
??memmove??rT:
BX PC
Nop
REQUIRE memmove


RSEG CODE:CODE:NOROOT(2)
ARM

//---------------------------------------------------------------------------
// Safely copy c bytes from source s to destination d.
// void *memmove(void *d, const void *s, unsigned c);
//---------------------------------------------------------------------------
memmove:
cmp r0,r1 // Is d > s ?
bls memcpy // Jump to memcpy if d <= s

// Need to copy backwards, starting at tail ends of source and
// destination arrays. Copy a word or a byte at a time?
orr r3,r1,r0 // tmp = s | d
orr r3,r3,r2 // tmp = s | d | c
ands r3,r3,#3 // Is tmp even multiple of 4?

add r1,r1,r2 // s + c (end of source buffer)
add r2,r2,r0 // d + c (end of dest'n buffer)
beq move1 // Jump if tmp is multiple of 4
b move2

// Because the source and destination arrays are not aligned to even
// word boundaries in memory, transfer only a byte at a time.
move3:
ldrb r3,[r1,#-1]! // Load next byte from source
strb r3,[r2,#-1]! // Store next byte to dest'n
move2:
teq r0,r2 // More bytes to move?
bne move3 // Jump if more bytes
bx lr // All done

// Because count c is an even multiple of 4 and the source
// and destination arrays begin on even word boundaries, move
// an entire word at a time from source to destination.
move4:
ldr r3,[r1,#-4]! // Load next word from source
str r3,[r2,#-4]! // Store next word to dest'n
move1:
teq r0,r2 // More words to move?
bne move4 // Jump if more words

bx lr // All done

END

А 'уходить' по любому надо, но максимально исключая пересылки память-память в пинципе

Но для SAM7 это не так. Надо помнить что слабое место у SAM7 это флеш. В ARM режиме размер кода увеличивается в среднем на 30%, а это значит как минимум на 30% больше обращений к медленной флеш. Плюс в SAM7 применена технология ускоренной выборки для Thumb режима (по две Thumb инструкции за одно обращение к флеш). Т.е. при размещении программы во флеш Thumb режим заведомо в выигрыше.

1. К счатью на SAM7 свет клином не сошелся .
2. Все не так радужно и с Thumb - на моих реальных программах много использующих 32-битовость увеличение размера кода МНОГО меньше, а количество команд которые по любому надо исполнять ЗАМЕТНО больше. Практически вышесказанное Вами в большей степени относится к коду написанному в "восьмибитном" стиле с обильным использованием 8-бит переменных, что изрядно душит ARM (в обоих режимах). Для изначально "правильных" программ Thumb у меня ПРОИГРАЛ. Правда на SAM7 не гонял, а на LPC там, конечно, MAM описанный Вами эффект дополнительно сглаживает, но не слишком, ибо частота повыше а Flash потормознее.