Rt linux что это

Обновлено: 05.07.2024

До недавнего времени для решения задач автоматизации в основном использовались операционные системы (ОС) реального времени (РВ). Это компактные системы, основанные на микроядерной архитектуре, - такие так VxWorks, OS-9, PSOS, QNX, LynxOS. Эти системы обладают быстрым временем реакции на события и прерывания, компактностью кода, хорошей встраиваемостью и другими преимуществами, характерными для операционных систем с микроядерной архитектурой.

Кроме того, перечисленные системы уже много лет на рынке, имют массу применений в ответственных проектах, что является дополнительным фактором доверия к ним. И, наконец, разработчик ответственной системы с повышенными требованиями к надежности, купив коммерческую ОСРВ, не остается наедине с возможными проблемами, так как может пользоваться услугами технической поддержки поставщика.

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

Наверное, классические операционные системы реального времени остаются самым надежным решением при построении систем жесткого реального времени повышенной надежности. Однако систем с такими требованиями не так много в мире, который нас окружают. Возможны ли другие решения?

Заблуждается тот, кто считает, что ОС реального времени - недорогой инструмент. Приходится платить за среду разработки, дополнительное программное обеспечение, драйверы и каждую лицензию в отдельности, что часто выливается в круглую сумму. Конечно, во многих применениях без ОС реального времени пока обойтись нельзя. Они оправдывают себя в высокотехнологичных проектах (тренажеры, уникальное оборудование) или в массовых изделиях (сотовые телефоны, анализаторы). Однако в то же время существуют задачи, для решения которых требуется поддержка режима реального времени, но затраты на разработку не окупаются.

Куда податься?

Мечта любого разработчика - операционная система на все случаи. Чтобы и управляла, и печатала, и т. д. Однако универсальные ОС, такие как Windows NT и Unix, не предназначены для задач реального времени и зачастую с ними не справляются. Приведем достаточно типичный пример. Разработчик перенес свою программу из DOS в Unix. Программа должна сохранять на диске снятую с видеокамеры информацию, а также управлять работой камеры. В DOS все шло гладко, но при переходе в среду Unix появились задержки в передаче на камеру управляющих сигналов. В результате анализа ситуации выяснилось, что задачи пользователя простаивают из-за процесса sync, который призван синхронизировать кэш файловой системы при обращении к диску. Попытки отключить подкачку и установить программе управления камерой наивысших приоритетов результатов не дали.

Так как же быть разработчику? Закупать операционную систему реального времени? Или все же есть способ добиться предсказуемого поведения и компактной реализации при использовании традиционных операционных систем?

Смесь бульдога с носорогом

А что же Unix? Традиционно, во многих ОС реального времени используются подмножества API-интерфейсов Unix, что сближает эти операционные системы с Unix. Существуют также полнофункциональные Unix-системы, поддерживающие режим реального времени.

Бурный рост популярности Linux побуждает разработчиков внимательнее присмотреться к этой операционной системе. У Linux много достоинств: открытость кода; большое количество сопутствующего программного обеспечения, пока в основном ориентированного на серверные применения; наличие неплохой документации на API-интерфейс и ядро операционной системы; работа на процессорах различных классов. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы: SGI, IBM, Intel, Motorola и т.д. В частности, Motorola активно работает в своей традиционной сфере встраиваемых систем и продвигает на рынок продукт LinuxEmbedded. Вообще говоря, Linux прекрасно подходит для компактных встроенных применений; на рынке уже появились поставщики, предлагающие усеченные варианты этой операционной системы, которые занимают 1-2 Мбайт на жестком диске. В качестве примера можно привести проект Linux Router Project.

Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения - RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему "жесткого" реального времени, а KURT (KU Real Time Linux) относится к системам "мягкого" реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач.

Проект KURT (http://hegel.ittc.ukans.edu/projects/kurt) характеризуется минимальными изменениями ядра Linux и предусматривает два режима работы - нормальный (normal mode) и режим реального времени (real-time mode). Процесс, использующий библиотеку API-интерфейсов KURT, в любые моменты времени может переключаться между этими двумя режимами. Программный пакет KURT оформлен в виде отдельного системного модуля Linux - RTMod, который становится дополнительным планировщиком реального времени. Данный планировщик доступен в нескольких вариантах и может тактироваться от любого системного таймера или от прерываний стандартного параллельного порта. Так как все процессы работают в общем пространстве процессов Linux, программист использует в своих программах стандартные API-интерфейсы Linux и может переключаться из одного режима в другой по событиям, либо в определенных местах программы. При переключении в режим реального времени все процессы в системе "засыпают" до момента освобождения ветви процесса реального времени. Это довольно удобно при реализации задач с большим объемом вычислений, по своей сути требующих механизмов реального времени, например в задачах обработки аудио- и видеоинформации.

Стандартно такты планировщика RTMod задаются от системного таймера - время переключения контекста задач реального времени (time slice) равно 10 мс. Используя же KURT совместно с UTIME, можно довести время переключения контекста задач до 1 мс. Прерывания обрабатываются стандартным для ОС Linux образом - через механизм драйверов.

set_rtparams позволяет добавить процесс в ядро с маской SCHED_KURT. Только процессы, чья политика в планировщике установлена как SCHED_KURT, смогут работать в режиме реального времени;
get_num_rtprocs получает идентификатор "rt_id" процесса из планировщика реального времени RTMod;
rt_suspend позволяет приостановить планировщик реального времени;
get_rt_stats получает статус процесса из таблицы планировщика процессов реального времени.

Простота использования KURT позволяет с максимальным комфортом программировать задачи, требующие как функций реального времени, так и всего многообразия API-интерфейса Unix. Использование "мягкого" реального времени обычно подходит для реализации мультимедийных задач, а также при обработке разного рода потоков информации, где критично время получения результата. Совершенно другой подход применен при реализации в Linux "жесткого" реального времени.

RTLinux

rtlinux) - это дополнение к ядру Linux, реализующее режим "жесткого" реального времени, которое позволяет управлять различными чувствительными ко времени реакции системы процессами. По сути дела, RTLinux - это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX-ядром Linux.

Разработчики RTLinux пошли по пути запуска из ядра реального времени Linux-ядра как задачи с наименьшим приоритетом. В RTLinux все прерывания обрабатываются ядром реального времени, а в случае отсутствия обработчика реального времени - передаются Linux-ядру. Фактически Linux-ядро является простаивающей (idle) задачей операционной системы реального времени, запускаемой только в том случае, если никакая задача реального времени не исполняется. При этом на Linux-задачу накладываются определенные ограничения, которые, впрочем, для программиста прозрачны.

Нельзя выполнять следующие операции: блокировать аппаратные прерывания и предохранять себя от вытеснения другой задачей. Ключ к реализации данной системы - драйвер, эмулирующий систему управления прерываниями, к которому обращается Linux при попытке блокировать прерывания. В этом случае драйвер перехватывает запрос, сохраняет его и возвращает управление Linux-ядру.

Все аппаратные прерывания перехватываются ядром операционной системы реального времени. Когда происходит прерывание, ядро RTLinux решает, что делать. Если это прерывание имеет отношение к задаче реального времени, ядро вызывает соответствующий обработчик. В противном случае, либо если обработчик реального времени говорит, что хочет разделять это прерывание с Linux, обработчику присваивается состояние ожидания (pending). Если Linux потребовала разрешить прерывания, то прерывания, которые находятся в состоянии "pending", эмулируются. Ядро RTLinux спроектировано таким образом, что ядру реального времени никогда не приходится ожидать освобождения ресурса, занятого Linux-процессом (рис. 1).

Рис. 1. Механизм работы RTLinux - Linux-расширения жесткого реального времени

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

Ключевой принцип построения RTLinux - как можно больше использовать Linux и как можно меньше собственно RTLinux. Действительно, именно Linux заботится об инициализации системы и устройств, а также о динамическом выделении ресурсов. "На плечи" RTLinux ложится только планирование задач реального времени и обработка прерываний. Для простоты запуска в контексте ядра, сохранения модульности и расширяемости системы процессы реального времени реализованы в виде загружаемых модулей Linux. Как правило, приложение реального времени с RTLinux состоит из двух независимых частей: процесса, исполняемого ядром RTLinux, и обыкновенного Linux-приложения.

Для иллюстрации работы приложения реального времени рассмотрим прикладной модуль, который использует ядро реального времени RTLinux в виде загружаемого модуля Linux:

Как и каждый модуль Linux-ядра, процесс реального времени должен выполнить процедуры инициализации и завершения аналогичные модулям Linux:

Подобный модульный подход к написанию приложений присущ многим расширениям реального времени для универсальных систем, когда задача реального времени работает независимо от ОС. Разработчики уже приняли схему, по которой задачи, критичные к времени реакции, программируются с помощью API-интерфейсов, предусмотренных расширением реального времени, а все служебные и интерфейсные функции возлагаются на традиционную операционную систему. Логично предположить, что при использовании данного подхода разработчику потребуется изучить только API-интерфейс реального времени.

На наш взгляд, оба подхода в реализации механизмов реального времени, заложенные в KURT и RTLinux, применимы для большинства задач реального времени. Правда, до определенного времени проект KURT находился в "подвешенном" состоянии и почти год не развивался, что вывело команду RTLinux в лидеры этого технологического направления. Однако совсем недавно вышла новая версия KURT 2.0 для Linux-ядер версий 2.2.5, 2.2.9 и 2.2.13.

Многие разработчики уже приняли Linux и внедряют ее в своих коммерческих проектах как основную операционную систему для серверов приложений. Однако до сих пор при реализации вертикальных проектов на нижнем уровне применялись специализированные ОС реального времени. Ситуация может существенно измениться благодаря использованию расширений реального времени для Linux. Теперь не надо тратить средства на изучение и покупку специализированной ОС, а весь проект можно реализовать в рамках одной системы и без чрезмерных затрат.

Real-Time Linux (RT- Linux)

Базовые концепции реального-времени (RT) . Жесткое реальное время и LINUX.

Что такое реальное-время?

До того как перейти к введению в RT-LINUX, необходимо рассмотреть несколько идей связанных с понятием "реальное время" (real time, RT). Мы будем говорить, что:

" система реального времени это информационная система , в которой корректность выходной информация зависит не только от примененных алгоритмов, но и от момеyнтов времени появления информации. "

Не достаточно чтобы информация была правильной, необходимо чтобы она появлялась в строго определенных временных интервалах. Заметим, что из вышесказанного определения система реального времени необязательно быстрая, как кто либо мог считать. Например, система навигации корабля в начале могла бы показаться не системой реального времени, потому что скорость мала и обычно "достаточно" времени (порядка минут) для принятия решения. Тем не менее, в соответствии с нашим определением, это действительно система реального времени.

Заметим что мы определили "систему реального времени", а не систему в ральном времени. Системы в реальном времени, в основном быстрые системы, создают иллюзию "реальности". Обычно от всех симуляторов и интерактивных игр требуется, создать впечатление реального мира, и чем больше картинок генерится в единицу времени тем лучше.

Давайте теперь более детально рассмотрим понятие "временые ограничения" (temporal restriction), предположим кто-либо хочет управлять скоростью двигателя с различной нагрузкой на валу с использованием ПИД-закона регулирования. (ПИД-закон это пропорционально- интегрально- дифференциальный закон регулирования). С нашей точки зрения, ПИД-закон, это функция со своим набором параметров. В этом примере скорость двигателя - параметр, получаемый от двигателя и напряжение питания двигателя - параметр, управляющей скоростью вращения двигателя. Теория алгоритмов управления, которая кстати весьма обширна, не принимает в расчет время вычисления алгоритма ПИД-функции, т.е. время от измерения скорости двигателя, до момента, когда мы воздействуем на двигатель, очень мало. В обычных условиях системы позволяют иметь небольшую задержку. Другая характеристика ПИД-закона это периодичность, другими словами необходимо постоянно, через определенные интервалы времени, вычислять ПИД-функцию. Если время между последовательными вызовами ПИД-функции слишком велико, двигатель может достичь нежелаемой скорости. Подводя итог, ПИД-закон может быть рассмотрен как функция, исполняемая периодически с периодом (Pi); с максимальной допускаемой ПИД-законом задержкой, (Di), и, в соответствии от скорости процессора исполнение ПИД кода требует определенного количества времени (Сi). .

Pi: Период задачи i.

Di: Максимальная допустимая задержка выдачи управления, задачи i.

Ci: наихудшее время выполнения задачи i.

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

Проблемы появляются, когда в системе может выполняться несколько задач и они вынужденны делить процессор (процессоры) между собой. Это препятствует нам использовать класические системы с разделением ресурсов типа LINUX. Конечно нет необходимости упоминать: даже не пытайтесь писать программы, требующие реального времени под Windows . И еще совет, не пишите вообще никаких программ для этой платформы.

Не все системы реального времени идентичны, совсем не одно и то же, что управлять системой вспрыска топлива двигателя самолета или показом mpeg-файлов. В первом случае, малейшая задержка в выполнении может привести к потере человеческих жизней или большим материальным потерям, во втором случае это означает простое ухудшение качества системы - картинка может замирать или часть кадров будет пропадать. Первый тип известен как системы "жесткого реального времени" (hard real time, HRT), а второй, как системы "мягкого реального времени" (soft real time, SRT). . Мы будем иметь дело c системами HRT.

Разработка RT-систем проходит различные фазы: во первых, определяются задачи, что должно быть выполyено и в каких временных границах (time restriction); во вторых, пишется код и окончательно измеряется время выполнения каждой задачи, а планирование запуском задач осуществляется, таким образом, чтобы быть уверенным что задачи не выйдут за временные границы в работающей системе. Тестовое планирование основано на применении ряда тестов ко всей группе задач, и если они проходят тест, то возможно гарантировать, что ни одна из задач не перейдет временные границы. Если нет, необходимо начать разработку сначала, выбрать более быстрый процессор или другие алгоритмы для решения задачи.

Подведем итог. Задачи определяются трямя временными параметрами Pi, Di и Ci. Система должна гарантировать время выполнения задач, т.е. при выполении любого набора задач, все задачи остануться внутри своих временных границ. Гарантировать время выполнения - это значит что система должна быть предсказуемой (predictable). Говоря, что система является системой реального времени или система предсказуема, обычно подразумевают одно и то же. .

Какая связь между операционной системой и реальным временем?

Семантическая реализация сигналов управления - ответственность программиста а временные ограничения зависят от операционной системы.

По сравнению с "нормальной" ОС, целью ОС реального времени является уменьшить сложность. Мы не нуждаемся в ОС которая делает много вещей, что важно, так это чтобы задачи запускались предсказуемо и быстро.

Более предпочтительными являются такие ОС, где контекст обычно меняется за 10 условных временных тактов, в худшем случае за 12, чем ОС, где хотя в среднем это происходит за 3, но иногда может быть и за 20 условных временных тактов.

Не следует удивляться что ОС реального времени медлительнее, чем обычные ОС. Иногда, в целях получения предсказуемого поведения, необходимо даже запретить использование кеша, соответственно с потерей производительности. Кеш, процессоры с конвеерной выборкой и алгоритмами предсказания ветвления являются настоящими врагами предсказуемости и, следовательно, системам реального времени.

POSIX RT рассширения.

POSIX это абревиатура Portable Operating Systems Interface (Переносимый интерфейс операционных систем). Cтандарт, предназначенный для достижения переносимости программного обеспечения на уровне исходных кодов. Другими словами, программа для POSIX совместимой операционной системы должна компилироваться и выполняться на любой другой POSIX совместимой ОС, даже, если последняя и от другого поставщика. POSIX стандарт определяет интерфейс который ОС предлагает прикладным программам: набор системных вызовов (set of system calls). POSIX стандарт разрабатывается IEEE (Instiute of Electrical and Electronic Engineering) и стандартизуется ANSI (American National Standards Institute) and ISO (International Standards Organisation). Очевидно, что POSIX основан на UNIX. Большинство ОС, включая Windows NT, стремятся от версии к версии достичь совместимости с POSIX стандартом.

Работа над POSIX стандартом разделена между несколькими рабочими группами, в которых работают представители компьютерных фирм, программистских компаний, официальные представители государства и частные лица, профессионалы в той или иной области програмиррования. Каждая группа заботится о разработке какого-либо аспекта ОС. Для примера, группа называемая POSIX.4 занимается вопросами относящимися к реальному времени.

POSIX.4-дополнение, переименованное в 1003.1b в 1993 г., позволяет использовать ОС для реального времени. Совершенно очевидно что большинство этих расширений относится к управлению временем и приоритетами процессов, а также системным вызовам для взаимодействия между процессами (the inter-process communication).

POSIX-дополнения разрабатываются для повышения контроля над системой управления ресурсами ОС.

LINUX 2.0 поддерживает многие POSIX-совместимые системные вызовы реального времени . но этот аспект LINUX мы будем обсуждать в будущей статье. Версия 2.2. с большой вероятностью будет на 100% совместима с POSIX 1003.1b.

Linux реального времени (real-time Linux, RT-LINUX)

Victor Yodiken и Michael Barabanov разработали RT-LINUX будучи на факультете компьютерных наук института добычи полезных ископаемых и технологий, расположенного в New Mexico. Michael сделал эту работу частью диплома, Master of computer science. Последняя доступная версия 0.6. На момент написания этой статьи RT-LINUX был доступен только для Intel платформ.

RT-Linux решает проблему поновому. Вместо того, чтобы менять ядро LINUX, пытаясь сделать его предсказуеммым, они написали не зависимое от основного ядра свое маленькое ядро - планировщик. Основное ядро LINUX запускается, как задача этого ядра, разделяя процессор с другими задачами реального времени. Linux использует процессор наравне c другими задачами реального времени, более точно LINUX является фоновой задачей, и исполняется только, если не исполняется ни одна из задач реального времени.

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

Ядро LINUX (как и большинство ОС) обычно запрещает прерывания, как средство синхронизации или при выполнении критических участов кода. Если во время, когда Linux запретит прерывания, придет прерывание от часов, оно будет блокированно и, следовательно, потеряна временная точность. В RT-LINUX применено оригинальное решение: все вызовы cli, sti, and iret (ассемблерные команды управления прерываниями) заменены на S_CLI, S_STI и S_IRET, и LINUX никогда не может запретить прерывания.

Недостаток планировщика, приходящего с RT-LINUX, это то, что он приоритетный планировщик, с фиксированными приоритетами и для LINUX выделен самый низкий приоретет. Если задачи реального времени возьмут все процессорное время, тогда Linux не получит времени и может сложится впечатление, что система остановилась.

В случае RT-LINUX мы не только имеем систему реального времени, но и класическую ОС. Мы можем гонять WEB, в то время как измеряется и контролируется физический объект.

Установка RT-LINUX.

Для преобразования LINUX в RT-LINUX, нужно модифицировать исходные коды ядра, наложив заплату, которая приходит с RT-LINUX и скомпилировать ядро. Теперь, как это сделать. Я предполагаю, что файл rtlinux-0.6-2.0.33.tgz лежит в директории /usr/src и что он был распакован в директорию /usr/src/rtlinux-0.6. Я также допускаю, что ядро уже сконфигурировано ( make config), и тогда:

Новое ядро появится как и "нормальное" ядро, однако уже приготовленное стать системой реального времни. В директории /usr/src/rtlinux-0.6-2.0.33/testing находятся различные демонстрационные программы.

Кроме примеров, пришедших с дистрибутивом (директория testing), вы можете взять на интеренет (Internet) другой пример подготовленный Олегом, который позволяет нам создать карту времени выполнения задач. Один из файлов этой демо-программы, планировщик с изменениями, он не только планирует выполнение задач, но так же посылает информацию, связанную с принятыми решениями. Это информация накапливается и сохраняется в файле, который может быть отображен графически. В результате мы увидим, в каком порядке различные задачи выполнялись и как задачи с высшим приоритетом захватывали время задач с низшим приоритетом. LINUX, как задача, не представлен.

Каждой задаче соответствует горизонтальная ось. Прямоугольниками показано время использования задачей процессора (в нашем случае мы имели моно-процессорную систему и только одна задача могда быть выполнена в единицу времени). В этом примере границы каждой задачи равны их периоду. Период каждой задачи, временной интервал ( представлен как ) в течение которого задача должна быть выполнена. Задачи в верхней части, имели высший приоритет и возможность захвата процессорного времени у других задач, что и произошло в момент времени равный 600.

Будущее RT-LINUX.

Уже существует много-процессорная версия RT-LINUX. Количество сервисов предлагаемых RT-LINUX преднамеренно уменьшенно, нет необходимости включать функции которые не очень нужны, если надо сохранить систему предсказуемой. Тем не менее, некоторые расширения уже доступны, такие, как семафоры и возможность управлять задачами реального времени через /proc/sys.

Несколько недель назад начато создание руководства по RT-LINUX.

Заключение

До появления RT-LINUX многие инженеры, которые хотели использовать системы реального времени, были вынужденны использовать MS-DOS и писать все необходимые драйверы или покупать системы реального времени (за запредельные цены). Теперь разработчики имеют полнофункциональную ОС и возможность разрабатывать приложения на той же системе, где они будут запущены. В действительности мы можем запустить несколько приложений реального времени, и в то же время рабоатать на интернет, и без всяких проблем.

Наша следующая статья в этой серии будет рассматривать несколько примеров приложений реального времени, и мы обсудим написание собственных приложений реального времени.
Перевод: dobrozhelatel' -->

Операционная система реального времени необходима, когда к работе процессора или потоку данных предъявляются жесткие временные требования. Таким образом она часто выполняет роль блока управления в специальных устройствах. Проведение научных экспериментов, приложения визуализации в медицине, промышленные устройства управления являются системами реального времени. Механизмы впрыска топлива автомобильных двигателей, контроллеры бытовой и военной техники также являются системами реального времени.

Возможности ядра в реальном времени существует уже более десяти лет в экосистеме программ с открытым исходным кодом. Столько же времени доступна поддержка Red Hat Enterprise Linux (RHEL) для ядра реального времени. Тем не менее многие системные администраторы неверно истолковывают его основные концепции и фактическое рабочее поведение. В этой статье я опишу некоторые из его основных функций, отличия от стандартного ядра и шаги по установке.

Планировщик ЦП в реальном времени

Для разных классов задач можно обозначить системы мягкого реального времени и системы жесткого реального времени. Первые не гарантируют точное время, когда критический процесс будет запланирован в реальном времени. Они гарантируют только то, что процессу будет отдано предпочтение перед некритическими процессами. Вторые имеют более строгие требования и задание либо выполняется в заданных временных рамках, либо считается не выполненным.

Мы называем задержкой события время, которое проходит с момента возникновения события до момента его обслуживания. Есть два типа задержек, оказывающих влияние на производительность ОС реального времени.

Задержка прерывания

interrupt service routine (ISR)

Планировщик с учетом приоритетности процессов

Наиболее важной особенностью ОС реального времени — немедленно реагировать на критический процесс, требующий доступ к ресурсам CPU. В результате планировщик для операционной системы реального времени должен поддерживать алгоритм приоритетного прерывания. Такие алгоритмы назначают каждому процессу приоритет в зависимости от его степени важности. Если планировщик также поддерживает приоритетное прерывание, текущий процесс на CPU по запросу будет вытеснен в пользу более приоритетного процесса.

Рис. 3 Классификация планировщиков.

Существует несколько алгоритмов для планировщика в реальном времени.

Рис. 4 Планировщик EDF.

SCHED_FIFO — политика упреждающего планирования с постоянным приоритетом, при которой процессы с одинаковым приоритетом обрабатываются в порядке «первым пришел — первым обслужен» (FIFO). Данная политика может иметь не менее 32 уровней приоритета.
SCHED_RR — политика аналогична SCHED_FIFO, но использует метод временного среза (циклический перебор) для планирования процессов с одинаковыми приоритетами. Он также имеет 32 уровня приоритета.
SCHED_OTHER — политика не определена и зависит от системы; может вести себя по-разному в разных реализациях.

Установка и использование RHEL Real Time

Для начала следует подключить репозиторий Red Hat Enterprise Linux для Real Time, и установить группу пакетов RT.

В составе RT идут эти компоненты:

kernel-rt — ядро с функционалом реального времени;
rt-setup — установка окружения Red Hat Enterprise Linux Real Time;
rt-tests — утилиты тестирования функций RT;
rt-eval — для оценки возможности применять RT на данной системе;

Посмотрим на некоторые отличия kernel-rt от стандартного ядра.

При высокой нагрузке происходит проверка приоритета задачи (1-99).
Высокоприоритетным (99) задачам отдается предпочтение при доступе к ресурсам центрального процессора.
Не задействует политику Completely Fair Scheduling (CFS).
Использует политику SCHED_FIFO, либо же SCHED_RR.

Рис. 5 Сравнение kernet_rt со стандартным ядром.

На графике показан замер времени отклика из миллиона повторений для систем, использующих ядра RHEL Linux 7 и RHEL Real Time соответственно. Синие точки на этом графике представляют время отклика (в микросекундах) систем со стандартным ядром RHEL 7, а зеленые — RHEL 7 Real Time. Из графика видно, что особенность kernel-rt в гораздо меньшей дисперсии и, соответственно, в большей предсказуемости времени отклика системы.

Настройка и тестирование

После установки RT может потребоваться дополнительная настройка и доводка для достижения наиболее стабильных показателей времени отклика системы. Такие требования могут предъявить компании финансового, или телекоммуникационного сектора. Сама настройка — итеративный процесс и нужно запастись терпением в начале процесса. Вряд ли получится подкрутить пару переменных и понять, что достигнут наилучший результат из возможных.

Утилита hwlatdetect из пакета rt-tests покажет задержки, вызванные аппаратным и микропрограммным обеспечением, путем опроса источника тактовых импульсов и поиска непонятных пропусков.

В данном примере parameters указывает на задержку и способ обнаружения. Порог задержки по умолчанию был выставлен на 10 микросекунд (10 μs).

RT имеет также утилиту rteval для тестирования производительности системы в реальном времени под нагрузкой. Программа создаёт большую нагрузку на систему, используя планировщик SCHED_OTHER, а затем измеряет отклик в реальном времени на каждом из активных CPU. Цель в том, чтобы постоянно выполнялись различные задачи, такие как выделение / освобождение памяти, дисковый I/O, вычисления, копирование памяти и другие.

Каждый поток измерений берет временную метку, бездействует в течение некоторого интервала, а затем принимает другую временную метку после пробуждения. Задержка по результатам измерения равна t1 - (t0 + i) , где

На данный момент в репозиторий Сизиф под архитектуру x86_64 собраны два ядра реального времени:

Содержание

"Двойное ядро" состоящее из высокоприоритетного ко-ядра Cobalt реализующего различные (skins) RTOS API Xenomai 3 и ядра линукс с I-Pipe (Adeos) патчем реализующим систему жёсткого реального времени. (Обратите внимание, что ядро Mercury не поддерживается.) Xenomai 3 может эмулировать RTOS API: pSOS+, uITRON, VxWorks, RTAI, VRTX, а так же содержит нативное API Alchemy и поддерживает Real-Time Driver Model (RTDM). Документация на англ.

Юзерспейс и специализированные тесты для этого ядра находятся в пакете xenomai .

Real Time Linux с PREEMPT_RT патчем (Ingo Molnar, Thomas Gleixner) реализующим POSIX real-time API. Иногда называемое -rt ядро.

Считается, что ядра данного типа наиболее оптимально работают с vanilla конфигом. Поэтому была использована следующая методология создания конфига: defconfig + все опциональные модули из std_def ядра + тюнинг RT (отключено NO_HZ , отключены многие опции _DEBUG + прочие мелкие оптимизации).

Для облегчения тестирования это ядро содержит два дополнительных патча от консорциума OSADL:

Для тестирования этого ядра можно использовать пакет linux-rt-tests .

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

Базовый способ тестирования ядра реального времени (POSIX API), это запуск утилиты cyclictest параллельно с созданием нагрузки на систему (генерацию нагрузки вы должны организовать сами, например, запуском unixbench , stress-ng , hackbench , gltestperf в цикле) в течении длительного времени (не менее 24 часов). Пример запуска:

Пример вывода на обычном ядре (std_def):

Для оценки результата следует смотреть на значения Max показывающие время реакции на прерывания в микросекундах. (Есть примеры, на обычной системе, где Max доходит до 5-значных чисел.) Пример вывода на -rt ядре (SMI прерываний не было):

Тест (с помощью hwlat tracer'а ядра) обнаруживает задержки создаваемые железом или firmware не зависимые от ядра, такие как SMI. (Не используйте его на продакшен системах или во время работы других тестов так как принцип его работы - нагружать процессоры на продолжительное время при запрещенных прерываниях, постоянно замеряя время (TSC) и определяя таким образом интервалы с пропусками.) Пример на системе с большими задержками:

Небольшая утилита (от IBM) проверяющая, что запущенное ядро имеет свойства -rt ядра. Запускать с опцией -v для просмотра отчета.

Более легкий в использовании аналог cyclictest (от Siemens и SUSE) с уклоном в воспроизводимый статистический анализ. (Домашняя страница. Видео презентация. англ.) Пример запуска:

Сабж. Просто на rt-kernel у меня не глючит аудио. Но я часто использую виртуалки, в основном VirtualBox. Работает, но возможны ли какие-нибудь сбои, особенно с внутренней виртуальной сетью? Хост Debian 9 на rt-kernel.

Virtualbox с linux-rt совместим весьма плохо. Может работать прекрасно, но периодически модуль ядра виртуалбокса будет посылать ядро в ступор при загрузке. Это как минимум.

Да и еще куча граблей у rt есть.

Поэтому я использую обычное, а если надо обрабатывать звук - guitarix например, то тогда загружаюсь на rt.

А другие системы виртуализации?

Не в курсе, может с kvm и нет проблем.

Виртуализация и RT несовместимы.

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

Более того, тебе и современные Intel и AMD процессоры не дадут никакого RT, ибо говноME и говно_что_там_у_амд.

Тебе нужны старые атомы, процы до и включая Core2Duo, и аналогичное старьё от AMD. Ну или ARM/MIPS на платформах без зондов типа RPi.

Ну и используй себе на здоровье. А то что будет ио подтупливать в виртуалках, так у тебя же не продакшен сервера в них.

ТС вообще то спрашивал не о рт в виртуалках.

Поэтому никто даже и не пытался как-то обеспечить реальную работу RT ядер в гостях.

Поэтому никто даже и не пытался как-то обеспечить реальную работу RT ядер в гостях

У меня _хост_ на rt-kernel, а не гости.

ТС вообще то спрашивал не о рт в виртуалках.

А о чём? Под RT ядром пускать например VirtualBox? Если RTAI - то плевать. Если это какое-нибудь дебиановское *-rt ядро - то можно огрести.

Оно всего лишь RT-шедулит VM'ы. В какой-то степени это даст результат но только на очень длительных временных интервалах. Для обыного применения там, где используется RT непригодно.

Если RTAI - то плевать. Если это какое-нибудь дебиановское *-rt ядро - то можно огрести.

А чем rt-kernel в Debian отличается от RTAI?

У меня _хост_ на rt-kernel, а не гости.

Значит не так понял. Если RTAI - то пофиг. Если это обычно PREEMPT_RT ядро, то возможно огребёшь. Пробуй. Запусти какой-нибудь latency-test, напряги чем-нибудь твою виртуалку, да погляди.

Читайте также: