В статье приводятся результаты тестирования производительности операционной системы реального времени QNX Neutrino на различных аппаратных платформах и в сравнении с другими встраиваемыми операционными системами. Рассматриваются задержки переключения между потоками, время обработки прерывания от системного таймера, производительность механизмов синхронизации и т.д.
Бельгийская компания Dedicated Systems Experts*, специализирующаяся на работе с системами реального времени, провела независимое тестирование и оценку нескольких операционных систем. В публичный доступ выложены документы с описанием методики тестирования, обзорное описание операционных систем и отчеты по тестированию QNX Neutrino 6.5, ОС на базе ядра Linux 2.6.33.7.2 с патчами реального времени v.30 и Windows Embedded Compact 7 (бывшая Windows CE) [1–6].
QNX традиционно получил очень хорошие оценки, как при обзорном сравнении (8-9 из 10), так и при тестировании на конкретной аппаратуре (9 из 10). Среди сильных сторон по- прежнему отмечают отличную архитектуру и хорошую документацию, производительность и соответствие требованиям реального времени. Среди недостатков отмечено, что не все компоненты системы доступны в исходных кодах, и несмотря на то что QNX обладает достаточно внушительным списком сетевых и Интернет-технологий, по этому параметру он уступает конкурентам – 8/10 против 9/10 и 10/10 у Windows и Linux.
Другие тестируемые системы получили оценки в целом ниже, чем QNX, хотя достаточно любопытно отметить, что за тесты реального времени Linux-RT получила 4/10 (большего от PREEMPT_RT ожидать и не следовало – [7]. – Прим. ред.), а Windows Embedded Compact 7 благодаря предсказуемому поведению получила такую же высокую оценку, как и QNX (9/10).
Периодически при работе с системами реального времени в QNX возникает необходимость спрогнозировать или объяснить ту или иную задержку, например при обработке прерываний. Особый интерес добавляет то, что есть возможность сравнить поведение достаточно современных систем с разными архитектурами. Тестирование QNX проводилось на следующих аппаратных платформах:
Погрешность измерений составляет 0,2 микросекунды.
Одна из ключевых величин, влияющих на работу всей системы, – время обработки прерывания от системного таймера. Прерывание от системного таймера (системный тик) – это периодическое событие, в QNX 6 по умолчанию оно происходит с интервалом в 1 мс. Системный тик является основой для большинства системных функций работы с временем и задержками. Длительность системного тика в QNX может быть изменена с помощью системной функции ClockPeriod() вплоть до минимального значения в 10 мкс. Такая гибкость позволяет тонко настроить систему на требуемое время реакции, однако следует помнить, что при уменьшении периода системного тика возрастёт нагрузка на систему вследствие большего количества прерываний от таймера.
Прерывания в QNX запрещаются только на крайне малые промежутки времени, и любые системные или пользовательские функции, включая системные вызовы и другие обработчики прерываний, могут быть вытеснены при возникновении прерывания, в том числе и от системного таймера. Поэтому при оценке времени какого-либо события следует для худшего сценария учитывать вероятность совпадения этого события с системным тиком. Практически во всех максимальных значениях измерений в последующих тестах будет присутствовать время обработки прерывания от системного таймера.
Для сравнения – Linux-RT на компьютере на базе Pentium MMX 200 обрабатывает прерывание от системного таймера в среднем в течение 19-21 микросекунды с единичными всплесками до 55 микросекунд. У Windows Compact 7 время обработки системного таймера на платформе Intel Pentium II 233 МГц (на Pentium MMX 200 Windows Compact 7 отказался работать) имеет в среднем разброс 4-7 микросекунд.
Единицей выполнения и планирования в QNX является поток. Каждый поток имеет собственный контекст выполнения (IP – instruction pointer, SP – stack pointer и др.), но находится в адресном пространстве процесса, и каждый процесс включает как минимум один поток.
Планированием потоков в QNX занимается менеджер процессов. Менеджер процессов объединён с микроядром QNX в модуль procnto и является неотъемлемой частью системы.
QNX 6.5 предоставляет 255 уровней приоритетов и следующие типы планирования: FIFO, карусельное (Round Robin) и спорадическое.
В этом тесте измерялось время переключения между потоками с одинаковым приоритетом, работающими с дисциплиной диспетчеризации FIFO. Для переключения потоки добровольно освобождали процессор (yield).
Тест проводился в трех различных сценариях:
При создании потока в сценарии 1 измеряется время системного вызова, а для сценариев 2 и 3 измеряется время от момента системного вызова до получения управления создаваемым потоком.
Итак, результаты тестов по созданию и удалению потока.
QNX предоставляет стандартные для POSIX-систем механизмы синхронизации в виде семафоров и мьютексов.
Операции по созданию и удалению семафора в среднем занимают:
Время захвата и освобождения семафора, не использующегося другими потоками, невелико и составляет в среднем для тех же платформ соответственно 0,5/1,2/2,5 мкс.
В следующем тесте ставилась задача выяснить, каким образом количество заблокированных потоков влияет на время захвата и освобождения семафора. В случае когда на семафоре заблокировано несколько потоков, его захват или освобождение вызывает перепланирование, то есть такой тест отвечает на вопрос, сколько времени тратит ОС на перепланирование.
В тесте создаётся 128 потоков с различными приоритетами, приоритет потока, создающего другие потоки, ниже, чем у создаваемого. Когда созданный поток получает управление, он пытается захватить семафор, но тот уже занят, поток блокируется, и управление получает создающий поток. Время от попытки захвата семафора до получения управления создающим потоком в этом тесте называется временем попытки захвата семафора, это время включает задержку переключения между потоками.
После того как создан последний поток, создающий поток начинает освобождать семафор. Время от момента освобождения семафора до получения управления потоком, заблокированным на семафоре с высшим приоритетом, называется временем освобождения семафора (в этом случае это время также будет включать задержку переключения между потоками).
Как показывают результаты тестов, время освобождения семафора не зависит от количества заблокированных на нем потоков, что безусловно хорошо.
Взаимно исключающий семафор – мьютекс можно назвать двоичным семафором, но его поведение отличается от семафоров. Мьютекс имеет концепцию захвата владельцем и в отличие от семафоров может использоваться для предотвращения инверсии приоритетов.
Время захвата и освобождения мьютекса единственным потоком, то есть без конкуренции за мьютекс, очень мало и в случае с Intel Atom и Beagle-XM Board находится на уровне погрешности измерений. Это достигается за счёт поддержки атомарных операций и отсутствия необходимости в полноценном системном вызове.
В следующем тесте запрос и освобождение мьютекса происходили в разных потоках. Высокоприоритетный поток, ожидающий мьютекс, находится в заблокированном состоянии, низкоприоритетный поток освобождает мьютекс. Время захвата мьютекса в этом случае измеряется от момента запроса мьютекса до момента получения управления потоком, владеющим мьютексом.
Также перед освобождением мьютекса низкоприоритетным потоком дополнительный поток со средним приоритетом находится в готовом к исполнению состоянии, однако он не получает управление, поскольку низкоприоритетный поток, владеющий мьютексом, перед освобождением мьютекса наследует высокий приоритет потока, ожидающего мьютекс.
Время освобождения мьютекса измеряется от момента запроса на освобождение мьютекса до момента получения управления потоком, ожидающим мьютекс.
В обоих случаях полученный результат включает в себя задержку переключения между потоками.
Обработка прерываний является ключевой частью систем реального времени, поэтому крайне важно, чтобы задержки при их обработке были минимальными.
При возникновении прерывания микроядро сохраняет контекст выполняющегося потока и после идентификации прерывания передаёт управление обработчику прерывания. Обработчик прерываний выполняется в контексте содержащего его потока и имеет полный доступ к оборудованию. Во время работы обработчика прерывания остальные прерывания разрешены, поэтому при возникновении другого прерывания обработчик может быть вытеснен более высокоприоритетным прерыванием (в случае если приоритеты прерываний поддерживаются оборудованием).
Вместо использования обработчика прерывания можно также использовать механизм уведомления о прерывании посредством события и выполнять обработку на приоритете обычного потока. В этом случае на время обработки прерывание находится в замаскированном состоянии, и после обработки его необходимо размаскировать самостоятельно с помощью системной функции InterruptUnmask().
Для последующих тестов в качестве независимого источника прерываний используется внешняя PCI-плата для систем X86 и внутренний таймер (General Puprose) для платы на базе ARM.
В этом тесте измерялось время перехода из выполняемого потока в обработчик прерывания.
При сравнении с результатами других систем следует иметь в виду, что в их тестах учитывается также аппаратная задержка обработки прерывания. Задержка обработки прерывания для Linux-RT на компьютере на базе Pentium MMX 200 составляет в среднем 8,5 мкс с максимумом в 32,4 мкс. Для Windows Compact 7 на компьютере Intel Pentium II 233 МГц задержка составляет в среднем 6,8 мкс, максимум 12,3 мкс.
В этом тесте измерялось время перехода из обработчика прерывания обратно в поток.
Для сравнения – задержка планирования для Linux-RT на компьютере на базе Pentium MMX 200 составляет в среднем 2,7 мкс с всплесками до 26,1 мкс.
В этом тесте обработчик прерывания разблокирует самый высокоприоритетный поток в системе. Измеряется время перехода из обработчика в этот поток (включает задержку переключения между потоками).
Для сравнения – задержка планирования для Linux-RT на компьютере на базе Pentium MMX 200 составляет в среднем 21,6 мкс, с всплесками до 76,4 мкс. Для Windows Compact 7 на компьютере Intel Pentium II 233 МГц задержка составляет в среднем 7,5 мкс, максимум 17,7 мкс.
Этот тест отвечает на вопрос, какой минимальный интервал возникновения прерываний может выдержать QNX без потери прерываний.
Тест проводился с различными интервалами и количеством прерываний:
Для сравнения – интервал прерываний, на котором Linux-RT на компьютере на базе Pentium MMX 200 не теряет ни одно прерывание из миллиарда, составляет 150 мкс. У Windows Compact 7 на компьютере Intel Pentium II 233 МГц эта же величина составляет всего 13 мкс. ●
Экономика профилактики: использование Интернета вещей для планирования профилактического обслуживания оборудования
Машины, а точнее, сложные высокотехнологичные установки – станки или другое технологическое оборудование для любой промышленной отрасли представляют собой ценные активы, которые необходимо защищать от повреждений, неисправностей и отказов с помощью надлежащих мер по техническому обслуживанию. В этой статье будет рассмотрен один из примеров создания системы, автоматически контролирующей состояние и время работы машин с последующей отправкой уведомлений о графике профилактического технического обслуживания (ПТО). 23.04.2024 СТА №2/2024 427 0 0Блок управления для исполнительных устройств в оптическом тракте лазерной системы
В статье представлен блок управления для исполнительных устройств в оптическом тракте лазерной системы. Приведены решения на аппаратном и программном уровнях, обоснован выбор средств автоматизации. 23.04.2024 СТА №2/2024 334 0 0Построение цифрового двойника склада металлопроката с использованием искусственной нейронной сети
Изложены методика и результаты эксперимента по применению искусственной нейронной сети для отслеживания перемещений продукции металлопроката на территории цеха. Приведены преимущества такого способа организации цифрового двойника склада. 23.04.2024 СТА №2/2024 307 0 0Горячее резервирование с MasterSCADA 4D и ПЛК Regul R500 на примере АСУ ТП для авиатопливных комплексов
В статье представлено решение для автоматизированного контроля и управления технологическими объектами склада одного из технологических лидеров российской авиатопливной отрасли. Система построена на базе ПЛК REGUL500 с поддержкой горячего резервирования центральных процессоров и программной платформе MasterSCADA 4D с поддержкой резервирования серверов, работы рантайм на операционной системе Astra Linux и синхронизацией данных на программном уровне. Эти составляющие, а также опыт сертифицированного интегратора ООО «ЛИТЭК», позволили создать отказоустойчивую систему управления повышенной надёжности в полном соответствии с современными требованиями стратегии цифровой трансформации. 23.04.2024 СТА №2/2024 443 0 0