Вот есть процесс в user space Linux. Он в цикле опрашивает порт IO (через медленную функцию доступа к IO из user space). Если там что-то случилось/не случилось, он делает некую работу.

Есть другие процессы (и сама система). Они прерывают мой процесс. Процессов таких минимум, они не сильно активны. По сети активности нет. Винчестера нет, только NOR FLASH и SD.

Если вести речь о PXA270, на 312 Мгц, то о какой "временной девиации" может идти речь? Т.е. на какое максимальное время система может прервать мой процесс? Можно ли говорить о том, что "дырка" будет не более 10 мс?

Аспекты kernel module, RTAI чур пока не трогать. Реь идет о тупом программизме в user space.

Тут еще вопрос в том, с какой частотой будет вызываться шедулер. Если период вызова шедулера будет больше или равна 10 мс, то, понятно, "дырка" может быть больше 10 мс.

В стандартном варианте, насколько я понимаю, 10 мс. Можно ли говорить о том, что "дырка" будет не более 50...100 мс?

Это можно будет утверждать только при жестко заданных условиях: какие процессы запущены, их приоритеты, какие прерывания активны и как часто они возникают, сколько времени может отнять обработка отдельного прерывания. Если знать все эти параметры, то, думаю, можно уложиться в 50 мс.

Понятно, что без описания всей остальной системы вопрос, мягко говоря, не сильно корректный. Но мне пока важно качественно понять продолжительность "дырки".

Т.е. можно говорить, что если не "дурить" в остальной части системы, время дырки для моего процесса не будет превышать 100мс. Это меня устраивает!

Задам свой вопрос.
Если написать демон или драйвер, и запустить всё это в kernel space, то что можно ожидать по задержкам?

Ни фига не гарантируется, вот навскидку несколько моментов, которые легко удлиняют switch_task jitter в несколько раз :
- способ реализации вкомпиленных в ядро драйверов устройств - любой драйвер в состоянии запретить прерывания на столько, на сколько он захочет, причем может быть неважно есть данное устройство в системе или нет
- способ взаимодействия контроллера памяти и DMA с CPU - есть всяческие пересылки, которые постоянно происходят в системе, они захватывают шину, вопрос на сколько - обычно задержки такого рода минимальны
- способ реализации захвата шины процессора набортными платами, тут поле непаханое, вот пример из Intel мира - чипсет i810/i815 с набортным видео в состоянии удерживать шину CPU до 1мс ! т.е. в зависимости от типа обмена легко получаем jitter на данных системах до 100мс

Вывод: только комплексный и правильный выбор hard и soft архитектуры может решить вопросы данного рода с порядочной долей вероятности, ну и тесты, тесты и тесты ...

Хм... Я говорил про embedded систему на PXA270. Вроде там i810/i815 не шибко нужен

Вообще "дело ясное, что дело темное". Но 100 мс, как я уже говорил, меня устраивает на крайний случай.

Вообще, по моему скромному мнению, следует внести опрос портов IO в kernel space с последующей записью в файл устройства. А далее из user space жрать из этого файла устройство все, что надо.
Если есть беспокойство по поводу того, что ядро не даст нужного приоритета для kernel module, есть один вариант (я как-то его реализовывал, но придумал не сам). Если надо, потом попробую описать.

Kernel module работает как часть ядра, т.е. о приоритете говорить не совсем корректно. Другое дело механизм передачи управления функциям из модуля. Тут есть варианты, начиная с древних BH-handlers и заканчивая потоками ядра.

Я имел в виду немного другое. В свое время пришлось решать задачу по использованию дополнительной клавиатуры, которая сидела на томже прерывании, что и стандартная. Только скан-коды у нее начинались с E1. Погеморроиться пришлось прилично. Ядро попросту игнорировало эти скан-коды. А править и пересобирать его нельзя было по условиям задачи.

- в стандартном варианте - 10мс., но при ядре старше 2.6.х вы можете эту дискретность уменьшить.

- но вы можете просто не позволять решедулировать этот процесс user space другими, играясь приоритетом и политикой диспетчеризации, тогда дискретность вам вообще до фени (только не забыть устранить всякое "динамическое управление приоритетом" со стороны ОС):



- это, в общем случае, так, но у вас, по сказанному раньше, нет особенно с фокусами ни юзеровских ни системных процессов?

- неприятность в том, что кроме штатного решедулирования вам большую (во много раз) дисперсию могут "подарить" другие механизмы: возникновение свопинга (который должен быть напрочь исключён), ... инверсия приоритетов, которую можно создать уже при 3-х процессах/потоках...
Смотрите и в эту сторону.

P.S. а вообще, именно из-за этого, что механизмы никакого Linux не гарантируют невозникновение каких-то задержек на все-все 100% - это заложено в идеологии системы - Linux ни с какими приставками RT не будет до конца RT (даже при 2-х ядерности)...
Хотя у некоторых здесь бытует мнение, что всякое RT - это некий мистификасьён ... - может они что-то знают, и будем им верить?

А kernel module никак и не решит вашу проблему: он может уменьшить и детерминировать время латентности на прерывание, или I/O операции ... но вас ведь интересует "временная девиация" в пользовательском приложении, так?

Это правильно, но есть одна загвоздка - надо уметь писать программы для kernel space.

... вот только в user space до этого нужно ждать (может и до бесконечности) RUNNING и доступа к этому файлу устройства...

В принципе, ничего сложного. Могу порекомендовать переводную книгу по этой теме:
http://www.nclug.ru/wiki/index.php?page=knz_ldd2 (Linux Device Drivers 2nd edition)
Если надо - приаттачу простой код


Тогда все нужно описывать в kernel space и уповать, что проца хватит (в должном объеме) и на эту нитку тоже...
Судя по постановке задачи, жрущих процессорное время в 3 горла процессов нет, да и активируются они редко. Тогда:
1) если не очень принципиальны редкие задержки - разделить код на User и Kernel Space
2) если очень принципиально - все в kernel space.

Хочу также обратить внимание на "быструю" и "долгую" обработку прерываний в Linux.

Нет, не надо - user space realtime это уже давно прошедший этап в RTAI.

Я помню про RTAI - с Вашей подачи познакомился с этим чудом с полгода назад. Но он есть далеко не для всех процов! Для "народного" AT91RM9200 нету. Для PXA270 свободного не видел. Вот тут хотят 300 евро, причем за image - непонятно, как там насчет GPL и исходников...
http://www.vollmann.ch/en/colibri/shop.html#pro_support

Для Cirrus EP93xxx RTAI есть - но не тянет меня на эти процы по ряду причин.

Спасибо за желание помочь - это очень приятно. LDD2, LDD3 у меня есть, с "техническим" английким проблем не испытываю. Есть даже переведенная книжка Померанца по программированию kernel module. Но как-то стремно нырять в этот омут. Я хотел вариант lite написать в user space (при помощи всяких внешних аппаратных ухищрений доведя допустимую девиацию до 100 мс), а затем, по мере набора опыта, перетащить полностью или целиком в kernel space.

Я бы так и делал, и, может оказаться, не только в lite, но и в конечном варианте...
Я не скажу наверняка, как это будет в Linux (я это не проверял), но в QNX - разумно распорядившись приоритетами, можно гарантировать, что время начала операции будет плавать между 2-4 ticksize ... но всё, что касается диспетчеризации, вытеснения + деталей отработки службы времени (а там всё совсем не очевидно) - это всё регламентируется моделями POSIX, а одна и другая ОС в той или иной мере пытаются следовать POSIX. Мне кажется, что при ticksize=10мс. вы должны определённо вписаться в 100мс. интервал, если обезопаситься от всех неожиданностей + разумно распорядиться приоритетами + использовать только статические приоритеты при RR диспетчеризации (это те, кторые RT - об этом хорошо растолковывается в такой книжке "Ядро LINUX с комментариями" ... или как-то так - нет под рукой). Потом результат можно легко проверить на адекватность ... и у вас ещё остаётся возможность переопределить в ядре ticksize в сторону уменьшения.

P.S. в конечном счёте, если это серьёзная нужда и не лень повозиться, я готов специально найти, вырезать и выслать из книжки:
http://www.books.ru/shop/books/357604
- раздельчик, где специально ставилась задача синхронизации с наименьшей дисперсией интервала, с проверкой результата (это под QNX, но GCC - может быть "в лоб" перенесено в LINUX и проверено) ... это не совсем то, но очень близкие вещи - может на что-то натолкнуть.

Спасибо! Думаю, за 150р мне проще будт ее купить QNX мне не грозит, все будет под Linux, вначале на AT91RM9200, затем на PXA270.

Какой arm значения не имеет - клавное что архитектура поддерживается ядром, заточить ядро под новый камень (их в за год с десяток появляется) дело одно-двух дней. Такой древний камень как AT91RM9200 работает под linux'ом давно, RTAI его держит, по памяти, с 2005 года.
Если требования к задаче довольно строги - перенос в kernel space особого рояля не играет.




А кстати как QNX, атмеловские кристаллы держит ?

P.S. Вот линка на текущий порт linux на атмеловское чудо: http://maxim.org.za/AT91RM9200/2.6/

Решение есть. Появилось совсем недавно, в виде патча к последнему(или одному из последних) ядер 2.6. Собственно, страница с патчем: http://kerneltrap.org/node/6750 После патча и включения его в ядро, функции usleep и nanosleep начинают работать настолько точно, насколько позволяет ваша машина. (Насколько я понимаю, зависит это от чипсета) Мне-таки удалось получить 100 микросекундную выдержку - проверял осциллографом - на PIV с i975. А на старом компьютере (PIII c VIA Apollo Pro) минимальным временем задержки стала 1 миллисекунда вместо 20 мс, что тоже неплохо. Впрочем, судя по дате последнего сообщения, это уже неактуально.

P.S. А вот интересно, под windows кто-нибудь пробовал получать задержки в порядка сотни микросекунд..?

Это так называемые RT патчи от Молнара - к реалтайму имеют слабое отношение - так как писались для сведения задержек до приемлемого уровня для multimedia apps. Чипсет тут ни причем - существует понятие time source - это может быть RTC, RTDSC,, HPET или APIC тамеры, т.е. RTAI например чудесно работает на 486SX или других подобных процах, которых полно во встраиваемом оборудовании.

Ой-Ой-Ой. Отписал не в ту тему, прошу меня извинить. Да-да, это те самые патчи, которые делают возможным брать задержки от другого источника... Но, насколько я понимаю(могу сильно ошибаться) например, HPET таймер реализуется именно чипсетом - однако, это уже оффтопик.
По теме: если вопросы переключения задач зависят в данном случае только от ядра(причем, гарантировать нужный timeslice скорее всего, нельзя), то, быть может, само ядро стоит немного подправить?))
Насколько "немного" - уже другой вопрос. Однако сама возможность не исключается?

Если переключение/и т.д. будет зависеть от ядра - то мы будем иметь классический хреновый realtime, которого полным полно (RTLinux/QNX/Linux-rt). Посмотрите как устроен adeos - это тонкая прослойка между железом и всем остальным, включая ядра (т.е. несколько совершенно различных OS не проблема) - adeos виртуализирует прерывания/таймеры/scheduler - сами ядра OS запускаются как самая низкоприоритетная RT-задача, соответственно ядра править не надо.

Прошу прощение за поднятие старой темы. Но для меня это актуально.

Т.е. я правильно понимаю, что если под linux запущу это

То мне не гарантируется меандр с периодом 200 мс на неком порте X, разряде 1? RT патчи особо не интересуют, отношение почему-то скептическое...

Прерывания обрабатывать не нужно.

Правильно.
Во-первых, sleep(100) отправит процесс спать на 100 секунд, а не на 100 мс.
Во-вторых, никто не гарантирует, что когда время сна истечет, планировщик немедленно передаст управление этой задаче. Там может оказаться много других желающих получить процессорное время...

Ну вообще я написал псевдокод. Поэтому у меня sleep засыпает на миллисекунды)))

Ок, понятно. А если еще и приложения типа интенсивно работающего веб-сервера, то вообще труба...

Спасибо!

C RT патчами как раз никакой нагруженный веб-сервер и даже обработчик прерываний не заставит ждать задачу с большим приоритетом - это и подразумевает детерминизм, ну а скепсис в основном от непонимания происходящего

Да, Вы правы! Мое понимание пока основывается на чтении соответствующих статей, а там неоднозначность, ровно как и на соответствующих форумах. Все-таки же не зря RTOS существуют...?)

Используя программное таймерное прерывание "Линукса" можно вполне получить уход времени отработки обработчика прерывания не более 25 мкс на обычном ядре без выкрутасов и ухищрений. Как это делается обсуждалось здесь.

Что-то с памятью моей стало... Спасибо!