hard rt из линукса - это фантастика. Можешь взять ядро из платформы RedHat MRG, там рилтаймовских патчей всяко больше, чем в ванилле. Плюс тестируется и активно саппортится.
What sort of real-time performance should I expect?
The typical answer given by all performance experts when asked question like this is, "it depends". Not only does it depend on the speed of the CPU and the architecture, but also on the device drivers and of the hardware. For example, if a device grabs the PCI bus for long periods during DMA activity, that can introduce significant latencies in the system. In addition some firmwares can stop the system for housekeeping activities via Service Management Interrupts (SMI's) on x86 and x86_64 architectures; SMI's can not be trapped by the OS, so latencies introduced by SMBIOS routines can only be addressed by working with the firmware designers of the motherboard. On 2006-2007 high-end AMD and Intel CPU's systems have been deployed with 10-30us scheduler and interrupt latencies; on other platforms, your mileage will definitely vary. The platforms tested and in use with CONFIG_PREEMT_RT section of this wiki does have some examples of latency numbers found by various -rt users and developers.
> Разработчиков (Молнар энд ко) уже оповестил, что оно hard rt стало? ;)
Лейбл "Hard RT, мамой клянус!!11" дает сертификация, которая проводится на фиксированной аппаратно-программной платформе. А то, что патч спроектирован так, чтобы сделать эту сертификацию возможной, Мольнар, Ростедт, Глейкснер и прочие достойные люди знают и без меня.
Мы одно время долго трахались с Линуксом в попытках соорудить из него realtime - заказчику поставил условие, что время отклика ситемы должно быть <10 милисекунд. В результате для подобных задач стали использовать QNX. С линуксом на данный момент это не реально.
Про rtai и xenomai я знаю и всетаки лениво писать драйвера для железок которые уже поддерживается стандартным ядром линукса. Да и если мне нужно будет чемто управлять то я лучше возюму какой нибуть контроллер(wago, fastwell, beckhoff итд) и используя более высокоуровневые абстракции реализую проект быстрее и качественнее. В принцыпе от линукса мне не нужны бешенные скорости, нужно чтобы процесс с переодичностью 100мс(ну можно > 100мс) обрабатывал данные.
> Мы одно время долго трахались с Линуксом в попытках соорудить из него realtime - заказчику поставил условие, что время отклика ситемы должно быть <10 милисекунд.
Пропуск директивного срока хоть иногда допустим или нет?
Сейчас понял что мои требования были сформулированны не однозначно. Тоесть я создаю переодический процесс с периодом 100мс и он должен жестко 1 раз в 100мс вызыватся и обрабатывать данные. Стандартное ядро мне это позволит?
>> Пропуск директивного срока хоть иногда допустим или нет?
> Нет. QNX справляется.
Странно, у нас Линукс вполне справляется с 5мс. Правда, у нас пропуски иногда допустимы, но они бывают настолько редко, что их не замечают. Ну и есть веские подозрения на то, что их вызывает не ядро :)
> Отличный способ борьбы с инверсией приоритетов %)
Я просто к чему, есть программа исполюзующая библиотеку в которой нельзя создать мутекс c опцией PTHREAD_PRIO_INHERIT и не хотелось бы её патчить, или писать свою реализатцию. А переодичность эмилируется так:
Строятся временные метки по которым после обработки данных вычисляется время на которое нужно заснуть, чтобы наступил следующий период. Здесь встаеть проблема атомарности: взять текущее время расчитать время для достижения следующего периода и заснуть. В принцыпе я думаю chrt -f 10 my_cool_rt_program меня спасет, или я ошибаюсь?
PS: Не хочется выходить за рамки этой библиотеки но чувствую что прийдется. В принцыпе я знаю как это сделать но пока не охота.
> В принцыпе я думаю chrt -f 10 my_cool_rt_program меня спасет, или я ошибаюсь?
Ну, если учесть, что я не понял твою задачу - ХЗ :) Но вообще, если единственное RT-приложение в твоей системе - это твоя my_cool_rt_program, и ты можешь свести конфликты за ресурсы между нитями к фиксированным временам (не зависящим от времени обработки), то разумное распределение приоритетов в программе тебя спасет :) Но я бы дал более высокий приоритет нити, которая общается с устройством сбора данных.
> Расскажи, что за патчи использовали? Что за настройки?
Никаких патчей, стандартные настройки для низкой латентности - CONFIG_PREEMPT, CONFIG_HZ=1000, CONFIG_PREEMPT_BKL - по вкусу. Вероятно, в программе дело - у нас нить, которая отвечает за реакцию на события, максимально разгружена, максимально приоритетна, и блокируется на очень короткое фиксированное время.
> ЗЫ Эта проблема возникла у нас больше года назад, может с тех пор чтото изменилось?
Проблема в том, что недопустимы даже редкие просрочки.
>Никаких патчей, стандартные настройки для низкой латентности - CONFIG_PREEMPT, CONFIG_HZ=1000, CONFIG_PREEMPT_BKL - по вкусу.
Завтра на работе покапаюсь, видаль чтото мы недодумали тогда.
>Вероятно, в программе дело - у нас нить, которая отвечает за реакцию на события, максимально разгружена, максимально приоритетна, и блокируется на очень короткое фиксированное время.
У нас обычная программа, никаких RT фич не предусмотрено - по идее в RT-системе это и не нужно, всё ложится на ядро.
> Проблема в том, что недопустимы даже редкие просрочки.
Какой именно QNX использован, если не секрет? IIRC, QNX4 никогда не целилась на hard rt, не знаю насчет QNX6.
> У нас обычная программа, никаких RT фич не предусмотрено - по идее в RT-системе это и не нужно, всё ложится на ядро.
ИМХО, это всегда не так. Особенно это не так с Линуксом, который генетически - ОС общего назначения, и имеет в составе вещи типа планировщика диска (который, IIRC, просто не учитывает приоритеты планирования процессов, выдавших запросы). Ну и просто здравый смысл говорит о том, что RT-зависимую часть лучше вынести в отдельный модуль, где соблюдение директивных сроков обозримо и контролируемо.
>Ну и просто здравый смысл говорит о том, что RT-зависимую часть лучше вынести в отдельный модуль, где соблюдение директивных сроков обозримо и контролируемо.
Согласен. Вобщем у нас было так - небольшой сервачёк(около 100000 строк) собирает данные, обрабатывает их и каждые десять милисекунд кладёт в память(MODBUS TCP), откуда из каждые 10 милисекунд забирает клиент на "верхнем уровне". QNX c этим справляется на 5. А вот с линуксом не вышло.