Попытаюсь описать проблему.
Есть 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, размеры каких-то буферов?
Не хватает знаний в области сетевых технологий, чтобы сформулировать задачу точнее.
У кого есть какие размышления? Спасибо.