Кстати, о птицах...

А emBetter кто нибудь реально пробовал?

http://www.stzedn.de/index.php?id=6&L=1

Расписано красиво... А как на деле?

emBetter - неизвестный продукт неизвестной фирмы.
Лучше взять TCP/IP стек от фирмы CMX:
http://www.cmx.com/tcpstacks.htm
Он стоит 9500USD и свободно нигде не лежит.

Лучше автора никто не сравнит:
http://www.sics.se/~adam/mobisys2003.pdf

Надо добавить, что сейчас LwIP свободно "доразрабатывается" на нонгну: savannah.nongnu.org/projects/lwip/
Пофиксено немало багов и функциональности добавлено.

После отимизаций стека LwIP на STR912FA получил скорость TCP 5.6 метра в секунду .

Весьма интересно в чем заключались эти оптимизации. Хотябы в общих словах.
Кстати у меня при попытке увеличить TCP_SND_BUF выше TCP_MSS сразу пропадала связь и на аки он отвечал ресетами. Неужели у at91sam7x256 ему памяти не хватает... А так скорость 300килоБАЙТ в секунду уверенно.

1) 8- битные и 16 битные переменные полей которые работали как счетчки или как переменные хранящие длинну, также все локальные счетчики счетчики были сделаны 32 битным типом.

2) критичные функции типа CRC перенесены в ОЗУ (в итоге программа в ОЗУ сьела 8к )

3) драйвер MAC буфиризирован.

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

5) естественно заменен алгоритм CRC на более быстрый, он кстати идет вместе с стеком но почемуто не включен в него.

6) выкинуты функции memcpy библиотечные и заменены на более быстрые.

7) ну и естественно выбраны оптимальные настройки памяти стека.

8) по итогу код стека во флеш. ~22К, в ОЗУ 8К, использовано памяти под кучу и другую фигню ~60к


Ну приблизительно вот.

Вот мои настройки стека
Нажмите для просмотра прикрепленного файла

Что это значит? можно подробнее?



Т.е. вы реализовали то, что в лвип-шной конфе называют зеро сайз копи? Я тоже думал над реализацией чего либо подобного, но меня затерзали "мутные сомнения". Если ядро работает с езернет памятью, то захватывает шину и емак должен дождаться освобождения ресурса. Мы получаем выигрыш от отсутствия копирования память-память, но получаем блокировку емак-а.
В ином варианте мы тратим время на копирование, но дальше работают оба банка памяти. Один с ядром, а другой с емасом.

Я так понимаю, вы проводили какое-то тестирование. Можно ли подробнее узнать:
1 насколько этот механизм увеличил пропускную способность стека
2 есть ли пропадание пакетов из-за блокировки емак-а
3 Я понял что исходящие пакеты вы обрабатываете "по старому". Почему здесь не применяете зеро сайз копи?

У STR912 нету езернет памяти, есть токо фифо которое в принципе скрыто от юзера, между фифо и озу стоит DMA.

Смысл буферизации заключается в том что б как можно меньше терять пакеты. Если не запустить DMA пакет не будет принят. Работает следующим как токо принят пакет, выделяется новый pbuf размером на макс пакет (1520 байт) и запускается DMA и так пока не кончатся pbuf , приложения следит за этими pbuf и когда надо передвает в стек.


намного как при передачи так и при приеме. изначально при первом старете получил 13 mbit/s передача и 5-6 mbit/s прием, на данный момент 40-46 mbit/s передача, 25-30 прием


Пропадаение пакетов есть, особенно если сеть перегружена броадкастами, но это не от блокировки емака, а от нехватки pbuf, память ведь ограничена.


Да по старому, вся проблема в STR DMA, он требует выравнивание адреса 4, а payload pbuf не имеет выравнивания и приемущественно расположен на границе 2 из-за 6 байтового MAC адресса. В дальнейшем можно будет переписать управление PBUF так чтобы выходные пакеты имели выравниваение, но это потом.... сейчас меня такие параметры устраивают, а времени в обрез

Моя ошибка - невнимательно прочитал тред, я почему то был уверен, что вы используете лпс2300. Но в информация по любому очень интересная, большое спасибо

Возвращаясь к теме подскажите хороший tcp/ip стек, кроме uIP:
Кто-нибудь использовал Keil'овский RL-TCPnet?
Как он по скорости, в сравнении с теми же uIP/lwIP?

вот здесь Keil выкладывает тесты скорости (опять же - как тестировали, какие еще задачи"болтались" и т.д. - непонятно)

Да видел я это... KB/s - это килобит или килобайт?

если килобит, то получается для TCP 1.8Мбитт/сек - маловато...

Просто сейчас стоит задача организовать передачу данных в ПК с максимальной скоростью. Скорость чем больше - тем лучше. Процессор - LPC2468 (в будущем планируется заменить на LPC3250 или около того, но пока LPC2468). Протокол TCP (данные терять и путать нельзя - там длинные куски по 2 - 100Кбайт).
Тем по uIP/lwIP на форуме много, а вот по кейловскому стеку я ничего не нашел, вот и хотелось узнать о нем мнение, что лучше выбрать?

Надо думать, все же килобайт. Но все равно маловато. Обратите еще внимание на одинаковую скорость TCP на разных платформах для 1400 байт - что-то в консерватории явно не так.


Ну, чтобы обеспечить целостность данных вовсе не обязательно использовать именно TCP.

Да, и к тому же в предпоследней строчке TCP быстрее UDP... Будем считать это банальная опечатка - скопировался результат с предыдущей платформы

Согласен, можно прописывать в начало пакета номер и использовать UDP и самому отправлять квитанции. Если квитанций нет какое-то время - отправлять повторно. Но получается почти тот-же TCP, только заголовок проще... Вот я и решил сразу TCP и использовать.

Если устраиват UDP - дейтаграмные посылки, а не собираетесь использовать TCP, то нет нужды заморачиваться особенно со стеком - на сайте у атмела должны быть тесты типа BasicEthernet

Это писал не я и два года назад. Писавший это уже получил ответы на свои вопросы.

Та в том-то и дело, что не совсем устраивает (см. мой предыдущий пост). И использовать собираюсь я использовать именно TCP!

Что-то так и не встретились пользователи RL-TCPnet, что немного настораживает...

На вот такой платке: http://www.starterkit.ru/html/index.php?na...p=view&id=9 ,
TCP/IP стэк кейловский (RTL), при частоте тактирования контроллера 72 МГц, в thumb mode (ибо библиотека там только для thumb),
удалось пропихнуть в сторону компа
~20000 коротких (18 байт) UDP пакетов в секунду...

К сравнению - у меня lwip, TCP, пакеты по 1024 байта, функции RAW API tcp_write() - 1638400 байта в сек поток работает отлично. Разработанная система - восьмиканальный анализатор. Только нужно комп брать многоядерный и выделить поток независимый на прием. Плата - та-же, стартеркита, на LPC2368, 64 МГЦ тактовая, ARM-mode

Многоядерный для приема 1600 кБайт/с? Или какая-то обработка все же делается?

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

Ну у меня масштабы попроще
Полный мониторинг одновременно двух CAN шин.
Достигнутой скорострельности вполне достаточно для этого.
Без лишних заморочек с буферизацией и пр.
Один udp пакетик - для каждого CAN сообщения. Многое упрощает..
Оврхед UDP не нарягает...

Это получается 0,34Мбайт/с, а если учесть (основываясь на все той же же кейловской RL-TCPnet Performance) что при увеличении пакета в 140 раз скорость увеличилась раз так в 30, то для большого пакета должно быть около 10Мбайт/с. Или около 5Мбайт/с для TCP.

1638400байт/сек = 1,56Мбайт/сек - это максимальная скорость, или просто быстрее передавать не было необходимости?

На pc на 10Мбитном интефейсе реально получить 8 мегабит на длинных пакетах, а на 100Мбитном 60.

PC-шки, они же разные..

На Marvel'е, на 100-Мбитном линке можно и 100:
Нажмите для просмотра прикрепленного файла

нет необходимости...