Самый быстрый и самый маленький TCP-стек., По просьбам трудящихся. Опции

[Rst7]

Итак, по просьбам трудящихся выкладываю порт своего стека на LPC1768, выдранный из текущего проекта, над которым щас тружусь.

 NikeE_CM3.zip ( 350.37 килобайт ) Кол-во скачиваний: 563


Собирается IAR'ом 6.20.3 (вроде крайний на текущий момент), за подправить для GCC - даже не просите.

В качестве PHY используется KSZ8041TL, что, в общем, не принципиально - править, если что, файл emac.c

Тактовая проца в проекте - 100МГц, кварц - 20МГц, менять - функция InitPLL в файле hardware_init.c

Так же для генерации 50МГц REFCLK используется сам процессор через модуль CLKOUT. Кому не надо, в файле hardware_init.c необходимо убрать

CODE

  //Нужно если 50МГц для RMII генерируется процом
  PINSEL3 |= (0x01UL<<22); //CLKOUT on P1.27
  CLKOUTCFG=0x00000110; //CLKOUT 100MHz/2=50MHz used for RMII

Стек поддерживает TCP (и серверные, и клиентские сокеты), ICMP. Очень не долго прикрутить UDP. Поддерживается Fast Retransmit на передачу. На прием - сделаю чуть позже (если, конечно, понадобится).

Архитектура стека - callback по событиям из низкоприоритетного прерывания (используется модуль RIT как таймер, необходимый для TCP и заодно происходит Wakeup этого потока при поступлении пакетов - через прерывание от EMAC, которые должно быть высокоприоритетным (но при этом очень короткое, TODO - управление Flow Control)). Сам стек - network.c.

По умолчанию IP-адрес - 192.168.0.100.

Есть вебинтерфейс, даже с поддержкой ajax - можно поставить галочку Update Graphics и повеселиться (естественно, с браузером, который понимает HTML5 - Опера, Хром, Тормозилла - все годится). Кнопки "<<" и ">>" тоже можно понажимать. Для создания и отображения этих данных копать show_data.c и HTMLsource/http_root_level3.

Еще там случайно md5-авторизация в вебсервере сделана



Эмулятор EEPROM в проекте не прикручен, так что на страничке конфигурации настройки стека не сохраняются. Когда у себя в проекте прикручу, сюда сделаю порт.

На порту 2000 висит отдаватель файла со случайными числами размером 100 мегабайт - это для теста скорости. В папочке GetData лежит проект забирателя для большого брата (собирать C++ Builder'ом).

Ну вот теперь, собственно, за скорость. По TCP - 90Мбит/с.


На этом, кстати, предлагаю закончить спор о максимально достижимой скорости по TCP.

Ну размеры вообще не угадываются - 3.7кБ собственно стек, вебсервер - 3.5кБ. Ах да, там еще странички пакуются, но это осталось с версии для AVR, можно честно выбросить.

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

Ну и на посошок - лицензии. От это все - GPL, так что пользуйтесь.

На все вопросы постараюсь ответить тут.

Добавлено 29 июня 2011г:
http://electronix.ru/forum/index.php?s=&am...st&p=956930 - ревизия 1315.

Добавлено 30 июля 2011г:
http://electronix.ru/forum/index.php?s=&am...st&p=957213 - ревизия 1318.

[andrewlekar]

Эмуляцию EEPROM уже хочется глянуть. У меня своя есть, но довольно сложная реализация и сектора не очень эффективно используются.

[Rst7]

Эмуляцию EEPROM уже хочется глянуть.

А что, собственно стек не интересен?

[prottoss]

А че он самый быстрый то? С чем сравнивалось?
У мя тоже есть свой стек правда в LPC я не силен Но есть SAM7X... Как нить измерю сантиметры

[Rst7]

А че он самый быстрый то? С чем сравнивалось?

А Вы замечали, что у нас на форуме в каждом обсуждении, касаемом TCP-стеков имеется несколько обязательных фраз про то, что TCP - это очень медленно и т.д.? И обычно выше 30мбит никто не поднимается в заявках

[prottoss]

А Вы замечали, что у нас на форуме в каждом обсуждении, касаемом TCP-стеков имеется несколько обязательных фраз про то, что TCP - это очень медленно и т.д.? И обычно выше 30мбит никто не поднимается в заявках

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

А сколько занимает памяти TCP-сокет кстати? И сколько стек использует стека?

[Rst7]

А сколько занимает памяти TCP-сокет кстати?

49 байт, если мне не изменяет память.

И сколько стек использует стека?

Немного. 40 байт стека в основном коде плюс немного в процедурах (не более 16 байт). Callback-и, например, в http-сервере - 48 байт суммарно. Правда, есть еще md5, тот добавляет 56 байт.

Я о том, с чем сравнивалось - почему он "самый быстрый"

Пока ни с чем, исключительно по общей тенденции реплик по форуму. Мне лень ковыряться в других стеках и доводить их до ума - дабы можно было адекватно сравнить. Давайте с Вашим померяемся

[prottoss]

Давайте с Вашим померяемся

Хорошо. Постараюсь причесать до понедельника. После отпуска ни как не могу настроиться на нормальный лад

[Rst7]

Хорошо. Постараюсь причесать до понедельника.

Так а по-простому? Прикрутите к подходящему Вашему проекту тестовый сокет, в который скормится метров 100 рандома и вуаля. Я такой использую:

CODE

  r=r*1103515245+12345;

Софтик для теста можете у меня из архива взять.

[prottoss]

Так а по-простому?

Сейчас попробую. Просто проект пылится уже более двух лет. По моему под 4 ИАР еще. Так что сегодня и по быстрому не обещаю.

[scifi]

Интересная штука. Эх, причесать бы код и абстрагировать от железа - получился бы полезный для многих проект. А с документацией ещё полезнее было бы...
Кстати, для разбора заголовков HTTP есть интересная библиотека: HTTP parser. Чтобы не изобретать свой велосипед.

[prottoss]

Эх, причесать бы код

Да автору без обид - я тож об этом подумал - куча-мала

[Rst7]

Эх, причесать бы код и абстрагировать от железа

От железа к железу оно в полпинка переносится. Изначально это был проект под AVR, который с рукопашным эзернетом был. Порт по времени занял два дня.

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

А вот документацию, конечно, надо делать. Только где взять время

[zltigo]

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

Я пока исходники вообще не смотрел, но к "оторвать от железа" сразу отношусь плохо - этих оторванных от железа, использующих от возможностей железа 0 целых хрен десятых уже понаписано немеряно. На данный момент максимальную ценность представляют решения которые наконец-то показывают, как максимально эффективно работать с конкретным железом и какой эффект от этого получается. Судя по скорости работы с конкретным железом этот стек интегрирован хорошо. И именно в этом его положительный пример.

[Rst7]

Судя по скорости работы с конкретным железом этот стек интегрирован хорошо.

Честно говоря, не сильно я там особенности железа использую. Есть что покрутить (в частности, есть тонкости в передатчике), но исключительно ради снижения CPU load. Будет свободное время - займусь. Пока на очереди - Flow Control.

[VslavX]

А че он самый быстрый то? С чем сравнивалось?
У мя тоже есть свой стек правда в LPC я не силен Но есть SAM7X... Как нить измерю сантиметры

А вот я, кстати, не отказался бы померяться сантиметрами
Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек. Или может готовое приложение есть? Я смотрел на ntttcp, но MS деталей этого теста, увы, не раскрывает.
PS. Если просто по TCP слать в discard, то мой стек на LPC17@100 дает чуть более 4Мбайт/сек, но хотелось бы таки более осмысленного теста.
PPS. exe-шники для at200 и getdata, имхо, в архиве лишние, а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает.

[Rst7]

Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32)

Я не знаю, что там обсуждать. Я просто в своей тестовой софтине принимаю из сокета и пишу в файл (ибо на самом деле моя тестовая софтина для получения данных с АЦП была). Сто метров с замером времени - вполне адекватный тест. Следующая серия тестов - накатываем dummy net, втыкаем очередь-задержку (можно небольшую, пара миллисекунд вполне для отсева пионерских поделок) и наслаждаемся

а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает.

Положу, пардон, совсем забыл.

[prottoss]

Так - поднял свой пыльный стек Теперь пытаюсь вникнуть в приложение на билдере. Сразу скажу, что сетевые приложения под Win32 не программировал, по этому туго. Чего там оно просит?

Код

if ((he=gethostbyname("nikee_cm3.tst"))==NULL)
        {
                ShowMessage("Error: gethostbyname failed!");
                return;
        }

Можно на пальцах? Другим тоже, думаю, интересно будет.
Сокет, я так понимаю, сервером открывать?

[Rst7]

Чего там оно просит?

В windows/drivers/etc/hosts добавьте запись nikee_cm3.tst с нужным Вам IP-адресом.

Да, сокет на младшем брате должен быть серверный.

[blackfin]

А вот я, кстати, не отказался бы померяться сантиметрами
Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек.

Можно, например, Ethereal'ом протестировать..

Но для полноты картины хорошо бы три-четыре сокета открыть:
[attachment=59138:Ethereal.jpg]

[VslavX]

Можно, например, Ethereal'ом протестировать..

Можно, но там нужно долго в цифры втыкать - например, смотрю - показывает что два пакета по 1460 байт принимаются с интервалом 7 мкс, хотя на скорости 100Мбпс это ну никак. Потом подумал - оно ж у меня в гигабитный свитч воткнуто, тот мог такое учудить, вполне... Не-а, даже на гигабите в 7 мкс не укладывается . У меня "продвинутый" свитч - он порт-мирроринг позволяет (только так можно помониторить свой девайс, например, к NAS-у подключенным), так на зеркальном порту тайминги вообще уезжают.

В-общем, со своего тестика тоже отряхнул пыль, прикрутил новый блочный режим TCP, который с тех времен появился, потестил - 5.8Мбайт/сек в дискард оно бросает. Анализ траффика показывает что банально недостаточные размеры буферов TCP-сокета в моем стеке не дают разогнаться (также реализован механизм предотвращения заторов, но он тут даже нормально накопить статистики не успевает ). Банально - кидаем 4К в буфер сокета TCP, оно отдает три пакета по 1460+1460+остаток и ждет ACK. Пока ACK нету - буфер полный, новые данные приложение в сокет не пишет - некуда, все стоит. Пришел ACK, буфер почистился - кидаем новые 4К данных, они тут же снова улетают - и опять ждем ACK. Вот так оно кусочками и дергается. Если выкинуть промежуточный свич (там он еще и на зеркальный порт кидает траффик) то пинг уменьшиться, и скорость еще может на пару-тройку процентов вырасти.

Надо сказать, что отправка данных по TCP у меня организована слегка неоптимально - есть копирование с одновременным подсчетом контрольной суммы TCP. Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать, под это дело буду также учится делать отправку данных без копирования - по ссылке.

[blackfin]

Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать...

Да ладно, не переживайте..

TCP уже не модно: Cisco to cut 6,500 jobs, sell plant.

[Rst7]

Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать, под это дело буду также учится делать отправку данных без копирования - по ссылке.

Однако я обхожусь без сей аппаратной приблуды. А скорость в два раза выше

[Rst7]

Можно, например, Ethereal'ом протестировать..

Но для полноты картины хорошо бы три-четыре сокета открыть:

Только еще бы выделить чистый траффик по полезной нагрузке, ибо как-то в общую сумму складывать ACK'и и вообще служебную ересь нехорошо. Банальное чтение данных из сокета на большом брате и измерение времени - самое то.

[VslavX]

Однако я обхожусь без сей аппаратной приблуды. А скорость в два раза выше

Ну, допустим, не в два, а чуть больше чем в полтора . А сейчас я поигрался конфигурацией, отключил отладку - и получилось чуть более 70Мбит/сек - 16Мбайт ушло за 1910 мс. При этом потребовалось 31К кода и 16К оперативки. Так что спорить что Ваш стек самый быстрый и маленький - не буду .
Вопрос такой - я правильно понял, что источник данных кладет данные прямо в сетевой буфер эзернета в колбек-процедуре. А если требуется повторная отправка, то вызывается событие REGENERATE? Тогда получается что приложение должно само решать вопросы хранения данных у себя до подтверждения их получения удаленной стороной со стороны TCP. То есть - в-общем случае, стек буферов данных у себя не имеет, а просто сваливает проблему на приложение, отсюда и расход памяти собственно в стеке маленький.

Да ладно, не переживайте..

Да я не переживаю . Rst7, конечно, выкатил свой очередной шедевр, но он как болид F1 - ездит быстро, но это машинка не на каждый день чтобы на работу добираться.

TCP уже не модно: Cisco to cut 6,500 jobs, sell plant.

Ага, Циска от непрофильного ширпотребного производства избавляется и собирается как раз на "немодном TCP" сосредоточиться (на сетевом оборудовании).

[Rst7]

Ну, допустим, не в два, а чуть больше чем в полтора

Имеем заявленные мной 90мбит/с = 11Мбайт/с (примерно). А Вы заявляли о 5.8Мбайт/с. 11/5.8=1.9. "Маша - это Маша, а два раза - это два раза" (ЦЭ)

А сейчас я поигрался конфигурацией, отключил отладку - и получилось чуть более 70Мбит/сек - 16Мбайт ушло за 1910 мс.

А теперь предлагаю вставить dummy net с задержкой пакетов на 2-3мс

Вопрос такой - я правильно понял, что источник данных кладет данные прямо в сетевой буфер эзернета в колбек-процедуре. А если требуется повторная отправка, то вызывается событие REGENERATE?

Да, и смысл в этом самый глубокий. Незачем навешивать лишних буферов. Само приложение куда лучше стека знает, как работать с генератором тех данных, которые будут передаваться в сокет. Да, это усложняет написание кода, но увеличивает быстродействие. И в общем зачете уменьшает количество требуемого ОЗУ.

Я уже как-то писал об этом, повторюсь:

У меня в стеке есть три callback'а для режима передачи

SEND - сгенерить новых данных для передачи (не более стольки-то) и вернуть количество сгенеренных данных.
REGENERATE - откатиться на точку последнего подтверждения
ACK - переместить точку последнего подтверждения на сколько-то байт.

CODE

char *out;
char *ack;

SEND(p,max)
{
   len=max;
   memcpy(p,out,len);
   out+=len;
   return len;
}

REGENERATE(p,max)
{
   len=max;
   memcpy(p,ack,len);
   out=ack;
   return len;
}

ACK(len)
{
   ack+=len;
}

В начале out и ack указывают на начало буфера передачи.

На самом деле в реальности там нет memcpy. Это псевдокод для иллюстрации. На самом деле там какой-то циклический буфер, или железка, или еще чего - например, http-сервер в виде машины состояний, который непосредственно печатает в p, а ack и out для него - не более чем состояние.

[halfdoom]

Ну вот теперь, собственно, за скорость. По TCP - 90Мбит/с.

Неплохо, у нас тут народ пилил что-то опенсорсное, так выше 68Мбит/c забраться не удалось. Про размеры кода вообще молчу .

[blackfin]

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

Их никто и не складывает. Данные идут в одном направлении, а ACK'и - в другом.
Измерение скорости в Ethereal'е нужно начинать уже после того как на PC запущено тестовое приложение и созданы сокеты. Это исключает "служебную ересь", связанную с открытием сокетов.

Сообщение отредактировал blackfin - Jul 28 2011, 04:15

[andrewlekar]

А что, собственно стек не интересен?

Не особо. Мне только обработка прерывания EMAC интересна.

[VslavX]

Имеем заявленные мной 90мбит/с = 11Мбайт/с (примерно). А Вы заявляли о 5.8Мбайт/с. 11/5.8=1.9. "Маша - это Маша, а два раза - это два раза" (ЦЭ)

Сейчас Маша осталась Машей (с внутристековой буферизацией), но при этом 70Мбит/с .

А теперь предлагаю вставить dummy net с задержкой пакетов на 2-3мс

Хотите сказать что у Вас скорость не упадет? В случае генерации псевдослучайных данных - вполне может быть, и неудивительно - тут буфера нет. А вот если передавать что-то осмысленно-реальное, то буфер все равно появится - в приложении. И как только емкость канала превысит размер этого буфера - скорость упадет как миленькая. Пример - передача файла с MMC карточки. Можно читать данные с карты в колбеке - но это некамильфо, операция долгая, мало того что делать прийдется ее в прерывании, так еще и все другие сокеты встанут, приемный буфер сети переполнится (flow control нуна доделывать ) и так далее. Поэтому буферизация тут будет нужна без вариантов.

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

Смотря какое приложение. Если относительно простое - то такой подход справляется. А если приложение относительно сложное - то ну его нафиг - добавлять в него еше тисипишные заморочки типа "ну не шмогла, давай повторим". А если надо наложить поверх такого TCP другой протокол со своими фреймами, типа PPTP или iSCSI, то без буферизации тут вешалка.

В-общем, реализация на колбеках любопытная, но вся работа по буферизации свалена на приложение. Если буферизация приложению не нужна - все выглядит интересно, но если приложение делает хоть шаг в сторону, то "вечер перестает быть томным" ©. Режим работы TCP с колбеками несложно добавить и в мой стек, сижу вот думаю, что оно реально может дать на моих задачах - пока выгода неочевидна.

[Rst7]

Их никто и не складывает. Данные идут в одном направлении, а ACK'и - в другом.

Кстати, по фильтру не заметно. Ибо нет фильтрации. Так что оба направления считаются. Да и Ethereal тут показывает общий траффик - служебная информация (заголовки ETH, IP, TCP) - тоже в сумме.

Это и приводит к числу (Avg. MBit/s), больше 100мбит/с - что естественно, невозможно.

Пример - передача файла с MMC карточки.

А оно-то хоть заявленную скорость даст? Какая ФС используется? Сколько собственно в этой ФС буферов?

Можно читать данные с карты в колбеке - но это некамильфо, операция долгая, мало того что делать прийдется ее в прерывании

Делать ее придется не в самом приоритетном прерывании, так что не беда.

так еще и все другие сокеты встанут, приемный буфер сети переполнится (flow control нуна доделывать ) и так далее. Поэтому буферизация тут будет нужна без вариантов.

Встанут остальные сокеты - это да, это реальное ограничение. Хотя, конечно, его можно обойти.

А если надо наложить поверх такого TCP другой протокол со своими фреймами, типа PPTP или iSCSI, то без буферизации тут вешалка.

PPTP - это дело такое, там основной траффик GRE/IP, на рассматриваемый случай не ложится, а доп. TCP соединение для управления - ну просто замечательно укладывается на систему с колбеками - там машина состояний, все дела.

iSCSI - тоже песня, блоки с устройства читать. На колбеках как два пальца.

[VslavX]

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

Не в скорости дело, а в том что нельзя надолго заниматься своими делами в колбеке. И не всегда это "надолго" связано с тем что устройство медленное. OK, другой пример. Возьмем Web сервер, только ресурсы его положим не в программную флеш (допустим ресурсы большие, или флешки для программы и так не хватает), а во внешний чип, скажем AT45, подключенную по SPI. И добавим еще одну задачу - какой-нить логгер, который просто собирает свои данные и записывает в эту AT45. Объем AT45 разделим в каком-нить соотношении между логгером и ресурсами Web. И получается что аппаратура SPI+AT45 разделяется между двумя задачами, нужна синхронизация, и вот из-за этой самой синхронизации сетевой колбек банально может надолго задуматься. Конечно, можно сделать "закат солнца вручную" - придумать свою какую-то модель синхронизации, например не ждать в колбеке данные а сразу выходить без посылки и прочее. Но тут кто за что борется - Вы за чистую скорость в отдельно взятом проекте, а я, например, за максимальное наследование кода в кучке разнородных проектов.

Встанут остальные сокеты - это да, это реальное ограничение. Хотя, конечно, его можно обойти.

Конечно можно - с помошью буферизации . Или есть какие-то другие идеи?
Подход на колбеках мной рассматривался неоднократно, в итоге я от него таки отказался - именно из-за возможной блокировки в колбеке вследствие синхронизации или просто длительной операции. Тот вариант который у меня сейчас есть на прием колбекам несильно уступает (данные вообще нигде не копируются), а по передаче - есть одно копирование (мб и избавлюсь со временем - сделаю реферальную отсылку, но тут выигрыш будет заметным именно при аппаратном полсчете сумм).

PPTP - это дело такое, там основной траффик GRE/IP, на рассматриваемый случай не ложится, а доп. TCP соединение для управления - ну просто замечательно укладывается на систему с колбеками - там машина состояний, все дела.

А кому нужно управляющее соединение без канала данных? Я сейчас как раз PPTP обдумываю (для девайсов с GPRS весьма и весьма нужен туннель), без буфера ну никак не получится.

iSCSI - тоже песня, блоки с устройства читать. На колбеках как два пальца.

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

Ну в целом, имхо, у Вас получилось удачно - для многих несложных устройств вполне будет работать. Хорошо бы причесать код (по железкам файлы разнести - PHY отдельно, EMAC отдельно, чтобы порты делать), написать документацию (не слишком объемную притом) и придумать хорошее название (типа "Тисипец ™" ) - многим вполне может быть интересно.

[Rst7]

Подумал про передачу данных, например, с MMC. Да, для пущего профита желательно в стеке разделить этапы приготовления к передаче нового сегмента и собственно генерацию данных для передачи. Тогда, при необходимости передачи новых данных callback на приготовление запускает чтение с MMC и вываливает с прерывания. Когда от MMC приходит готовность, опять происходит wakeup стека и непосредственно чтение по SPI (ну или 4хбитному интерфейсу) происходит уже в буфер передачи.

Когда дело дойдет до ФС в проекте - сделаю.

А кому нужно управляющее соединение без канала данных?

Так канал данных не через TCP организован. Посему мы его тут не рассматриваем.

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

Я, конечно, внимательно на досуге покурю соответствующий RFC ради спортивного интереса, но, думаю, Вы преувеличиваете. Если у Вас блочное устройство как источник данных - в любом случае нет проблем с откатом.

Возьмем Web сервер, только ресурсы его положим не в программную флеш (допустим ресурсы большие, или флешки для программы и так не хватает), а во внешний чип, скажем AT45

См. чуть выше, описал идею и метод, пока Вы писали свой пост.

Хорошо бы причесать код (по железкам файлы разнести - PHY отдельно, EMAC отдельно, чтобы порты делать)

Ну для этого нужно разбить примерно пополам файл emac.c. Только смысл? Ибо там того кода с гулькин куй и все прозрачно.

Выносить в отдельный файл работу с EMAC в собственно стеке считаю вредным и бесполезным.

[VslavX]

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

Угу, а если стек занят (ну по другому сокету что-то отдает или удаленный хост задумался, пакет пропал и тд) и этот wakeup задерживается? Причем в общем случае он так нехило на секунды задержаться может. При этом ресурс MMC+SPI заблокирован и никто им больше пользоваться в этот момент не может (ну там логгер чего писнуть хочет).

Еще интересно как тут с приемом. В нормальном стеке с внутренней буферизацией всегда можно четко вычислить свое окно и передать его удаленному хосту. А тут если по колбеку всегда выггребание непонятно как TCP-шный хендшейк себя вести будет. Или таки есть внутренни приемный буфер у сокета?

Так канал данных не через TCP организован. Посему мы его тут не рассматриваем.

Ага, это я упустил - не дошел до инкапсуляции еще.

Я, конечно, внимательно на досуге покурю соответствующий RFC ради спортивного интереса, но, думаю, Вы преувеличиваете. Если у Вас блочное устройство как источник данных - в любом случае нет проблем с откатом.

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

Ну для этого нужно разбить примерно пополам файл emac.c. Только смысл? Ибо там того кода с гулькин куй и все прозрачно.
Выносить в отдельный файл работу с EMAC в собственно стеке считаю вредным и бесполезным.

Вечером прокомментирую - мне щаз убегать нужно, сорри.

[prottoss]

Так а по-простому? Прикрутите к подходящему Вашему проекту тестовый сокет, в который скормится метров 100 рандома и вуаля. Я такой использую:

Код

  r=r*1103515245+12345;

Софтик для теста можете у меня из архива взять.

Вчера таки поправил проект под ИАР 5, правда TCP заработал только в полном DEBUG-е. Получил примерно 3500-4500 кбит/с при разных замерах . РС с платкой соединен через 4-х портовый модем. А Вы тестировали точка-точка? Сегодня попробую разобраться, че там компилятор в TCP выкидывает. Платформа AT91SAM7X256 + DM9161. Компилировал в ARM-режиме.

Наверное у Вас реально самый быстрый стек

Встанут остальные сокеты - это да, это реальное ограничение. Хотя, конечно, его можно обойти.

Конечно можно - с помошью буферизации . Или есть какие-то другие идеи?

Можно, используя RTOS и вместо колбеков флаги. Относительно легко переделывается.

[Rst7]

Угу, а если стек занят (ну по другому сокету что-то отдает или удаленный хост задумался, пакет пропал и тд) и этот wakeup задерживается? Причем в общем случае он так нехило на секунды задержаться может. При этом ресурс MMC+SPI заблокирован и никто им больше пользоваться в этот момент не может (ну там логгер чего писнуть хочет).

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

Еще интересно как тут с приемом. В нормальном стеке с внутренней буферизацией всегда можно четко вычислить свое окно и передать его удаленному хосту.

И тут всегда можно вычислить. А иногда - например, для разбора HTTP-запросов, оно и нафиг не нужно, все делается на лету.

В общем, при такой архитектуре принципиально иным должно быть построение остального кода. Только тогда будут скорости. Хотя, в общем-то и в обычных bsd-style дизайнах нельзя забывать о том, что, например, очень нежелательно кормить, скажем, функцию send по одному байту. Понятное дело, что есть буферизация, но накладные расходы на вызов будут просто феерические.

А с другой стороны сама по себе bsd-style архитектура не позволяет работать с zero-copy. А zero-copy - это не только в самом стеке, но и еще и в генераторе/приемнике данных. Т.е. проблему скорости надо решать в комплексе.

А Вы тестировали точка-точка?

Свич торчит 16типортовый между девайсом и большим братом.

Можно, используя RTOS и вместо колбеков флаги. Относительно легко переделывается.

Там все-же сложнее ситуация. И опять-же, повторюсь, решать ее надо в комплексе. Обработчик медленный и печальный - уносите его в низкоприоритетную задачу/прерывание (я просто разноприоритетными прерываниями как неким аналогом RTOS пользуюсь), разбивайте его на подзадачи, возможно - добавляйте ему необходимые буфера.

[AlexandrY]

Итак, по просьбам трудящихся выкладываю порт своего стека на LPC1768, выдранный из текущего проекта, над которым щас тружусь.

Никаких шансов что это самый быстрый стек.
Еще года 3-и назад выкладывал результаты работы микриумовского стека.
Там без проблем было сделать 98 Mbit/s на 90 MГц процессоре, причем в среде RTOS!

Посмотрел ваш код и вижу вы даже не пытались оптимизировать расчет IP и TCP CRC, нет попыток оптимизировать пересылки в памяти.
Много мест где в программном цикле ожидаются сигналы.
Т.е. на RTOS код не портируется, а попытка исполнения одновременно с вашим TCP стеком других быстрых асинхронных задач, например с той же скоростью обслуживать USB приведет к полной деградации одной из задач.

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

[Rst7]

и вижу вы даже не пытались оптимизировать расчет IP и TCP CRC

Это не так накладно, как кажется. Даже сейчас там чуть менее чем 2 такта на байт, т.е. на полновесный пакет имеем ~30мкс. Конечно, эту оптимизацию можно провести, но это копейки.

нет попыток оптимизировать пересылки в памяти

Там нет больших пересылок. Нечего оптимизировать.

Много мест где в программном цикле ожидаются сигналы.

Это место там одно - ожидание освобождения передатчика. Про это я упоминал, и да, оно поддается оптимизации.

Т.е. на RTOS код не портируется

Не вижу проблем, кстати, с портом под RTOS

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

Смысл этого комментария мне неясен. Если две задачи в сумме дают CPU load более 100%, то естественно, что вместе они будут давать меньшую производительность каждая.

Кстати называть ваш код "стеком" принципиально не верно.

Не согласен. Стек - он не потому что он в исходнике иерархичен, а от того, что иерархично обрабатывает протоколы.

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

Именно это и приводит к потери производительности.

[VslavX]

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

Ну я понял Вас так - что когда надо читать данные с MMC в сокет, то вызывается колбек, на MMC посылается команда чтения сектора, и управление возвращается в стек. Потом некто в фоне прокручивает протокол MMC по SPI и по готовности снова пытаеся начать передачу в сокет. То есть - SPI занят, MMC готова давать данные, осталось только получить передающий буфер сети. А тут засада - идет передача по другому сокету, например, и все - аппаратный ресурс SPI+MMC тупо простаивает, потому как нет буфера. C MMC есть еще засада - SDHC карты отдают сектора только целиком, поэтому если REGENERATE будет невыравнен (а он в 99% невыравнен) по границе сектора, то возникает оверхед. В-общем, это я к тому что без буфера можно сделать, но коряво оно будет.

И тут всегда можно вычислить. А иногда - например, для разбора HTTP-запросов, оно и нафиг не нужно, все делается на лету.

А как тут вычислишь - если приложение всегда забирает данные, и ackno тупо инкрементитцо перед rx колбеком. А если приложение не может забрать данные - допустим пишет оно их в MMC, и темп поступления данных по сети выше темпа записи? Где тут "дульный компенсатор" который регулирует поток входящих данных?

А с другой стороны сама по себе bsd-style архитектура не позволяет работать с zero-copy. А zero-copy - это не только в самом стеке, но и еще и в генераторе/приемнике данных. Т.е. проблему скорости надо решать в комплексе.

А zero-copy вполне можно и без колбеков сделать - на прием в моей реализации это есть и сейчас, то есть сетевые буфера которые записал EMAC вполне можно отдать приложению в таком же виде, причем такой блочный интерфейс одновременно сосуществует и работает с bsd-style вызовами, эта архитектурная проблема решается без напряга. На передачу по UDP тоже сделан zero-copy - буфер аллоцируется сразу у нужного сетевого драйвера, при этом готовятся все нужные заголовки нижних уровней - с учетом физики, фрагментации и прочего. Но по TCP вот засада - именно из-за ретрансмитта, поэтому пока есть одно копирование. Вы из этой проблемы выскочили при помощи REGENERATE, но не всем такое катит.

Выносить в отдельный файл работу с EMAC в собственно стеке считаю вредным и бесполезным.

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

[Rst7]

Кстати, о максимальной пропускной способности.

Имеем максимальный пакет 1518 байт с полезной TCP-нагрузкой 1460 байт. Плюс 96 бит IFG. Итого максимальная скорость в битах в секунду по полезной нагрузке равна 95424836. И те, кто заявляет больше (например - 98 у AlexandrY ) привирают.

Ну я понял Вас так - что когда надо читать данные с MMC в сокет, то вызывается колбек, на MMC посылается команда чтения сектора, и управление возвращается в стек. Потом некто в фоне прокручивает протокол MMC по SPI и по готовности снова пытаеся начать передачу в сокет. То есть - SPI занят, MMC готова давать данные, осталось только получить передающий буфер сети. А тут засада - идет передача по другому сокету, например, и все - аппаратный ресурс SPI+MMC тупо простаивает, потому как нет буфера.

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

C MMC есть еще засада - SDHC карты отдают сектора только целиком, поэтому если REGENERATE будет невыравнен (а он в 99% невыравнен) по границе сектора

Это надуманная проблема. Свести выравнивание к границе сектора - цена одного пакета. Так что никакого геморроя.

Где тут "дульный компенсатор" который регулирует поток входящих данных?

Крутите окно заранее. В принципе, можно и небольшой буфер использовать, только без фанатизма. Вообще грамотный выбор окна и MTU - залог успеха при ограниченных объемах ОЗУ.

Кстати, а дайте-ка описание SDHC протокола карт, попробую сделать пример реализации - все одно в хозяйстве пригодится.

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

Я попробую. Хотя, честно говоря, особо не вижу смысла. Стек сей - не для бездумного ^C^V в свой проект. Сначала надо подумать, потом сделать.

[AlexandrY]

Именно это и приводит к потери производительности.

Я думаю это на самом деле повышает производительность.
Ваш текст пересыщен прыганьями по двойным указателям.
Потому как в процессе обработки вы работает с разнородными разнесенными структурами.

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

Но вообще если вы не смогли достичь физического максимума скорости значит вы нагрузили проц на все 100%.
Т.е. любая дополнительная реальная задача резко уменьшит производительность вашего "стека" и не факт что линейно.

Правильнее было бы действительно продемонстрировать скорость при одновременной работе TCP и файловой системы.
А так это коня в вакууме напоминает.

[VslavX]

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

Буфер-то в стеке появится, но будет отдан другому сокету, например. И пока это другой сокет не прекратит передачу - MMC будет стоять.

Крутите окно заранее. В принципе, можно и небольшой буфер использовать, только без фанатизма. Вообще грамотный выбор окна и MTU - залог успеха при ограниченных объемах ОЗУ.

Что значит крутить окно заранее? Это вообще не задача приложения - крутить окно. Вы на примере, пожалуйста, прокомментируйте - нужно писать входящий поток из сокета в MMC, просто - последовательно по секторам, без всякой файловой системы. Как это предполагается сделать и где тут "крутить окно"? Скорость ММС ну пусть будет 512байт/мс. А сети - пусть 10Кбайт/мс.

Это надуманная проблема. Свести выравнивание к границе сектора - цена одного пакета. Так что никакого геморроя.

Это не надуманная проблема, это следствие необходимости удовлетворять REGENERATE по произвольной границе при отсутствии буфера. И допустим, слать выравнено по границе сектора еще можно (вообще дикость, ну и мы ж за пропускную бьемся, да? 1460 - наше фсе ), а как это вы заставите удаленный хост подтверждать прием четко по границе сектора? То есть - в любой момент может прийти REGENERATE типа "а дайте-ка мне вот 5 байт из этого сектора и далее".

Кстати, а дайте-ка описание SDHC протокола карт, попробую сделать пример реализации - все одно в хозяйстве пригодится.

В закромах есть.

Я попробую. Хотя, честно говоря, особо не вижу смысла. Стек сей - не для бездумного ^C^V в свой проект. Сначала надо подумать, потом сделать.

Это Ваша оценка ценности этого модуля. Еще паре-тройке-десятке человек на форуме интересно обсудить теоретические вопросы. А "трудящимся", по "просьбе" которых это выложено, ценны именно читабельность и портабельность.

В настоящей стековой архитектуре обработка на каждом этапе идет на близких данных, эффективнее используется кэш или буфер данных.

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

[Rst7]

Что значит крутить окно заранее? Это вообще не задача приложения - крутить окно.

То и значит. Приложение знает, чего происходит у него, а у сферического стека в вакууме один способ - буферизация. В условиях недостатка ОЗУ в микроконтроллерных применениях это единственный способ - смычка города с деревней более глубокое взаимодействие приложения и стека.

Как это предполагается сделать и где тут "крутить окно"? Скорость ММС ну пусть будет 512байт/мс. А сети - пусть 10Кбайт/мс.

Для таких скоростей проще выставить окно в 512 байт и закрыть вопрос. Получили пакет - запустили запись. По готовности - отправили Window Update. Все. Если хочется достичь теоретической производительности в данном случае - надо сделать буфер на один сектор. Это все при условии минимального Round Trip Time.

(кстати, а как тут с примитивной маршрутизацией - хотя бы на gw, есть такое?),

Все в порядке. Хотя и необычно реализовано.

[VslavX]

Для таких скоростей проще выставить окно в 512 байт и закрыть вопрос. Получили пакет - запустили запись.

Угу, и еще залезли в s->win и сделали его нулевым, потому как вдруг уйдет ACK с новым ACKNO и удаленный хост вышлет новые данные. Готична.

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

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

[halfdoom]

Но хранить MAC-адрес удаленного хоста в TCP-сокете - это готично . А если нету вообще снизу MAC-адреса (кстати, а как тут с примитивной маршрутизацией - хотя бы на gw, есть такое?), например PPP вместо эзернета? А если несколько интерфейсов, один с эзернетом, другой с PPP, куда бедному TCP-сокету податься?

Возможно я не прав, но реализация протокола от Rst7 заточена под вполне конкретное применение. Это позволяет выжать максимум скорости для данной реализации. Отсюда и MAC, и коллбэки, и не совсем четко разнесенная по уровням обработка. Но если устройство соответствует ТЗ, то это абсолютно не важно.

[Rst7]

Угу, и еще залезли в s->win и сделали его нулевым, потому как вдруг уйдет ACK с новым ACKNO и удаленный хост вышлет новые данные. Готична.

А как еще? Именно так. Только бояться не надо, ничего сложного.

[VslavX]

Возможно я не прав, но реализация протокола от Rst7 заточена под вполне конкретное применение. Это позволяет выжать максимум скорости для данной реализации. Отсюда и MAC, и коллбэки, и не совсем четко разнесенная по уровням обработка. Но если устройство соответствует ТЗ, то это абсолютно не важно.

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

А как еще? Именно так. Только бояться не надо, ничего сложного.

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

[Rst7]

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

Так надо тогда профессию сменить на грузчика. А нам, профессионалам, денег будет больше.

Возможно я не прав, но реализация протокола от Rst7 заточена под вполне конкретное применение. Это позволяет выжать максимум скорости для данной реализации.

Именно. Более того, оптимальный стек с ppp-транспортом должен строиться по другим принципам.

Более того, все забывают о том, что ресурсов в притык. Если флеша еще хватает с головой, то с ОЗУ - крепкие напряги. А ведь TCP-стек в устройстве - это не конечная цель, а всего лишь некая подсистема для обеспечения работы основного функционала. И она должна быть экономичной по ресурсам.

[blackfin]

Более того, все забывают о том, что ресурсов в притык. Если флеша еще хватает с головой, то с ОЗУ - крепкие напряги.

Ага, вот тут и встает наш Главный холиварный Вопрос: "Что делать, - каждый раз заново переписывать кривой уникальный TCP/IP-стек под каждый новомодный нанопроцессор, или доплатить денег, и купить более подходящий по ресурсам микропроцессор, в который без лишних телодвижений влезет нормальный, полнофункциональный, скоростной TCP/IP-стек + RTOS + Ваше_Любимое_Приложение?"

[Rst7]

Ага, вот тут и встает наш Главный холиварный Вопрос

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

[yakub_EZ]

IAR 6.21.1.2846 и common components 6.3.3.1990. При компиляции просит revision.c, где его взять?

[Rst7]

При компиляции просит revision.c, где его взять?

Он при компиляции создается отдельной софтиной. Можно сделать вручную из revision.tmpl, там просто строка текстовая в константу засовывается, т.е. шаблон заменить на 123, например.

И еще, собирать надо Target Release.

[zltigo]

Ага, вот тут и встает наш Главный холиварный Вопрос: "Что делать, - каждый раз заново переписывать кривой уникальный TCP/IP-стек под каждый новомодный нанопроцессор, или доплатить денег, и купить более подходящий по ресурсам микропроцессор, в который без лишних телодвижений влезет нормальный, полнофункциональный, скоростной TCP/IP-стек + RTOS + Ваше_Любимое_Приложение?"

При этом в этом "нормальный, полнофункциональный, скоростной TCP/IP-стек" не будет MAC уровня под Ваше железо или вообще, либо MAC будет написан минимально-формально. Это вообще-то сразу вычеркивает слово "скоростной" ( по отношению к стеку, а не процессору ). В дополнение к MAC написанному для галочки скорее всего вылезут еще и проблемы минимальности-универсальности-убогости взаимодействия с MAC уровнем вообще. Захочешь реально сделать конкретную работу хорошо по любому придется либо перепахивать нечто чужое и большое, либо, как вариант, что-то более-менее обозримое и заточенное под задачу. Иначе прямой путь не глядя за ради IP стека к чему-либо типа штопанного Линукса и гигагерцам.

[VslavX]

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

ИМХО, как раз LPC17xx неудачно выбран для иллюстрации уникальности стека. Если на AVR (откуда это все было портировано) с такой уникальностью еще можно было смириться, то на LPC17xx (у которого ресурсов более чем) это вызывает удивление.

[blackfin]

При этом в этом "нормальный, полнофункциональный, скоростной TCP/IP-стек" не будет MAC уровня под Ваше железо или вообще, либо MAC будет написан минимально-формально.

Так я, если Вы заметили, именно за это и голосую обеими руками..

А именно, всё железо-зависимое нужно вынести в сетевой драйвер. В этом драйвере и будут жить все железо-зависимые функции MAC уровня, типа SGDMA, IO, MDIO, и пр. (ессно, в зависимости от возможностей процессора). При этом сам TCP/IP-стек должен быть максимально независимым от аппаратной платформы, т.е., "НЕ уникальным" и иметь четко выраженный формализованный интерфейс на основе стандартных вызовов: OpenDevice(), DeviceIOCtl(), SyncRead(), SyncWrite(), CloseDevice(). В этом случае, при переходе на другую платформу, нужно будет переписать только драйвер. TCP/IP-стек, при этом, останется без изменений.

Как-то так..

[zltigo]

и иметь четко выраженный формализованный интерфейс на основе стандартных вызовов

Примитивность этого формализованного интерфейса обычно и гробит возможности MAC железа сводя их к нескольким унылым примитивам. В результате чего приходится править этот самый "независимый" (от разума) стек до получения приемлимого результата за счет правильного использования MAC железа. Или наращивать мегагерцы и ядра для компенсации "унифицированного" подхода к работе.

[VslavX]

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

А что там по Вашему должно быть? Очереди входящих и исходящих пакетов, функция руления линком и его параметрами - разрешение/запрет, выбор скорости, MDX, можно еще доступ к регистрам PHY для доступа к его особому функционалу. Ну у меня есть еще колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования. А чего еще от MAC-а нужно-то?

[zltigo]

А что там по Вашему должно быть?

Там должно быть то, что позволит полностью использовать возможности конкретного железа. Вот у Вас есть то, что Вы назвали "колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования". Вы еще мечтаете об использовании аппаратного CRC. Как это ложится на нечто абстрактно универсальное взаимодействие с MAC уровнем массово низводимое разработчиками "универсальных" стеков в своей основной функции до передать/принять фрейм?

[Rst7]

ИМХО, как раз LPC17xx неудачно выбран для иллюстрации уникальности стека.

Ну почему же? Вполне такой себе середнячок по нынешним временам. Мейнстрим.

то на LPC17xx (у которого ресурсов более чем) это вызывает удивление.

Ресурсов более чем? Очень странное заявление. Нет, ну если, конечно, светодиодом через веб-интерфейс мигать - тогда, конечно, да. Но заявки-то - "хотим 100M через TCP". А теперь давайте считать. Все ОЗУ там - 64кБайт. При скорости в почти 12 Мбайт/с и полностью занятым под буфера TCP ОЗУ максимальный round-trip time, с которым можно обеспечить эту самую дико желаемую всеми цифру - всего 5 миллисекунд.

В реальной жизни это означает, что три обычных неуправляемых L2-свича в гирлянде приведут к падению скорости и ничего Вы стандартным построением TCP-стека не сделаете. А если это, скажем, из подсетки в подсетку, разделенные даже адекватной Циской с L3 маршрутизацией - то все, зопа.

[VslavX]

Там должно быть то, что позволит полностью использовать возможности конкретного железа.

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

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

И что? Эта неплохая технология позволяет жить и довольно быстро меняться без потери пакетов десятку сокетов, используя всего 16К памяти. Если памяти много и квоты никого не инетересуют, то это ведь можно и отключить.

Вы еще мечтаете об использовании аппаратного CRC. Как это ложится на нечто абстрактно универсальное взаимодействие с MAC уровнем массово низводимое разработчиками "универсальных" стеков в своей основной функции до передать/принять фрейм?

Вполне нормально ложится, есть резервное место в поле флагов в пакете (которое при желании расширяется). Если MAC умеет проверять суммы при приеме, то в поле свойств интерфейса будет стоять флажок "а смотрите как я круто умею проверять/считать суммы". И процедура приема пакетов (ессно, версия которая скомпилирована с флагами что у нее могут быть такие умные интерфейсы) просто будет смотреть и проверять во входящих пакетах на таких умных интерфейсах этот флажок, вместо тупого вызова tcp_check_sum. И с отправкой аналогично. В-общем, такой себе out-of-band канал в интерфейсе с MAC-ом должен быть, и это все не моя придумка - идеология подсмотрена в NDIS.

[zltigo]

И что? Это неплохая технология

А я что-то плохое говорил??? Я просто отметил, что Вам стало тесно в рамках простейшего взаимодействия между уровнями. Это НОРМАЛЬНО.

Вполне нормально ложится, есть .... если ... то .... просто будет ....

Так о чем Вы это? О том, что можно добавить, углубить, расширить, улучшить.... Так я ровно о том-же, что можно, но и в первую очередь о том, что в абстрактном стеке всего этого НЕТ и придется его дорабатывать под возможности MAC. Либо НЕ дорабатывать - и так сойдет.

[VslavX]

конечно, да. Но заявки-то - "хотим 100M через TCP". А теперь давайте считать. Все ОЗУ там - 64кБайт. При скорости в

Это заявки оторванные от реальности. Передать-принять 100мбит/сек, допустим, у Вас получилось, и похоже таки со 100% загрузкой ядра (раз 92 мбита из 95), но кто на этом проце и всего с 64К памяти осмысленно сгенерировать или обработать 12Мбайт/сек сможет? Вы можете привести пример, когда на LPC17xx нужно 100Мбит/сек и от этого будет смысл?

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

Да и на Вашей реализации тоже ничего не сделаете. Как только данные станут осмысленными (а не генератор ПСЧ), то в приложении у Вас появится буфер, и упретесь в те же самые 64K.

[Rst7]

и похоже таки со 100% загрузкой ядра (раз 92 мбита из 95),

А вот тут тонкость. Я малость оптимизировал (сократил в два раза с 30 до 15мкс) расчет IP Checksum, а результат не изменился. Так что CPU load там походу меньше 100%, но пока неясно недостижение теорпредела. Раз пошла такая пьянка, то я решил таки доделать вменяемую процедуру отправки пакета, которая не будет ждать готовности тупо в цикле. Правда, за сегодня сделать не успел, но, думаю, завтра получим нормальные данные по загрузке CPU.

Да и на Вашей реализации тоже ничего не сделаете. Как только данные станут осмысленными (а не генератор ПСЧ), то в приложении у Вас появится буфер, и упретесь в те же самые 64K.

Ну я понимаю, что http-сервер недостаточно осмысленные данные генерирует, но ладно Придется таки сделать читалку с SD с топовой скоростью. C 45DB даже смысла обсуждать нет, ибо там есть вообще произвольное чтение.

[VslavX]

Ну я понимаю, что http-сервер недостаточно осмысленные данные генерирует, но ладно

Хм, а разве он их генерирует, а не просто берет ресурс из флешки? Тогда это у Вас аналог буфера на 512К, просто тип буфера const

Придется таки сделать читалку с SD с топовой скоростью. C 45DB даже смысла обсуждать нет, ибо там есть вообще произвольное чтение.

Имхо, не получится с SD по SPI ничего с нормальной скоростью прочитать. Ну в идеале будет 3Мбайт/сек - больше просто SPI не позволит. Надо ждать LPC1788 - там SD контроллер 4-битный и аппаратный, вот там можно попробовать до 100Мбит подняться.

[Rst7]

Хм, а разве он их генерирует, а не просто берет ресурс из флешки?

Распаковывает на ходу и подставляет изменяемые параметры. Даже если и рассматривать флеш как буфер на 512к, у Вас-то такого нет

Имхо, не получится с SD по SPI ничего с нормальной скоростью прочитать.

Да ладно, я ногодрыгом 4хбитный интерфейс сэмулирую, мне не привыкать.

[VslavX]

А вот тут тонкость. Я малость оптимизировал (сократил в два раза с 30 до 15мкс) расчет IP Checksum

Это для пакета в 1460 байт? Примерно 1 такт на байт? Можно глянуть код основного цикла подсчета? Потому как у меня полтора такта на байт выходит.

[Rst7]

Это для пакета в 1460 байт? Примерно 1 такт на байт? Можно глянуть код основного цикла подсчета? Потому как у меня полтора такта на байт выходит.

Да. Я щас не у своего рабочего компа, завтра буду у него, выложу. Хотя... Момент...

SVN - великая вещь

CODE

static UREG16 IPChecksum(UINT16 *data, UREG16 len)
{
unsigned long long acc=0;
UINT32 *p=(UINT32*)data;
UREG i=len>>5;
if (i)
{
len-=i<<5;
do
{
acc += *p++;
acc += *p++;
acc += *p++;
acc += *p++;
acc += *p++;
acc += *p++;
acc += *p++;
acc += *p++;
}
while(--i);
}
i=len>>2;
if (i)
{
len-=i<<2;
do
{
acc+=*p++;
}
while(--i);
}
data=(UINT16*)p;
if (len >=2) {acc+=*data;len-=2;}
if(len == 1)
{
acc += *(UINT8 *)data;
}
do
{
acc=(acc&0xFFFF)+(acc>>16);
}
while((acc>>32));
UINT32 acc32=acc;
do
{
acc32=(acc32&0xFFFF)+(acc32>>16);
}
while((acc32>>16));
return (~acc32)&0xFFFF;
}

Ну такое, туповато, но действенно.

[VslavX]

Распаковывает на ходу и подставляет изменяемые параметры. Даже если и рассматривать флеш как буфер на 512к, у Вас-то такого нет

Ничего, зато у меня много чего другого есть
Кста, сегодня я коллегам (которые пишут приложения юзающие мой стек) предложил "покрутить окно руками" и нарвался на встречное предложение "покрутить мое лицо ногами" . Ну не нужны им проблемы протокола - там у них своих хватает.

Да ладно, я ногодрыгом 4хбитный интерфейс сэмулирую, мне не привыкать.

А что - на PIO получится 25МГц выдать? Да и процессорного времени отожрет, ну да ладно.

[Rst7]

А что - на PIO получится 25МГц выдать?

Ну придется извратнуться, конечно. Главное там - не процом ждать готовности, на этот предмет есть пара идей.

и нарвался на встречное предложение "покрутить мое лицо ногами"

Ну это кто на что учился.

[aaarrr]

Да ладно, я ногодрыгом 4хбитный интерфейс сэмулирую, мне не привыкать.

А еще придется CRC16 считать для каждой из четырех линий отдельно. Не стоит овчинка выделки - сделать можно, но скорость едва ли будет выше чем при работе через SPI.

[Rst7]

А еще придется CRC16 считать для каждой из четырех линий отдельно.

Ох ты... Этот момент я как-то просмотрел. Надо, конечно, подумать, но, боюсь, что Вы правы, зопа.

[Rst7]

Не стоит овчинка выделки - сделать можно, но скорость едва ли будет выше чем при работе через SPI.

По моим расчетам скорость вытаскивания данных из SD может быть 8 мегабайт/с. Это ногодрыгом с одновременным расчетом CRC. Вроде бы, конечно, если не обсчитался.

[Rst7]

Сделал правильный отправлятель пакетов (без тупого ожидания) и отображение загрузки CPU.

 NikeE_CM3_rev1315.zip ( 357.68 килобайт ) Кол-во скачиваний: 146


Почему-то рассчитанный мной теорпредел не достигается (числа пляшут в районе 91..92Мбит/с), но мне сейчас нечем разобраться - нет достаточно быстродействующего осциллографа, чтобы рассмотреть точно паузы между пакетами.

При этом загрузка процессора - 43%.

[RA3WUM]

Rst7
Сколько данный стек занимает RAM? В LPC1114 можно использовать?

[Rst7]

Сколько данный стек занимает RAM? В LPC1114 можно использовать?

Дык тут нижний уровень не такой, как на AVR, тут используется модуль EMAC в LPC17xx, никакой рукопашной, как это в том проекте. Повторять эпопею мне что-то не улыбается.

Или как Вы его хотите использовать? От этого, кстати, и требования к ОЗУ зависят.

[RA3WUM]

Или как Вы его хотите использовать? От этого, кстати, и требования к ОЗУ зависят.

Хочу сделать относительно дешёвый декодер mp3 или ogg потока по http (интернет-радио) через wi-fi модуль. Соответсвенно скорость порядка 96-192 кБит/с.

[Rst7]

Соответсвенно скорость порядка 96-192 кБит/с.

Источник где? В большом интернете? Тогда не годится, будет икать, мало места под буфера.

Расчет такой - сделайте пинг в ваше любимое радио, посмотрите время ответа - это так называемый Round Trip Time.

Допустим, мы подобрали MTU так, чтобы нам сыпалось много маленьких пакетиков с данными - пусть не очень экономно, зато можно быстро перевести сервер в состояние Fast Retransmit при потере пакета. Будем для простоты считать, что уведомление серверу о потере пакета начинает лететь сразу после этого события. Значит, повтор пакета произойдет за время Round Trip Time. Но за это время нам упадет много новых пакетов, которые необходимо сохранить, ибо они валидные. Суммарно этих данных будет ваше 96-192кБит/с умножить на RTT. Ну, скажем, RTT будет 50мс - адекватная цифра для современных интернетов. За это время упадет 5-10 килобайт данных, которые надо сохранить. Плюс, кстати, к ним еще служебная инфа.

[RA3WUM]

Источник где? В большом интернете? Тогда не годится, будет икать, мало места под буфера.

Расчет такой - сделайте пинг в ваше любимое радио, посмотрите время ответа - это так называемый Round Trip Time.

Конечно в большом, у меня пинг от 16-75 миллисекунд в зависмости от радиостанции.
Что нужен внешний буфер это понятно. В некоторых конструкциях web-радио используются RAM или FRAM с интерфейсом SPI.
Последняя кстати у меня и живьём есть, так что планирую её поставить.
В качестве декодера VS1053.
Если не ошибаюсь на вашем стеке уже делали интернет-радоприёмник?

[Rst7]

Если не ошибаюсь на вашем стеке уже делали интернет-радоприёмник?

Да. Но почему именно LPC1114? Зачем? Я бы еще понял, если бы он был декодером. Вот только не влезет. А вот, кстати, в LPC1768 я бы весь мотлох попробовал бы запихать - декодер тоже.

[RA3WUM]

Да. Но почему именно LPC1114? Зачем? Я бы еще понял, если бы он был декодером. Вот только не влезет. А вот, кстати, в LPC1768 я бы весь мотлох попробовал бы запихать - декодер тоже.

В моих краях его проще достать и он дёшев (меньше 3 баксов). С LPC1768 всё намного хуже обстоит.
С точки зрения экономии конечно можно заставить декодировать mp3 кристалл из LPC17-й серии. Но в моём случае что есть под рукой, от того и отталкиваюсь.

[Rst7]

Но в моём случае что есть под рукой, от того и отталкиваюсь.

VS1053 тоже завалялась под рукой? Ценой, кстати, под десятку баксов

[Rst7]

Поигрался с dummynet, подправил некоторые неточности.

Ревизия 1318 -  NikeE_CM3_rev1318.zip ( 357.97 килобайт ) Кол-во скачиваний: 518

[RA3WUM]

VS1053 тоже завалялась под рукой? Ценой, кстати, под десятку баксов

Да она есть, точнее эволюшнкит с исходниками. Как и wi-fi модуль ZeroG ZG2100M.
lpc1114 можно "занять" графическим интерфейсом пользователя на lcd от siemens S65 или аналогичного.

Сообщение отредактировал RA3WUM - Jul 30 2011, 11:59

[VslavX]

Небольшой апдейт про "Машу"
Включил ключик компилятора для оптимизации по скорости, внес еще пару коррекций в RTOS (давно уже ждали, но руки не доходили) - в-общем, достигнуто 83.3Мбит/сек - 16 мегабайт чистых данных ушло за 1610мс. В принципе, достигалось и 86Мбит/сек - но после патча драйвера EMAC на приоритет событий отправки, при этом оно принимать при ограниченном буфере похуже будет, поэтому такой вариант я забраковал. Имхо, вполне приличный результат для полноценного универсального стека - проигрывает по скорости узкозаточенному совсем немного -10-15 процентов.
Есть еще небольшой резерв - цикл подсчета chksum/копирования исходящих пакетов я не разворачивал, но там сложная функция на асме (одна из трех для всего стека, которые от проца зависят) - лениво уже переделывать. Из печального - загрузка процессора у меня при такой массированной отправке 99% - увы, такова плата за универсальность решения. Если отправлять осмысленные данные (считаем что заберем половину проц.времени) то эффективная скорость на LPC17 - 5Мбайт/сек. Где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут, выходит даже эти 5Мбайт/сек - сферический конь в вакууме, потому как их нечем загрузить.

[prottoss]

Небольшой апдейт про "Машу"... ...где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут, выходит даже эти 5Мбайт/сек - сферический конь в вакууме, потому как их нечем загрузить.

Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК.

[VslavX]

Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК.

Почему? Энергопотребление? Да там PHY потребляет само по себе стока же сколько и LPC17 в макс нагрузке. А эти 5Мб/сек - при половинной загрузке.

[Rst7]

Имхо, вполне приличный результат для полноценного универсального стека - проигрывает по скорости узкозаточенному совсем немного -10-15 процентов.
....
Из печального - загрузка процессора у меня при такой массированной отправке 99% - увы, такова плата за универсальность решения.

Ага, из суперпечального Т.е. таки два раза (даже больше), ибо у меня 43% CPU Load.

Дак, ИМХО, глубокий смысл не в том, где взять такой поток, а в том, чтоб меньше загрузить МК.

Безусловно.

А эти 5Мб/сек - при половинной загрузке.

Ну а у меня - при четверти

[prottoss]

Почему? Энергопотребление?

Не только. Меньше загружен МК одной задачей - больше задач можно выполнить... 2Х2

[Rst7]

Где на LPC17 взять такой реальный поток данных - непонятно, ни SD, ни USB, ни UART, ни ADC такого не дадут

Прямое чтение с GPIO (или через DMA) вполне такой поток даст. Скрестить что-ли с JPEG-кодером ради прикола Я как-то делал вариант того веселого проекта в ARM-инкарнации на LPC2134, микросхеме SDRAM (окученной ногодрыгом) в качестве видеопамяти и SAA7113 в качестве АЦП. Уж не помню уже подробностей, но в разрешении 320*240 порядка 15 кадров в секунду Ч/Б можно было обработать (тактовая была 54МГц). На CM3 со 100МГц будет веселее и по мегагерцам и по общей производительности.

[VslavX]

Ага, из суперпечального Т.е. таки два раза (даже больше), ибо у меня 43% CPU Load.

А ничего что мое решение обладает на порядок большими фичами? Можно за минуту этот стек скомпилировать на 4 совершенно разных платформы, или за 5 минут написать на его основе бридж или роутер. И свои приложения пользователям на нем попроще (мягко говоря) писать. Так что проигрыш всего 10 процентов скорости - это очень невысокая плата. Да, еще момент - мое решение заточено больше на прием, и путь данных по приему несильно от Вашего отличается (только рулежка окнами автоматическая , а еще Out-of-Order Segments и Selective ACK), передача - по остаточному принципу, что там в квотах на память останется. Так что сравнение скорости передачи - максимально невыгодное для меня. Я все-таки на досуге напишу тестовую утилиту - чтобы и прием, передача, эхо, да по нескольким сокетам одновременно, там еще померяемся .

Прямое чтение с GPIO (или через DMA) вполне такой поток даст.

Даст, но это тот самый случай когда REGENERATE все это зарежет на корню - надо будет заводить большой буфер и хранить в нем DMA-нутые данные до ACK-а по TCP. Ну или терять данные, но это как бы неспортивно

[Rst7]

Так что проигрыш всего 10 процентов скорости - это очень невысокая плата.

Проигрыш у Вас, повторюсь, в два раза. Физический предел, будем считать, Вы тоже почти достигаете, но при загрузке в 100%. У меня в этом случае - загрузка 43%.

Даст, но это тот самый случай когда REGENERATE все это зарежет на корню - надо будет заводить большой буфер и хранить в нем DMA-нутые данные до ACK-а по TCP.

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

[VslavX]

Проигрыш у Вас, повторюсь, в два раза. Физический предел, будем считать, Вы тоже почти достигаете, но при загрузке в 100%. У меня в этом случае - загрузка 43%.

А я не спорю что проигрыш, архитектура совершенно другая, и реализация обобщенная, и сравнение (на передачу) невыгодное. Было бы удивительно если универсальное решение выиграло у специализированного.

Буфер-то этот можно иметь и внутри проца - сколько надо (или сколько можно), столько и выделить. Это не скажется на быстродействии

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

[Rst7]

а еще Out-of-Order Segments и Selective ACK

Я с одним знакомым реализовывал обработку Fast Retransmit в приемнике этого стека (не в выложенных версиях). Ну что могу сказать - работает. Для интернет-радио помогает здорово. Буфер, конечно, требуется.

Было бы удивительно если универсальное решение выиграло у специализированного.

Почему Вы так упорно называете мое решение "специализированным"? Два дня на порт с AVR (между прочим, с софтовым MAC'ом) на LPC (EMAC железный) - это жесть какая специализация, все надо было с нуля переписать

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

Ну, если по байтику носить - то, конечно, зопа. Намекаю - допустим, из периферии у Вас в буфер данные достает DMA. Считаем, что CPU load равен нулю. Вменяемый memcpy из этого буфера - это даже быстрее из расчета на байт, чем текущий генератор рандомов:

CODE

     41              r=r*1103515245+12345;
   \   0000002C   0CFB0676           MLA      R6,R12,R6,R7
     42              *((UINT32*)data)=r;
   \   00000030   41F8046B           STR      R6,[R1], #+4
     43              data+=4;

[VslavX]

Я с одним знакомым реализовывал обработку Fast Retransmit в приемнике этого стека (не в выложенных версиях). Ну что могу сказать - работает. Для интернет-радио помогает здорово. Буфер, конечно, требуется.

При приеме я сталкивался с реализациями TCP где FR реализован весьма своеобразно - например в QNAP NAS (на базе линуха). Вот он фигачит поток на все окно, невзирая на то как там приходят ACK-и, есссно, пакеты начинают "по дороге" пропадать (не всякий свич спокойно пропускает 125Мбайт/сек), и если не реализован SACK, то наступает зопа.

Почему Вы так упорно называете мое решение "специализированным"?

Дело не в порте и не в архитектуре - хотя, если тут перейти на RTOS, то это свою плату возьмет и может стать не так весело. Специализировано потому что заточено на одну конкретную среду передачи и жестко привязано к набору Ethernet/ARP/IP/TCP. И чтобы получить, например, другую среду, или мультинтерфейсность то надо это решение капитально дорабатывать. Но самое неприятное, имхо, колбеки - это далеко не самый простой и удобный вариант для разработки приложений (приходится делать то что нужно, а не то что хочется ), все проблемы буферизации и синхронизации вынесены на сторону приложения, к тому же еще требуется обслуживать проблемы протокола - то есть в общем случае вопрос протокола TCP этим кусочком кода полностью не закрыт.

Ну, если по байтику носить - то, конечно, зопа. Намекаю - допустим, из периферии у Вас в буфер данные достает DMA. Считаем, что CPU load равен нулю.

OK, согласен.

P.S. Кстати, а не хотите сделать функцию которая копировала бы данные в передающий буфер и одновременно считала IP_checksum - такую себе замену memcpy. И сохранять эту сумму где-нить в сокете. При отправке смотреть - 0 - значит приложение копировало или генерировало само, а не 0 - значит это сумма payload-а и можно только досчитать сумму заголовков и все.

[Rst7]

хотя, если тут перейти на RTOS, то это свою плату возьмет и может стать не так весело.

Не пора ли завязывать есть эти кактусы, кстати? Опять я каждый раз слышу - "а мне надо под RTOS/будет сильно медленнее". Не читайте перед обедом советских газет пользуйтесь RTOS, пишите свои фреймворки с вменяемым быстродействием. У меня в последнее время вообще желание пропало - все равно машины состояний в прерываниях с верно выбранными приоритетами эффективнее. На худой конец есть setjmp/longjmp - это чтобы организовать поток по быстрому/по местному. На CM3, кстати, опять можно эффективно использовать.

Про быстродействие malloc/free (особенно тех реализаций, которые доступны вместе с исходниками обычно используемых RTOS) - отдельный разговор. Вопрос, вызывающий обычно батхерт у RTOSописателей и RTOSопользователей (средней продвинутости, умные - те всякими пулами памяти пользуются и всякие изобретения изобретают) - "На сколько максимально времени ваш malloc (или free) блокирует шедуллер"?

Но самое неприятное, имхо, колбеки - это далеко не самый простой и удобный вариант для разработки приложений

Зато эффективный в условиях недостатка ресурсов и куда более гибкий. Конечно, посложнее в использовании, хотя мне, например, уже давно пофиг, я не беру в работу проекты, в которых во главу угла поставлено "time to market".

Конечно, пионер предпочтет по байтику вызывать send или recv - у меня были такие заказчики и у них были свои "программисты высокого уровня" (дословно), пришлось их заставить читать из стека по одному байту для получения строки до \n. Иначе они не могли, не получалось у них сделать вменяемую буферизацию, при этом обычная отмазка у них была такая - "Ваш прибор присылает неправильные данные". Хотя, понятное дело, в telnet'е все было верно, но это же не показатель для таких супер-специалистов

Нет, понятно, за пару десятков килопрезидентов я бы написал им адекватный код для большого брата. Но ведь "нет ручек - нет и апельсинчиков" (цэ)

Кстати, а как Вы организовываете http-сервер и разбор входящих строк? Не многовато ли буферов используете в общем зачете?

Я, понятное дело, строки разбираю прямо в пришедшем пакете машиной состояний. Никаких накладных расходов.

и если не реализован SACK, то наступает зопа.

Я тоже рассматривал вопрос реализации SACK. Вот только не помню, какой-то узкий момент отложил имплементацию. Уж не помню какой. Надо освежить в памяти соответствующий RFC и, наверное, заимплементить.

P.S. Кстати, а не хотите сделать функцию которая копировала бы данные в передающий буфер и одновременно считала IP_checksum - такую себе замену memcpy. И сохранять эту сумму где-нить в сокете. При отправке смотреть - 0 - значит приложение копировало или генерировало само, а не 0 - значит это сумма payload-а и можно только досчитать сумму заголовков и все.

Мысль, конечно, интересная и здравая. Если крепко придавит - реализую.

[zltigo]

Не пора ли завязывать есть эти кактусы, кстати? Опять я каждый раз слышу - "а мне надо под RTOS/будет сильно медленнее". Не читайте перед обедом советских газет пользуйтесь RTOS, пишите свои фреймворки с вменяемым быстродействием.

Написание и использование RTOS (кстати, ои очень очень разные встречаются) абсолютно не накладывает никаких ограничений на использование каких-либо других средств, ЕСЛИ в этом есть необходимость. И malloc/free предоставляют возможность разрешить проблему нехватки памяти. Написание чего-либо уникального, на самом деле тоже не проблема, поскольку используются наработанные приемы и кубики, но в общем случае достаточно бессмысленное занятие, поскольку важны узкие места и время лучше тратить на их расшивку. И еще, даже при наличии опыта и заготовок изготовление некой штучной "системы" тем не менее черевато неочевидными системными ошибками , а оно это надо?

[Rst7]

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

Да я не протестую против использования RTOS. Я протестую против бездумного использования. Фраза "будет сильно медленнее" именно из-за этого вызывает ненависть. Ну и вообще, общедоступного "портабельного и читаемого" гуано на эту тему в интернетах не меньше, чем TCP-стеков.

[VslavX]

Не пора ли завязывать есть эти кактусы, кстати? Опять я каждый раз слышу - "а мне надо под RTOS/будет сильно медленнее". Не читайте перед обедом советских газет пользуйтесь RTOS,

Никаких кактусов, кста . Когда в проекте за полмиллиона строк и на их базе нуна пару раз в месяц генерить релизы для разных заказчиков на разных платформах, то поневоле задумаешься как это все структурировать-стандартизировать и чтобы не то что легче жить стало, а чтобы это все банально не загнулось. Ессно, работают несколько человек - и взаимодействие между ними тоже надо в какие-то рамки укладывать. Все это уже на практике проходили. И на асме проиложения 20 лет назад писали, перешли на C- получили скачок в скорости и качестве разработки. И машины состояний на прерываниях делали - потому как ресурсов не было, появились ресурсы - перешли на RTOS, и снова скачок в качестве и скорости разработки.

пишите свои фреймворки с вменяемым быстродействием. У меня в последнее время вообще желание пропало - все равно машины состояний в прерываниях с верно выбранными приоритетами эффективнее.

Смотря что считать эффективнее - если больше успеешь сделать, при этом меньше устанешь да и в кармане будет больше звенеть, то вот это и есть эффективность. Например, машину на прерываниях для управления ударным печатающим механизмом я писал примерно три недели - шаговые двигатели с разгоном-торможением, управление кареткой, графика/текст, взаимодействие с основной программой. А в отдельной задаче RTOS - три дня. 12 рабочих дней - мой чистый профит. Ну да, оно взяло чуток больше памяти и проц времени, но ТЗ и time-to-market удовлетворило. В-общем, я лет 15 не слазил с этих машин на прерываниях, оно конечно приятно и красиво - штучный товар, при разработке получаешь удовольствие, но хрен Вы меня на них обратно с RTOS-а сдернете. Мож я просто старый и ленивый стал

Про быстродействие malloc/free (особенно тех реализаций, которые доступны вместе с исходниками обычно используемых RTOS) - отдельный разговор.

Угу, все именно так. Поэтому malloc/free у меня и нету - только пулы. Но там у меня много навернуто - референс каунтеры (из стека не то что сокет - интерфейс можно асинхронно удалить - например при выдергивании USB такое может быть), квоты, оповещения интерфейсов/сокетов/приложений о появлении памяти. Сейчас, кста, по прошествии времени видно что кое-что из этих задумок лишнее, надо будет пооптимизировать/под флаги компиляции убрать. Глядишь и я wire-speed достигну .

Зато эффективный в условиях недостатка ресурсов и куда более гибкий. Конечно, посложнее в использовании, хотя мне, например, уже давно пофиг, я не
беру в работу проекты, в которых во главу угла поставлено "time to market".

Ну значит Вы счастливчик, что можете это себе позволить. Но ресурсы нынче дешевы, их тоже многие могут себе позволить и выполнить "презренный time-to-market" не будучи таким виртуозом как Вы.

Кстати, а как Вы организовываете http-сервер и разбор входящих строк? Не многовато ли буферов используете в общем зачете?

А в том же сегменте где пришел и разбираю. То есть - MAC кладет в цепочку приемных сегментов - эта же цепочка попадает приложению HTTP, и в них и идет анализ. Закончился - вернули буфера обратно стеку. От Вашей ситуация отличается только тем, что разбор идет не в колбеке где даже почесать себя нигде нельзя, а в отдельном потоке и никто при этом в спину не дышит (ну кроме market-а ).

[Rst7]

Угу, все именно так. Поэтому malloc/free у меня и нету - только пулы.

Приятно видеть адекватного профессионала Я, собственно, выше на пост zltigo отвечал, там отметил, что протест вызывает бездумное использование. Рад, что Вы в курсе дела. Тогда мне непонятно, почему Вам кажется, что при использовании RTOS сильно упадет производительность?

[VslavX]

Да я не протестую против использования RTOS. Я протестую против бездумного использования. Фраза "будет сильно медленнее" именно из-за этого вызывает ненависть.

Я не сказал "сильно медленее", я сказал - "возьмет свою плату". Какую - мне пока не ясно. Будет время - я попрофайлю свой стек, потому как не совсем понятно куда время процессорное ушло. Дополнительное копирование 10Мбайт/сек могло отожрать ну 10% от 100МГц, но не 60% же. RTOS тоже по идее не должна бы - 16 мегабайт это примерно 12тыс исходящих и 6 тыс входящих пакетов, ну пусть 20тыс всего, по два переключения контекста по 2мкс - 40мс из 1600мс. Тоже отнюдь не 60%. Надо зарытую собаку искать, поэтому тут не тока спортивный интерес с моей стороны.