Здравствуйте, cppguard, Вы писали:
C>Ничего из него непонятно.
Тогда проще: представьте, что Вы работаете на конвейере, по которому движутся, скажем, тонкие стеклянные изделия, которые Вам нужно упаковывать в коробки. Конвейер может иметь следящее устройство, которое останавливает его, если Вы не успеваете снять очередное изделие, а может и не иметь его. Скорость Вашей работы может быть как выше скорости конвейера, так и ниже нее.
— Если Вы всегда успеваете вовремя снять изделие, и аварийная остановка никогда не срабатывает, или вообще не предусмотрена — это hard realtime.
— Если Вы обычно успеваете, но в редких случаях остановка таки срабатывает — это soft realtime. Здесь также возможно, что остановки не происходит, и изделие разбивается (теряется безвозвратно). Предполагается, что такие случаи не наносят заметного вреда общему процессу. Так работает, например, передача по UDP, что не мешает организовать по TCP вполне надежную передачу звука или видео в реальном времени.
— По мере увеличения частоты остановок из-за неуспевания уменьшается возможность отнесения процесса к realtime.
Здравствуйте, cppguard, Вы писали: C>Ничего из него непонятно.
лучше читать книги, чем спрашивать на форуме
C>Вот в обсуждении прояснили кое-какие моменты. Как, например, разница в real-time system и real-time OS.
Во-первых, до этого легко можно было бы догадаться, зная, что для любого программно-аппаратного комплекса задаются системные требования и ПО требования.
Во-вторых, ничего особенно практического эта инфа не добавляет в общее понимание проблемы.
Pzz>>Не очень понятно, что такого может быть упущено в железе, чтобы оно не годилось для RT. Но вот драйвера железа дейтвительно бывают разного качества. И иные будут серьезно мешаться риалтаймовости. S>Я слышал про режимы работы цпу, мол защищенный режим не годится для rt.
Возможно речь шла про подкачку виртуальной памяти, для которой нужен защищенный режим но которую совершенно необязательно использовать в защищенном режиме.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тогда проще: представьте, что Вы работаете на конвейере, по которому движутся, скажем, тонкие стеклянные изделия, которые Вам нужно упаковывать в коробки. Конвейер может иметь следящее устройство, которое останавливает его, если Вы не успеваете снять очередное изделие, а может и не иметь его. Скорость Вашей работы может быть как выше скорости конвейера, так и ниже нее.
ЕМ>- Если Вы всегда успеваете вовремя снять изделие, и аварийная остановка никогда не срабатывает, или вообще не предусмотрена — это hard realtime.
ЕМ>- Если Вы обычно успеваете, но в редких случаях остановка таки срабатывает — это soft realtime. Здесь также возможно, что остановки не происходит, и изделие разбивается (теряется безвозвратно). Предполагается, что такие случаи не наносят заметного вреда общему процессу. Так работает, например, передача по UDP, что не мешает организовать по TCP вполне надежную передачу звука или видео в реальном времени.
Вот это типичное университетское объяснение real-time. И проблема в том, что даже непрограммист легко поймёт задачи систем реального времени и принцип разделения на soft, firm и hard. А у программистов другие вопросы:
— какую систему считать real-time?
— какими качествами должна обладать эта система?
— чем принципиально (кроме микроядра) QNX отличается от Linux?
— является ли Minix real-time OS?
— почему роботы работают на Linux, хотя это не real-time OS?
— почему моя магнитола иногда жёстко тупит и зависает, хотя внутри QNX?
Здравствуйте, cppguard, Вы писали:
C>- какую систему считать real-time?
Такую, которая обеспечит решение задачи в заданных рамках. То есть, для линии по сортировке/упаковке яиц может сгодиться и soft realtime, пока процент боя не выходит за допустимые пределы. А для управления реактором уже потребуется hard realtime (в пределах требуемой надежности).
Ну и надо понимать, что бессмысленно повышать надежность realtime в отрыве от общей надежности всей системы (железо+периферия+ОС+софт). Если, скажем, вероятность пропуска события — 1E-8, а вероятность глюка памяти — 1E-7, то особого смысла в таком строгом realtime нет.
C>- какими качествами должна обладать эта система?
Из обязательных — выполнять требуемые действия в пределах отведенного для них времени. Все остальное можно сделать на более высоких уровнях. Ну и понятно, что совокупное быстродействие должно быть достаточным для решения поставленных задач. Например, если железо и ОС гарантируют своевременный прием и передачу видеокадров, но прикладной софт сделали такой, что обрабатывать эти кадры он не успевает, от realtime особого толку не будет.
C>- чем принципиально (кроме микроядра) QNX отличается от Linux?
Тут не скажу, я не спец по обеим. Но в Linux многое делают системные службы (демоны), которые являются обычными пользовательскими процессами, разве что с повышенным приоритетом. В QNX они явно тоже переработаны.
C>- является ли Minix real-time OS?
Вообще ничего о ней не знаю.
C>- почему роботы работают на Linux, хотя это не real-time OS?
И Linux, и Windows, и MacOS — это не hard realtime, но вполне себе soft realtime с достаточно малым временем реакции, если грамотно настроены. Если от робота не требуется гарантированного времени реакции в единицы миллисекунд, он может работать даже на винде.
C>- почему моя магнитола иногда жёстко тупит и зависает, хотя внутри QNX?
Возможно, это как раз случай сочетания строгой ОС с не пойми каким софтом. Типа, заказчик где-то прочитал про realtime и QNX, и потребовал сделать магнитолу на ней. А софт и GUI, как водится, писали на куче разношерстных фреймворков, оно и тормозит, и никакая ОС это спасти не сможет.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>В венде драйвера могут занять систему своим полезным делом в любой момент, когда захотят, и на произвольное время.
ЕМ>А в каких ОС они этого не могут? Какие ОС умеют жестко ограничивать время работы драйверов, не нарушая при этом работу периферии?
Ну как вариант, пытаться решать проблему не в рантайме, давая драйверу по мозгам, а организационно, не стараясь не пропускать кривых драйверов в систему.
Здравствуйте, bnk, Вы писали:
bnk>Мое понимание такое, realtime означает что у системы есть гарантированное время обработки задач (реакции на события).
Это так и есть — любое событие обрабатывается за заранее заложенное время. Если такое не соблюдается, это уже не система реального временни — она опаздывает. В случае АЭС это взрыв реактора. Так что на АЭС должны быть только настоящие системы реального времени и без багов, иначе на милисекунду замедлить поднятие стрежня в реакторе — может и цепная ядерная реакция произойти. Это совсем другие системы и софт иной.
Здравствуйте, cppguard, Вы писали: C>Посоветуешь что-нибудь годное по теме?
Единственное, что я читал — "Real-Time Systems and Programming Languages. Ada, Real-Time Java and C/Real-TIme POSIX", Alan Burns, Andy Wellings.
Это такая мешанина из примеров кода и теории.
Наверняка есть и другие книги, и может лучше.
Здравствуйте, _ilya_, Вы писали:
__>Это так и есть — любое событие обрабатывается за заранее заложенное время. Если такое не соблюдается, это уже не система реального временни — она опаздывает. В случае АЭС это взрыв реактора. Так что на АЭС должны быть только настоящие системы реального времени и без багов, иначе на милисекунду замедлить поднятие стрежня в реакторе — может и цепная ядерная реакция произойти. Это совсем другие системы и софт иной.
Все верно, кроме взрыва. Системы аварийного выключения дублированы в другом контуре управления и от основного компа системы управления не зависят. Ну и процессы там не настолько быстро развиваются, чаще всего успевает среагировать даже оператор.
Это конечно предположения, а не инсайд, но вот так примерно в таких системах все и делается. А не на основе надежды на абсолютно правильное железо и безупречный софт.
Здравствуйте, Pzz, Вы писали:
Pzz>пытаться решать проблему не в рантайме, давая драйверу по мозгам
А что, ее таки можно решить такими методами? Сможете описать хоть мало-мальски реалистичный сценарий?
Pzz>а организационно, не стараясь не пропускать кривых драйверов в систему.
И чем тогда будет отличаться "истинно риалтаймовая" система от "условно риалтаймовой"?
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>а организационно, не стараясь не пропускать кривых драйверов в систему.
ЕМ>И чем тогда будет отличаться "истинно риалтаймовая" система от "условно риалтаймовой"?
Ну, вероятно, наличием риалтаймовых сертификационных требований к драйверам.
Здравствуйте, Pzz, Вы писали:
ЕМ>>И чем тогда будет отличаться "истинно риалтаймовая" система от "условно риалтаймовой"?
Pzz>Ну, вероятно, наличием риалтаймовых сертификационных требований к драйверам.
Ну так в той же NT такие требования существуют еще с самых ранних версий, но на них систематически забивает сам MS. А его тесты HCK/HCK этих параметров, насколько я знаю, вообще никогда не проверяли.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
как уже описали, наиболее критические процессы не выполняются на известных нам ОС, даже если
достаточно ядер и дать процессу высокий уровень приоритета — окончательных гарантий нет.
однако понятие реального времени растяжимо. если на внеший триггер сможешь гарантировать выполнение
операции и ответ до прихода следующго, тоесть вписываешся в такт — значит работаешь в режиме реального времени.
как ты это сделаешь, тут много вариантов
Здравствуйте, pik, Вы писали:
pik>как ты это сделаешь, тут много вариантов
Меня вот это конкретно интересует. Детские определения из учебника я прочитал много лет назад =) По факту получается, что многие системы, которые должны быть в реальном времени, на самом деле таковыми не являются. Их пишут на линупсе, надеясь, что всё будет как-то работать. Тот же ROS2. Или пишут bare metal, где вообще сложно не быть real-time, и говорят, что это real-time.
Здравствуйте, cppguard, Вы писали: C>По факту получается, что многие системы, которые должны быть в реальном времени, на самом деле таковыми не являются. Их пишут на линупсе, надеясь, что всё будет как-то работать.
Уже писали тут. Проигрывание видео — это пример реал-тайма. Пока нет конкретных требований, сложно сказать про абстрактную систему, нарушает она их или нет.
Если ты про роботов всяких, типа service robots, которыми в универах развлекаются, что-то не видел, чтобы к ним какие-то жесткие требования предъявляли.
C>Тот же ROS2.
Последний раз, когда я смотрел ROS — это был фреймворк для написания параллельно выполняющихся нод, с собственным механизмом передачи сообщений, "стандартными" типами данных и готовые ноды для всяких SLAM и проч. Хард-реалтаймом он себя (тогда) не называл, и потом, он не определял планирование задач, этим занималось ядро ОС.
>Или пишут bare metal, где вообще сложно не быть real-time
Вот вообще ортогональные вещи. Что мне мешает написать бейр-метал, в котором будут несколько тасков без инверсии приоритетов, и таск с нисшим приоритетом будет "душить" таск с высшим приоритетом?
Здравствуйте, student__, Вы писали:
__>Уже писали тут. Проигрывание видео — это пример реал-тайма. Пока нет конкретных требований, сложно сказать про абстрактную систему, нарушает она их или нет. __>Вот вообще ортогональные вещи. Что мне мешает написать бейр-метал, в котором будут несколько тасков без инверсии приоритетов, и таск с нисшим приоритетом будет "душить" таск с высшим приоритетом?
То ли не встречался с проблемой, то ли прикалываешься. Как я видел в своей жизни объяснение реального времени. Дают пример с потоковым декодированием аудио-видео. Тут как бы всё понятно, soft real-time, нет вопросов. Дальше — дают пример с бортовым компьютером в автомобиле и говорят что-то типа: "Если ABS сработает в нужный момент, то может случиться авария, поэтому вот пример hard real-time". И я начинаю размышлять: "Окей, а какие методы позволяют достичь этого самого rea-time? Может есть алгоритмы? Или методы верификаии?". И правильный ответ — да, методы есть, их много, они разные. И про них никто тебе не расскажет, нужно самому копать. А блок ABS просто написан на bare metal, там полностью детерминистичный алгоритм, который при всём желании не может дать случайные задежки. Поэтому ABS это пример real-time system, но не real-time подхода к разработке. А меня, как разработчика, в первую очередь интеруют именно инструменты предоставления гарантии real-time.
__>Последний раз, когда я смотрел ROS — это был фреймворк для написания параллельно выполняющихся нод, с собственным механизмом передачи сообщений, "стандартными" типами данных и готовые ноды для всяких SLAM и проч. Хард-реалтаймом он себя (тогда) не называл, и потом, он не определял планирование задач, этим занималось ядро ОС.
The Robot Operating System без гарантии real-time это какая-то нелепица. Если посмотреть на задачи, которыми занимались основатели — The Willog Garage, то становится понятно, что реальное время там и не нужно было, я всё это понимаю, но абсурда это не отменяет. А если верить Википедии, то наработки компании после её продажи использовались во вполне себе серьёзных проектах.
Здравствуйте, pagid_, Вы писали: _>Это конечно предположения, а не инсайд, но вот так примерно в таких системах все и делается. А не на основе надежды на абсолютно правильное железо и безупречный софт.
Есть и другие примеры — скажем, система стабилизации какого-нибудь F22. Сам по себе он аэродинамически неустойчив, и если компьютер опоздает с вычислением управляющего воздействия в ответ на порыв ветра, то машинка просто рассыплется в воздухе. Поэтому там всё работает именно на основе надежды на абсолютно правильное железо (с тройной, емнип, избыточностью) и безупречный софт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, cppguard, Вы писали: >А меня, как разработчика, в первую очередь интеруют именно инструменты предоставления гарантии real-time.
Рекомендую ту книгу, которую я упомянул. Там нет про конкретные ОС, но есть теоретическая инфа о том, как, например, верифицируется непропуск планировщиком дедлайнов для конкретных типов систем, с наперёд известными пиковыми нагрузками (частотой некоего события) и максимальных длительностей отдельных операций, составляющих решаемую техническую задачу.
Изучив некоторую базу теории уже можно рассматривать конкретную ОС и проч. инструменты, сам я пока до этого не дошёл.
C>The Robot Operating System без гарантии real-time это какая-то нелепица. Если посмотреть на задачи, которыми занимались основатели — The Willog Garage, то становится понятно, что реальное время там и не нужно было, я всё это понимаю, но абсурда это не отменяет. А если верить Википедии, то наработки компании после её продажи использовались во вполне себе серьёзных проектах.
Ну видимо не в совсем серьёзных, в которые абы какой POSIX не пустят. А для сервис-робота особой разницы нет, сработает ли блокировочный бампер к моменту t0 или t0+5ms.
