uClinux. Сеть. Потоки. Real Time. Опции

[RCray]

Попытаюсь описать проблему.

Есть uClinux на BF537, работает многопоточное (pthread) пользовательское приложение.

Один из потоков (P1) отвечает за обмен данными между сетью (UDP, recvfrom, sendto) и периферийным процессором (по SPORT, но это не важно), идёт обмен критичными ко времени обмена данными. Время между обращениями к этому потоку не должно превышать T1 (скажем 20 мс).

При активировании обмена сторонними данными по сети относительно большими объёмами данных (скачивания какого-нибудь левого файла, запрос страницы по http) около мегабайта приводит к задержкам обработки нашего критичного потока >T1.

Интересно отметить, что в ligthhttpd есть такой параметр, как полоса. Можно менять её при компилировании, и тем самым страница web-интерфейса устройства грузится дольше, но передача управления потоку не выходит за рамки установленного числа T1. Для сравнения размер передаваемых данных web-страницы составляет 1,5 Мб, установка максимальной полосы (при которой страница грузится 2 сек) приводит к задержкам > T1, до 40-50 мс, установка полосы при которой страница грузится (2 мин) к задержкам > T1 не приводит. Понятно что 2 минуты это ни в какие ворота.

Размышления о TCP/IP стеке, сетевом драйвере uClinux'а привели к ключевым словам - Adeos/Xenomai/RTnet.

Перевод uClinux на Adeos/Xenomai не помог, хотя пользовательское приложение уже работает с API функциями сетевого программирования для риал-тайма. Всё-равно ситуация повторяется. Не знаю может быть это связано с тем, что остались системные вызовы (recvfrom, sendto) при работе с сетью, которые всё-равно переводят потоки из primary mode (Xenomai) в secondary mode (Linux).
Значит вопрос в драйвере сети и нужно копать в сторону RTnet и написании своего риал-тайм драйвера MAC? Или могут помочь какие-то шаманства со стеком TCP/IP, размеры каких-то буферов?

Не хватает знаний в области сетевых технологий, чтобы сформулировать задачу точнее.

У кого есть какие размышления? Спасибо.

[etoja]

Во-первых, линукс не является системой реального времени, а во-вторых , блэкфин быстрый только на маленьком внутреннем ОЗУ.

[RCray]

Это понятно. Я пытаюсь понять почему может быть задержка обработки потока и по возможности устранить эту причину.
У критичного ко времени потока максимальный приоритет из всех потоков в системе и SCHED_FIFO.

[tturist]

Хм... Если ваш веб-сервер дествительно имеет параметр nice() с минимальным приоритетом, а критичный поток обозначен как real-time, планировщик должен всегда вызывать ваш поток. Получается что планировщик вообще не вызывается в системе 40-50мс? Может быть даже в отсутствии запросов по http ваша система загружена достаточно основательно задачей обработки UDP-SPORT? Не пробовали хоть как-то оценить загрузку системы?
Какой поток данных, насколько сложную обработку выполняет нитка UDP-SPORT? Размер буферов данных как соотносится с размером кэша процессора?
При сборке ядра частота планировщика 100Гц, вытесняемость ядра включена? Версия ядра вообще свежая более менее?
Отладочные сообщения часом в консоль не выводятся (или какие-либо другие)?


Сообщение отредактировал tturist - Nov 23 2010, 07:17

[RCray]

Долго не возвращался к решению данной проблемы. Сейчас вернулся и обнаружил, что проявление проблемы исчезает при переключении устройства в 100 Мбитный свич (до этого был 10 Мбитный).

[tturist]

рад что ваша проблема разрешилась. получается ваш веб-сервер дополнительно загружал 10М ethernet потоком 6,3М. интересно было бы понять почему это приводило к таким тормозам с планировщиком. вместе с основной задачей ваши 10М не переполнялись?