7 Приложение A: Комментарии поставщика
8 Приложение B: Используемые сокращения
9 Приложение C: История модернизации документа
1 Общая информация
1.1 Продукт
QNX NEUTRINO RTOS v6.2.0 от фирмы QNX Software Systems Ltd.
1.2 Преимущества
- Быстродействие
- Отличная архитектура для распределенных и устойчивых систем
- Хорошая поддержка платформ
1.3 Недостатки
- Медленная интегрированная среда разработки
1.4 Рейтинги
Для подробного описания рейтингов читатель может обратиться к приложению D документа "Report definition and test plan", который расположен по адресу http://www.dedicated-systems.com/encyc.
1.5 Цены
Для получения детальной и соответствующей настоящему времени информации по ценам на продукт, свяжитесь с производителем.
2 Введение
Данный документ состоит из двух частей. Первая часть дает техническую оценку продукта, а часть вторая его практическую оценку. Техническая оценка представляет собой теоретическое изучение особенностей архитектуры и дизайна (проектирования/исполнения) операционной системы, основанное на документации к продукту и опыте работы. В практической оценке рассматриваются и комментируются результаты различных тестов продукта.
Данный отчет обсуждает различные технические аспекты, затронутые в документе “What makes a good RTOS”. Этот документ отражает мнение Dedicated Systems Experts о том, чем с необходимостью должна обладать операционная система для того, чтобы ее можно было назвать хорошей операционной системой реального времени. Таким образом, вопрос “Что делает RTOS хорошей”, считается неотъемлемой частью данного отчета.
2.1 Различные шаги при создании данного отчета
Первым шагом является исследование оцениваемого продукта и выполнение большого количества различных тестов. После получения и анализа результатов тестов, Dedicated Systems Experts создают первую версию данного отчета. Копия данного проекта предоставляется производителю для оценки.
На втором шаге изучаются комментарии и ответная реакция производителя. Комментарии, которые признаны справедливыми, добавляются в отчет.
2.2 Стратегия модернизации
Для улучшения качества отчета, фирма Dedicated Systems всячески приветствует отправку читателями на адрес (info@dedicated-systems.com) любых пожеланий, замечаний и информации о неточностях в отчете, на которые они сочтут нужным обратить внимание. Отзывы читателей тщательно рассматриваются и принимаются во внимание при составлении версий с незначительными изменениями (minor version). Каждая такая следующая версия доступна владельцу первой бесплатно.
При внесении в отчет новой информации (например, результатов новых тестов), создается версия с существенными изменениями (major version). Такая версия поступает в продажу. Владельцам предыдущих версий предоставляется скидка.
3 Техническая оценка
Для разъяснения содержания следующих разделов, читателю предлагается обратиться к документу “Report definition and test plan”, который может быть загружен c сайта (http://www.dedicated-systems.com/). Этот документ определяет (помимо многого другого) различные модели защиты памяти, объекты и особенности, упомянутые в разделе Богатство API. Также документ содержит детальное разъяснение проведенных тестов.
3.1 Инсталляция и конфигурация
Инсталляция простая и быстрая. Создание и конфигурирование конкретного образа QNX осуществляется посредством IDE или с использованием текстовых build-файлов.
3.1.1 Инсталляция
Операционную систему реального времени QNX NEUTRINO v6.2 легко и быстро инсталлировать. Самый простой путь инсталляции QNX NEUTRINO v6.2 - это использование CD-диска, который вы можете заказать у фирмы-производителя, “QNX Software Systems”. Инсталляция базовых модулей занимает всего несколько минут, это значит, что по завершении этого процесса будут проинсталлированы ядро и пользовательский интерфейс (встраиваемая графическая оболочка Photon microGUI). Дополнительные модули, например, компиляторы, и т.д. могут быть проинсталлированы с использованием менеджера устройств (DEV).
3.1.2 Конфигурация
Конфигурация QNX NEUTRINO RTOS v6.2 достаточно проста. При полной инсталляции системы, такие проблемные компоненты, как жесткие диски или сетевые карты, определяются автоматически. Если требуется дальнейшее конфигурирование, его можно осуществить при использовании графического пользовательского интерфейса.
Построение конкретного QNX образа происходит при использовании build-файлов. Для изменения, добавления и конфигурирования модулей необходимо редактирование соответствующих текстовых build-файлов. В документации к системе содержится большое количество примеров описания build-фалов.
Дополнительно IDE содержит инструмент построения системы, делающий доступным управление QNX-образами. Данный инструмент изменяет build-файлы при помощи графического интерфейса для создания образа (как загрузочного образа, так и флэш – образа) и позволяет импортировать существующие build-файлы. Помимо этого, данный инструмент конфигурирования системы предоставляет анализ зависимостей (например, указывает потерянные библиотеки), подобно тому как “диетолог” создает уменьшенные версии используемых вами разделяемых библиотек, содержащие только используемые вами функции.
Несмотря на то, что запуск Momentics IDE занимает достаточно большое количество времени (несколько минут), инструмент построения системы работает достаточно быстро и довольно-таки прост в использовании. Сначала Вы должны немного поэкспериментировать, для того чтобы понять, где располагаются различные модули (например, обнаруженные устройства, включенные в DLL). Вы можете улучшить результат, добавив колонку комментария в процессе выбора. При включении модуля в построитель системы, данный комментарий отображается в IDE и объясняет использование и опции библиотеки. Построитель системы также автоматически добавляет разделяемые библиотеки, которые необходимы добавленным модулям в вашей целевой конфигурации системы.
Наилучшим образом построитель системы инициализируется существующим (простым) build-файлом, который устанавливает основную конфигурацию.
Функция "диеты" работает очень хорошо и является одной из тех вещей, которых мы не обнаружили ни в одном другом графическом построителе платформы. Конечно, "диетизация" разделенных библиотек - это медленный процесс (проверяющий все зависимости), но это требуется сделать только в конце цикла построения.
Графический инструмент построения системы, с его проверками зависимостей и функцией «диеты», является главным усовершенствованием по сравнению с QNX v6.1.
3.2 Архитектура RTOS
Истинно клиент-серверная архитектура, предоставляющая полную защиту виртуальной памяти. QNX NEUTRINO RTOS v6.2 является операционной системой на базе обмена сообщениями и может быть с легкостью распределена между большим количеством сетевых узлов. RTOS поддерживает SMP и предоставляет множество дополнительных HA (High Availability) возможностей.
3.2.1 Архитектура системы
QNX NEUTRINO RTOS v6.2
имеет клиент - серверную архитектуру, состоящую из микроядра и сгруппированных
вокруг него взаимодействующих процессов. Микроядро включает в себя только
сервисы ядра, такие как нити, сигналы, передача сообщений, синхронизация,
планирование заданий и таймер. Микроядро само по себе не подвергается
планировке. Его код выполняется только в результате вызова ядра или
возникновения аппаратного прерывания. Дополнительные функциональные возможности осуществляются взаимодействующими процессами, которые действуют как серверные процессы и отвечают на запросы процессов клиента (например, прикладного процесса). Примеры таких серверных процессов - менеджер файловой системы, менеджер процесса, менеджер устройства, менеджер сети, и т.д. В то время как ядро запускается на 0 уровне привилегий процессора Intel, менеджеры и драйверы устройств запускаются на уровнях 1 и 2 (для исполнения действий ввода/вывода). Прикладные процессы запускаются на 3 уровне привилегий и поэтому могут выполнять только общие команды процессора.
QNX NEUTRINO RTOS v6.2 -
операционная система, основанная на передаче сообщений. Обработка передачи
сообщений является фундаментальным средством межпроцессорного взаимодействия (IPC)
в данной RTOS. Обработка передачи сообщения основана на клиент-серверной модели:
клиент (например, прикладной процесс) посылает сообщение серверу (например,
менеджеру устройства), который возвращает результат. Многие запросы QNX NEUTRINO
RTOS API используют данный механизм передачи сообщений. Например, когда
прикладной процесс хочет открыть файл, запрос к системе переводится в сообщение,
которое посылается менеджеру файловой системы. Менеджер файловой системы (после
доступа к диску через его драйверы устройств) отвечает обработчиком файла. Этот
механизм передачи сообщений является прозрачным относительно сети, то есть,
система может быть распределена между более чем несколькими сетевыми узлами, без
необходимости каких-либо изменений в коде приложения. При передаче сообщений между клиентом и сервером, QNX NEUTRINO RTOS v6.2 использует так называемый механизм приоритет, управляемый клиентом (“client-driven priority”). Это означает, что серверный процесс наследует уровень приоритета клиентского процесса, требующего обслуживания. Когда обслуживания запроса клиента завершено, серверный процесс может восстановить свой первоначальный уровень приоритета. Если обслуживания требуют несколько клиентов одновременно, серверный процесс принимает уровень приоритета клиентского процесса с наиболее высоким приоритетом. Это помогает избежать инверсии приоритетов.
Архитектура клиент-сервер имеет много преимуществ, одно из которых – устойчивость к ошибкам. Каждый менеджер (за исключением менеджера процессов) и драйвер устройства запускается в его собственном адресном пространстве виртуальной памяти, что приводит к надежности и устойчивости системы. Цена, которую приходится платить, - это производительность: выполнение системных вызовов приводит к небольшому количеству переключений контекстов (с дополнительными расходами на защиту памяти), что приводит к некоторому понижению производительности.
3.2.2 Основные системные ресурсы
3.2.2.1 Методика обработки заданий
QNX NEUTRINO RTOS v6.2 использует процессы и нити. Процесс определяет адресное пространство, в котором будут запущены нити и всегда содержит, по крайней мере, одну нить.
Существует 63 уникальных
уровня приоритетов нитей, доступных приложениям. Этого количества достаточно, но
иногда желательно иметь 128 уровней приоритетов. Это особенно важно для больших
приложений реального времени, разработанных с использованием таких технологий
как RMA (Rate Monotonic Analysis), в которых каждая нить должна иметь свой
собственный уникальный уровень приоритета. Планировщик заданий управляет нитями, используя очередь с приоритетами (FIFO), алгоритм round-robin или "sporadic scheduling" – нововведение, реализованное в QNX 6.2.
Спорадическое (случайное) распределение является адаптивным: т. е. приоритет нити понижается, если она требует слишком много квантов времени центрального процессора. После некоторого времени существования с низким приоритетом (период пополнения), нить снова приобретает свой прежний уровень приоритета. Все эти параметры (включая границы приоритетов) могут изменяться для каждой нити.
|
||||||||||||
3.2.2.2 Методика управления памятью
В QNX NEUTRINO RTOS v6.2
каждому процессу отводится свое собственное пространство виртуальной памяти.
Виртуальная память поддерживает страничный механизм распределения. Виртуальная
память защищает как пользовательские, так и системные процессы друг от друга,
что приводит в высокой устойчивости системы к ошибкам. Поддерживается подкачка на диск (свопинг), но для этого требуется ее явно задействовать при помощи семейства "отпирающих" вызовов. В QNX Software не рекомендуется использовать эти вызовы, так как они не предназначены для общих целей, а только для совместимости с GNU-компиляторами и связующими трансляторами. Обычно свопинг является нежелательным для встроенных систем, но последнее время становится все более и более необходимым для централизованных систем. Вот почему QNX планирует поддержку явного свопинга в следующих версиях.
Подкачка по обращению - это способность операционной системы загружать исполняемые части в память, когда это необходимо. В QNX NEUTRINO RTOS v6.2 сегмент кода бинарных данных целиком загружается в память при выполнении. Подкачка по обращению пагубно отражается на предсказуемости в режиме реального времени и, таким образом, не включена в QNX RTOS.
|
||||||||||||
3.2.2.3 Методика обработки прерываний
Обработчик прерываний в микроядре осуществляет управление прерываниями на их начальной стадии. Нить, имеющая соответствующие привилегии, может динамически устанавливать и удалять обработчики прерываний путем передачи микроядру адреса функции-обработчика (ISR). При возникновении прерывания, обработка передается сначала в микроядро, которое содержит код для его переадресации. Перед вызовом ISR микроядро сохраняет контекст исполняемой нити и переустанавливает регистры процессора таким образом, что ISR имеет доступ к адресному пространству нити, в которой он содержится. Это позволяет ISR выполнить обработку, пользуясь данными и буферами нити, в которой она содержится, или буферизовать принятые данные для последующей обработки этой нитью. Это также дает возможность ISR осуществлять доступ ко всем устройствам, находящимся в домене ответственности (области префиксов) данной нити, и непосредственно выполнять операции ввода-вывода. QNX NEUTRINO RTOS v6.2 поддерживает распределение прерываний. При возникновении прерывания, каждая программа обработки соответствующего прерывания, связанного с аппаратным прерыванием, обрабатывается по очереди. Пользователь не должен брать на себя ответственность за порядок вызова программ обработки прерываний.
Прерывания не блокируются
во время выполнения управляющей прерываниями программы, таким образом,
прерывания могут быть вложенными. Немаскируемые прерывания могут быть обслужены
во время выполнения уже запущенной программы обработки прерывания. Так как QNX NEUTRINO RTOS
v6.2 является клиент-серверной операционной системой, основанной на передаче
сообщений, взаимодействие ISR и нити основано на сигналах и пульсах. ISR может
посылать пульсы и сигналы нитям и процессам и делать готовой ждущую прерывания
нить путем вызова "InterruptWait". ISR также могут передавать данные через
определенные приложениями структуры соответствующим процессам. Использование
семафоров было преднамеренно блокировано, так как это недостаточно хорошее
решение для системы реального времени, с архитектурой основанной на передаче
сообщений.
|
||||||||||
3.3 Богатство API
QNX NEUTRINO RTOS v6.2 предоставляет как POSIX-совместимость, так и собственные API. API приспособлены для работы с системами, основанными на сообщениях, как и архитектура самой операционной системы.
Таблицы, представленные ниже, описывают основные объекты реального времени и особенности POSIX и QNX интерфейсов. Во время интерпретации данных результатов, читателю необходимо помнить, что представленные таблицы затрагивают только строго определенное множество системных вызовов. QNX NEUTRINO RTOS v6.2 предоставляет другие интерфейсы, которые в данных таблицах не рассматриваются.
3.3.1 Управление заданиями
|
3.3.2 Часы и таймер
|
|
3.3.3 Управление памятью
|
|
3.3.4 Обработка прерываний
|
3.3.5 Объекты синхронизации и исключения
Помимо указанных ниже механизмов, QNX NEUTRINO RTOS v6.2 предоставляет дополнительные возможности выполнения синхронизации, некоторые из которых являются очень мощными (соединенные нити, блокировка читатель/писатель, sleepons, spinlocks, барьеры и так далее). Также QNX NEUTRINO RTOS v6.2 предоставляет actomic_xxx функции, которые могут быть использованы для осуществления высокоскоростных операций, не требуя при этом традиционных исключающих элементов.
|
|
|
|
|
|
3.3.6 Объекты связи и передачи сообщений
|
|
3.4 Поддержка Интернет
Комплект разработки QNX Momentics содержит следующие продукты и инструменты:
- Встроенный веб-сервер. Встроенный веб-сервер поддерживает CGI 1.1, HTTP 1.1, динамический HTML (включая команды Server Side Include). Вы также можете управлять SSI, используя сервер данных. Сервер данных позволяет множеству нитей разделять данные: для этого существует специальный процесс, обновляющий сервер данных в соответствии с состоянием драйверов аппаратных устройств, в то время как встроенный веб-сервер имеет доступ к текущему состоянию данных.
- Небольшой веб-браузер для просмотра информации. Он полностью поддерживает HTML 3.2, фреймовую структуру, технологии javascript, cookies и т.д. Возможна даже реализация аудио/видео потока. Браузеры Mozilla и Opera не так давно также были приспособлены для использование под QNX NEUTRINO RTOS v6.2.
- Источник доступный для построения интернет – приложений для встроенных систем.
- Широкая поддержка сети и протоколов. Для получения более детальной информации читатель может обратиться к сайту DS.
3.5 Инструменты
Существует большое количество доступных в QNX NEUTRINO RTOS v6.2 инструментов. Нововведением для QNX NEUTRINO RTOS v6.2 является QNX Momentics IDE, базирующееся на расширяемом среде Eclipse.
Дополнительно могут быть использованы Metrowerks Codewarrior IDE и пакет разработчика GCC. Данные пакеты разработчиков содержат наиболее часто используемые инструменты.
Новый IDE был сильно расширен по сравнению с предшествующей версией QNX. IDE снабжен хорошими обучающими видео (на CD), позволяющими быстро начать работать с системой. Предоставляемый пользовательский интерфейс интуитивно понятен.
Самым большим недостатком данного IDE является большая ресурсоемкость (потребляемая память и время центрального процессора), таким образом, для старых платформ и оборудования его использование сильно затруднено. Несомненно, что время подключения IDE в таком случае (у нас для Pentium 200 MHz MMX с 128MB RAM это заняло около пяти минут) совершенно неприемлемо. Уже запущенный IDE работает медленно, но все же работает: только позаботьтесь о том, чтобы не закрыть случайно IDE окно... В новых продуктах мы все чаще и чаще замечаем следующую особенность: кажется, будто программисты больше не работают в ограниченной среде разработки и начинают крайне непроизводительно кодировать!
Также мы заметили некоторые проблемы работы компилятора: возникающие при компиляции ошибки не всегда правильно ставятся в соответствие строкам кода в редакторе, на которых они возникли. Однако, переустановка IDE решает данную проблему.
Помимо инструментов, которые будут подробно рассмотрены ниже, доступны также дополнительные возможности:
- Пакет разработчика Photon для разработки пользовательских Photon интерфейсов.
- Пакет разработчика TCP/IP для разработки программ соединения вида точка-точка по протоколу TCP/IP.
|
3.6 Документация и поддержка
Мы были весьма обрадованы прекрасной технической поддержкой данной версии продукта. Документация в значительной степени улучшена по сравнению с предшествующей версией QNX (6.1).
Безусловно, разработчики QNX Software читали отзыв по QNX 6.1 RTOS. И мы рады были тому факту, что главная критика не осталась незамеченной: недостаточное документирование параметров API. Теперь все параметры подробно описываются в документации. Дальнейшее улучшение может дать добавление ссылок на описание используемых для этих параметров структур.
Как и раньше, документация выполняет важную работу по предоставлению основной информации о системе и ее архитектуре.
QNX Software предоставляет платную расширенную поддержку своим пользователям (Стандартная и Приоритетная поддержка).
3.7 Методология разработки
Предшествующие версии QNX RTOS использовали только подход, при котором и главная и целевая машины совпадали. В QNX Neutrino RTOS v6.2 разработчики могут использовать как self-hosted так и кросс модель разработки.
Как уже описано в разделе 3.2, QNX Neutrino RTOS v6.2 может иметь как конфигурацию, состоящую из одного микроядра, так и включать многочисленные модули, превращаясь тем самым в полноценную многопользовательскую операционную систему обслуживаемую как среда разработки.
Преимуществом self-hosted подхода является возможность пользователя работать на одной машине: приложение может тестироваться на одной машине, на которой и было разработано, отладка может проходить локально, и так далее.
Проблем при взаимодействии главной и целевой машин не возникает. Разработчики, предпочитающие стандартный рабочий стол MS-Windows или Solaris рабочему столу QNX, могут использовать инструменты cross-разработки. В дополнение к QNX Momentics IDE, для MS-Windows может быть использован Metrowerks IDE для компиляции и отладки с Windows host-машины.
Вопрос, какой вид разработки лучше - кросс или self-hosted - является часто обсуждаемым. На самом деле, это зависит от качества инструментов. Если уровень инструментов cross-разработки низкий, следует отдать предпочтение self-hosted разработке. К сожалению, оценка качества инструментов разработки выходит за границы данного отчета. Но, несомненно, то, что операционная система поддерживает оба эти метода, является большим преимуществом.
4 Практическая оценка
Система быстра и предсказуема. Во время проведения тестов мы не встретили ни одного факта, свидетельствующего о недостатках производительности, предсказуемости или устойчивости системы к ошибкам.
4.1 Тестируемая система
Все тесты были проведены с использованием следующего оборудования:
- Материнская плата: Chaintech 5TTMT M201 с 33MHz PCI-шиной
- BIOS: Award BIOS v4.51PG
- ЦП: Intel Pentium 200MHz MMX Family 5 Model 4 Stepping 3 (с 32KB L1 Cache)
- RAM: 32 Mb DIMM
- L2 Memory Cache: 512KB
- Жесткий диск: Western Digital Caviar 34300, primary master, UDMA 2
- Графический адаптер: S3 Trio 64V2/DX в PCI slot 1
- Сетевая карта: SVEC NE2000 Plug & Play ISA network card
- VMETRO PCI exerciser in PCI slot 3 (PCI interrupt level D, local bus interrupt level 10)
- VMETRO PBT-315 PCI analyzer in PCI slot 4.
- Во время проведения тестов, по умолчанию внешний и ЦП внутренний КЭШи задействованы, если не указано обратное.
- DRAM-таймирование установлено на 60 нс.
4.1.1 Операционная система и конфигурация приложения
Все тесты были проведены с минимальным образом ядра, за исключением тестов файловой системы и сетевых стеков.
Все тестовые приложения используют POSIX-совместимое API, там где это возможно.
4.1.2 Дополнительные комментарии
Все тесты были проведены с использованием модели памяти "d", подробно описанной в документе DS "Report definition and test plan".
Данная модель памяти предоставляет полную защиту виртуальной памяти для всех процессов.
4.1.3 Сравнение результатов теста с QNX 6.1
Сравнение результатов тестов для рассматриваемой и предшествующей версий является хорошим упражнением.
4.2 Обработка прерываний
В данных разделах будет тестироваться способность системы к обработке различных типов прерываний. Различные сценарии тестов включают в себя:
- Одиночные прерывания, не приводящие к перепланировке заданий
- Одиночные прерывания с перепланировкой заданий
- Одновременное возникновение двух прерываний
- Вложенные прерывания
- Максимальная поддерживаемая частота прерываний, не приводящая к их потерям
Все показатели были сняты на уровне ISR. QNX NEUTRINO RTOS v6.2 также предоставляет возможность непосредственной обработки прерываний на уровне потоков (без явной обработки ISR), но здесь данный метод не использовался.
4.2.1 Одиночное прерывание – без перепланировки
Для этого теста была создана высокоприоритетная нить, устанавливающая обработчик прерываний, и затем начинающая постоянную запись отсчетов на шину PCI. Прерывания генерировались приблизительно каждые 50мкс и прерывали работу нити. Каждый раз при возникновении прерывания запускался их обработчик, писал отсчет на PCI шину и завершался. После завершения обработчика прерываний, прерванная нить возобновляла работу. Система не перепланировалась.
Данный тест измеряет время ожидания обработки прерывания при сильно загруженной системе, в то время как главная (высокоприоритетная) нить постоянно пишет отсчет на шину, занимая всю доступную мощность ЦП.
Измеряемыми показателями являлись время ожидания обработки прерывания и время обработки прерывания. Временем ожидания обработки прерывания является время, которое требуется для переключения от прерванного задания к ISR, временем обработки прерывания является время, которое требуется для возобновления выполнения задания.
Необходимо помнить, что на персональном компьютере прерывание таймера имеет по умолчанию самый высокий приоритет (выше, чем любое другое внешнее прерывание). В связи с этим обстоятельством, для получения результатов теста в худшем случае, время требующееся на обработку этого временного прерывания должно быть добавлено к времени ожидания обработки прерывания.
Для обсуждения времени обработки прерывания таймера (его ISR), читатель может обратиться к пункту 4.10.
4.2.1.1 Время ожидания обработки прерывания
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-1 IL-a-1.d
Рис. 4.2-2 IL-a-1.d - распределение частоты
4.2.1.2 Время обработки прерывания
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-3 IDL-a-1.d
Рис. 4.2-4 IDL-a-1.d - распределение частоты
4.2.2 Одиночное прерывание – с перепланировкой
Идея данного теста состоит в том, что выполнение ISR реализует нить с более высоким приоритетом, чем приоритет прерванной ISR нити. Т.о., система нуждается в перепланировке.
Время обработки прерывания, оцененное в разделе 4.2.2.1, является временем, которое требуется системе для переключения между ISR и сигнализированной ISR нитью.
4.2.2.1 Время обработки прерывания
- Число нитей: 2
- Модель памяти: d
|
Рис. 4.2-5 IDL-b-1.d
Рис. 4.2-6 IDL-b-1.d - распределение частоты
4.2.3 Два одновременных прерывания
В данном тесте генерировались два (почти) одновременных прерывания. Это было реализовано путем добавления в систему второй программы тестирования PCI (PDrive).
- PDrive_HI (генерирует высокоприоритетные прерывание) реализует PCI-прерывание по линии C (INTC#) и генерирует прерывания с уровнем IRQ 9.
- PDrive_LO (генерирует низкоприоритетные прерывания) реализует PCI-прерывание по линии B (INTB#) и генерирует прерывания с уровнем IRQ 10.
Две обрабатывающие прерывания процедуры (ISR_HI and ISR_LO) сопоставлены уровням IRQ 9 и 10 соответственно.
Время ожидания обработки прерываний оценивалось и для ISR_HI, и для ISR_LO. Время ожидания обработки прерывания измерялось как время между выполнением последней команды прерываемой нити и первой команды ISR. Разница во времени возникновения прерываний не превышала 100нс, что по определению классифицируется как одновременное возникновение прерываний.
Проблем
связанных с этими прерываниями в системе не возникало. Высокоприоритетное
прерывание обслуживалось системой в первую очередь, максимальное время ожидания
обработки составляло 3мкс. Низкоприоритетное прерывание обслуживалось сразу
после полной обработки прерывания с более высоким приоритетом, но за менее чем 6
мкс после возникновения обоих прерываний. 4.2.3.1 Время ожидания обработки прерывания – ISR_HI
- Число нитей: 2
- Модель памяти: d
|
Рис. 4.2-7 : Время ожидания обработки прерывания для высокоприоритетной ISR
Рис. 4.2-8: Время ожидания обработки прерывания для высокоприоритетной ISR – Распределение частоты
4.2.3.2 Время ожидания обработки прерывания – ISR_LO
- Число нитей: 2
- Модель памяти: d
|
Рис. 4.2-9: Время ожидания обработки прерывания для низкоприоритетной ISR
Рис. 4.2-10: Время ожидания обработки прерывания для низкоприоритетной ISR – Распределение частоты
4.2.4 Обработка вложенных прерываний
В разделе 4.2.3 рассматривались два (почти) одновременных прерывания. Оба прерывания генерировались в узком окне времени, раньше, чем система имела возможность отреагировать на возникновение первого из них. В данном разделе будет повторен тот же тест, но с небольшой задержкой между возникновением прерываний.
Цель заключается в генерации высокоприоритетного прерывания во время обработки прерывания с более низким приоритетом соответствующим ему ISR.
Хорошая RTOS должна обрабатывать вложенные прерывания без каких либо проблем.
В рассматриваемом тесте задержка между прерываниями с низким и высоким приоритетами будет варьироваться от 1.5 до 3 мкс.
4.2.4.1 Обработка вложенных прерываний – интервал 1.5 мкс
В начале PDrive_LO генерирует низкоприоритетное прерывание (INTB#, IRQ 10), затем через 1.5 мкс PDrive_HI (INTC#, IRQ 9) генерирует высокоприоритетное прерывание. Результаты разделов 4.2.4.1.1 и 4.2.4.1.2 показывают, что все высокоприоритетные прерывания обслуживаются раньше их низкоприоритетных аналогов. Однако, скриншот анализатора шины, показанный на рис. 4.2-11, демонстрирует, что IRQ_LO возникает раньше IRQ_HI (INTB# сигнал становится неактивным раньше INTC#).
Этот факт является
хорошим свидетельством того, что прерывания могут быть вложенными, но все же не
представляет неопровержимого доказательства. Например, возможна ситуация, когда
IRQ_HI возникшее раньше IRQ_LO, было обработано ISR_LO. Однако, в результате
инспектирования отсчетов анализатора, мы можем подтвердить возможность обработки
вложенных прерываний. 
Рис. 4.2-11: скриншот анализатора PCI шины
4.2.4.1.1 Время ожидания обработки прерывания – ISR_HI
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-12: Время ожидания обработки прерывания для высокоприоритетной ISR
Рис. 4.2-13: Время ожидания обработки прерывания для высокоприоритетной ISR – Распределение частоты
4.2.4.1.2 Время ожидания обработки прерывания – ISR_LO
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-14: Время ожидания обработки прерывания для низкоприоритетной ISR
Рис. 4.2-15: Время ожидания обработки прерывания для низкоприоритетной ISR – Распределение частоты
4.2.4.2 Обработка вложенных прерываний – интервал 2.25мкс
Тест совпадает с рассмотренным в предыдущем разделе, но интервал времени между прерываниями теперь составляет 2.25мкс. Результаты показывают, что в большинстве случаев ISR_LO выполняется раньше ISR_HI.
4.2.4.2.1 Время ожидания обработки прерывания – ISR_HI
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-16: Время ожидания обработки прерывания для высокоприоритетной ISR
Рис. 4.2-17: Время ожидания обработки прерывания для высокоприоритетной ISR – Распределение частоты
4.2.4.2.2 Время ожидания обработки прерывания – ISR_LO
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-18: Время ожидания обработки прерывания для низкоприоритетной ISR
Рис. 4.2-19: Время ожидания обработки прерывания для низкоприоритетной ISR – Распределение частоты
4.2.4.3 Обработка вложенных прерываний – интервал 3 мкс
Теперь, когда интервал между прерываниями с разными приоритетами увеличивается до 3 мкс, ISR_LO всегда начинает работу раньше ISR_HI, так как максимальное время ожидания для ISR_LO меньше минимального времени ожидания ISR_HI.
4.2.4.3.1 Время ожидания обработки прерывания – ISR_HI
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-20: Время ожидания обработки прерывания для высокоприоритетной ISR
Рис. 4.2-21: Время ожидания обработки прерывания для высокоприоритетной ISR – Распределение частоты
4.2.4.3.2 Время ожидания обработки прерывания – ISR_LO
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.2-22: Время ожидания обработки прерывания для низкоприоритетной ISR
Рис. 4.2-23: Время ожидания обработки прерывания для низкоприоритетной ISR – Распределение частоты
4.2.5 Максимально достижимая частота прерываний – ISR уровень
Целью тестов данного раздела является определение максимально достижимой (периодической) частоты возникновения прерываний без потерь. В разделе 4.2.5.1 определяется минимально достижимый интервал между прерываниями методом генерации 1000 периодических прерываний. Тест повторяется с увеличением частоты до тех пор, пока не произойдет потери одного или более прерываний. Таким образом, определяется максимально достижимая частота возникновения прерываний без потерь.
Чтобы проверить, могут ли результаты раздела 4.2.5.1 быть обобщены на более долгие периоды времени, в разделе 4.2.5.2 рассматривается более продолжительный тест, подвергающий систему миллиарду (109) периодических прерываний.
Результат считается положительным только в том случае, если не было потеряно ни одного прерывания.
Все прерывания обслуживаются на ISR-уровне. При этом ISR не выполняет никакой полезной работы, а только записывает отсчет в анализатор шины и завершается.
4.2.5.1 Короткие тесты
Таблица 4.2-1 показывает, что при генерации прерываний с периодичностью менее 5.5мкс, система неизбежно начинает "терять" их. Максимальная частота прерываний по сравнению с предшествующей версией QNX (6.1) не изменилась.
|
4.2.5.2 Испытания на долговечность
Таблица 4.2-2 демонстрирует результаты теста, в котором система подвергалась одному миллиарду (109) периодических прерываний, возникающих с определенной частотой.
Из-за характера тестовой системы определить точное количество потерянных прерываний, если это число превышало 32768, не представлялось возможным.
Максимальная частота возникновения прерываний по сравнению с предшествующей версией системы QNX (6.1) не изменилась.
|
Результаты теста были
положительными при периодичности возникновения прерываний установленной на 9мкс,
т.е. каждое прерывание было обработано. Когда периодичность возникновения прерываний была уменьшена до 8мкс, 12 прерываний обслужены не были.
Но необходимо помнить, что данный тест можно считать стресс–тестом не только самой RTOS, но и аппаратного оборудования PC. Таким образом, никаких определенных суждений о том, какая именно часть системы виновна в потере прерываний, вынести нельзя. Но так как во всех тестах используется одно и то же оборудование, результаты тестирования различных RTOS могут быть сравнены между собой.
4.3 Нити (потоки)
Тест данного раздела обрабатывает создание и удалений нитей. Тест заключается в непрерывном создании и удалении нитей. Создаваемые новые нити соединяется с удаляемыми.
В QNX удаление нити реализуется самой удаляемой нитью, и таким образом уровень приоритета удаления нити совпадает с уровнем приоритета самой нити.
В большинстве RTOS удаление нити - это нить, освобождающая ресурсы. Способ реализации в QNX более предсказуем, поскольку высокоприоритетная нить, удаляющая нить с более низким приоритетом не должна делать всю обработку (что является фактически своего рода инверсией приоритета!).
Т.о., тест немного адаптирован для получения сопоставимых результатов: удаляющая нить ждет удаляемую (используя соединение) для того, чтобы убедиться, что все ресурсы освобождены. Без данного ожидания система израсходует всю доступную память: удаленные нити никогда не станут активными и ресурсы фактически не будут освобождены. Известно, что в этом случае запрос создания нити возвращает ошибку, но сама система остается работоспособной.
4.3.1 Создание
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.3-1 TF-a-1.a
Рис. 4.3-2 TF-a-1.a - распределение частоты
4.3.2 Удаление
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.3-3 TF-b-1.a
Рис. 4.3-4 TF-b-1.a - распределение частоты
4.4 Переключение между нитями одного процесса
Для данного теста создается некоторое количество нитей с одинаковым уровнем приоритетов. Как только нить становится активной, она автоматически дает сигнал процессору о запуске следующей нити. Тест повторяется для 2, 10 и 128 нитей. Время ожидания переключения между нитями это время, которое требуется системе для того, чтобы переключиться с одной нити на другую. Все нити принадлежат одному процессу.
4.4.1 Время переключения между нитями (TSL-a-2.d)
- Число нитей: 2
- Модель памяти: d
|
Рис. 4.4-1 TSL-a-2.d
#
Рис. 4.4-2 TSL-a-2.d - распределение частоты
4.4.2 Время переключения между нитями (TSL-a-10.d)
- Число нитей: 10
- Модель памяти: d
|
Рис. 4.4-3 TSL-a-10.d
Рис. 4.4-4 TSL-a-10.d - распределение частоты
4.4.3 Время переключения между нитями (TSL-a-128.d)
- Число нитей: 128
- Модель памяти: d
|
Рис. 4.4-5 TSL-a-128.d
Рис. 4.4-6 TSL-a-128.d - распределение частоты
4.5 Переключение между нитями разных процессов
Данный тест практически повторяет тест времени переключения между нитями, рассмотренный в разделе 4.4, за исключением того, что каждая нить в данной системе будет принадлежать разным процессам. Т.о., данный тест будет оценивать время переключения между процессами. Тест проводится для 2, 10 и 128 процессов. Время переключения между процессами дольше времени переключения между нитями, так как каждый процесс имеет свое собственное пространство виртуальной памяти. Однако, в самом худшем случае время переключения между процессами не превысило 22 мкс. Результаты худшего случая получаются при первой активации процесса, это легко можно заметить при проведении теста с 128 процессами.
4.5.1 Время переключения между нитями (TSL-b-2.d)
- Число нитей: 2
- Модель памяти: d
|
Рис. 4.5-1 TSL-b-2.d
Рис. 4.5-2 TSL-b-2.d - распределение частоты
4.5.2 Время переключения между нитями (TSL-b-10.d)
- Число нитей: 10
- Модель памяти: d
|
Рис. 4.5-3 TSL-b-10.d
Рис. 4.5-4 TSL-b-10.d - распределение частоты
4.5.3 Время переключения между нитями (TSL-b-128.d)
- Число нитей: 128
- Модель памяти: d
|
Рис. 4.5-5 TSL-b-128.d
Рис. 4.5-6 TSL-b-128.d - распределение частоты
4.6 Семафоры
Тесты в разделах 4.6.1, 4.6.2 и 4.6.3 обрабатывают создание и удаление семафоров. Пиковые значения результатов тестов связаны с прерываниями таймера, происходившими каждую миллисекунду во время измерений. Также рассматривается тот факт, что время удаления семафора не зависит от того, был он использован или нет. Т.е. предполагается, что при поступлении запроса на создание семафора все необходимые ресурсы уже выделены.
Тест синхронизации, результаты которого представлены в разделе 4.6.6, создает ситуацию, в которой несколько разноприоритетных нитей ожидают сигнала одного и того же семафора. В QNX NEUTRINO RTOS v6.2 существует 64 уровня приоритетов. Поскольку самый низкий уровень зарезервирован на задание «простоя» и не может быть использован приложениями, тест проводился с использованием 63 нитей.
Идея теста заключается в
том, чтобы проверить, зависит ли сумма времени освобождения и времени
переупорядочивания от числа ожидающих сигнала семафора нитей. Как показывают
результаты теста, представленные на рисунке 4.6-12, для QNX NEUTRINO RTOS v6.2
такой зависимости нет. Измеряемые значения остаются постоянными для цикла тестов
с числом ожидающих семафора нитей, варьирующимся от 1 до 63. В QNX NEUTRINO RTOS v6.2 сумма времени освобождения и времени переупорядочивания является независимой от числа ожидающих одного и того же семафора нитей. Возможно, это означает, что система пересортировывает очередь ожидающих семафора нитей при каждом добавлении в нее новой нити. Результаты тестирования синхронизации были обработаны повторно для получения времени, которое требуется системе для того, чтобы захватить не сигнализирующий семафор и произвести переупорядочивание заданий, для запуска следующей нити (см. раздел 4.6.7). Всякий раз, когда нить пытается захватить не сигнализирующий семафор, она добавляется в очередь семафора. Цель этого испытания состоит в том, чтобы проверить, что время добавления новой нити в очередь семафора (и сортировки очереди!!) независимо от числа нитей в очереди.
Результаты представленные
на рис. 4.6-14 (стр. 68) показывают, что никакой зависимости между временем
сортировки очереди и числом нитей в ней нет. 4.6.1 Создание (SEO-a-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.6-1 SEO-a-1.d
Рис. 4.6-2 SEO-a-1.d - распределение частоты
4.6.2 Удаление (SEO-b-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.6-3 SEO-b-1.d
Рис. 4.6-4 SEO-b-1.d - распределение частоты
4.6.3 Удаление после использования (SEO-c-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.6-5 SEO-c-1.d
Рис. 4.6-6 SEO-c-1.d - распределение частоты
4.6.4 Отсутствие разногласий – Захват (SEO-d-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.6-7 SEO-d-1.d
Рис. 4.6-8 SEO-d-1.d - распределение частоты
4.6.5 Отсутствие разногласий – Освобождение (SEO-e-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.6-9 SEO-e-1.d
Рис. 4.6-10 SEO-e-1.d - распределение частоты
4.6.6 Синхронизация (SEO-f-63.d)
- Число нитей: 63
- Модель памяти: d
|
Рис. 4.6-11 SEO-f-63.d
Рис. 4.6-12 SEO-f-63.d – Покомпонентное изображение
4.6.7 Захват несигнализирующим семафором
- Число нитей: 247
- Модель памяти: d
|
Рис. 4.6-13 Захват несигнализирующим семафором
Рис. 4.6-14 Захват несигнализирующим семафором – покомпонентное изображение
4.7 Мьютексы
Данный тест несвязанных между собой захватов и освобождений мьютекса, результаты которого представлены в разделах 4.7.1 и 4.7.2, реализован в виде непрекращающегося цикла захватов и мгновенно следующих за ними освобождений мьютекса.
В QNX NEUTRINO RTOS v6.2 реализован весьма критичный для RTOS механизм наследования приоритетов. Он протестирован путем создания 3 нитей, для которых сразу же возникла проблема инверсии приоритетов: нить с высоким уровнем приоритета претендовала на захват мьютекса, которым уже владела нить с более низким приоритетом, в свою очередь, нить со средним уровнем приоритета не давала запуститься нити с низким приоритетом и освободить мьютекс. Т.о., высокоприоритетная нить не могла захватить мьютекс.
В данном тесте оценено время, которое требуется высокоприоритетной нити для захвата мьютекса. В это время включалось время повышения приоритета низкоприоритетной нити, освобождение ею мьютекса и переключение на высокоприоритетную нить для предоставления ей возможности захватить мьютекс.
Рис. 4.7-5 (стр. 72)
показывает, что механизм наследования приоритетов является стабильным:
максимальное время для совершения этой серии операции не превышало 14мкс. И
по-прежнему прерывания от таймера являлись причиной случайных выбросов. Данный тест показывает значительные улучшения в системе, по сравнению с предшествующей версией. Очевидно, что проблема инверсии приоритетов является худшим случаем развития событий в системе реального времени. Сценарий развития событий в подобной ситуации был улучшен более чем на 30% по сравнению с предыдущей версией.
|
4.7.1 Отсутствие разногласий – Захват (SEO-d-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.7-1 SEO-d-1.d
Рис. 4.7-2 SEO-d-1.d - распределение частоты
4.7.2 Отсутствие разногласий – Освобождение (SEO-e-1.d)
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.7-3 SEO-e-1.d
Рис. 4.7-4 SEO-e-1.d - распределение частоты
4.7.3 Инверсия приоритетов (SEO-g-3.d)
- Число нитей: 3
- Модель памяти: d
|
Рис. 4.7-5 SEO-g-3.d
Рис. 4.7-6 SEO-g-3.d - распределение частоты
4.8 Файловая система – права доступа
Тесты данного раздела оценивают производительность файловой системы QNX.
Сначала мы оценили время создания и удаления файлов. Средним временем создания файла было 5 мс, максимальное время создания составило около 15 мс. Данное максимальное значение было получено при проведении первой последовательности тестов.
Было проведено по три теста на чтение и запись в файл. Различие в проводимых тестах заключалось в размере обрабатываемых данных - 1 байт (1), 1 блок размером в 512 байтов (1b) и 10 блоков размером в 5120 байтов (10b). Была использована синхронную операцию чтения/записи таким образом, чтобы получать общее значение времени записи и чтения данных. И чтение, и запись считаются завершенными, только в том случае, если данные были перемещены на устройство хранения и вся информация файловой системы по операции ввода/вывода была обновлена.
Файловый системы реального времени обычно очень просты. Файлы должны быть непрерывными, для того чтобы не возникала ситуация непредвиденных перемещений головки диска на другие секторы или цилиндры, что в противном случае добавило бы непредсказуемости к системе.
QNX Neutrino RTOS v6.2 поддерживает несколько видов файловых систем, от простой до сложной. Собственная файловая система (Fsys) включает в себя поддержку директорий, символьных ссылок и даже индивидуальные права доступа к файлам для индивидуальных пользователей или групп пользователей. Более того, файлы не обязательно должны быть непрерывными. Большие файлы могут располагаться в нескольких областях. Под областью здесь понимается непрерывное множество блоков на диске. Однако, области, в которых располагается файл, не обязательно будут непрерывными.
Факт, подтверждающий прерывистость файлов доказывается в разделе 4.8.4, в котором обрабатывается чтение 1 блока (512 байтов). Средняя операция чтения занимает около 150 мкс, но периодически повторяющаяся операция чтения занимает от четырех до пяти раз больше.
Те же рассуждения могут быть проведены для операции записи. При использовании данной файловой системы при разработке приложений реального времени, необходимо учитывать данную фрагментацию и убедиться в том, что время перехода к новой области ограничено.
Также QNX NEUTRINO RTOS v6.2 поддерживает неструктурированную файловую систему, представляющую собой случайно доступную последовательность байтов, не имеющую никакой определенной структуры. Это предоставляет возможность более предсказуемого получения данных, но за распознавание этой структуры становятся ответственными сами приложения.
4.8.1 Создание
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.8-1 FS-a-1.d
Рис. 4.8-2 FS-a-1.d - распределение частоты
4.8.2 Удаление
- Число нитей: 1
- Модель памяти: d
|
Рис. 4.8-3 FS-b-1.d
Рис. 4.8-4 FS-b-1.d - распределение частоты
4.8.3 Чтение – 1 байт
- Число нитей: 1
- Модель памяти: d
- Число байтов: 1 байт
|
Рис. 4.8-5 FS-c-1.d.1
Рис. 4.8-6 FS-c-1.d.1 - распределение частоты
4.8.4 Чтение – 512 байтов
- Число нитей: 1
- Модель памяти: d
- Число байтов: 1 блок (512 байтов)
|
Рис. 4.8-7 FS-c-1.d.1b
Рис. 4.8-8 FS-c-1.d.1b – распределение частоты
4.8.5 Чтение – 5120 байтов
- Число нитей: 1
- Модель памяти: d
- Число байтов: 10 блоков (5120 байтов)
|
Рис. 4.8-9 FS-c-1.d.10b
Рис. 4.8-10 FS-c-1.d.10b - распределение частоты
4.8.6 Запись – 1 байт
- Число нитей: 1
- Модель памяти: d
- Число байтов: 1 байт
|
Рис. 4.8-11 FS-d-1.d.1
Рис. 4.8-12 FS-d-1.d.1 - распределение частоты
4.8.7 Запись – 512 байтов
- Число нитей: 1
- Модель памяти: d
- Число байтов: 1 блок (512 байтов)
|
Рис. 4.8-13 FS-d-1.d.1b
Рис. 4.8-14 FS-d-1.d.1b – Распределение частоты
4.8.8 Запись – 5120 байтов
- Число нитей: 1
- Модель памяти: d
- Число байтов: 10 блоков (5120 байтов)
|
Рис. 4.8-15 FS-d-1.d.10b
Рис. 4.8-16 FS-d-1.d.10b – распределение частоты
4.9 Сетевой стек – TCP/IP
В данном разделе рассматривается производительность и эффективность сетевого стека TCP/IP. QNX NEUTRINO RTOS v6.2 предоставляет две различных реализации стеков TCP/IP.
- Полный стек TCP/IP: полная реализация стека TCP/IP.
- Компактный стек TCP/IP: сильно сокращенная реализация TCP/IP стека для систем с ограниченными ресурсами.
Цель данного теста заключается в том, чтобы оценить частотный диапазон и использование процессора для различных размеров пакетов. Размер пакета варьируется от 1 до 2000 байтов, приращение на каждом шаге составляет 40 байтов. Для получения дополнительной информации по реализации данного теста читатель может обратиться к документу "Report definition and test plan", который находится на сайте (http://www.dedicated-systems.com/encyc/buyersguide/rtos/rtosmenu.htm).
Тесты были проведены на изолированной 10 Mbit/s изернет-сети. Отправитель блокирует Нагл алгоритм. Этот алгоритм может связывать несколько небольших отправок данных в одну большую, которая и посылается в одном TCP/IP пакете. Этот механизм значительно упрощает указанный выше протокол взаимодействия, но часто неприменим в системах реального времени из-за возникающих задержек.
4.9.1 Полный TCP/IP стек – способность приема
Рис. 4.9-1 показывает, что при увеличении размера пакета приемная способность полного TCP/IP стека достигает 1000 кБ/с. Стек использует почти 100% доступных мощностей процессора, независимо от размера пакета.
Рис. 4.9-1: Полный TCP/IP стек – способность приема
4.9.2 Компактный стек TCP/IP – способность приема
Компактный TCP/IP стек предоставляет немного меньшую производительность по сравнению с его полным аналогом, но использует меньшие мощности процессора.
Рис. 4.9-2: Компактный TCP/IP стек – способность приема
4.9.3 Полный TCP/IP стек – способность отправки
Те же замечания, что и к тесту раздела 4.9.1 (Полный TCP/IP стек - приемная способность).
Рис. 4.9-3: Полный TCP/IP стек – способность отправки
4.9.4 Компактный TCP/IP стек – способность отправки
Те же замечания, что и в разделе 4.9.2 (Компактный TCP/IP стек - приемная способность). Способность отправки компактного стека значительно меньше, чем у его полного аналога. В общем, производительность компактного TCP/IP стека очень сильно зависит от размера пакета, что видно из рис. 4.9-4.
Рис. 4.9-4: Компактный TCP/IP стек – способность отправки
4.10 Порядок обслуживания прерывания по часам
В данном разделе обсуждается ISR часов. QNX NEUTRINO RTOS v6.2 доступна для различных аппаратных платформ, которые, в свою очередь, могут по разному влиять на поведение RTOS в режиме реального времени. В рассматриваемом разделе мы будем определять различия между двумя видами архитектуры целевого аппаратного оборудования:
- Целевая машина, у которой прерывание часов обладает самым высоким уровнем приоритета.
- Целевая машина, у которой прерывание часов имеет не самый высокий уровень приоритета.
Целевые машины с архитектурами аппаратного оборудования второй категории не обязательно присваивают прерыванию часов самый высокий уровень приоритета. Таким образом, система отреагирует на другие внешние прерывания (с уровнем приоритета выше, чем у прерывания часов) как можно быстрее, поскольку их обработка не будет задержана часами. Можно предположить, что выбор подобных архитектур наиболее соответствует системам реального времени, но есть один недостаток: низкий приоритет прерывания часов может вызвать неустойчивость в синхронизации часов. Для некоторых видов приложений, в которых важна точная частота тиков часов, это может быть неприемлемым.
В разделе были выполнены два теста на изучение времени выполнения ISR часов. Главная нить каждого теста остается неизменной: повторяющееся выполнение вычисления, занимающее около 224 мкс. Затем часы прерывают главную высокоприоритетную нить, и оценивается увеличение времени вычислений. Разница между нормальным (минимальным) временем вычисления и временем вычисления в худшем случае и есть худший случай времени обработки прерывания часов (никаких других прерываний в системе не возникает).
Первый тест, результаты которого представлены в разделе 4.10.1, включает только главную нить. И, как видно из рис. 4.10-1, непрерываемые вычисления занимают 224 мкс. Время вычислений во второй серии опытов колеблется около 228 мкс, что было вызвано возникновением прерывания часов. Можно сделать следующий вывод: стандартное время выполнения ISR часов составляет приблизительно 4 мкс (на Pentium 200 MHz).
Данный тест был повторен
с добавлением дополнительных нитей, выполняющих оператор "sleep", который
заканчивал свое действие в середине вычислений главной нити (это похоже на
установку таймера). Результаты данного тестирования не приводятся, так как
добавление дополнительных нитей никак не повлияло на время выполнения ISR часов.
Двумя главными операциями, выполняемыми ISR часов, являются обновление регистра счетчика часов и управление временем истечения таймера. С каждым тиком часов регистр счетчика должен обновляться и это минимальная работа, которую ISR часов должна выполнять снова и снова. Это случай, когда выполнение ISR часов занимает 4мкс.
С другой стороны, при выполнении ISR часов обновляется регистр счетчика и возможно истекает срок по таймеру, что может привести к выполнению дополнительной работы. В некоторых системах это приводит к значительному увеличению времени выполнения ISR часов. Как было отмечено ранее, эта проблема возникает для целевых машин, у которых прерывание по часам имеет самый высокий приоритет, так как это замедляет реакцию системы на другие прерывания.
4.10.1 Clock ISR – без загрузки системы и без таймеров
- Число нитей: 1
- Модель памяти: a
|
Рис. 4.10-1 ISR часов(без загрузки, без таймера)
Рис. 4.10-2 ISR часов (без загрузки, без таймеров) – Покомпонентное изображение
4.11 Максимальное количество объектов
В данном разделе мы определяем, наносит ли ущерб производительности системы создание большого количества объектов (семафоров и нитей). Это реализовано путем проведения теста на время ожидания переключения между нитями с использованием 128 нитей (см. раздел 4.4) при загрузке системы большим количеством дополнительных объектов.
Для определения того, существует ли зависимость производительности системы от количества созданных объектов, результаты данного теста сравниваются с результатами того же теста, но при незагруженной объектами системе.
Максимальным числом объектов при проведении теста считается наибольшее число объектов, которое может быть создано без возникновения ошибки "недостаточный объем памяти". В идеале, результаты этого теста должны совпадать с результатами тестирования незагруженной системы.
4.11.1 Семафоры
Цель данного теста заключается в том, чтобы определить, влияет ли создание большого количества семафоров на производительность системы. Для этого проводится тест на время ожидания переключения между нитями (128 нитей) при загрузке системы семафорами.
Число семафоров, которое может быть создано в QNX NEUTRINO RTOS v6.2 без превышения размеров памяти, очень велико. Поэтому тест проводился с использованием 100,000 семафоров. Никакой полезной работы при проведении теста эти семафоры не выполняют, они просто загружены в систему.
Рисунок результатов теста представлен совместно с тестированием нитей в следующем разделе данного документа.
4.11.2 Нити
Цель данного теста заключается в том, чтобы проверить влияет ли создание большого количества нитей на производительность системы. Для этого был проведен тест времени ожидания переключения между нитями (128 нитей) при загрузке системы 10,000 дополнительных нитей.
Эти дополнительные нити не выполняли никаких действий во время проведения теста, а только были загружены в систему.
Рис. 4.11-1 Сравнительная характеристика времени переключения между нитями
Как видно из рисунка
4.11-1, минимальное, среднее и максимальное значения времени ожидания изменяются
при загруженной объектами системе, но максимальное значение остается приемлемым
- около 11мкс. Т.е. при загрузке системной памяти нитями не происходит
значительной потери производительности. 4.12 Утечки памяти (Memory leaks)
Данный раздел определяет, приводят ли различные системные операции к утечкам памяти.
4.12.1 Создание/удаление семафоров и мьютексов
Цель данного раздела заключается в том, чтобы определить приводят ли системные операции создания и удаления семафоров и мьютексов к случаям утечки памяти. Тест реализован следующим образом (псевдокод):
LOOP 1000 times