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

[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, никакой рукопашной, как это в том проекте. Повторять эпопею мне что-то не улыбается.

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