Здравствуйте, cppguard, Вы писали: >Поэтому ABS это пример real-time system, но не real-time подхода к разработке. А меня, как разработчика, в первую очередь интеруют именно инструменты предоставления гарантии real-time.
Это вряд ли тот пример, на котором вся сложность реалтайма с т.з. софта и планирования возникает во всей красе, а здесь больше про автоматическое управление, обратную связь и всё такое. На входе поступает инфа от фиксированного количества датчиков, решается оптимизационная задача, где каждая итерация вычисления занимает фиксированное время. В результате управляющий сигнал подаётся на выход. С т.з. софта это, например, тот же бизи луп и поллинг, и основная сложность в хардовой архитектуре и выборе конкретных МК и шин данных, чтобы уложиться в максимальные величины длительности В/В и вычисления целевой функции. Если абсолютные величины (например, по шине ходят ещё какие-то данные от других подсистем) не фиксированы, может потребоваться контроль джиттера В/В, но хрен знает, нужно ли это для ABS.
И ABS'у связь с приборной панелью и остальным инфотейнментом нужна разве чтобы отправить "я сработал" или "я неисправен" в журнал событий или на приборную панель, но отправка этого всего тоже включается в расчет итерации бизи лупа.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности".
Под этим термином могут пониматься разные вещи. Но в самом общем виде, это когда для работы программы имеет значение реальное (физическое) время, которое мы измеряем с помошью реальных (физических) часов.
Например, компьютерные игры бывают пошаговые, а бывают реального времени. В пошаговых играх время тоже может идти, например в Цивилизации за каждый ход проходит некоторое количество лет, но к физическим часам это отношения не имеет. В игре же реального времени, игровое время соответствует физическому, при этом гарантии, что игра не будет ингода притормаживать тебе никто не дает.
C>Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time?
Допустим у тебя есть обыкновенный видеофайл. В нем есть обычное видео, записанное с частотой 25 кадров в секунду и длиной 10 секунд. Тебе надо проиграть этот файл в реальном времени. У тебя мощное железо и хороший софт, который позволяет обработать и показать кадр 10 раза быстрее. То есть ты можешь проиграть 10 секундное видео за 1 секунду. По идее, если ты проиграешь видео за 1 секунду, ты в 10 секунд укладываешься, даже с большим запасом. Но это не real-time! Чтоб проиграть видео в реальном времени, время на видео должно идти с той же скоростью, что и физическое.
Если же у тебя слабое железо, и ты не успеваешь обрабатывать кадр за нужное время, ты можешь начать выкидывать какие-то кадры, ухудшить качество видео и тд и тп, но все равно проиграть его за те же 10 секунд.
C>Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Я специально ничего не стал писать про ОС реального времени. Это уже более узкое понятие. Если запущенный тобой процесс вообще не имеет никакого отношения к физическому времени, а просто что-то вычисляет, то он не будет real-time, даже если ты его запустишь на QNХ.
Здравствуйте, cppguard, Вы писали:
C>The Robot Operating System без гарантии real-time это какая-то нелепица.
Нелепица — это неумение прочитать первый абзац Википедии:
Robot Operating System (ROS or ros) is an open-source robotics middleware suite. Although ROS is not an operating system (OS) but a set of software frameworks for robot software development, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management.
говорят что MS DOS досихпор летает в космосе одно из упоминаний
В конце 1993 года российская компания Физтех-софт выпускает первую коммерческую версию PTS-DOS v6.4 (номер версии следует системе версий MS-DOS — Microsoft выпустила MS-DOS v6.2 в ноябре 1993 года).
Некоторые программисты, покинувшие Физтех-софт в 1995 году и основавшие Paragon Software выпустили собственную версию PTS-DOS v6.51CD с поддержкой приводов CD-ROM.
Физтех-софт продолжила разработку своего кода, выпустила PTS-DOS v6.6 и показала PTS-DOS v6.65 на выставке CeBIT в 1997 году[1]. Следующая версия от Физтех-софт, PTS/DOS Extended Version 6.70, выпускалась под названием PTS-DOS 2000 и продается до сих пор (начало 2009 года), как последний 16-битный PTS-DOS. Система ДОС Багет, основанная на PTS-DOS 2000, сертифицирована Министерством обороны Российской Федерации.
Paragon продолжил разработку линии PTS-DOS и выпустил Paragon DOS Pro 2000 (также известный как PTS/DOS Pro 2000) с поддержкой файловой системы FAT-32 и жёстких дисков более 8 гигабайт. Согласно сообщениям Paragon, это была последняя версия и вся разработка с тех пор была прекращена. Эта версия поставлялась с исходным кодом более старого PTS-DOS v6.51.
В 2002 году Физтех-софт выпустил 32-битную версию PTS-DOS — PTS-DOS 32 (известный как PTS-DOS v7.0[2]) с поддержкой файловой системы FAT-32, жёстких дисков более 8 гигабайт и памяти до 4 гигабайт.
Здравствуйте, sergey2b, Вы писали:
S>говорят что MS DOS досихпор летает в космосе одно из упоминаний
Так и Вояджеры до сих пор летают. Типа, кто там их из этого космоса достанет.
С другой стороны, в космосе, как и в автомобилях, всегда был очень длинный жизненный цикл железа: пока спроектируют, потом в серию выведут, потом эту серию надо годами поддерживать.
Здравствуйте, Nuzhny, Вы писали:
N>Нелепица — это неумение прочитать первый абзац Википедии: N>
N>Robot Operating System (ROS or ros) is an open-source robotics middleware suite. Although ROS is not an operating system (OS) but a set of software frameworks for robot software development, it provides services designed for a heterogeneous computer cluster such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management.
Robot Operating System is not an operating system — не вижу подвоха. Я прексрасно знал и до этого, что ROS не реализует какие-то реальные вещи из мира роботов, а является по сути скоплением алгоритмов кинематики, управления и т.д. Но в реального робото всё это не воткнуть.
Здравствуйте, cppguard, Вы писали:
C>Но в реального робото всё это не воткнуть.
Зависит от робота. ROS — это же наполовину образовательный проект Стэнфорда, где студент может взять какой-то узкий алгоритм, реализовать только его с правильным интерфейсом и весь пайплайн будет работать. Например, SLAM — классический пример использования. На модельках или даже в симуляторе, без проблем.
В Боинг ROS не засунут, на конвейер тоже, военные использовать его не станут, Тесла к себе не поставит. Но штука хорошая для своей ниши.
Здравствуйте, cppguard, Вы писали:
C>Может есть алгоритмы? Или методы верификаии?". И правильный ответ — да, методы есть, их много, они разные. И про них никто тебе не расскажет, нужно самому копать.
А что про них рассказывать-то в общем случае? Это как про таблицу умножения монографию писать. Оно ж и так понятно: нужно убедиться, что по всем путям выполнения сумма всех возможных задержек не превышает некоторых разумных величин, определяемых или интуитивно, или статистически. Если делается программа для голого процессора — учитываем его внутренние задержки и задержки самой программы. Если используются внешние устройства — добавляем задержки шин и устройств. Используется ОС — добавляем задержки ядра, драйверов и приоритетных служб. Используются библиотеки — добавляем их задержки.
А о том, как устранить лишние задержки в тех или иных устройствах и системах, написано до хренища. Просто оно не стоит на одной полке.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Основательно погрузился в этот процесс в декабре, поэтому отвечаю сам себе. Прежде всего, "real-time" это очень широкий термин, который охватывает разные уровни системы. Если речь идёт именно про операционные системы, то "real-time OS" означает наличие планировщика, работающего в соответствии с жёстко вытесняющей моделью (это моя вольная трактовка). Проще говоря, real-time scheduler выполняет задачу (системный поток), пока она не заблокируется в ожидании ввода-вывода, примитива синхронизации, вызова sleep() или не передаст управление явно, вызовав yield(). Как только самый приоритетный поток завершился или заснул, планировщик выбирает следующую задачу с таким же приоритетом или ниже, если нет задач с таким же приоритетом. При этом для задач с равным приоритетом могут использоваться разные политику выбора. Например, политика FIFO устанавливает очерёдность исполнения на основании очерёдности добавления в очередь. То есть, задачи добавленыые (запланированные) ранее будут исполнены первее. Другая политика, Round-Robin, позволяет исполнять задачи с равным приоритетом всевдо-параллельно, предоставляя каждой фиксированную порцию вермени исполнения. Для сравнения, планировщики Linux и Windows тоже учитывают приоритет, но при этом стараются дать квант времени даже для задач с низким приоритетом, потому что в данном случае значение отклика системы гораздо важнее. В конкретных ОСРВ могут встречаться специфичные политики. Например, SCHED_DEADLINE в Linux позволяет задать для задачи ограничение по сроку исполнения — тот самый функционал, который приводят в абстрактных примерах. В случае этой политики планировщик выбирает следующую задачу на основании заявленного времени работы и времени завершения. Планировщик (в данном случае является синонимом "политики") deadline хорошо иллютстрирует отличие ОСРВ от обычных систем. В QNX deadline в случае нарушения гарантий времени работы со стороны приложения позволяет установить обработчик соответствующего события и обработать его программно, Linux же ничего не делает кроме понижения приоритета задачи. Помимо планировщика ОСРВ отличаются общей предсказуемостью времени работы обработчиков прерываний и системных вызовов. А ещё есть разные дополнительные инструменты. Например, partitions в QNX позволяют разделить ресурсы ЦП между кластерами задач в заранее заданом соотношении. Так можно отдать 20% на некритичные задачи и 80% на критичные, а ОС сама позаботится о распределении ресурсов. Отдельно я бы выделил прикладные приёмы программирования для задач реального времени, как, например, отказ от динамической памяти, или повсеместное использование в STL C++ детерминированного аллокатора, или вообще Epsilon GC для Java c жёстким контролем за выделением памяти. Но про это очень мало написано.
Если говорить про разделение на категории, то можно выделить три группы. Первая — это коммерские ОСРВ вроде QNX и VxWorks. Вторая группа это открытые ОСРВ, которые собираются вместе с приложением, например, FreeRTOS и RIOT. Я не знаю, есть там разделение на уровень ядра и на прикладной, но уже один факт того, что эти ОС по сути являются частью приложения, заставляет изучать их в особом порядке. Наконец, есть Linux, обросший за долгие годы многими инструментами, присущими ОСРВ, а в недавнем прошлом ещё и получивший PREEMPT_RT в основную ветку. Зачем я привёл эти три группы? Да просто потому что если мы начинаем рассуждать о системах реального времени (операционных в том числе), то нужно чёткое понимание, что именно мы обсуждаем, а иначе будет блуждание в тумане.
Подытоживая написанное в одном предложении: ОСРВ это прежде всего чёткая очерёдность задач в соответствии с их приоритетами, и ещё некоторые другие инструменты, позволяющие наиболее эффективно использовать вычислительные ресурсы, сохраняя гарантию успеть выполнить задачу до того, как результат станет неактуальным.
Здравствуйте, Maniacal, Вы писали:
C>>Вот это интереснее. Прекратить — отрубить процесс? Или речь о системных вызовах? M>Применимо к прошивкам телевизоров, например. Не успел кадр обработать, давай другой начинай.
Ну, не зря же программа Время начинается на цифровых телеках/приставках примерно на пол-секунды, а то и секунду позже, чем на аналоговых... ))
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>В венде драйвера могут занять систему своим полезным делом в любой момент, когда захотят, и на произвольное время. ЕМ>А в каких ОС они этого не могут? Какие ОС умеют жестко ограничивать время работы драйверов, не нарушая при этом работу периферии?
Тут дело не только в ОС, а еще в конкретном оборудовании и настройке самой ОС, в т.ч. настройки её при компиляции ядра.
И Windows, и Linux могут быть собраны таким образом для конкретной железки, чтобы, допустим, прерывания обрабатывались только нулевым ядром.
В этом случае даже "короткое" аппаратное прерывание, маскирующая другие прерывания, не заденет процессы, исполняющиеся в других ядрах, а там уже вопрос приоритета, если есть боязнь вытеснения — в виндах отродясь был realtime-приоритет, для linux есть соотв. патчи.
А для "длинных" софтовых прерываний в этих ОС никогда не было проблем одновременной их обработки.
В общем, это вопрос сочетания сборки ядра, распределения аппаратных ресурсов (в т.ч. назначения affinity для прикладных потоков) и взаимодействия драйвера устройства и прикладного кода, требующего реалтайм.
Например, не стоит создавать взаимные блокировки ресурсов у драйвера и прикладной части, стоит использовать lock-free техники.
С сигналингом тоже достаточно просто — прикладной процесс может находиться в режиме ожидания на некоем HEVENT, имея при этом realtime-приоритет, а драйвер, после подготовки данных, может дёрнуть этот примитив синхронизации и тогда прикладной процесс получит в своём привязанном через affinity аппаратном потоке ресурс проца.
Ну и, сам прикладной код может целиком жить в драйвере, хотя в этом случае писать придётся на Си или на сильно урезанном С++ — без исключений/RAII, без динамической инициализации глобальных объектов, без RTTI и, возможно, без сохранения плавающих регистров м/у прерываниями, т.е., подавляющее большинство плюсовых библиотек использовать будет невозможно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И Linux, и Windows, и MacOS — это не hard realtime, но вполне себе soft realtime с достаточно малым временем реакции, если грамотно настроены. Если от робота не требуется гарантированного времени реакции в единицы миллисекунд, он может работать даже на винде.
На Win XP работает ЧПУ софтина Mach3, которая напрямую управляет шаговыми двигателями с частотой как минимум в килогерцы, а то и десятки. И если бы там профукивались тайминги, то траектория была бы не совсем та, которую хотелось бы
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time?
Лично для меня realtime в ОС в первую очередь означает гарантированное время, от прихода события, до момента, когда начали выполняться первые инструкции обработчика события.
Например, устройство по DMA заполнило буфер и вызвало аппаратное событие, которое в свою очередь вызвало прерывание, внутри которого ОС было уведомлено, что данные готовы, после чего (уже не в прерывании, а в задаче ОС в пользовательском коде) начали обрабатываться данные. В данном случае, если от момента, когда железо вызвало событие, до момента обработки данных в пользовательском коде, промежуток детерминирован, то это realtime, если не детерминирован и зависит от фазы Луны, то не realtime
Здравствуйте, vdimas, Вы писали:
V>В этом случае даже "короткое" аппаратное прерывание, маскирующая другие прерывания, не заденет процессы, исполняющиеся в других ядрах
Не знаю, как в Linux, а в Windows аппаратные прерывания — один из последних факторов, влияющих на реактивность процессов. На современном железе нужны десятки-сотни тысяч прерываний в секунду, чтобы они стали ощутимо кому-то мешать. В основном тормозят кривые драйверы (в том числе родные) и чрезмерно раздутый код ядра.
V>в виндах отродясь был realtime-приоритет, для linux есть соотв. патчи.
Это всего лишь наивысший приоритет user-mode кода. От тормозов в ядре он спасти не может.
V>не стоит создавать взаимные блокировки ресурсов у драйвера и прикладной части, стоит использовать lock-free техники.
Стоит, но кто бы это делал в той же винде...
V>прикладной код может целиком жить в драйвере, хотя в этом случае писать придётся на Си или на сильно урезанном С++ — без исключений/RAII, без динамической инициализации глобальных объектов, без RTTI и, возможно, без сохранения плавающих регистров м/у прерываниями, т.е.,
RAII не требует ничего, кроме поддержки конструкторов/деструкторов, это реализовано везде. А что такое "динамическая инициализация глобальных объектов"?
V>подавляющее большинство плюсовых библиотек использовать будет невозможно.
Их уже из-за исключений невозможно использовать. Ну и еще потому, что про наличие небесконечной памяти их авторы, похоже, забыли уже очень давно.
Здравствуйте, пффф, Вы писали:
П>На Win XP работает ЧПУ софтина Mach3, которая напрямую управляет шаговыми двигателями с частотой как минимум в килогерцы, а то и десятки.
Если конфигурация системы тщательно вылизана, то вполне реально. А вот устроить такое в обычной домашней/офисной системе с интернетом и мультимедиа уже вряд ли получится, хотя чисто технически ничто не мешает.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>На Win XP работает ЧПУ софтина Mach3, которая напрямую управляет шаговыми двигателями с частотой как минимум в килогерцы, а то и десятки.
ЕМ>Если конфигурация системы тщательно вылизана, то вполне реально. А вот устроить такое в обычной домашней/офисной системе с интернетом и мультимедиа уже вряд ли получится, хотя чисто технически ничто не мешает.
Ничего там не вылизывалось, ставил на древнюю систему самую обычную древнюю XPшку, по сети закидывал файлы с жи кодом, и пилил
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Не знаю, как в Linux, а в Windows аппаратные прерывания — один из последних факторов, влияющих на реактивность процессов.
Это от драйвера зависит.
Маскируемое прерывание должно быть отработано как можно быстрее, т.е. в идеале — выставить пару флагов, разрешить аппаратные прерывания и инициировать уже программное прерывание.
ЕМ>На современном железе нужны десятки-сотни тысяч прерываний в секунду, чтобы они стали ощутимо кому-то мешать.
Реалтайм бывает разный.
Современные Windows и Linux на грамотно построенной аппаратуре и соотв. драйверном и прикладном ПО способны обеспечить реакцию в единицы микросекунд запросто.
ЕМ>В основном тормозят кривые драйверы (в том числе родные) и чрезмерно раздутый код ядра.
Приличная часть кода ядра может и не использоваться вовсе, а в Linux лишнее можно легко выключить из сборки.
Ведь ты ж не будешь строить реалтаймовую систему как "просто еще одну программу" на десктопе общего назначения?
Зачем запускать десятки ненужных процессов?
V>>в виндах отродясь был realtime-приоритет, для linux есть соотв. патчи. ЕМ>Это всего лишь наивысший приоритет user-mode кода. От тормозов в ядре он спасти не может.
Процессоры сегодня многоядерные, поэтому, если с драйвером нет взаимных блокировок ресурсов и прикладной поток исполняется в другом ядре чем то, которое обслуживает прерывание, то прикладной процесс с наивысшим приоритетом будет всегда оперативно получать тики проца.
Там всей разницы, что ожидающий на семафоре или HEVENT такой поток получает тики проца в Windows сразу же при установке примитива сигнализации, а в Linux такие потоки получали тики проца через стандартный решедуллинг раз в 1/1000 сек, почему Linux и не считалась системой реального времени. Но есть патчи, которые заставляют решедулить потоки при установке из ядра примитивов сигнализации, т.е. которые передают управление нужному потоку сразу — у каждого примитива сигнализации есть список ожидающих его потоков. На autoreset HEVENT обычно ожидает один поток, на семафоре могут ожидать несколько потоков, например, несколько прикладных потоков с наивысшим приоритетом раскиданы по физическим ядрам и обрабатывают поступающие данные в режиме СМО.
V>>не стоит создавать взаимные блокировки ресурсов у драйвера и прикладной части, стоит использовать lock-free техники. ЕМ>Стоит, но кто бы это делал в той же винде...
Там это делали отродясь, по крайней мере в дровах от самой MS.
V>>прикладной код может целиком жить в драйвере, хотя в этом случае писать придётся на Си или на сильно урезанном С++ — без исключений/RAII, без динамической инициализации глобальных объектов, без RTTI и, возможно, без сохранения плавающих регистров м/у прерываниями, т.е., ЕМ>RAII не требует ничего, кроме поддержки конструкторов/деструкторов, это реализовано везде.
RAII требует реакции на исключения.
Но, я мог здесь и поторопиться в рассуждениях, бо, действительно, в отсутствии исключений, дело только за вызовами деструкторов по выходу из scope.
ЕМ>А что такое "динамическая инициализация глобальных объектов"?
Это когда у глобальных/статических переменных вызывается конструктор и в конце работы модуля деструктор.
Оно ж и так понятно: нужно убедиться, что по всем путям выполнения сумма всех возможных задержек не превышает некоторых разумных величин, определяемых или интуитивно, или статистически. Если делается программа для голого процессора — учитываем его внутренние задержки и задержки самой программы. Если используются внешние устройства — добавляем задержки шин и устройств. Используется ОС — добавляем задержки ядра, драйверов и приоритетных служб. Используются библиотеки — добавляем их задержки.
