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

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

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

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

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

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


Стек поддерживает 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.

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

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

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

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

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

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

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



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



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

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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


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

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

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

Можно, например, 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 суммы умеет аппаратно считать, под это дело буду также учится делать отправку данных без копирования - по ссылке.

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

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

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

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

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



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


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

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



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



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

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

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

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

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

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


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


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

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

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

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



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



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



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



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

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

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


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


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


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

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

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

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



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



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



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



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

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

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

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




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


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


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

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

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

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

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



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

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

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



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



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

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

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

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

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



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



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



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



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



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



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

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


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


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


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

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

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



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



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



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

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



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

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

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

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

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

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


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


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


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


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



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

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



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



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

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

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

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

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

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



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

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



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

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

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

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