Каковы наилучшие способы приблизиться к задачам реального времени в ОС или ядре без реального времени?

Question

На компьютере с GNU/Linux, если вы хотите выполнять задачи реального времени (субмиллисекундные критически важные) задачи, вам почти всегда приходится проходить длительный, сложный и проблемный процесс исправления ядра, чтобы выявить адекватные поддержка [1][2].

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

Итак, мой вопрос в том, что является лучшим из вторым местом способами/тегами, чтобы пройти как можно ближе к вышеуказанной цели в реальном времени? Вещи, которые можно просто сделать в исходном коде приложений, без глубокого знания базового оборудования или слишком много «взлома ядра».

Приоритет приоритета процесса, запуск дополнительной нити для «критических» задач и (в C) с использованием вариантов nanosleep() - наилучшие ответы/трюки, которые я придумал до сих пор. Надеюсь найти больше.

Answer 1

sched_setscheduler(2) и друзья позволяют использовать два разных плановых планировщика в режиме реального времени, SCHED_FIFO SCHED_RR. Процессы, запущенные под этими планировщиками, приоритетнее, чем обычные процессы. Таким образом, пока у вас есть только несколько из этих процессов, и контролируйте приоритеты между ними, вы можете фактически получать ответы о реальном времени в реальном времени.

В соответствии с просьбой в комментарии, здесь разница между SCHED_FIFO и SCHED_RR:

С «в реальном времени» планировщиков, там до 100 различных приоритетов (POSIX требует только 32 различных уровней, так что один должен использовать sched_get_priority_min(2) и sched_get_priority_max(2), чтобы получить реальное число. планировщиками и работа упреждение процессы и потоки с более низким приоритетом, разница в том, как они работают задачи с одинаковым приоритетом.

SCHED_FIFO, это первый в первом из планировщика (следовательно, имя). Это означает, что задача, которая сначала попадает в очередь выполнения, разрешается запускать до тех пор, пока она не будет выполнена, добровольно откажется от i ts в очереди выполнения или упреждается задачей с более высоким приоритетом.

SCHED_RR, представляет собой круглый планировщик. Это означает, что задачи с одним и тем же приоритетом разрешены только для определенного кванта времени. Если задача все еще выполняется, когда это квант времени завершается, задача выгружается, а следующая задача в очереди выполнения (с таким же приоритетом) разрешается запускать до своего кванта времени. Как и в случае с SCHED_FIFO, задачи с более высоким приоритетом вытесняют более низкие приоритеты, однако, когда задача, упреждаемая задачей с более высоким приоритетом, разрешается запускать снова, тогда ей разрешено работать только на оставшееся время в ее кванте. См. Раздел Noes в разделе sched_rr_get_interval(2) о том, как установить квант времени для задачи.

Answer 2

MRG

Sub-миллисекунды будет трудно гарантировать на ядро ​​не-RT. Я знаю, что за последние годы произошла очень хорошая работа (например, большая блокировка ядра исчезла), но этого все еще недостаточно, чтобы гарантировать это.

Вы можете взять look в Scientific Linux от этих дружелюбных атомистов в CERN и Fermilab.У этого может быть установлен MRG (см. Мою ссылку), который дает вам предварительную установку патча PREEMPT_RT.

Или, если у вас есть деньги, вы можете получить Redhat MRG. Это полностью поддерживаемый дистрибутив Linux с встроенным патчем PREEMPT-RT, так что это избавит вас от проблемного исправления ядра.

Вещь, Редхат заряжает лот за это (3000 долларов США В УСТАНОВКЕ). Я думаю, что они упали, что одним из крупнейших клиентов для него являются высокоскоростные трейдеры, у которых есть еще много лотов и лотов, и поэтому они не заметят, что за дверью выйдет $ 3000/коробка/год.

Как уживался с ГПМ

Я сделал справедливый бит работы с ГПМ (с использованием обоих выше), и это очень хорошо. Он заменяет процедуры обслуживания прерываний в ядре запасов потоками для обслуживания прерывания. Это означает, что вы можете запускать свое программное обеспечение в приоритетах, превышающих потоки IRQ! Это то, что вам нужно сделать, если вы хотите приблизиться к , гарантируя латентность субмиллисекунд в вашем приложении.

Кажется, что происходит постепенный переход MRG в ядро ​​mainline, что, на мой взгляд, является хорошей вещью. Может быть, в один прекрасный день он станет основным.

Другие Gotchas

управление температурным режимом Современный процессор может быть реальной боли в области шеи. У меня были системы, которые блокировались на 0,3 секунды, в то время как прерывание системного управления обслуживалось (с помощью BIOS bleedin, а не операционной системы), только потому, что процессор немного разогрелся. См. this. Поэтому вы должны быть осторожны с тем, что делает ваше базовое оборудование. Как правило, вы должны начать беспокоиться о том, что вы управляете охлаждением современных ПК и возвращаетесь к большому вентилятору, который все время крутится.

Answer 3

Вы можете получить довольно далеко от Linux, удалив «нарушение» из других процессов в процесс реального времени. Я играл с тем же самым в Windows, что намного больший ужас, чтобы получить право, но он показывает направление. Итак, какой-то контрольный список:

• Самое важное (странно, но это правда): аппаратное обеспечение. Не ходите за ноутбуком, это будет оптимизировано, чтобы делать странные вещи во время прерываний SMM. Вы ничего не можете сделать.
• Драйверы: Linux (и Windows) имеет плохие драйверы и хорошие драйверы. Связано с оборудованием. И есть только один способ узнать: бенчмаркинг.

изолят от остальной части системы, отключить все совместное использование:

• изолят один процессор (man cpuset). Создайте два набора процессоров, один для обычных процессов и один для вашего процесса в реальном времени.
• Уменьшите часть кода в реальном времени до минимума. Общайтесь с большим буфером с другими частями системы. Уменьшите IO до минимальной (поскольку IO имеет плохие гарантии).
• Сделать процесс наивысшим (мягким) приоритетом в реальном времени.
• Отключить HyperThreading (вы не хотите разделить)
• предварительно выделите нужную вам память и mlock() память.
• Изолируйте устройства, которые вы используете. Начните с выделения выделенного IRQ устройству (переместите другие устройства в другое прерывание или удалите другие устройства/драйверы).
• Изолировать IO, который вы используете.

Снижение активности остальной системы:

• только начать процессы вы действительно нуждаетесь.
• удалите оборудование, которое вам не нужно, как диски и другое оборудование.
• disable swapping.
• не используют модули ядра Linux или загружают их спереди. Инициализация модулей непредсказуема.
• предпочтительно удалить пользователя также :)

сделать его стабильным и воспроизводимость:

• отключить все сбережения энергии. Вы хотите, чтобы все время выполнялось то же самое.
• просмотрите все настройки BIOS и удалите из них все «события» и «обмен». Таким образом, никакие фантастические скорости, тепловое управление и т. Д. Выбирайте низкую задержку, не выбирайте вещи с «всплеском» в названии, так как это обычно снижает производительность за худшую производительность.
• обзор настроек драйвера Linux и более низкие задержки (если применимо).
• использовать последнее ядро, которое каждый день пытается выглядеть как ядро ​​реального времени несколько больше.

И затем тест, используя стресс-тестирование и оставляя машину в течение нескольких дней при записи макс. Задержки.

Итак: удачи :)

Answer 4

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

Я категорически не согласен: Самая большая проблема в том, что вы можете быть заблокированы или предварительно упущены в течение произвольного промежутка времени без предупреждения. Не имеет большого значения, если вы можете спать с точностью 1us, если вы иногда можете спать на 500 мс. В реальном времени вычисления - это гарантированные наихудшие времена, а не прецизионные интервалы сна. Если вы хотите запрограммировать EEPROM I2C, вы можете воспользоваться таймером с высоким разрешением, который позволит вам как можно ближе соответствовать временам установки/удержания, не теряя времени. Случайная случайная задержка в 500 мс не имеет значения, потому что EEPROM просто сидит там, ожидая. Однако это не приложение в реальном времени. Если вы реализуете контур управления с обновлением 1us для управления сервоприводом, эта задержка в 500 мсек приведет к огромному поломке позиции, когда система работает неконтролируемо.

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