Linux + hard rt

Да, но по крайней мере мне неизвестно ни об одной сертификации.

hard rt из линукса - это фантастика. Можешь взять ядро из платформы RedHat MRG, там рилтаймовских патчей всяко больше, чем в ванилле. Плюс тестируется и активно саппортится.

> Да

Разработчиков (Молнар энд ко) уже оповестил, что оно hard rt стало? ;)

В фак заглянуть так трудно?

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.

Есть ещё rtai расширение. Оно вроде отпочковалось от rt. см. https://www.rtai.org/

Вроде rtai позволяет делать hard real time приложения.

> Разработчиков (Молнар энд ко) уже оповестил, что оно hard rt стало? ;)

Лейбл "Hard RT, мамой клянус!!11" дает сертификация, которая проводится на фиксированной аппаратно-программной платформе. А то, что патч спроектирован так, чтобы сделать эту сертификацию возможной, Мольнар, Ростедт, Глейкснер и прочие достойные люди знают и без меня.

А от rtai в своё время отпочковался Xenomai (xenomai.org)

Мы одно время долго трахались с Линуксом в попытках соорудить из него realtime - заказчику поставил условие, что время отклика ситемы должно быть <10 милисекунд. В результате для подобных задач стали использовать QNX. С линуксом на данный момент это не реально.

s/заказчику/заказчик/

есть какой-то от японцев для робатов, в новостях когда-то было ссылку не помню

Про rtai и xenomai я знаю и всетаки лениво писать драйвера для железок которые уже поддерживается стандартным ядром линукса. Да и если мне нужно будет чемто управлять то я лучше возюму какой нибуть контроллер(wago, fastwell, beckhoff итд) и используя более высокоуровневые абстракции реализую проект быстрее и качественнее. В принцыпе от линукса мне не нужны бешенные скорости, нужно чтобы процесс с переодичностью 100мс(ну можно > 100мс) обрабатывал данные.

Это хорошо.

> Мы одно время долго трахались с Линуксом в попытках соорудить из него realtime - заказчику поставил условие, что время отклика ситемы должно быть <10 милисекунд.

Пропуск директивного срока хоть иногда допустим или нет?

> В принцыпе от линукса мне не нужны бешенные скорости, нужно чтобы процесс с переодичностью 100мс(ну можно > 100мс) обрабатывал данные.

Айлол :D Да тебе обычного ядра хватит, только включить опции нужные :)

>Айлол :D Да тебе обычного ядра хватит, только включить опции нужные :)

Ты меня очень сильно успокоил :)) А то у меня какието сомнения были по этому поводу.

>> Да тебе обычного ядра хватит, только включить опции нужные :)

> Ты меня очень сильно успокоил :)) А то у меня какието сомнения были по этому поводу.

http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Linux-26-A-Brea...

и это всё - о довольно старых ядрах.

>В принцыпе от линукса мне не нужны бешенные скорости, нужно чтобы процесс с переодичностью 100мс(ну можно > 100мс) обрабатывал данные.

А что ты тогда про РТ? tailgunner правильно говорит - пользуйся стандартным ядром.

Сейчас понял что мои требования были сформулированны не однозначно. Тоесть я создаю переодический процесс с периодом 100мс и он должен жестко 1 раз в 100мс вызыватся и обрабатывать данные. Стандартное ядро мне это позволит?

> я создаю переодический процесс с периодом 100мс и он должен жестко 1 раз в 100мс вызыватся и обрабатывать данные. Стандартное ядро мне это позволит?

Да, конечно. Делаешь таймер, нить с планировщиком реального времени, и всё. Только берегись инверсий приоритетов.

В принцыпе все рт потоки запущу с одним приоритетом. И инверсси не должно быть.

PS: Спасибо за ответы.

>Пропуск директивного срока хоть иногда допустим или нет?

Нет. QNX справляется.

> В принцыпе все рт потоки запущу с одним приоритетом. И инверсси не должно быть.

Отличный способ борьбы с инверсией приоритетов %)

>> Пропуск директивного срока хоть иногда допустим или нет?

> Нет. 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, и ты можешь свести конфликты за ресурсы между нитями к фиксированным временам (не зависящим от времени обработки), то разумное распределение приоритетов в программе тебя спасет :) Но я бы дал более высокий приоритет нити, которая общается с устройством сбора данных.

В принцыпе нужно подумать все взвесить и написать. Еще раз спасибо за ответы.

>Вроде rtai позволяет делать hard real time приложения.

"There is no mathematical proof the RTAI gives hard realtime" (c) Paolo Mantegazza, главный разработчик RTAI.

З.Ы. Эти товарищи рекомендуют отрубать DMA и как-то борются (вроде даже успешно) с SMI. Хз как, т.к. я там не работал.

> прочие достойные люди знают и без меня.

Так и скажи: "Нет", а то голову морочишь.

>Странно, у нас Линукс вполне справляется с 5мс.

эээ... у нас пропуски были довольно часто. Расскажи, что за патчи использовали? Что за настройки?

>Ну и есть веские подозрения на то, что их вызывает не ядро :)

Нагрузка на процессор у нас около 2%.. так что я не знаю, работы с винтом на этом уровне - только логи.

ЗЫ Эта проблема возникла у нас больше года назад, может с тех пор чтото изменилось?

>>Странно, у нас Линукс вполне справляется с 5мс.

>эээ... у нас пропуски были довольно часто.

"Часто" - сколько? Секунда, минута, час?

> Расскажи, что за патчи использовали? Что за настройки?

Никаких патчей, стандартные настройки для низкой латентности - CONFIG_PREEMPT, CONFIG_HZ=1000, CONFIG_PREEMPT_BKL - по вкусу. Вероятно, в программе дело - у нас нить, которая отвечает за реакцию на события, максимально разгружена, максимально приоритетна, и блокируется на очень короткое фиксированное время.

> ЗЫ Эта проблема возникла у нас больше года назад, может с тех пор чтото изменилось?

O_O у нас всё работало еще на 2.4+lowlat

> Так и скажи: "Нет"

Я сказал ровно то, что хотел.

> а то голову морочишь.

Мольнара спроси :D

>"Часто" - сколько? Секунда, минута, час?

Много раз в минуту, щас уже не вспомню сколько.

Проблема в том, что недопустимы даже редкие просрочки.

>Никаких патчей, стандартные настройки для низкой латентности - CONFIG_PREEMPT, CONFIG_HZ=1000, CONFIG_PREEMPT_BKL - по вкусу.

Завтра на работе покапаюсь, видаль чтото мы недодумали тогда.

>Вероятно, в программе дело - у нас нить, которая отвечает за реакцию на события, максимально разгружена, максимально приоритетна, и блокируется на очень короткое фиксированное время.

У нас обычная программа, никаких RT фич не предусмотрено - по идее в RT-системе это и не нужно, всё ложится на ядро.

> Проблема в том, что недопустимы даже редкие просрочки.

Какой именно QNX использован, если не секрет? IIRC, QNX4 никогда не целилась на hard rt, не знаю насчет QNX6.

> У нас обычная программа, никаких RT фич не предусмотрено - по идее в RT-системе это и не нужно, всё ложится на ядро.

ИМХО, это всегда не так. Особенно это не так с Линуксом, который генетически - ОС общего назначения, и имеет в составе вещи типа планировщика диска (который, IIRC, просто не учитывает приоритеты планирования процессов, выдавших запросы). Ну и просто здравый смысл говорит о том, что RT-зависимую часть лучше вынести в отдельный модуль, где соблюдение директивных сроков обозримо и контролируемо.

>Какой именно QNX использован

QNX Neutrino версию сейчас не могу посмотреть

>Ну и просто здравый смысл говорит о том, что RT-зависимую часть лучше вынести в отдельный модуль, где соблюдение директивных сроков обозримо и контролируемо.

Согласен. Вобщем у нас было так - небольшой сервачёк(около 100000 строк) собирает данные, обрабатывает их и каждые десять милисекунд кладёт в память(MODBUS TCP), откуда из каждые 10 милисекунд забирает клиент на "верхнем уровне". QNX c этим справляется на 5. А вот с линуксом не вышло.