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



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

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


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

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



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



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

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


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


OK, согласен.

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

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

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



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

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

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

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

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



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



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

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

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

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


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


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


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


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

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

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

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

Да она в любом случае пригодилась (и не только мне) - всегда приятно на такое посмотреть, ну и пообщаться по-поводу

Прекращаете троллить Rst7 - он же не написал что его стек мегабыстрый, мегауниверсальный и вообще лучше всех. Посмотрите стартовое сообщение.

Кстати, еще раз о FR. Вообще-то в линухах он вполне адекватно работает. А можете лог wireshark'а от такой сессии состряпать?



Толсто Плохой у нас из админа форума тролль Я, правда, тоже долго название топика выбирал, дабы вызвать побольше флуда. Но вышло вполне конструктивное обсуждение

Могу, но чуть позже - той платы под рукой нету. И оно большое - там гигабитный поток на пару секунд - под гигабайт лог, и, надо сказать, не очень адекватный, через Port-Mirroring (потому как прямой линк девайс-NAS - нету компа между ними) снималось - он немного пакеты тасует. Но факт такой - если его исходящий пакет пропадает, то невзирая на толпу ответных обычных ACK-ов с одинаковым ACKNO этот NAS сначала шлет все мегабайты что у него попросили по искази, а потом еще и виснет на 200мс с тайм-аутом. В итоге в потоке имеем простои под 200мс - неприятно. Вопрос открытый , все руки не доходят - работа с этим NAS-ом редкий случай, а с Windows оно нормально общается. Надо сказать, что QNAP все исходники выложил, и техподдержка нормальноая - если что, можно и их попинать.