Pull to refresh

Comments 7

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


Крайне злостная инсинуация, закладывающая заранее неверный посыл в методологический аппарат:

0.
а обработчик прерываний обязан быть прост, чтобы на длительное время не блокировать систему.

Обработчик ничего никому не обязан. В СРВ системообразующие функции должны решаться с наивысшим преоритетом любыми эффективными средствами. То, о чем Вы толкуете не более чем интерактивность. Если Вам важно уложиться в тайминги — переносите в ISR, пользователь обойдется. Если же система строится как комплексный АРМ оператора, да еще и с функциями реалтаймового процессирования чего-то с АЦП, то и тест должен быть комплексным, с учетом интерфейсных задач.

1.
Он лишь отправляет сообщение пользовательскому потоку, который активируется и обрабатывает готовый фрейм

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

2.
В качестве теста предлагается следующий код

Тест не специфичен. Во всех СРВ есть встроенные низкоуровневые механизмы. Чтобы сравнить потенциал двух ОС РВ следует стремиться выжать из них максимум, а не запускать некий универсальный код. Универсалии, как известно, противопоставляются оптималиям.

Как известно, лидером среди операционных систем реального времени является QNX.

С чего бы это?

Низкая популярность является причиной отсутствия драйверов под эту ОС на сайтах производителей.

Для АЦП, ЦАП, дискретного I/O драйвера пишутся в большинстве случаев за пару дней. Помнится, были прикольные агрегаты у L-CARD, с собственным подгружаемым микрокодом. Вот с ними было интересно, да.
Не смог удержаться от комментариев по самой методике, извините.

0.
мы изменяем длительность системного тика до 10 мкс

Этим Вы создали чудовищное расходование ресурсов ядром ОС, обеспечив фору RTLinux. Я вообще удивлен, что прикладной тест в таких условиях выдал что-то вменяемое. В здравом уме на современном оборудовании ставить разрешение таймера ниже 1мс не рекомендуется. СРВ стремятся обеспечить потокам soft-affinity исходя из ассоциаций с прерываниями, запуская потоки на тех ядрах, на которых генерируется IRQ. Делается это из соображений экономия на когерентности кэшей. В Ваши условиях ядро ОС будет стремиться возобновлять поток теста на ядре, которое с интервалом 10мкс дергает системный таймер. И его обработчик может легко сам отъесть 2-3мкс от этого интервала. Итого сам по себе тик в 10мкс создает нагрузку на процессор до 20-30% на пустом месте.

1.
Временные интервалы замеряются циклами тактовой частоты процессора для большей точности

Счетчик тактов плавает, так как он разный на разных ядрах. Тест не учитывает этого.

2.
Это обеспечивает выбор планировщиком именно этого потока при его готовности. Мешать работе потока теоретически может только обработка прерываний

Вы сейчас серьезно? Почитайте вот об этом, пожалуйста: Priority Inheritance Protocol & Priority ceiling protocol.

3.
К счастью для точного подсчёта времени в Linux используется отдельный аппаратный высокоточный таймер HPET (High Precision Timer Support) предоставленный платформой

Т.е. источники тактирующего системного сигнала и их точность разные. Если не во всех, то в большинстве, СРВ можно переконфигурировать систему на использование конкретного системного таймера.

4.
Поскольку тактовая частота процессора 3.4 ГГц, то переполнения 32-х разрядного значения за секунду быть не должно

Если начали ровно в начале 32-х разрядного кванта времени. Это не обеспечивается.

5.
Давайте разберёмся что же, такое usleep. По сути это системный вызов. Т.е. обращение к ядру ОС которое разворачивается в просьбу перевести поток в состояние покоя, завести таймер на 500 мкс и переключиться на выполнение других, менее приоритетных задач. Как только истекает запрошенное время, генерируется прерывание и система переводит поток в активное состояние.

У Вас здесь заложена большая системная ошибка, которой будет лишен внешний источник IRQ с собственным тактированием. Таймеры работают совершенно не так. Если считать накладные расходы на работу с таймером строго =0, то чтобы обеспечить четкое тактирование системный вызов должен попасть +- в момент прерывания таймера. И вот почему. Для usleep() и других на уровне ядра ОС запоминаются состояние текущего счетчика системного таймера и ближайшее значение после интервала задержки. Никакие отдельные аппаратные таймеры не заводятся на каждый usleep() в системе — аппаратных таймеров не хватит. Таким образом, замер времени будет плавать в зависимости от удачности момента вызова usleep().

Итого: делать выводы о том как будут обрабатываться данные от ISR без самого ISR все-таки не вполне корректно. Что-то Вы измерили однозначно. Вот только риторический вопрос — что именно?

P.S. Плохая практика измерять характеристики СРВ методами ОС общего назначения. См. замечание 5. Измерения и оценки систем реального времени всегда проводят внесистемными средствами.

P.S.2. В свое время ставили эксперимент. 2 команды: представители Астры (c RT-патчем) и QNX на одном и том же железе демонстрировали два сценария:
— строб на вход дискретной платы, выдача строба в ISR на выход дискретной платы;
— строб на вход дискретной платы, выдача строба в прикладном потоке на выход дискретной платы;
Статистика и выбросы накапливались осциллографом. Попробуйте такую методику, результаты будут интересными. Разработчики стремились выжать максимум из своих детищ, что придавало оттенок конкуренции.

А чем закончился эксперимент из P.S.2?

Точных цифр за давностью лет не назову. Результаты были таковы, что «выбросы» у СРВ и RTLinux были до единиц-десятков мкс стабильно, но у последнего встречались единичные до сотни или двух. На этом стенде остановились на СРВ, поскольку времянку терять было нельзя.

На втором стенде смотрели производительность сети. Не реалтаймовость, так как rt ethernet никто не требовал. Там Астра показала себя лучше.

В общем случае остановились на том, что «кесарю кесарево,...».

"Мало компаний, предлагают драйверы для своих устройств под Qnx"

Что не удивительно, учитывая что для того что б собирать софт для этой ОС нужно покупать лицензию на sdk за ~2 млн, и даже для исследовательских целей его накопать тот ещё геморрой. По моему это худшее что только может сделать компания разрабатывающая ОС

Коллеги всем спасибо за коментарии. Вижу, что тема оказалась интересна. Замечу, что тест не претендует на звание всеобъемлющего критерия сравнения ОСРВ.

По поводу чрезмерной загрузки системы при смене значения системного тика на QNX. Да нагрузка возросла, но на удивление, не всё так плохо.

Общая загрузка системы: 8.2%, ядро: 0.3%, сам тест: 1.4%

Действительно не рекомендуется менять тик ниже 1 мс. Но мне было интересно поработать на временном интервале 500 мкс, а такого значения при тике 1 мс не получить. Опытным путём выяснилось, что погрешность перепланирования для QNX в этом тесте находится в рамках одного тика. Поэтому был выбран минимальный.

Общая загрузка системы: 8.2%, ядро: 0.3%, сам тест: 1.4%

Вы неверно оценили увиденное. У вас поток скачет по ядрам. Спроецируйте увиденное на производительность 1 ядра CPU и увидите, что это даже круче того, что я умозрительно ожидал. Грубо говоря, ущерб производительности в работе таймера ~= 8.2*8 ядер.

мне было интересно поработать на временном интервале 500 мкс
мы изменяем длительность системного тика до 10 мкс

На интервалах в единицы и десятки мкс. только поллинг, атомики и активное ожидание.
Only those users with full accounts are able to leave comments. Log in, please.