CC BY
5
Дашевский В. П. Dashevsky V. Р.
кандидат технических наук, старший научный сотрудник, руководитель отдела прототипирования робототехнических и встраиваемых систем,
Санкт-Петербургский институт информатики и автоматизации Российской академии наук, г. Санкт-Петербург, Российская Федерация
Будков В. Ю. Budkov V. Уи.
кандидат технических наук, старший научный сотрудник, руководитель лаборатории технологий больших данных киберфизических систем, Санкт-Петербургский институт информатики и автоматизации Российской академии наук, г. Санкт-Петербург, Российская Федерация
УДК 004.031.43 DOI: 10.17122/1999-5458-2019-15-3-92-100
СПЕКТРОСКОПИЯ ЗАДЕРЖЕК В СИСТЕМАХ РЕАЛЬНОГО ВРЕМЕНИ
В сложных системах реального времени (СРВ), в которых происходит взаимосвязанная обработка сигналов от внешних источников данных, применяются специализированные операционные системы реального времени (ОСРВ), которые гарантируют синхронное выполнение этой обработки с процессами в реальном мире. Одной из важнейших характеристик СРВ является время реакции на внешние события, зависящие от характеристик как аппаратной, так и программной части, поэтому задача определения реальных задержек переносится на конечных разработчиков СРВ. Эта задача зачастую требует внесения модификаций в программный код ОСРВ, доступа к управлению внешними выводами процессора, что не всегда возможно. Данная работа рассматривает возможность применения статистического подхода для решения задачи по измерению различных задержек в СРВ. В статье описаны задержки, связанные с выполнением базовых системных примитивов, возникающие в операционных системах реального времени, способы их измерения и модели их образования на примере ОСРВ с вытесняющей многозадачностью и раздельными стеками процессов. Рассмотрены модель образования задержек реакции на прерывание, модель формирования задержки при планировании и переключении контекста процессов для случаев пробуждения процесса с более высоким и низкими приоритетами. Описан способ измерения квантов времени, выделяемых на выполнение задач с одинаковым приоритетом. Предложен метод измерения задержек, основанный на сравнительном анализе спектров задержек, получаемых в разных режимах работы СРВ. Основное его преимущество заключается в том, что метод доступен для прикладного программного обеспечения с обычным уровнем привилегий, не требует модификации системных программ или ядра операционной системы. Единственным условием для его успешного применения является наличие в процессоре счетчика тактов или любого иного системного счетчика с высокой частотой изменений, обеспечивающего достаточную разрешающую способность по времени.
Ключевые слова: система реального времени, операционная система реального времени, спектроскопия, время задержки, вытесняющая многозадачность, обработка прерываний, спектр задержек, таймер задержек, метод измерения задержек, модель системных задержек.
DELAY SPECTROSCOPY IN REAL-TIME SYSTEMS
In complex real-time systems (RTS), where occurs interdependent processing of incoming signals from external data sources, specialized real-time operating systems (RTOS) are employed, which ensure synchronization of such processing with real-world events. One of the most important characteristics of RTS is the response time to external events, depending as on hardware, as on software implementations. Therefore, the problem of determination of actual delay times should be solved by the RTS developers. This task often requires modifications of RTOS source code, access to processor output and control of its output, what is not always feasible. This paper considers possible application of a statistical approach to this problem, including measurement of various delays in RTS. This paper describes delays, related to execution of basic system primitives, arising in real-time operating systems, ways of their measurement and how they can be established in terms of ROTS with preemptive multitasking and isolated process stacks. An interrupt response delay model was elaborated, as well model of delay establishment during process context planning and switching for waking of higher-priority and lower-priority processes. A time slice measurement approach is proposed, where time slices are allocated for execution of equal-priority tasks. A delay measurement method is proposed, based on comparative analysis of delay spectra, arising in such modes of RTS operation. The main advantage of this method is that it is applicable with general-purpose software with usual priority level, and it requires no modifications of system programs or operating system kernel. The only prerequisite for successful implementation of it is a provision of a CPU cycle counter or any other counter with high frequency of modification registration, enabling enough precise timing resolution.
Key words: real-time system, real-time operating system, spectroscopy, delay time, preemptive multitasking, interrupt handling, delay spectrum, delay timer, delay measurement method, system delay model.
Введение
Системы реального времени (СРВ), основанные на микропроцессорах, являются наиболее распространенным видом подобных систем. В сложных системах, где имеется необходимость выполнения в реальном времени сразу нескольких взаимосвязанных процессов, применяются специализированные операционные системы реального времени (ОСРВ) [1-4]. Такие операционные системы, помимо прочих функций, присущих всем операционным системам, позволяют гарантировать выполнение процессов синхронно с внешними процессами в реальном времени.
Для более ясного изложения в данной работе будет использоваться модель операционной системы с вытесняющей многозадачностью и раздельными стеками процессов. Тем не менее, сама методика исследований может быть обобщена и на другие случаи.
Важнейшими характеристиками ОСРВ являются задержки, связанные с выполнением базовых системных примитивов:
— время реакции на прерывание;
— время переключения потока;
— время переключения контекста процесса;
— время планирования группы процессов;
— время захвата и освобождения ресурса;
— время выполнения системного вызова.
На практике разработчики всегда сталкиваются с трудностями при определении значений задержек [5-7]. Это связано с тем, что времена зависят как от аппаратной части системы, так и от программной части — реализации ОСРВ. Производители микропроцессоров сообщают времена, относящиеся к аппаратуре, например, период тактовой частоты процессора, количество тактов на выполнение каждой команды, количество тактов на регистрацию сигнала прерывания и вызов обработчика и т.п. Поскольку они ничего не знают про особенности реализации ОСРВ, то они не могут сообщить всех временных характеристик, интересных конечному разработчику прикладного программного обеспечения. Разработчики ОСРВ также не могут указать реальные задержки, поскольку они зависят от характеристик аппаратной платформы, таких как тактовая
частота ядер процессора, кэш-память, внешняя память, объём памяти, настройки контроллеров внешних шин и интерфейсов и т.д. Таким образом, задача определения реальных задержек падает на конечного разработчика всей СРВ, который определился с выбором как аппаратной части, так и всех программных компонентов ОСРВ.
Сбор такого большого количества данных о системе всегда затруднителен для конечного разработчика. Обычно пользователю доступны измерения производительности системы на уровне прикладных процессов (benchmarks) [8, 9].
Такие тесты измеряют производительность различных операций. Обычно подразумевается, что измеряемые характеристики подвержены минимальному влиянию случайных факторов и отражают усредненные значения производительности, которые будут воспроизводиться в условиях работы целевых программ. Измерение внутренних задержек аппаратуры и базовых примитивов ОСРВ недоступно для прямого измерения на уровне прикладных программ. Прямое измерение системных задержек требует внедрения в код операционной системы механизмов фиксации и вывода информации о прохождении определенных контрольных точек.
В простейшем случае это может быть управление внешними выводами процессора (например, GPIO [6, 10, 11]). Такой подход возможен, если пользователю доступно внесение изменений в системные функции ядра ОСРВ и настройка выводов процессора, связанных с измерениями. Преимущество подхода — в простоте и небольшом расходе производительности и памяти на организацию измерений. Недостаток в том, что для коммерческих ОСРВ внесение изменений невозможно.
Альтернативный подход заключается в наличии в системе таймера высокого разрешения, в идеале работающего на тактовой частоте процессора, показания которого заносятся в журнал контрольных точек системных функций ядра и драйверов операционной системы (ОС). Анализируя журнал работы ядра ОСРВ, можно вычислить задержки на выполнение ключевых опера-
ций [6, 7, 12]. Достоинство метода в том, что он не требует конфигурировать выводы процессора для выдачи контрольных сигналов. Недостатки в том, что для коммерческих ОСРВ внесение изменений невозможно, и требуется больше ресурсов процессора и памяти для записи журнала событий на низком уровне. Кроме того, такой параметр, как время реакции на прерывание не может быть получен таким методом, так как момент возникновения сигнала прерывания не фиксируется в журнале первичных событий.
Ниже приводится описание предлагаемого метода построения спектров задержек, который лишен данных недостатков и позволяет исследовать задержки СРВ с помощью небольшого приложения прикладного уровня, которое может работать в системе с самым низким приоритетом и не мешать остальным приложениям работать в реальном времени.
Модель образования задержек
Спектры задержек позволяют измерять характерные для внутренних процессов временные интервалы. Однако измеряемые величины могут в действительности являться суммой нескольких базовых задержек, поэтому непосредственные результаты измерений требуют обработки для получения базовых временных характеристик. Для правильной обработки результатов необходимо сформировать модель образования задержек и их влияние на измеряемые времена.
Модель задержек в общем случае зависит от реализации ядра конкретной ОСРВ и выходит за рамки данной работы. Для упрощения изложения в рамках данной статьи остановимся на одном из наиболее популярных случаев ОСРВ с вытесняющей многозадачностью, системой фиксированных приоритетов задач на основе контроллера прерываний [13].
Задержка реакции на прерывание
Реакция на прерывание представляет собой один из наиболее сложных случаев для прямого измерения задержки, поскольку в момент возникновения исходного события система может быть занята, прерывания заблокированы, поэтому определение задержки возможно косвенным способом.
Обработка прерывания происходит следующим образом:
1. возникает внешний сигнал прерывания;
2. сигнал прерывания фиксируется контроллером прерываний;
3. контроллер прерывания формирует прерывание центрального процессора;
4. центральный процессор заканчивает работу в режиме запрещенных прерываний (опционально);
5. центральный процессор получает информацию от контроллера прерываний и переходит к обработчику прерываний, запрещая при этом прерывания;
6. обработчик прерываний ОСРВ производит первичную обработку прерываний, пробуждая процессы драйверов либо запуская прикладные обработчики прерываний в драйверах;
7. обработчик прерываний включает разрешение прерываний и выходит.
Традиционно задержка реакции на прерывание (interrupt latency) определяется как время между шагами 1 и 6 (рисунок 1). Измерение этого времени сложно, поскольку требует синхронизации с внешним сигналом прерывания, которая недоступна внутри ОСРВ. Однако стоит заметить, что шаг 4 в действительности может являться окончанием обработчика 7 предыдущего прерывания (выделено серым цветом на рисунке 1). По этой причине задержка реакции на прерывания фактически равна времени выполнения пустого обработчика прерывания, который не делает ничего, а сразу выходит. А этот интервал доступен к измерению по спектру задержек, так как это фактически минимальное время, на которое может быть прерван процесс построения спектра задержек.
G© ©©
Сигнал прерывания
Флаг прерывания в контроллере прерывания
Выдача прерывания в процессор (ЦПУ)
Обработчик прерывания
Задержка выполнения фонового процесса
Прерванный процесс построения спектра
ООО
измерение по спектру
ооооо
Выдача сигнала реакции на прерывание (GPIO)
Задержка реакции на прерывание
измерение осциллографом
Рисунок 1. Этапы вызова обработчика и задержка реакции на сигнал прерывания
В общем случае обработчики прерываний могут быть вложенными. Вероятность образования вложенных прерываний обычно ниже, чем одиночных, и поэтому это отразится на статистике измеряемых задержек.
В простейшем случае обработка прерывания заканчивается регистрацией данных в драйвере и остается в контексте процесса, строящего спектр задержек. Поэтому самые маленькие времена в спектре задержек естественно относить к выполнению обработчиков прерываний. В более сложных случаях следствием обработки прерываний будет
переключение контекста процесса, и задержка вырастет.
Задержка планирования и переключения контекста
В ОСРВ с вытесняющей многозадачностью обработка прерываний завершается одним из трех способов:
1. простой возврат в прерванный процесс;
2. пробуждение процесса, приоритет которого ниже, чем у текущего процесса;
3. пробуждение процесса, приоритет которого выше, чем у текущего процесса.
- 95
В первом случае время вытеснения измерительного процесса определяется временем работы обработчика прерывания, как показано на рисунке 1. Второй и третий случаи похожи тем, что изменяется множество активных процессов, в результате чего запускается планировщик, задача которого определить, какой из активных процессов в данный момент имеет наивысший приоритет. Если после работы планировщика выясняется, что текущий процесс и есть самый приоритетный (случай 2 на рисунке 2), то ко времени работы простого обработчика
прерывания добавляется время работы планировщика (точнее, его «холостой ветви»). Если же среди активных процессов появляется более приоритетный процесс (случай 3), то события развиваются более сложным образом. Во-первых, в системе появляются переключения контекстов процессов, во-вторых, появляется время работы процессов с более высоким приоритетом, в-третьих, появляется время работы планировщика при выбывании процесса (рисунок 2, случай 3). И все эти ветки могут найти свое отражение в измеряемой статистике.
Случай 2:
Код ядра ОСРВ Основной обработчик прерывания Планировщик t
i к 1 Г
Прерванный процесс^ построения спектра V. v v. ооооо^ t -►
Случай 3:
Код ядра ОСРВ
Прерванный процео построения спектра
\ ООО
Основной обработчик прерывания
Планировщик
Переключения контекста
Планировщик
I
ООО/
Процесс обработки системного таймера
это время может быть сведено к нулю
Рисунок 2. Схема возникновения задержек на планирование и переключение контекста
Для исследования задержек такого типа удобно сделать специализированный процесс, который будет пробуждаться по событию от обработчика прерывания таймера и сразу засыпать снова. В этом случае вытеснение фонового процесса будет происходить за время, равное двум временам переключения контекста, и время работы планировщика.
Квант выполнения процессов одного приоритета
В некоторых ОСРВ планировщик выполняет процессы с одинаковым приоритетом по алгоритму round robin, чтобы обеспечить квазипараллельность их выполнения. Квант времени выбирается обычно порядка 10 мс, чтобы обеспечить оптимальное соотношение между потерей времени на переключения контекстов и скоростью реакции при взаимодействии с человеком (как правило, ввод и вывод на консоль). Величина кванта времени может оказаться важной, если процессы
96 -
Electrical and
состоят не только из вычислений, но и занимаются последовательным вводом-выводом, поэтому представляет интерес измерение этих величин.
Для оценки кванта времени можно запустить два измерительных процесса на одном уровне приоритета, как показано на рисунке 3. В этом случае у них возникает биение с периодом, равным кванту времени. Квант времени обычно в сотни и тысячи раз больше времен работы планировщика и переключения контекста, поэтому ими можно пренебречь и считать максимальную задержку выполнения этих процессов квантом времени планировщика.
Метод измерения задержек Измерение задержек основано на сравнительном анализе спектров задержек, получаемых в разных режимах работы СРВ. Принцип измерения основан на том, что программа с самым низким приоритетом постоянно в цикле опрашивает показания счетчика тай-
Информационные комплексы и системы Метод измерения задержек
Процесс измерения экземпляр 1 ос>ос> ос>ос> оооо t Ьт
Процесс измерения экземпляр 2 i Г к i к
1 Т Квант времени
оооо оооо планировщика ^ _ь.
Рисунок 3. Переключение процессов на одном уровне приоритета
мера высокого разрешения и сравнивает их с порогом. Показания ниже порога считаются вариациями времени выполнения одной итерации цикла и не вносятся в статистику, а показания выше порога связаны с вытеснением программы различными системными операциями (обработкой прерываний, переключением контекста и т. п.) и используются для построения спектра задержек. Анализ спектра позволяет выделить характерные времена, связанные с внутренними процессами в ОС. Умышленно подвергая СРВ воздействию,
которое вызывает вытеснение измерительного процесса определенным видом активности (обработкой прерываний, переключением контекстов, планированием группы задач и т.п.), разработчики могут наблюдать накопление в статистике времён, связанных с этой активностью и тем самым идентифицировать задержки, создаваемые ей.
Алгоритм измерительного процесса
Кратко ядро алгоритма запишем на языке Си (рисунок 4).
typedef long long ta_t; // в соответствии с разрядностью таймера
int main (} {
ts_t prev_ta - read_timeatamp () ;
// инициализируем массивы и т.п. // ...
while(loop) {
ts_t this_ts = read_time3tamp(); ts_t time = this_ts - prev_ts;
if (time > ts_threashoi,d)
update_statistica(time); // собираем статистику
}
// выводим статистику для обработки
}
Рисунок 4. Алгоритм работы измерительного процесса
Функция read_timestamp() осуществляет чтение аппаратного счетчика таймера высокого разрешения (подробнее см. ниже). Функция update_statistics() занимается тем,
что сохраняет значение задержки в массиве. В простейшем случае вид этой функции может быть таким (рисунок 5).
unsigned, long ts_statistics [TS_BINS] ;
void update_statistics(ts_t time) {
const int TS_GRANULARITY = 1000; // приемлемая разрешающая способность
ts_t bin = time / TS_GRANULARITY;
if (bin < TS_BINS)
ts_statistics[bin]++;
}
Рисунок 5. Функция обновления статистики с фиксированным интервалом (простейший случай)
- 97
Электротехнические и информационные комплексы и системы. № 3, т. 15, 2019
Таймер высокого разрешения
Для измерения задержек достаточно иметь какой-либо таймер высокого разрешения, чтение счётчика которого возможно на уровне прикладных программ. Для упрощения изложения будем считать, что счётчик таймера имеет разрядность N бит и считает последовательно циклически от 0 до 2К-1. В таком случае разность показаний счётчика таймера, полученных в последовательные моменты времени (предполагается, что нас интересуют достаточно близкие события, интервал между которыми не превышает периода переполнения счетчика таймера), будет равна интервалу времени между событиями.
В идеальном случае таймер должен считать на тактовой частоте процессора, чтобы его показания менялись с каждой выполненной инструкцией процессора. Для современных процессоров с тактовыми частотами порядка 1-2 ГГц период переполнения даже 32-битного счетчика таймера составит 2-4 с, что вполне достаточно для однозначного измерения основных задержек СРВ, которые исчисляются микро- и миллисекундами.
Спектр задержек
Спектром задержек будем считать гистограмму распределения задержек в некоторой сетке интервалов. Спектр задержек представляет собой массив целых чисел, каждое из которых равно частоте возникновения определенной задержки цикла в заданном интервале значений. В простейшем случае функция update_statistics() может собирать статистику с фиксированным размером интервала (рисунок 5). В этом случае точность измерения задержек будет высокой, но для их регистрации может потребоваться значительный объем памяти. Например, при регистрации задержек до 20 мс с величиной интервала в 100 нс потребуется 200 тысяч интервалов, или 800 килобайт для 32-битных значений частот. В небольших СРВ такой объем памяти может быть значительным. Поэтому на практике разумно применять подход с переменным размером интервала гистограммы, величина которого растет с
увеличением задержек, сохраняя приемлемой относительную погрешность их измерения.
После работы алгоритма измерительного процесса в течение определенного времени необходимо профильтровать спектр, убрав оттуда величины задержек, которые не связаны с измеряемыми величинами, чтобы нормировать спектр для сравнения между несколькими запусками. Далее нужно построить нормированный спектр, вычислив отношение значений каждого интервала к сумме значений по всем интервалам. Сравнивая нормированные спектры, можно определить интервалы, в которых произошло изменение числа событий, и через их номера определить соответствующую задержку и время реакции СРВ на эти события.
Выводы
Предлагаемая в статье спектроскопия задержек является методом косвенного измерения временных характеристик СРВ. Достоинством метода является то, что он позволяет избежать модификации системного программного обеспечения (ПО): ядра и драйверов ОСРВ. Более того, при наличии доступа на чтение к таймеру с высоким временным разрешением реализация метода может проводиться на уровне прикладного ПО без прав суперпользователя.
Статистический характер собираемой информации сам по себе не дает возможности проводить прямые измерения задержек. Однако пользователь может анализировать спектры задержек, подвергая свою систему различным нагрузкам. Сравнивая спектры задержек под различными нагрузками и без них, можно определять характерные времена конкретной системы реального времени.
Предложенный метод носит общий характер, его можно применять не только к системам с вытесняющей многозадачностью, но и к любым другим. Основная задача пользователя — правильно описать модель задержек в своей системе и на её основе правильно провести сравнительный анализ спектров задержек.
Список литературы
1. Nandana V., Jithendran A., Shreelek-shmi R. Survey on RTOS: Evolution, Types and Current Research // International Journal of Computer Applications. 2015. Vol. 121. No. 21. P. 28-31. DOI: 10.5120/21825-5077.
2. Wang S.H., Cheng S.W., Huang C.C.J. Puyuma: Linux-Based RTOS Experimental Platform for Constructing Self-driving Miniature Vehicles // Computing Conference — 2018: Proceedings of Science and Information Conference. Cham, Switzerland. 2018. Vol. 858. P. 985-994. DOI: 10.1007/978-3-030-01174-1_75.
3. Garre C., Mundo D., Gubitosa M., Toso A. Real-Time and Real-Fast Performance of General-Purpose and Real-Time Operating Systems in Multithreaded Physical Simulation of Complex Mechanical Systems // Mathematical Problems in Engineering. 2014. Vol. 2014. URL: https://www.hindawi.com/journals/ mpe/2014/945850 (accessed 16.06.2019). DOI: 10.1155/2014/945850.
4. Raja B., Firdous A., Ishak A.M., Anand M. Design and Implementation of Health Care Video Monitoring System Based on RTOS // Indian Journal of Public Health Research and Development. 2019. Vol. 10. No. 4. P. 1260-1265.
5. Lee S.C., Ong S.E., Ali N.B.Z. Test Methodology for Real-Time Operating System // Bulletin of Networking, Computing, Systems, and Software. 2014. Vol. 3. No. 1. P. 10-12.
6. Hillary N. Measuring Performance for Real-Time Systems. Chandler: Freescale Semiconductor, 2005. 14 p. URL: https://www.nxp. com/docs/en/white-paper/CWPERFORMWP. pdf (accessed 15.06.2019).
7. Herzog B., Gerhorst L., Heinloth B., Reif S., Honig T., Schroder-Preikschat W. INTspect: Interrupt Latencies in the Linux Kernel // Computing Systems Engineering (SBESC) — 2018: Materials of VIII Brazilian Symposium. Salvador, Bahia, Brazil. 2018. P. 83-90. DOI: 10.1109/SBESC.2018.00021.
8. Tan S.L., Nguyen B.A.T. Survey and Performance Evaluation of Real-Time Operating Systems (RTOS) for Small Microcontrollers // IEEE Micro. 2009. Vol. 99. Issue 99. URL: https://ieeexplore.ieee.org/document/5210078 (accessed 18.06.2019). DOI: 10.1109/MM.2009. 56.
9. Parikh H., Shah R., Shah U., Deshmukh S. Performance Parameters of RTOSs; Comparison of Open Source RTOSs and Benchmarking Techniques // Advances in Technology and Engineering — 2013: Materials of International Conference. Mumbai, India. 2013. URL: https:// ieeexplore.ieee.org/document/6524742 (accessed 12.06.2019). DOI: 10.1109/ ICAdTE.2013.6524742.
10. Nisar S.K., Ahmed M., Ayub H., Baig I. Operating System Performance Analyzer for Low-End Embedded Systems // International Journal of Computer Science Issues (IJCSI). 2011. Vol. 8. Issue 6. No. 3. P. 341-348.
11. Abdulganiyu A., Rabiu I. Comparative Analysis of Real-Time Operating System (RTOS) of Some Selected OS Using External Signal Generator and Oscilloscope // International Journal of Science and Engineering Investigations. 2017. Vol. 6. No. 63. P. 47-53.
12. Koker K. Embedded RTOS: Performance Analysis with High Precision Counters // Autonomous Robots and Agents: Article in the Book. Berlin: Springer-Verlag Berlin Heidelberg, 2007. P. 171-179. DOI: 10.1007/978-3-540-73424-6_20.
13. Reddy B.M.K., Satyanarayana G.S.R., Seetaramanjaneyulu B. Scheduling Latency Comparison of Two Open-Source RTOSs on CORTEX-M3 // Embedded Systems — 2014: Materials of International Conference. Coimbatore, India. 2014. P. 59-62. URL: https:// ieeexplore.ieee.org/document/6953051 (accessed 14.06.2019). DOI: 10.1109/Embed-dedSys.2014.6953051.
References
1. Nandana V., Jithendran A., Shreelek-shmi R. Survey on RTOS: Evolution, Types and Current Research. International Journal of Computer Applications, 2015, Vol. 121, No. 21, pp. 28-31. DOI: 10.5120/21825-5077.
2. Wang S.H., Cheng S.W., Huang C.C.J. Puyuma: Linux-Based RTOS Experimental Platform for Constructing Self-driving Miniature Vehicles. Proceedings of Science and Information Conference «Computing Conference — 2018». Cham, Switzerland, 2018, Vol. 858, pp. 985-994. DOI: 10.1007/978-3-030-01174-1_75.
3. Garre C., Mundo D., Gubitosa M., Toso A. Real-Time and Real-Fast Performance
of General-Purpose and Real-Time Operating Systems in Multithreaded Physical Simulation of Complex Mechanical Systems. Mathematical Problems in Engineering, 2014, Vol. 2014. Available at: https://www.hindawi.com/journals/ mpe/2014/945850 (accessed 16.06.2019). DOI: 10.1155/2014/945850.
4. Raja B., Firdous A., Ishak A.M., Anand M. Design and Implementation of Health Care Video Monitoring System Based on RTOS. Indian Journal of Public Health Research and Development, 2019, Vol. 10, No. 4, pp. 12601265.
5. Lee S.C., Ong S.E., Ali N.B.Z. Test Methodology for Real-Time Operating System. Bulletin of Networking, Computing, Systems, and Software, 2014, Vol. 3, No. 1, pp. 10-12.
6. Hillary N. Measuring Performance for Real-Time Systems. Chandler, Freescale Semiconductor, 2005. 14 p. Available at: https:// www.nxp.com/docs/en/white-paper/ CWPERFORMWP.pdf (accessed 15.06.2019).
7. Herzog B., Gerhorst L., Heinloth B., Reif S., Honig T., Schroder-Preikschat W. INTspect: Interrupt Latencies in the Linux Kernel. Materials of VIII Brazilian Symposium «Computing Systems Engineering (SBESC) — 2018». Salvador, Bahia, Brazil, 2018, pp. 83-90. DOI: 10.1109/SBESC.2018.00021.
8. Tan S.L., Nguyen B.A.T. Survey and Performance Evaluation of Real-Time Operating Systems (RTOS) for Small Microcontrollers. IEEE Micro, 2009, Vol. 99, Issue 99. Available at: https://ieeexplore.ieee.org/docu-ment/5210078 (accessed 18.06.2019). DOI: 10.1109/MM.2009.56.
9. Parikh H., Shah R., Shah U., Deshmukh S. Performance Parameters of RTOSs; Comparison of Open Source RTOSs and Benchmarking Techniques. Materials of International Conference «Advances in Technology and Engineering — 2013». Mumbai, India, 2013. Available at: https://ieeexplore.ieee.org/ document/6524742 (accessed 12.06.2019). DOI: 10.1109/ICAdTE.2013.6524742.
10. Nisar S.K., Ahmed M., Ayub H., Baig I. Operating System Performance Analyzer for Low-End Embedded Systems. International Journal of Computer Science Issues (IJCSI), 2011, Vol. 8, Issue 6, No. 3, pp. 341-348.
11. Abdulganiyu A., Rabiu I. Comparative Analysis of Real-Time Operating System (RTOS) of Some Selected OS Using External Signal Generator and Oscilloscope. International Journal of Science and Engineering Investigations, 2017, Vol. 6, No. 63, pp. 47-53.
12. Koker K. Embedded RTOS: Performance Analysis with High Precision Counters. Article in the Book «Autonomous Robots and Agents». Berlin, Springer-Verlag Berlin Heidelberg, 2007. pp. 171-179. DOI: 10.1007/978-3-54073424-6-20.
13. Reddy B.M.K., Satyanarayana G.S.R., Seetaramanjaneyulu B. Scheduling Latency Comparison of Two Open-Source RTOSs on CORTEX-M3. Materials of International Conference «Embedded Systems — 2014». Coimbatore, India, 2014, pp. 59-62. Available at: https://ieeexplore.ieee.org/document/ 6953051 (accessed 14.06.2019). DOI: 10.1109/ EmbeddedSys.2014.6953051.
