Доброго дня!

Надеюсь Юрий Тёмкин прочитает этот топик...

Использую LPC2387 с TNKernel и TN NET TCP/IP stack и хочу
в первую очередь сказать огромное спасибо Юрию за отличную работу.

Моя задача: Логгер (server) должен поереносить на запрос записанные данные с 2GB SD флеш к PC
Эти данные переносятся в блоках переменной величины.
Проблема: Стек переност 2 пакета по128 байт на 1 ACK, и если переность кратное от 128 байт
то всё прекрасно. Но при неудачном случае если 2 последних TCP пакета 128 и к примеру 100 байт то
то стек не посылает срзу второй пакет (100 байт,) а ждёт ACK на первый, тот приходит на первые 128 байт
с задержкой до 200мс. Что не приемлемо для моей задачи.

Это поведение описано в Delayed ACK - RFC1122

Возможно ли изменить это поведение в TN NET TCP/IP stack или сокетах со стороены PC
Windows, Visual Studio WTL?
До этого исползовал WIZnet c XC167 где второй пакет посылается сразу не зависимо о длинны данных.

Взаранее благодарен.

Не проще "добить" второй пакет фигней до 128 байт?

Попробуйте в ф-ции s_send() параметр flags выставить как MSG_OOB.

Блогодарю за ответ - это то что нужно!
MSG_OOB достаточно наверно только при посылке послкеднего пакета передавать?
Можно конечно и заполнить пакет во 128 байт, но это требует изменения в другом софте да и в мото-спорте каждая секунда дорога.

Так как скорость переноса зависит от величины пакета то хочу задать ещё один вопрос:
Как изменить максимальную величину посылакмого пакета стеком?

Как я понял это константа TCP_MSS в tn_tcp.h. Но столкнулся с TNNET_MID1_BUF_SIZE которая тоже
128 байт и NUM_MID1_BUF которые, как я понял, зависимы друг от друга.

512 байт было бы для меня идеально так как соответствует сектору флэшки.

Разобрался немного, в комментаре Юрия ясно написано: TCP_MSS 512 и всё поехало!
Ещё один вопрос для меня осталя открытым: Каким путём сократить расход операционной памяти стеком?
Использует кто этот стек вообще, или только я по незнанию задаю глупые вопросы?

Уважаемые коллеги - SOS!!!
Проблема с которой уже 3 дня бъюс без успеха:
Всё работало прекрасно до тех пор как написал бутлодер.
Всё зделал как на сайте оси описано и в дебагере всё выглядит хорошо.
Но как только зарускаю без дебагера длится ровно 2 минуты пока начинается переключение задач.
После 2 минут задержки всё как в сказке хорошо...

Инициализация железа проходит до конца, потом видно висит в tn_idle_task_func()
и irq не вызываютя. Но почему через 2 минуты начинают прерывания опять работать и
кто их задерживает/освобождает? Прям хоть в бубен стучи...

Может кто сталкивался с подбным феноменом.
IAR 5.40.1 , TNKernel ver 2.5.1, TN-Net V0.9

Бубен не принёс желаемых результатов но причину задержки 2х секунд нашёл (и это будет сегодня основательно...):
в bootloader использывается тоже таймер0, при входе в приложение все прерывания запрещаются
и таймер0 инициализируется по новой где забыто сам счётчик T0TC обнулить. Таким образом к времени
инициализации он находится уже за границей сравнения занесённой в T0MR0
и превое прерывание происходит после переполнения счётчика T0TC
и достижения значения T0MR0 по новой, что в моём случае длится 2 секунды.