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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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



Да бога ради!