реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> TNKernel в TN NET TCP/IP stack, Delaye ACK
prgjz
сообщение Nov 27 2009, 12:14
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 59
Регистрация: 3-01-07
Из: Germany
Пользователь №: 24 071



Доброго дня!

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

Использую 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 где второй пакет посылается сразу не зависимо о длинны данных.

Взаранее благодарен.
Go to the top of the page
 
+Quote Post
Dron_Gus
сообщение Nov 28 2009, 12:33
Сообщение #2


Профессионал
*****

Группа: Свой
Сообщений: 1 202
Регистрация: 9-01-05
Из: Санкт-Петербург
Пользователь №: 1 861



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


--------------------
Если сверху смотреть, то сбоку кажется, что снизу ничего не видно.
Go to the top of the page
 
+Quote Post
yuri_t
сообщение Nov 28 2009, 15:02
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937



Попробуйте в ф-ции s_send() параметр flags выставить как MSG_OOB.
Go to the top of the page
 
+Quote Post
prgjz
сообщение Nov 30 2009, 11:28
Сообщение #4


Участник
*

Группа: Участник
Сообщений: 59
Регистрация: 3-01-07
Из: Germany
Пользователь №: 24 071



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

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

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

512 байт было бы для меня идеально так как соответствует сектору флэшки.
Go to the top of the page
 
+Quote Post
prgjz
сообщение Dec 8 2009, 09:42
Сообщение #5


Участник
*

Группа: Участник
Сообщений: 59
Регистрация: 3-01-07
Из: Germany
Пользователь №: 24 071



Разобрался немного, в комментаре Юрия ясно написано: TCP_MSS 512 и всё поехало!
Ещё один вопрос для меня осталя открытым: Каким путём сократить расход операционной памяти стеком?
Использует кто этот стек вообще, или только я по незнанию задаю глупые вопросы?
Go to the top of the page
 
+Quote Post
prgjz
сообщение Dec 10 2009, 16:31
Сообщение #6


Участник
*

Группа: Участник
Сообщений: 59
Регистрация: 3-01-07
Из: Germany
Пользователь №: 24 071



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

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

Может кто сталкивался с подбным феноменом.
IAR 5.40.1 , TNKernel ver 2.5.1, TN-Net V0.9
Go to the top of the page
 
+Quote Post
prgjz
сообщение Dec 11 2009, 12:36
Сообщение #7


Участник
*

Группа: Участник
Сообщений: 59
Регистрация: 3-01-07
Из: Germany
Пользователь №: 24 071



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

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd July 2025 - 20:54
Рейтинг@Mail.ru


Страница сгенерированна за 0.01397 секунд с 7
ELECTRONIX ©2004-2016