Как повысить скорость работы по сети 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 можно убрать лишнюю обработку?

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

[_dem]

2 мегабита или 2 мегабайта ?

[Gemm]

...
Сейчас у меня скорость передачи данных приблизительно 2Мб/с по 100 мегабитной сети.
...

Сначала тоже юзали uIP, скорость была еще ниже. Потом подняли lwIP стек, включили все кеши (АТ91RM9200) - сейчас 64 Мбита, больше - никак

[OlegHmt]

2 мегабита или 2 мегабайта ?

Мегабита, ну может там до 3 Мегабит

В принципе вопрос этого плана я когда-то поднимал и был ряд ответов, но тогда эта часть проекта была отложена, поэтому ничего не исправлялось. К этому моменту я уже немного позабыл, что там делалось и теперь со свежым взглядом на сетевую часть проекта пробую её улучшить

Сначала тоже юзали uIP, скорость была еще ниже. Потом подняли lwIP стек, включили все кеши (АТ91RM9200) - сейчас 64 Мбита, больше - никак

Процесор немного не тот, но, в принципе, в этом что-то есть. Все таки uIP это восьмибитный, а lwIP - 32-х битный, но пока что стек менять очень не хочется, да ест lwIP больше памяти, а с этим напряжёнка

[chds]

А транспорт UDP или TCP?
Мы юзали uCOS у нас с подправленным стеком на UDP получалась скорость порядка 900кбайт/с проц на 48 МГц, делал похожую задачу, собирал данные с АЦП и пихал их в сетку. За счет TCP стека скорость падала вдвое. Все работало через PDU. С АЦП данные пихались прямо в выходной буфер, а оттуда при наборе нужного количества выпихивались в Ethernet. Мониторинг загрузки проца показывал 98%, из чего можно сделать заключение, что добавление хоть каких то дополнительных задач привело бы к уменьшению пропускной способности. Причем зависимость экспоненциальная, добавили моргание светодиодом и обработчик внешнего прерывания и скорость упала до 400килобайт/с.

[OlegHmt]

А транспорт UDP или TCP?
Мы юзали uCOS у нас с подправленным стеком на UDP получалась скорость порядка 900кбайт/с проц на 48 МГц, делал похожую задачу, собирал данные с АЦП и пихал их в сетку. За счет TCP стека скорость падала вдвое. Все работало через PDU. С АЦП данные пихались прямо в выходной буфер, а оттуда при наборе нужного количества выпихивались в Ethernet. Мониторинг загрузки проца показывал 98%, из чего можно сделать заключение, что добавление хоть каких то дополнительных задач привело бы к уменьшению пропускной способности. Причем зависимость экспоненциальная, добавили моргание светодиодом и обработчик внешнего прерывания и скорость упала до 400килобайт/с.

TCP
У меня там и моргание, и паралельные задачи, и обработка прерываний по таймеру где-то под 30кГц

[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.

[_dem]

Какую скорость требуется получить ?

на uip много не вытяните, нужно lwIp или ucTCP/IP.

[OlegHmt]

Какую скорость требуется получить ?

на uip много не вытяните, нужно lwIp или ucTCP/IP.

думаю раза в 2 подойдёт (5-6Мбит/с). Попробую выбросить копирование данных и сделаю всё на обмене указателями, а дальше будет видно по результатам

[OlegHmt]

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

Сообщение отредактировал OlegHmt - May 3 2008, 20:31

[defunct]

А пока такой вопрос - прошивка у меня компилируется в Thumb виде, согласно документации - использование ARM команд повышает быстродействие по сравнению с Thumb режимом.

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

Кроме того при прочих равных (если код выполнять из RAM), для IP стека ARM режим практически не даст никакого выигрыша, возможно даже проиграет, из-за big-endian формата данных в пакетах и множества byte и half-word полей.

В ARM режиме резонно написать некоторые особо критические функции, и разместить их в RAM. Но надо смотреть каждую конкретную функцию, т.к. например функция копирования приведенная выше и в ARM режиме и в Thumb компилуруется в 16 инструкций. Листинги привожу ниже:

ARM mode

Код

   258: static void memcpy_burst( U32 *pDest, U32 *pSrc, U32 size )
   259: {
0x00001EC0  E92D0010  STMDB     R13!,{R4}
0x00001EC4  E1A03002  MOV       R3,R2
   260:     U32  wCnt = (size + 3) >> 2; // words count to be copied
0x00001EC8  E1A02003  MOV       R2,R3
0x00001ECC  E2822003  ADD       R2,R2,#0x00000003
0x00001ED0  E1A02122  MOV       R2,R2,LSR #2
   261:     do
   262:     {
   263:         *pDest++ = *pSrc++;
0x00001ED4  E1A03001  MOV       R3,R1
0x00001ED8  E2831004  ADD       R1,R3,#0x00000004
0x00001EDC  E5934000  LDR       R4,[R3]
0x00001EE0  E1A03000  MOV       R3,R0
0x00001EE4  E2830004  ADD       R0,R3,#0x00000004
0x00001EE8  E5834000  STR       R4,[R3]
   264:     } while (--wCnt);
0x00001EEC  E1A03002  MOV       R3,R2
0x00001EF0  E2433001  SUB       R3,R3,#0x00000001
0x00001EF4  E1A02003  MOV       R2,R3
0x00001EF8  E3530000  CMP       R3,#0x00000000
0x00001EFC  1AFFFFF4  BNE       0x00001ED4
   265: }

Thumb mode

Код

   258: static void memcpy_burst( U32 *pDest, U32 *pSrc, U32 size )
   259: {
0x00001EC0  B410      PUSH      {R4}
0x00001EC2  1C13      ADD       R3,R2,#0
   260:     U32  wCnt = (size + 3) >> 2; // words count to be copied
0x00001EC4  1C1A      ADD       R2,R3,#0
0x00001EC6  3203      ADD       R2,#0x03
0x00001EC8  0892      LSR       R2,R2,#2
   261:     do
   262:     {
   263:         *pDest++ = *pSrc++;
0x00001ECA  1C0B      ADD       R3,R1,#0
0x00001ECC  3104      ADD       R1,#0x04
0x00001ECE  681C      LDR       R4,[R3,#0x00]
0x00001ED0  1C03      ADD       R3,R0,#0
0x00001ED2  3004      ADD       R0,#0x04
0x00001ED4  601C      STR       R4,[R3,#0x00]
   264:     } while (--wCnt);
0x00001ED6  1C13      ADD       R3,R2,#0
0x00001ED8  3B01      SUB       R3,#0x01
0x00001EDA  1C1A      ADD       R2,R3,#0
0x00001EDC  2B00      CMP       R3,#0x00
0x00001EDE  D1F4      BNE       0x00001ECA
   265: }

[OlegHmt]

Понятно, тогда вопрос со стороны lwIP - можно ли использовать для моей задачи пример использования стека из FreeRTOS? Первоначальное знакомство с примером показало, что в нём используются очереди, а в предыдущей версии ОС, когда я разбирался с обменом данными по USB, используя пример из FreeRTOS, то как раз очереди очень сильно тормозили обмен. И только когда я заменил их на обычные масивы - тогда смог выйти на расчётные скорости обмена данными.

[defunct]

Первоначальное знакомство с примером показало, что в нём используются очереди,

А чем очередь принципиально отличается от массива?
Это же массив указателей и пара индексов put/get.
В любом случае Вы вольны написать свои обёртки очередей.

[OlegHmt]

А чем очередь принципиально отличается от массива?
Это же массив указателей и пара индексов put/get.
В любом случае Вы вольны написать свои обёртки очередей.

Насколько я смог разобраться когда-то и вспомнить сейчас, во FreeRTOS, работа с очередями организована через усыпление всех активных задач, что, соответственно, сказывалось на быстродействии системы. Поэтому пришлось переделывать. Сейчас посмотрю что изменилось в новой версии операционки и как это всё сделано в интересующем меня примере.

[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 потормознее.

[Rst7]

В ARM режиме резонно написать некоторые особо критические функции, и разместить их в RAM. Но надо смотреть каждую конкретную функцию, т.к. например функция копирования приведенная выше и в ARM режиме и в Thumb компилуруется в 16 инструкций. Листинги привожу ниже:
...

Вы уж простите, что лезу, но вменяемые компиляторы делают совсем другой код:

Код

    623          __arm void memcpy_burst( U32 *pDest, U32 *pSrc, U32 size )
    624          {
    625            U32  wCnt = (size + 3) >> 2; // words count to be copied
   \                     memcpy_burst:
   \   00000000   032082E2           ADD      R2,R2,#+3
   \   00000004   2221A0E1           LSR      R2,R2,#+2
    626            do
    627            {
    628              *pDest++ = *pSrc++;
   \                     ??memcpy_burst_0:
   \   00000008   ........           LDR      R3,[R1], #+4
   \   0000000C   ........           STR      R3,[R0], #+4
    629            } while (--wCnt);
   \   00000010   012052E2           SUBS     R2,R2,#+1
   \   00000014   FBFFFF1A           BNE      ??memcpy_burst_0
    630          }
   \   00000018   0EF0A0E1           MOV      PC,LR           ;; return

Код

    623          __thumb void memcpy_burst( U32 *pDest, U32 *pSrc, U32 size )
    624          {
    625            U32  wCnt = (size + 3) >> 2; // words count to be copied
   \                     memcpy_burst:
   \   00000000   D21C               ADDS     R2,R2,#+3
   \   00000002   9208               LSRS     R2,R2,#+2
    626            do
    627            {
    628              *pDest++ = *pSrc++;
   \                     ??memcpy_burst_0:
   \   00000004   0B68               LDR      R3,[R1, #+0]
   \   00000006   0360               STR      R3,[R0, #+0]
   \   00000008   091D               ADDS     R1,R1,#+4
   \   0000000A   001D               ADDS     R0,R0,#+4
    629            } while (--wCnt);
   \   0000000C   521E               SUBS     R2,R2,#+1
   \   0000000E   F9D1               BNE      ??memcpy_burst_0
    630          }
   \   00000010   7047               BX       LR

А вообще-то, правильный memcpy должен работать в ARM и использовать STM/LDM (для больших кусков, для маленьких - развернутое копирование с переходом в нужное место) - тогда будет максимальное быстродействие, конечно, для выровненных данных, без этого - никуда.

Кроме того при прочих равных (если код выполнять из RAM), для IP стека ARM режим практически не даст никакого выигрыша, возможно даже проиграет, из-за big-endian формата данных в пакетах и множества byte и half-word полей.

Тут надо смотреть, чтобы хватало регистров. Если в тумбе не помещается в 8 регистров, то код резко ухудшается (и по размеру, и по быстродействию).
По поводу big-endian - тоже не согласен, переворот байт в арм-режиме занимает меньше, чем в тумбе.

[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

[defunct]

Вы уж простите, что лезу, но вменяемые компиляторы делают совсем другой код:

Да дело не во вменяемости. Компилил вменяемым RVCT.
Единственное забыл включить оптимизацию.

Но даже если взять оптимизированный код приведенный вами, то в ARM получается 4 слова в ключевом цикле, в Thumb - 3. Так что все равно надо смотреть, что будет выполняться быстрее на SAM7 при размещении во флеш.

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

Не важно на чем они писаны.
Стандартные библиотеки поддерживают стандарт, стандартная memcpy просто обязана делать проверки на выровненность данных и не выходить за границы копируемого участка, чтобы ничего лишнего не перетирать. Надо ли отметить, что опустив эти проверки, получается дополнительный выигрыш в скорости?

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

Тут все по-своему правы. Уходить надо, там где важна скорость. В этой ветке скорость важна, значит уходить надо.
Если важна универсальность, чистота и прогнозируемость кода, а на скорость можно забить, тогда можно и не уходить.

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

Есть места где от копирования не уйти. Если DMA не умеет самостоятельно склеивать списки в пакет, то "memcpy" как минимум понадобится для копирования ethernet/ip header'a в каждый пакет.

Для изначально "правильных" программ Thumb у меня ПРОИГРАЛ.

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

[prottoss]

Есть места где от копирования не уйти. Если DMA не умеет самостоятельно склеивать списки в пакет, то "memcpy" как минимум понадобится для копирования ethernet/ip header'a в каждый пакет.

Я же привел выше основную структуру данных... Пример: Нужно отправить TCP пакет = hEthernet+hIP+hTCP+DATA. Выделем у менеджера памяти минимум 4 блока (или больше в зависимости от размера блока DATA). У каждого блока есть DATALIST. Заполняем каждый блок свои хедером ну и пристегиваем данные. Адрес первого DATALIST (+ пристегнутые к нему остальные листы) отдаем драйверу EMAC. Драйвер после отправки пакета возвращает блоки опять в пулл памяти. И никккакого memcpy - тока обмен указателями

Вернее под DATA блоки вообще не выделяются - их транспорту отдает приложение, а он просто цепляет эти блоки в конец состава. Т.е разгрузки-погрузки вагонов не происходит

[defunct]

Я же привел выше основную структуру данных... Пример: Нужно отправить TCP пакет = hEthernet+hIP+hTCP+DATA. Выделем у менеджера памяти минимум 4 блока (или больше в зависимости от размера блока DATA). У каждого блока есть DATALIST. Заполняем каждый блок свои хедером ну и пристегиваем данные. Адрес первого DATALIST (+ пристегнутые к нему остальные листы) отдаем драйверу EMAC. Драйвер после отправки пакета возвращает блоки опять в пулл памяти. И никккакого memcpy - тока обмен указателями

Ну как же нет. Ключевая фраза у Вас - "заполняем каждый блок своим хидером". Как заполняем? быстрее и логичнее всего - скопировать заранее подготовленный шаблон. Стало быть полностью от копирования не ушли.

На более мощных процах (ARM9) EMAC DMA позволяет склеивать пакеты. Выделяется один блок требуемой длины под header, единожды заполняется (при старте TCP сессии). А дальше можно передавать DMA для каждого пакета этой сессии список состоящий из двух элементов, первый элемент - всегда указатель на один и тот же блок header, второй - на данные. Память с блоком содержищим Eth/IP header не будет освобождаться, и не будет нужды постоянно запонять Eth/IP.

[prottoss]

Ну как же нет. Ключевая фраза у Вас - "заполняем каждый блок своим хидером". Как заполняем? быстрее и логичнее всего - скопировать заранее подготовленный шаблон. Стало быть от копирования нельзя уйти.

Хедер TCP я заполняю примерно так:

Код

/* Fill IP header */
hIP.vihl = socket->vihl;
hIP.tos = socket->tos;
hIP.tlen = SWAP16(sizeof(IP_HEADER) +  sizeof(TCP_HEADER) + data_len);
hIP.id = IP_GetNextPacketID();
hIP.frags = 0;
hIP.ttl  = socket->ttl; /* ttl */
hIP.protocol  = IP_TCP; /* packet protocol */
hIP.src_ip = HOST_IP(); /* My IP */
hIP.dest_ip = arp_entry->ip; /* Dest IP */

/* Make checksum */
hIP.checksum  = 0;  
hIP.checksum  = (UINT16)~IP_MakeChecksum(0, &hIP, sizeof(IP_HEADER));

Код

/* Fill TCP header */
hTCP.src_port  = socket->src_port;
hTCP.dest_port = socket->dest_port;
hTCP.seqno = SWAP32(socket->send_unacked);
hTCP.ackno = SWAP32(socket->receive_next);
hTCP.hlen = (sizeof(TCP_HEADER) << 2) & 0xfc;
hTCP.window = SWAP16(socket->window);
hTCP.urgent = 0;
if(flags) /* If flags are sets, we update them, differently we leave old */
hTCP.flags = flags;
hTCP.checksum = TCP_MakeChecksum(&hIP, &hTCP, data);

hIP и hTCP - соответсвенно блоки прамяти для IP и TCP заголовка, и мне не понятно, с какого шаблона я их сформирую:-)

Ну и, думаю, что БЫСТРЕЕ и логичнее заполнить именно так

[defunct]

hIP и hTCP - соответсвенно блоки прамяти для IP и TCP заголовка,

Ок, как часто у вас поменяется Ethernet header и сколько полей IP заголовка в пределах сессии?
То, что не меняется - и будет шаблоном.

и мне не понятно, с какого шаблона я их сформирую:-)

Ну например в структуре "socket" резервируете 14 + 20 байт +2 байта GAP. единожды заполняете Eth/IP header - это будет шаблон.
далее выделяете блок для Eth/IP, копируете туда шаблон спец функцией расчитаной на быстрое копирование выровненных блоков длиной 9 слов. Меняете поле Len и пересчитываете CS.
Уже будет гораздо быстрее чем заполнение для каждого пакета.

[aaarrr]

Надо ли отметить, что опустив эти проверки, получается дополнительный выигрыш в скорости?

Оверхед от проверок минимальный, если, конечно, копируются не блоки по 8 байт.

Тут все по-своему правы. Уходить надо, там где важна скорость. В этой ветке скорость важна, значит уходить надо.
Если важна универсальность, чистота и прогнозируемость кода, а на скорость можно забить, тогда можно и не уходить.

ИМХО, если уходить значит вообще не копировать, тогда конечно. Но уделать по скорости копирования нормальную memcpy очень трудно.

[prottoss]

Ок, как часто у вас поменяется Ethernet header и сколько полей IP заголовка в пределах сессии?
То, что не меняется - и будет шаблоном.

То что Вы называете шаблоном для Ethernet header я называю ARP-cashe С него и формируется Ethernet header. Но опять же 14 байт я копирую без memcpy а копированием 3-х 32-бит чисел (dest & source hardware address) и одного 16-бит (protocol)

[Rst7]

расчитаной на быстрое копирование выровненных блоков длиной 9 слов.

Мне кажется, это мизер по сравнению с переносом при помощи memcpy из буфера в буфер собственно полезных данных, которых в каждом пакете под 1.5килобайта, если рекой льется

Вот где надо копать.

[defunct]

Но опять же 14 байт я копирую без memcpy а копированием 3-х 32-бит чисел (dest & source hardware address) и одного 16-бит (protocol)

Под memcpy в последних двух постах я подразумевал "копирование", а не библиотечную функцию.
всевозможные ускоренные копирования, это подразновидности memcpy. ;>

Мне кажется, это мизер по сравнению с переносом при помощи memcpy из буфера в буфер собственно полезных данных, которых в каждом пакете под 1.5килобайта, если рекой льется

Трафик он разный бывает. Может рекой литься и что-то мультимедийное, а там пакеты короткие и их много.

[prottoss]

Под memcpy в последних двух постах я подразумевал "копирование", а не библиотечную функцию.
всевозможные ускоренные копирования, это подразновидности memcpy. ;>

Ну в таком случае по вашему копирование двух указателей на данные а не самих данных тожде memcpy?

Я говорю не про не про Ethernet заголовок, который можно копировать и с помощью memcpy - ради бога (+- один попугай), а про то что ссказал Rst7 постом выше - про реку данных (или даже пакетов по 60 байт - их две реки в приличной сети), которые приходится постоянно копировать.

[defunct]

Я говорю не про не про Ethernet заголовок, который можно копировать и с помощью memcpy - ради бога (+- один попугай), а про то что ссказал Rst7 постом выше - про реку данных (или даже пакетов по 60 байт - их две реки в приличной сети), которые приходится постоянно копировать.

Ну дык на 60-ти байтных пакетах +/- попугай ой как видно.
На коротких пакетах уже и неактуально манипулировать четырьмя блоками, быстрее скопировать и передать одним.

Ну в таком случае по вашему копирование двух указателей на данные а не самих данных тожде memcpy?

Нет, я рассматривыаю только копирование частей тела пакета.
Указатели это другой вопрос, который упирается в другую проблему - чем больше блоков и чем короче блоки тем неэффективнее используется DMA. (на кадый пересылаемый блок DMA 4 раза должен обратиться к дескриптору, если блоки сравнимы по длине с дескриптором * 2, то эффективность сильно упадет).

[Rst7]

Ну дык на 60-ти байтных пакетах +/- попугай ой как видно.

Так. Стоп. Топикстартер говорил о том, что он льет по 1.5кб. Вот там и надо лишние memcpy убирать.

[prottoss]

Ну дык на 60-ти байтных пакетах +/- попугай ой как видно.На коротких пакетах уже и неактуально манипулировать четырьмя блоками, быстрее скопировать и передать одним.

Спорный вопрос. К тому же тема именно про большие объемы данных между приложениями, а не про скорость обмена ARP, DNS, BOOTP и прочими пакетами. Здесь как раз актуально то, что EMAC эти данные уже поместил в память, и у нас есть выбор - отдать данные приложению через memcpy, или как список указателей на блоки данных.

Во втором случае программа получается намного сложнее и объемнее по коду, но и скорость доставки данных приложению намного выше.

[blackfin]

Может рекой литься и что-то мультимедийное, а там пакеты короткие и их много.

Это с какого перепугу такое заявление? В стандарте RTP ничто не запрещает использовать для передачи мультимедиа длинные пакеты..

[defunct]

Это с какого перепугу такое заявление? В стандарте RTP ничто не запрещает использовать для передачи мультимедиа длинные пакеты..

А с чем вы несогласны с заявлением? В подавляющем большинстве аудио потоков, пакеты не превышают 100 байт.

[prottoss]

Указатели это другой вопрос, который упирается в другую проблему - чем больше блоков и чем короче блоки тем неэффективнее используется DMA. (на кадый пересылаемый блок DMA 4 раза должен обратиться к дескриптору, если блоки сравнимы по длине с дескриптором * 2, то эффективность сильно упадет).

Длина блоков, применительно к SAM7X уже выбрана - 128 байт для принимаемых пакетов - на мой взгляд оптимальна. Кстати, как раз удобно парсить заголовок пакета

[defunct]

prottoss
можете привести реальные цифры?
Сколько у вас получилось прокачать трафика через SAM7 списковым способом?
(для трафика 1.5k/пакет и для, скажем 200 байт/пакет).

[zltigo]

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

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

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

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

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

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

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

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

[blackfin]

А с чем вы несогласны с заявлением? В подавляющем большинстве аудио потоков, пакеты не превышают 100 байт.

Если пакеты маленькие, - их не много. Общий траффик для звука вряд ли больше 64 килобит/сек (G.711). Для G729 бит рейт не больше 11.8 килобит/сек, а для G.723 - он вообще меньше 6.3 килобит/сек. Можно предположить, это не те потоки, для которых нужно "повышать скорость работы по сети". Накладные расходы при передачи мультимедиа - заголовок UDP достаточно небольшой, - 8 байт, так что различие между двумя пакетами по 100 байт + два заголовка и между одним пакетом 200 байт + один заголовок невелико - 4%. Кроме того, RTP позволяет передавать внутри одного UDP-пакета несколько пакетов RTP, так что можно сэкономить и здесь. Ну и, наконец, мультимедиа - это не только "звук", но и "видео", а здесь пакеты отнюдь не маленькие... Вот с этим "всем" я и не согласен..

[Rst7]

Длина блоков, применительно к SAM7X уже выбрана - 128 байт для принимаемых пакетов - на мой взгляд оптимальна. Кстати, как раз удобно парсить заголовок пакета

Подождите радоваться. Вот понадобится поднять IPv6, сразу окажется, что весьма погано лезет в 128.

Добавлено позже: это я погорячился. IPv6 еще помещается в 128 байт, но если добавится какой-нибудь дополнительный подзаголовок, возможность которого оговаривает IPv6, то может оказаться, что не влезет.

[prottoss]

prottoss
можете привести реальные цифры?
Сколько у вас получилось прокачать трафика через SAM7 списковым способом?
(для трафика 1.5k/пакет и для, скажем 200 байт/пакет).

К сожалению пока не могу - я не измерял У меня не было такой задачи, чтоб выжать из стека все до микросекунды/байта на уровне приложения. Я просто изложил автору топика свои мысли по поводу организации обмена данными EMAC driver <---> TCPIP <---> Application для повышения скорости доставки данных.

[zltigo]

Если пакеты маленькие, - их не много. Общий траффик для звука вряд ли больше 64 килобит/сек (G.711).

Ага, только их может быть много, например, 30 потоков. Что в общем-то в сумме тоже немного - менее 2 мегабит, но формирование заголовеов начинает напрягать. А еще прием еще 30...

[prottoss]

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

[blackfin]

Ага, только их может быть много, например, 30 потоков. Что в общем-то в сумме тоже немного - менее 2 мегабит, но формирование заголовеов начинает напрягать. А еще прием еще 30...

Начинает напрягать?
Ставьте BF537-600..

[zltigo]

Ставьте BF537-600..

Будет напрягать его BGA и многослойка. С этим вообще справляется и трехсотмегагерцовый BF531..3, если-бы не отсутствие втроенного контроллера. На FPGA приличный тоже в принципе ляжет. Ну поскольку вещь не крупносерийная, то универсальную железку LPC2378+FPGA тоже натянется

Так как останусь при своем мнении...

Да бога ради!

[blackfin]

Будет напрягать его BGA и многослойка.

Меня не напрягает.. Мне нравится и BGA и многослойки..

С этим вообще справляется и трехсотмегагерцовый BF531..3,...

Да бога ради!

Ну поскольку вещь не крупносерийная, то универсальную железку LPC2378+FPGA тоже натянется

Да бога ради!
Но BF537 минус FPGA может оказаться дешевле..

[zltigo]

Меня не напрягает.. Мне нравится и BGA и многослойки..

Да мне они не нравятся - я их просто ОБОЖАЮ! Только вот есть условия производства у заказчика, да и перечень используемых чипов расширять КРАЙНЕ не желательно - специфика .

Но BF537 минус FPGA может оказаться дешевле..

Совсем минус не получится, например, коммутатор из BF не сделаешь - запаришся, да и SPORT-ов маловато. Памяти своей у него тоже маловато + загрузка - в общем обвеска набежит + стоимость многослойки....

[defunct]

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

Ну дык для SAM7 не наплевать.

К сожалению пока не могу - я не измерял У меня не было такой задачи, чтоб выжать из стека все до микросекунды/байта на уровне приложения.

Мне было бы очень интересно посмотреть.
Т.к. мой драйвер основан на копировании и использует блоки не по 128, а в макс размер пакета. C RX стороны идет сбор и копирование пакета, на TX стороне - копирования нет, правится TX дескриптор и отправляется блок длиной в пакет. Почему так - потому что проще формировать. Цифры у меня получились такие (PHY в дуплексе):

214 байт/пакет:
с нулевым процентом потерянных пакетов -
8.2kpps прием и одновременно 16.4kpps передача.
с 10% потерь -
14.5kpps прием и одновременно 22kpps передача.

(kpps - K packets per sec)

1536 байт/пакет соответвенно
0% drop - 3.3k / 5.6k
10% - 4.6k / 5.6k

PS: Тест производился в IP forwarding режиме. Последний отправленный пакет дублировался до тех пор пока не придет новый пакет с RX стороны (поэтому TX трафик больше).

[AlexandrY]

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.
Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.
Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.
RTOS-ы .. OS-ы на таких скоростях только мешают.

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

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

[OlegHmt]

Ну и темку же я поднял

Поделюсь результатами которые я успел получить. Разбирался, немного, с IwIP по примеру из FreeRTOS, тут пока, что грустно - стек хочет больше килобайт на 10-15 чем в примере с uIP, а я могу максимум 2кБ выделить. Сильно глубоко в дебри стека я пока не забрался, так что возможно в будущем что-то и выплывет.
Зато в моём коде начал играться с компиляцией отдельных файлов в ARM или Thumb. Так вот, когда-то я поставил весь стек (uIP) в ARM, а теперь, когда изменил на Thumb, у меня скорость передачи моих данных по сети возросла на треть.
Ещё сегодня попробую забрать копирование с буферов EMAC в буфер стека, а поставлю просто обмен указателями, тоже что-то подростёт, а дальше буду пробовать в стеке выбрасывать лишние вещи. На счёт обмена указателями, я думаю сделать так: как только пришёл пакет в EMAC буфера, все их пометить как использованые, поменять местами указатели и тогда обрабатывать данные, что-бы не нужно было делать менеджер памяти с переходом между отдельными 128 байтными кусками. Посмотрим, что выйдет

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.
Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.
Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.
RTOS-ы .. OS-ы на таких скоростях только мешают.

В данном проекте изменить процесор уже нельзя, да и без оси писать будет тяжело - много дополнительных задач, которые работают паралельно

[zltigo]

RTOS-ы .. OS-ы на таких скоростях только мешают.

А если вдувать в Ethernet пакеты со всей дури это не есть единственное предназначение устройства?

[AlexandrY]

Я ж не предлагаю отказаться от оси. Это ж святое!
В серьезных RTOS-ах есть фича как Raw IP и Zero Copy Interface
Но тут обсуждаются как бы возможности по интеграции отдельного недоразвитого пакета.
В принципе человек и пошел по пути сильной модернизации uIP и скорее всего придет к отказу от сервисов стека и RTOS чтобы увеличить скорость.
Применение uIP уже говорит, что дивайс явно не смартфоном будет, просто достался он вместе с RTOS
Пересылка этих пакетов в дивайсе чуть не единственная фича как можно понять.
Ближе к границе 90 Mbit, хорошая архитектура проца является очень важным моментом.

А если вдувать в Ethernet пакеты со всей дури это не есть единственное предназначение устройства?

[Rst7]

Возьмите процы от Freescale, в них IP-core Ethernet-а такой, что дескрипторы буферов приема могут быть настроены под любую длину фрагментов входных пакетов.Соответственно хидеры можете в одно место принимать, а данные сразу в точку назначения.Причем можно вызвать прерывание сразу по окончании хидера и таким образом фильтровать пакеты так чтобы целевой трафик не попадал в RTOS.

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

[AlexandrY]

Не забывают, а не договаривают. Ну не всеж сразу всем рассказывать.
Ладно, расскажу вам секрет.
Есть такой тэг VLAN, в MAC хидере. Используя его можно много чего придумать.

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

[Rst7]

Есть такой тэг VLAN, в MAC хидере. Используя его можно много чего придумать.

Не совсем понятно, что же можно придумать с этим тегом на приемном конце? Тег-то приходит из сети, и есть он или нет - еще неизвестно (обычно, в конечном устройстве его надо просто стрипнуть). А я о том, что и в IP-заголовке, и в TCP-заголовке возможны дополнительные опции - например, при открытии сессии очень все любят сунуть опцию MTU. Хотя, с другой стороны, при передаче собственно данных обычно дополнительные заголовки не встречаются (нефиг оверхед гонять, и это правильно), но закладываться на это - себе дороже.

Хотя, конечно, это мои размышлизмы, может в мотороловской реализации мака уже и подумали за нас. Дайте, чтоли, ссылочку на даташит, почитаем, проникнемся

[AlexandrY]

Вообще-то я просто прикалывался, но была одна мелкая идея.
Вот цифровое телевидение например юзает тег VLAN
Если в хидере обнаруживается заданный тэг то все такие пакеты уводятся роутером совсем в другие буферы и на другие порты.
Freescale удобны тем что, что там можно организовать прерывание сразу по приему MAC хидера, определить че за VLAN и быстенько сконфигурить адрес для приемника пакета данных которые будут еще через байт 28 (2.24 мкс) в лучшем случае.
Описание FEC-а от Freescale можно найти в любом ихнем ColdFire-е или ARM-е с встроенным Ethermet-ом

А принцип всей системы таков:
Спокойно юзаете свою ОС-ь.
Делаете там ARP, DHCP, DNS.. все че положено.
В некоторый момент получаете из сети по служебному соединению инфу о том, что скоро пойдут VLAN пакеты.
Настраиваете перехватчик MAC хидеров и его отводной канал передачи данных.
Перехватчик не юзает сервисы OC-и, если че нужно - дает понять через генерацию программных прерываний.
Все из предположения, что юзер использует собственный софт на стороне PC

Не совсем понятно, что же можно придумать с этим тегом на приемном конце? Тег-то приходит из сети, и есть он или нет - еще неизвестно (обычно, в конечном устройстве его надо просто стрипнуть). А я о том, что и в IP-заголовке, и в TCP-заголовке возможны дополнительные опции - например, при открытии сессии очень все любят сунуть опцию MTU. Хотя, с другой стороны, при передаче собственно данных обычно дополнительные заголовки не встречаются (нефиг оверхед гонять, и это правильно), но закладываться на это - себе дороже.

Хотя, конечно, это мои размышлизмы, может в мотороловской реализации мака уже и подумали за нас. Дайте, чтоли, ссылочку на даташит, почитаем, проникнемся