[:|||||||:] Операционные системы реального времени для авионики: обзор

Вроде у LynuxWorks есть две операционки - оригинальный LynxOS и rt-версия Linux. Какая из них проходила оценку?

LynxOS

> ОСРВ QNX Neutrino является наиболее совершенной ОС с технической точки зрения, располагает хорошим набором инструментальных средств, имеет относительно невысокую цену. Микроядерная архитектура обеспечивает высокую надежность и модульность разрабатываемых систем. Дополнительным плюсом является открытость исходных кодов. Но есть и «ложка дегтя»: в настоящее время QNX практически нигде не используется в авиации, и по этому параметру данная ОС проигрывает конкурентам (LynxOS и VxWorks). Дополнительный минус QNX: несоответствие стандарту ARINC-653.

Зашибись как "порвала"... =))) "Не используется", "не соответствует", и т.п. А ядерным реактором рулить - это не в воздушном бою участвовать, знаешь ли.

µC/OS-II рулит

Кстати

>Возможность написания переносимого ПО определяется в текущий момент соответствием стандарту POSIX. Все рассматриваемые ОС РВ поддерживают стандарт POSIX 1003.1. Преимущество есть у LynxOS — данная ОС обладает бинарной совместимостью с ОС Linux. То есть приложения Linux могут быть запущены под LynxOS без перекомпилирования. И, наоборот, приложения LynxOS могут быть запущены в Linux (версии 2.4.x c библиотекой языка Си glibs версии 2.2.2). Остальные ОС РВ для запуска Linux-приложений требуют их перекомпиляции. В этом случае зачастую процесс переноса даже POSIX-совместимых приложений может стать достаточно трудоемким из-за разницы в реализации библиотек и компиляторов.

> А ядерным реактором рулить - это не в воздушном бою участвовать, знаешь ли.

Именно так. Там скорости никакой не требуется, можно секунду-другую подумать над каждым действием.

А где RTAI?

А как же Linux+RTAI??? Патчишь ядро и получаешь RTOS. И юзаешь это все на GNU/Linux.

P.S. RTAI - GPL/LGPL

> Именно так. Там скорости никакой не требуется, можно секунду-другую подумать над каждым действием.

Молодец %)

А оно сертифицированно. Там ведь как, по идее, новая версия - опять сертифицировать.

У нас кстати не одна не сертифицирована пока. Тут ситуация такая что кто первый того и тапки ;) Там на первой страничке есть расширенная табличка с RTOS-ами но только эти 3 доступны в Рассее.

> А где RTAI?

RTAI - это тупик. Ветка -rt его зарулит.

По-моему, совершенно разные подходы. И таких откликов как в RTAI linux-rt не достигнет никогда из-за архитектурных ограничений.

Хотя было бы интересно почитать про linux-rt по-подробнее. С RTAI работал.

Кстати - примерно с год назад в новостях проскакивало что-то про проект боинга, где всё бегало под linux'ом. Там не RTAI юзался часом.

> По-моему, совершенно разные подходы.

Поначалу да, но вообще-то RTAI становится похожим на ветку -rt (уже ведь не нужно оформлять всё как модули ядра?).

> И таких откликов как в RTAI linux-rt не достигнет никогда из-за архитектурных ограничений.

Э... каких "таких"? И какие архитектурные ограничения помешают?

> Хотя было бы интересно почитать про linux-rt по-подробнее

https://ols2006.108.redhat.com/2007/Reprints/rostedt-Reprint.pdf

> Там не RTAI юзался часом.

Там был -rt от LynuxWorks, ЕМНИП. BlueCat или как-то так.

>И какие архитектурные ограничения помешают?

RTAI имеет наноядро, которое стоит над ядром Linux и управляет доставкой прерываний в Linux и RTAI. При переходе в hard real-time Linux отключается от прерываний полностью.

Из-за этого Линус RTAI не захотел включать в ядро.

>>И какие архитектурные ограничения помешают?

>RTAI имеет наноядро, которое стоит над ядром Linux и управляет доставкой прерываний в Linux и RTAI.

Я знаю, что такое RTAI. Вопрос был в том, какие именно ограничения ветки -rt помешают ему достичь реактивности RTAI, потому что я их не вижу (ОК, фиксированный оверхэд будет больше, но и всё).

> При переходе в hard real-time Linux отключается от прерываний полностью.

Почитай статью Ростедта.

>ОК, фиксированный оверхэд будет больше

Этого вполне достаточно ) RTAI, действительно, очень быстрый. Ну, плюс, нельзя прервать какой-нибудь "критический" участок в ядре (RTAI на это забивает болт).

(за статью спасибо, почитаю)

> RTAI, действительно, очень быстрый

Прогресс железа нас спасет. И о каких временах идет речь? В микросекундах.

> нельзя прервать какой-нибудь "критический" участок в ядре

Только тот, что защищен raw spinlock'ом

> RTAI на это забивает болт

Невытесняемые участки есть и в RTAI - они везде есть.

>И о каких временах идет речь? В микросекундах.

"Петька, приборы"

Какие времена интересуют? И на каком железе? ) У меня была своя специфическая задача, специфическое железо, и RTAI рвал QNX и RTLinux как по стабильности работы, так и по откликам и точности. Допускаю, что есть области, где всё хуже.

Точно помню, что десятки микросекунд там были (про меньшее просто не помню), но эта цифра абсолютно бесполезна.

>Невытесняемые участки есть и в RTAI - они везде есть.

Количество невытесняемых участков в наноядре, кхм, несколько меньше ) В этом и сила (и слабость) RTAI.

Если линукс не нужен, а нужно в какой-то момент вырубить совсем всё и сделать что-то очень важное очень быстро, с наноядром проще.

Если нужно красивое и сложное взаимодействие, возможно, с linux rt лучше. Но прострелить себе ногу более правильная архитектура всё равно не помешает )

> Какие времена интересуют?

Минимальные :)

> И на каком железе? )

На том, что использовалось :D

> RTAI рвал QNX и RTLinux как по стабильности работы, так и по откликам и точности

Насчет QNX ожидаемо, про RTLinux - странно, это практически то же самое.

> Точно помню, что десятки микросекунд там были

Осталось выяснить мощность железа :)

> прострелить себе ногу более правильная архитектура всё равно не помешает )

Отлаживать юзерспейс гораздо проще, чем ядреные модули.

>Минимальные :)

У RTOS есть различные характеристики связанные со временем. Так что твой вопрос по меньшей мере странен.

Поскольку я цифр (как говорил выше) не помню, то можешь поинтересоваться вот тут: http://issaris.org/rtai/list_distinct_cpus.php

Думаю, мои результаты не отличаются принципиально.

>про RTLinux - странно, это практически то же самое.

На некоторых версиях народ наблюдал даже разницу в два с половиной раза между временем RTLinux и RTAI (только что в maillist нашёл). У меня было не так радикально. А потом, RTLinux был нестабилен (не считая остальных недостатков).

>Отлаживать юзерспейс гораздо проще, чем ядреные модули.

В RTAI есть userspace realtime. LXRT.

> У RTOS есть различные характеристики связанные со временем. Так что твой вопрос по меньшей мере странен.

Мне для грубой оценки.

> http://issaris.org/rtai/list_distinct_cpus.php

RTAI UP latency maximum: 5148654 ns

аааафигеть. Я правильно понимаю, это латентность в 5 МИЛЛИСЕКУНД? o_O

>>Отлаживать юзерспейс гораздо проще, чем ядреные модули.

>В RTAI есть userspace realtime. LXRT.

Там и времена больше в разы.

>>В RTAI есть userspace realtime. LXRT. >Там и времена больше в разы.

На моей архитектуре - не в разы, а где-то на 10% (З.Ы. архитектура m68knommu).

>Мне для грубой оценки.

Для грубой оценки, мы получали отклонения не более 2 микросекунд на 50 миллисекунд.

>Я правильно понимаю, это латентность в 5 МИЛЛИСЕКУНД? o_O

Спрашивал про минимальное время, а сам смотришь максимальное? Ну давай, найди самую плохую машину )

RTAI UP latency maximum: 14149 ns

>> Я правильно понимаю, это латентность в 5 МИЛЛИСЕКУНД? o_O

> Спрашивал про минимальное время

Я с другой целью спрашивал :) Мне время в 2мкс просто не нужно - я даже считаю, что такую времянку должно обеспечивать устройство, не программа.

> а сам смотришь максимальное? Ну давай, найди самую плохую машину )

Это на Pentium4 1.8ГГц: http://issaris.org/rtai/show_entry.php?ts=2005-12-16+17%3A51%3A11%2B01

>>В RTAI есть userspace realtime. LXRT. >Там и времена больше в разы.

>На моей архитектуре - не в разы, а где-то на 10% (З.Ы. архитектура m68knommu)

Я, может, не понимаю чего-нибудь, но разве на архитектурах без MMU есть разница между ядром и юзерспейсом?

Отсутствие mmu != отсутствие колец.

> Отсутствие mmu != отсутствие колец.

Раскроешь тему? Чем реализуется защита памяти, если нет MMU, и в чем различие между кольцами, если нет защиты памяти? Ссылки вполне подойдут.

>Раскроешь тему? Чем реализуется защита памяти, если нет MMU, и в чем различие между кольцами, если нет защиты памяти? Ссылки вполне подойдут.

Различие между кольцами в наборе допустимых инструкций. Защита памяти отсутствует.

Но это ничего не меняет. Переход из userspace в kernelspace - это переключение стэков.

> Защита памяти отсутствует. Но это ничего не меняет. Переход из userspace в kernelspace - это переключение стэков.

При отсуствии защиты памяти оно практически бесплатное.

А чем же это оно платное при ее наличии?

> А чем же это оно платное при ее наличии?

Ы. Мы вообще об одном и том же говорим? Я говорил о переключении контекста с одной задачи на другую пр возникновении события. Для такого переключения нужно: 1) выбрать задачу из списка 2) переключить контекст. Первое не зависит от наличия MMU, для второго при отсуствии MMU нужно (упрощенно) поменять указатель стека и адрес возврата, а при наличии MMU вдобавок выполнить TLB flush и перезагрузить каталог страниц. Обе добавочные операции отнюдь не бесплатные. Если же речь просто о пересечении границы user/kernel (как в системном вызове), то деталей я не помню, но время там измеряется сотнями тактов на системах с MMU, про системы бе MMU не знаю.

>Мне время в 2мкс просто не нужно

Ну а мне было нужно ) Так что надеюсь, с rtai ничего плохого не случится. Судя по CVS'у жизнь идёт.

>Это на Pentium4 1.8ГГц:

Мобайл, во-первых. Во-вторых, там, похоже, чипсет не родной. Короче, плохое железо - это отдельный разговор. Интереснее, как оно работает, на хорошем )

P.S. Насколько я помню, в этом LiveCD было не самое удачное ядро. vanilla+rtai давало лучше результаты.