Linux в режиме реального времени
Операционная система реального времени необходима, когда к работе процессора или потоку данных предъявляются жесткие временные требования. Таким образом она часто выполняет роль блока управления в специальных устройствах. Проведение научных экспериментов, приложения визуализации в медицине, промышленные устройства управления являются системами реального времени. Механизмы впрыска топлива автомобильных двигателей, контроллеры бытовой и военной техники также являются системами реального времени.
При этом разные события имеют различные временные требования. Например, требование к задержке для антиблокировочной тормозной системы может составлять от 3-5 миллисекунд. То есть с момента, когда колесо впервые обнаруживает, что оно скользит, у системы, управляющей антиблокировочными тормозами, есть от 3-5 миллисекунд, чтобы отреагировать и исправить ситуацию.
Возможности ядра в реальном времени существует уже более десяти лет в экосистеме программ с открытым исходным кодом. Столько же времени доступна поддержка Red Hat Enterprise Linux (RHEL) для ядра реального времени. Тем не менее многие системные администраторы неверно истолковывают его основные концепции и фактическое рабочее поведение. В этой статье я опишу некоторые из его основных функций, отличия от стандартного ядра и шаги по установке.
Планировщик ЦП в реальном времени
Для разных классов задач можно обозначить системы мягкого реального времени и системы жесткого реального времени. Первые не гарантируют точное время, когда критический процесс будет запланирован в реальном времени. Они гарантируют только то, что процессу будет отдано предпочтение перед некритическими процессами. Вторые имеют более строгие требования и задание либо выполняется в заданных временных рамках, либо считается не выполненным.
Мы называем задержкой события время, которое проходит с момента возникновения события до момента его обслуживания. Есть два типа задержек, оказывающих влияние на производительность ОС реального времени.
- Задержка прерывания относится к периоду времени от поступления прерывания в CPU до запуска процедуры обработки. Когда происходит событие, ОС должна сначала завершить выполняемую инструкцию и определить тип возникшего прерывания. Затем она должна сохранить состояние текущего процесса до обработки прерывания с помощью специальной процедуры, interrupt service routine (ISR).
Рис. 1 Задержка прерывания.
Время, необходимое диспетчеру планирования для остановки одного процесса и запуска другого, называется задержкой диспетчеризации. Предоставление задач реального времени с немедленным доступом к процессору требует, чтобы ОС реального времени минимизировали также и эту задержку. Наиболее эффективным методом поддержания низкой задержки отправки является предоставление ядер с приоритетным прерыванием.
Рис. 2 Задержка диспетчеризации.
Планировщик с учетом приоритетности процессов
Наиболее важной особенностью ОС реального времени — немедленно реагировать на критический процесс, требующий доступ к ресурсам CPU. В результате планировщик для операционной системы реального времени должен поддерживать алгоритм приоритетного прерывания. Такие алгоритмы назначают каждому процессу приоритет в зависимости от его степени важности. Если планировщик также поддерживает приоритетное прерывание, текущий процесс на CPU по запросу будет вытеснен в пользу более приоритетного процесса.
Рис. 3 Классификация планировщиков.
Существует несколько алгоритмов для планировщика в реальном времени.
- Rate-Monotonic Scheduling — алгоритм со статическим приоритетом класса планирования. Статические приоритеты назначаются в соответствии с продолжительностью цикла задачи, вследствие чего более короткие циклы имеют более высокий приоритет исполнения. В худшем случае КПД загрузки центрального процессора ограничен следующей величиной.
При числе процессов n, стремящемся к бесконечности ряд будет сходиться к ln2 ≈ 0.693147.
Earliest-deadline-first (EDF) Scheduling динамически назначает приоритеты в соответствии с крайним сроком. Чем раньше крайний срок, тем выше приоритет и чем позже крайний срок, тем ниже приоритет. В отличие от RMS, планировщик EDF не требует, чтобы процессы были периодическими и постоянно запрашивали одно и то же количество процессорного времени на пакет. Единственное требование состоит в том, чтобы процесс объявлял свой крайний срок планировщику, когда он готов к запуску.
Рис. 4 Планировщик EDF.
На рисунке видим общий принцип работы планировщика. На точке 4 был замещён T1 и его место занял T2 так как его крайний срок наступал раньше, чем у T2. После отработки T3 планировщик вернулся к T1, который завершился на отметке 23.
POSIX real-time-scheduling. Стандарт POSIX.4 определяет три политики планирования. Каждый процесс имеет атрибут планирования, который может быть выставлен в одну из трех вариантов политики.
- 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 на данной системе;
После установки RT и перезагрузки нужно убедиться, что загружено ядро kernel-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) , где
- t1 — фактическое время измерения;
- t0 — теоретическое время пробуждения первой временной метки;
- i — интервал ожидания.
Отчет утилиты rteval выглядит так.
Использованные материалы
- Abraham Silberschatz, Peter Baer Galvin, Greg Gagne Operating System Concepts 9-th edition.
- What are the benefits of running the Red Hat Enterprise Linux for Real Time?
- Working with the real-time kernel for Red Hat Enterprise Linux
- Advanced tuning procedures to optimize latency in RHEL for Real Time
Источник
помогите с выбором real-time дистрибутива
всем привет! есть приложение написанное на C++ и Qt. нужно чтобы оно выполнялось на ОС линукс с поддержкой реального времени. че делать? 1)как к ядру стабильной версии прикрутить по своему усмотрению все что потребуется (GUI и тп)? или же есть готовые дистрибутивы, то как из них убрать все не нужное? (платформа X86 + поддержка RS485) 2)как по собственному усмотрению сделать систему встроенной или декстоп вариантах? 3)есть пошаговые руководства? (типо нажми туда пропиши вот это) p.s. в линуксе никогда не сидел и не знаю как там и что
Вы, конечно, уже определились с термином real-time и для чего он нужен в вашей конкретной задаче?
Изучать матчасть. Без этого в проектировании RT-систем — никуда.
В Debian есть realtime-ядро, остальное по вкусу.
мне раз в 1мс приходит пакет с данными, вот его и нужно успеть принять
ну вот как его установить и причесать? дайте направление, а то я только винде работал
есть приложение написанное на C++ и Qt. нужно чтобы оно выполнялось на ОС линукс с поддержкой реального времени. че делать?
в линуксе никогда не сидел и не знаю как там и что
А приложение, наверное, mission critical?
мне раз в 1мс приходит пакет с данными, вот его и нужно успеть принять
Риальне жесткие требования.
Поставь себе хоть какой-нибудь Linux и поучи немного матчасть.
Ну уж нет. Qt и прочай говногуйня отдельно, реальное время отдельно. У тебя процесс реального времени должен по какому либо простому последовательному протоколу общаться с обычным linux-процессом, который уже будет Qt использовать и тому подобное говно. Читай про архитектуру rt-linux.
мне раз в 1мс приходит пакет с данными, вот его и нужно успеть принять
Для принятия 1000 пакетов в секунду RT-система не нужна.
Ты будешь удивляться, но искоробочный лялих и 1мс тебе не гарантирует. Более того, он и одну секунду отклика с гарантией не даст.
В общем, пулеметчик в своем амплуа. Ни хера не знает, но вещает с апломбом и гуру из себя корчит.
RT-система нужна даже для 1 пакета в секунду.
RT-система нужна даже для 1 пакета в секунду.
Нет, не нужна. Она была бы нужна для очень быстрой обработки этого одного пакета в секунду за определённое и жёстко заданное время. Но автор темы про это ничего не сказал.
real-time
приложение написанное на C++ и Qt.
мне раз в 1мс приходит пакет с данными
Adeos patch для kernel-space, xenomai для user-space. Очень советую, можно использовать native,posix,vxworks и т.д. скины.
мне раз в 1мс приходит пакет с данными, вот его и нужно успеть принять
Бред какой-то. Вы понимаете что если вы не примите пакет в 1мс то это будет равноценно отказу систему? Вы знаете как работает hard реал-тайм?
Для «очень быстрой» не нужна. Для гарантированного времени отклика (пусть то будет 1мс, 1с или даже 10с) — нужна. Автор, я думаю, это понимает.
Ты будешь удивляться, но искоробочный лялих и 1мс тебе не гарантирует.
Более того, он и одну секунду отклика с гарантией не даст.
В общем, пулеметчик в своем амплуа. Ни хера не знает, но вещает с апломбом и гуру из себя корчит.
не пацаны.. есть конкретный вопрос-кто знает дайте конкретный ответ. я НИКОГДА не работал с линукс, и для начала помогите сделать ПЕРВЫЕ шаги в ВЕРНОМ направлении: — вот взял я и скачал с kernek.org ядро и чё? как его установить на комп и включить режим реального времени? как к нему прикрутить рабочее окружение? как на это все загрузить приложение с отладочной средой?
Для этого ненужно патчить ядро или юзать realtime.
Достаточно смоделировать свое приложение так чтоб оно принимало эти пакеты.
каждые 1-2 милисекунды приходят данные- вот их надо по любому принять- т.е. говорим системе , чтоб бросала все дела(отрисовка, вычисления) и принимала, данные, как только данные получены пусть дальше проц занимается вычилениями и прочим
Берёте себе Debian, читаете Debian Reference Guide, читаете документацию по ссылкам выше, ставите на свой Debian RT-ядро.
Ну и определись уже, нужен ли тебе жесткий real time. А то тут люди подозревают, что пакеты тебе только принимать нужно, а отклика за гарантированное время не требуется.
не пацаны.. есть конкретный вопрос-кто знает дайте конкретный ответ. я НИКОГДА не работал с линукс, и для начала помогите сделать ПЕРВЫЕ шаги в ВЕРНОМ направлении: — вот взял я и скачал с kernek.org ядро и чё? как его установить на комп и включить режим реального времени? как к нему прикрутить рабочее окружение? как на это все загрузить приложение с отладочной средой?
Тебе стоит поставить любой обычный дистрибутив linux и хоть чуть чуть разобраться с тем, как он работает.
Просто с ядром ты ничего не сделаешь. Тебе нужен ещё как минимум загрузчик и какой-то юзерспейсный процесс. Загрузчик загружает ядро, ядро инициализируется и инициализирует железо, а затем запускает первый процесс (обычно — init).
Если тебя интересует сборка системы с нуля из минимальных «запчастей» — посмотри в сторону LFS.
Откуда «принять»? Что с ними надо потом делать? Похоже, я был неправ, и ты таки не понимаешь, что такое real time.
Источник
