Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Мое понимание такое, realtime означает что у системы есть гарантированное время обработки задач (реакции на события).
Ни Windows, ни Linux этого не гарантирует (на прикладном уровне), т.к. система может заняться чем-то своим,
а твоя задача окажется в очереди, и может не выполниться за заданное время.
Даже если запустить 1 процесс, система может его легко приостановить его и заняться обработкой каких-нибудь прерываний например, и заниматься этим столько, сколько захочет.
realtime системе такое не разрешено делать, время отклика должно быть наперед известно.
Здравствуйте, bnk, Вы писали:
bnk>Даже если запустить 1 процесс, система может его легко приостановить его и заняться обработкой каких-нибудь прерываний например, и заниматься этим столько, сколько захочет. bnk>realtime системе такое не разрешено делать, время отклика должно быть наперед известно.
Плюс на уровне ПО, если операция не успевает выполниться, нужно её прекратить и начать следующую. ИМХО.
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, Maniacal, Вы писали:
M>>Плюс на уровне ПО, если операция не успевает выполниться, нужно её прекратить и начать следующую. ИМХО.
C>Вот это интереснее. Прекратить — отрубить процесс? Или речь о системных вызовах?
Применимо к прошивкам телевизоров, например. Не успел кадр обработать, давай другой начинай.
Здравствуйте, cppguard, Вы писали:
C>без всяких RT-патчей и запустить на нём лишь один про
Если I/O (дрова) предсказуемы, если таймауты точны, то да. Вообще, RT — это в большей части про многозадачность, и соотв. планирование, и в этой теме больше всего ресёрча и сложности проблематики. Один единственный процесс/поток — это вырожденный случай.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности".
Тоже так думаю. Достигается это ограничением времени на io операции.
C>Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Разве не от железа это зависит в первую очередь? Не всякое железо, цпц, для RT задач пригодно, если не ошибаюсь.
Здравствуйте, Sharov, Вы писали:
S>Разве не от железа это зависит в первую очередь? Не всякое железо, цпц, для RT задач пригодно, если не ошибаюсь.
Из того, что в обычном компе какое не подходит и почему? Не вижу проблем каких-то. Понятно, что требования по абсолютным таймингам должны удовлетворяться, а в остальном?
Здравствуйте, student__, Вы писали:
__>Из того, что в обычном компе какое не подходит и почему? Не вижу проблем каких-то. Понятно, что требования по абсолютным таймингам должны удовлетворяться, а в остальном?
Единственное, что приходит в голову — свитчи эзернет, в которых может быть большой диапазон отклика в зависимости от забитости очередей кадров. Но тогда просто не использовать эзернет.
Здравствуйте, cppguard, Вы писали:
C>Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time?
Смотря что вкладывается в эти N секунд. Реалтайм подразумевает, что данные, на основе которых выполняется задача, не успеют "протухнуть" до момента окончания выполнения задачи. Пока твой робот думает N секунд, как ему объехать пешехода, пешеход успел сходить в магазин и обратно, за эти N секунд ))
__>Из того, что в обычном компе какое не подходит и почему? Не вижу проблем каких-то. Понятно, что требования по абсолютным таймингам должны удовлетворяться, а в остальном?
Throttling — частота плавает.
Out of order, Branch Prediction тоже могут приводить к веселым последствиям.
Кэши всякие не дают гарантии по времени доступа к памяти. Помнится для винды был типа патч, который из нее делал типа риалтайм — он вроде как раз логику работы с кэшами правил.
линукс никогда не был реалтаймом
а вообще вопрос с собеседований на котором валят всех
так как никто не знает что вкладывать в этот смысл
для меня примером реалтайма есть QNX
а в ней кажется даже драйвера в ring3
т.е. безотказность и гарантированность исполнения потока данных
как я люблю отвечать на собесах
bnk>Мое понимание такое, realtime означает что у системы есть гарантированное время обработки задач (реакции на события). bnk>Ни Windows, ни Linux этого не гарантирует (на прикладном уровне), т.к. система может заняться чем-то своим,
Вообще-то в винде предусмотрено 32 очереди и первые 16 — как раз для процессов реального времени
Которые имеют приоритет безусловно более высокий, чем вторые 16
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
bnk>>Мое понимание такое, realtime означает что у системы есть гарантированное время обработки задач (реакции на события). bnk>>Ни Windows, ни Linux этого не гарантирует (на прикладном уровне), т.к. система может заняться чем-то своим,
LVV>Вообще-то в винде предусмотрено 32 очереди и первые 16 — как раз для процессов реального времени LVV>Которые имеют приоритет безусловно более высокий, чем вторые 16
IMHO тут как бы речь о том что нельзя быть немножко беременным.
Либо система гарантирует что нечто выполнится в течение наперед заданного времени, либо нет.
LVV>>Вообще-то в винде предусмотрено 32 очереди и первые 16 — как раз для процессов реального времени LVV>>Которые имеют приоритет безусловно более высокий, чем вторые 16
bnk>IMHO тут речь бы речь о том что нельзя быть немножко беременным.
В данном случае — можно... bnk>Либо система гарантирует что нечто выполнится в течение наперед заданного времени, либо нет.
Просто есть разные классы систем реального времени.
Есть системы жесткого реально времени, а есть мягкого.
Основное различие систем жёсткого и мягкого реального времени можно охарактеризовать так:
система жёсткого реального времени никогда не опоздает с реакцией на событие,
система мягкого реального времени не должна опаздывать с реакцией на событие.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, syrompe, Вы писали:
S>Throttling — частота плавает.
отключается
S>Out of order, Branch Prediction тоже могут приводить к веселым последствиям.
просто рассчитывается исходя из худшего сценария.
S>Кэши всякие не дают гарантии по времени доступа к памяти.
То же самое (как с предыдущими пунктами, либо первое, либо второе).
Это я не к тому, что надо именно такие процессоры для всех задач реалтайм использовать, а к тому, что принципиальных проблем нет, если только в худшем сценарии удволетворяются требования к системе.
Здравствуйте, student__, Вы писали:
S>>Разве не от железа это зависит в первую очередь? Не всякое железо, цпц, для RT задач пригодно, если не ошибаюсь.
__>Из того, что в обычном компе какое не подходит и почему? Не вижу проблем каких-то. Понятно, что требования по абсолютным таймингам должны удовлетворяться, а в остальном?
Могу ошибаться, но, насколько я понимаю, в том же Intel поверх ОС есть некий management (Intel Management Engine, вот это вот всё). На него у ОС никакого влияния и доступа нет. При этом он, естественно, для своей работы может забирать процессор. Т.е. предсказуемости нет.
Ещё про DMA слышал много плохого в этом плане, типа может процессор забрать, невзирая на приоритеты.
Кому нужен реалтайм — нужно или использовать микроконтролер, превращающий реалтайм в нереалтайм дополнительно к основному процессору (это, кстати, многие ARM вендоры предоставляют — типа 4-ядерный Application Processor и там же одноядерный микроконтроллер). Или полноценную платформу с софтом (типа QNX) и проверенным железом.
Здравствуйте, vsb, Вы писали:
vsb>Могу ошибаться, но, насколько я понимаю, в том же Intel поверх ОС есть некий management (Intel Management Engine, вот это вот всё). На него у ОС никакого влияния и доступа нет. При этом он, естественно, для своей работы может забирать процессор. Т.е. предсказуемости нет.
Разве не отключается в BIOS?
UPD: в инетах пишут, что правительство США обязало Интел сделать МЕ отключаемым.
Здравствуйте, Sharov, Вы писали:
S>Разве не от железа это зависит в первую очередь? Не всякое железо, цпц, для RT задач пригодно, если не ошибаюсь.
Это определяется тем, где образуются узкие места. Если в железе и около него, то не подходит железо. Если железо всегда укладывается в самые худшие прогнозы, но система в целом в них укладывается не всегда, то проблема, скорее всего, в софте.
Здравствуйте, syrompe, Вы писали:
S>Out of order, Branch Prediction тоже могут приводить к веселым последствиям.
Такие вещи начинают играть заметную роль только вблизи предельного быстродействия аппаратуры. В том, что делается на типовых компьютерах, на это можно не обращать внимания — основные тормоза происходят намного выше.
S>Кэши всякие не дают гарантии по времени доступа к памяти. Помнится для винды был типа патч, который из нее делал типа риалтайм — он вроде как раз логику работы с кэшами правил.
Это сугубо о программных кэшах — страничных, дисковых, файловых и прочих.
Здравствуйте, student__, Вы писали:
S>>Разве не от железа это зависит в первую очередь? Не всякое железо, цпц, для RT задач пригодно, если не ошибаюсь. __>Из того, что в обычном компе какое не подходит и почему? Не вижу проблем каких-то. Понятно, что требования по абсолютным таймингам должны удовлетворяться, а в остальном?
А как гарантировать, что io диска всегда будет не больше чего-то там?
Здравствуйте, LaptevVV, Вы писали:
LVV> bnk>IMHO тут речь бы речь о том что нельзя быть немножко беременным. LVV> В данном случае — можно... LVV> bnk>Либо система гарантирует что нечто выполнится в течение наперед заданного времени, либо нет. LVV> Просто есть разные классы систем реального времени. LVV> Есть системы жесткого реально времени, а есть мягкого.
И дефолтная винда не относится, ни к тем, ни к другим. Читайте об этом у Соломона и Русиновича (Внутреннее устройство Windows 2000. глава 3. стр. 86), они прямо об этом говорят и объясняют почему.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Вы путаете ос реального времени и система реального времени. Общее в этих вещах — время отклика. Разница в том, кто дает эти гарантии.
Дело не в том, сколько процессов и кто чем занят, а какие шансы, что время отклика превысит ожидаемое.
Теоретически, систему реального времени с конским временем отклика, типа наблюдения за погодой, управление антеной тв, можно построить на обычной ос, отключив в ней все что можно.
А если требуемое время отклика это доли секунды, то нужна ОС рв, в противном случае вы никакие гарантии не получите.
Например, в винде Sleep в средем выполняется ровно столько, сколько вы запросили. Но под нагрузкой может увеличиваться в десятки раз. Мне удавалось добиться Sleep(1000) в 15 и более секунд.
В ОС рв приоритет потока, который выполняет Sleep становится максимальным к моменту завершения интервала, потому этот поток получит выполнение точно в срок. В винде — никаких гарантий нет.
Так же в винде время обычного системного вызова может быть сколь угодно большим. А в ОСРВ оно более-менее детериминировано.
Еще одна из проблем, которые решены в ОСРВ — инверсия приоритетов. Когда высокоприоритетный поток ждет ресурс который занят низкоприоритетным, а тот не выполняется, т.к. время занимает поток среднего приоритета.
В ОСРВ низкоприоритетный поток получит наивысший приоритет как только высокоприоритетный начнет ожидать ресурс.
Здравствуйте, Sharov, Вы писали:
S>Вроде одно из св-в и определений RT, это bounded io. Т.е. речь о любой периферии в том числе.
я могу загрузиться с перфокарт, и дальше начать работать, со всем I/O столько в сети.
Диск сам по себе не особо надёжен, так что его использование в ответственных применениях, когда нужна именно гарантия записи с дедлайном, так себе идея.
И потом, в системе реального времени не вся периферия обязана быть bounded. На НМЖД можно, например, сбрасывать логи, которые потерять не 100% критично, и которые будут писаться на фоне. Для SSD наверняка проще получить априори худшее время записи.
Здравствуйте, cppguard, Вы писали:
C>Думал, что, начав заниматься робототехникой, окончательно разберусь с этим термином. Пока что для меня real-time является синонимом "детерминистичности". Есть ли разница между "успеет выполнить задачу за N секунд" и пониятием real-time? Если взять Linux, без всяких RT-патчей и запустить на нём лишь один процесс, который в цикле без ветвлений что-нибудь считать, будет ли такая система real-time?
Если сможешь доказать, что прога + ос (т.е. все целиком) ВСЕГДА реагирует на внешние раздражители за некоторое наперед известное время, то система будет системой реального времени, отчего ж нет.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вообще-то в винде предусмотрено 32 очереди и первые 16 — как раз для процессов реального времени LVV>Которые имеют приоритет безусловно более высокий, чем вторые 16
Это имеется ввиду, "типа риалтайм".
В венде драйвера могут занять систему своим полезным делом в любой момент, когда захотят, и на произвольное время. Так что венда может очень постараться, но не может ничего гарантировать.
Здравствуйте, Sharov, Вы писали:
S>Разве не от железа это зависит в первую очередь? Не всякое железо, цпц, для RT задач пригодно, если не ошибаюсь.
Не очень понятно, что такого может быть упущено в железе, чтобы оно не годилось для RT. Но вот драйвера железа дейтвительно бывают разного качества. И иные будут серьезно мешаться риалтаймовости.
Здравствуйте, reversecode, Вы писали:
R>линукс никогда не был реалтаймом
Так потому и пример с линуксом. Куча роботов и станков работают на нём, приборные панели в автомобилях. При этом, насколько я знаю, даже RT-patch не превращает Linux в аналог QNX.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То есть, даже статей в википедии на эту тему Вы не читали? ЕМ>Если читали, то чего именно там не хватает для понимания?
Читал. Там классический трактат, который дают в универах: про soft- и hard- real-time, про абстрактное понятие "задачи", но ни слова про конкретные инструменты или примеры.
Здравствуйте, Pzz, Вы писали:
Pzz>Не очень понятно, что такого может быть упущено в железе, чтобы оно не годилось для RT. Но вот драйвера железа дейтвительно бывают разного качества. И иные будут серьезно мешаться риалтаймовости.
Я слышал про режимы работы цпу, мол защищенный режим не годится для rt.
Здравствуйте, Sharov, Вы писали:
Pzz>>Не очень понятно, что такого может быть упущено в железе, чтобы оно не годилось для RT. Но вот драйвера железа дейтвительно бывают разного качества. И иные будут серьезно мешаться риалтаймовости.
S>Я слышал про режимы работы цпу, мол защищенный режим не годится для rt.
Здравствуйте, cppguard, Вы писали:
C>Читал. Там классический трактат, который дают в универах: про soft- и hard- real-time, про абстрактное понятие "задачи", но ни слова про конкретные инструменты или примеры.
Вот пример:
while (true)
{
t1 = read_input(x)
adjust_read_time(t1)
y = f(x)
t2 = write_output(y)
adjust_write_time(t2)
}
Здравствуйте, 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.
Здравствуйте, 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>Может есть алгоритмы? Или методы верификаии?". И правильный ответ — да, методы есть, их много, они разные. И про них никто тебе не расскажет, нужно самому копать.
А что про них рассказывать-то в общем случае? Это как про таблицу умножения монографию писать. Оно ж и так понятно: нужно убедиться, что по всем путям выполнения сумма всех возможных задержек не превышает некоторых разумных величин, определяемых или интуитивно, или статистически. Если делается программа для голого процессора — учитываем его внутренние задержки и задержки самой программы. Если используются внешние устройства — добавляем задержки шин и устройств. Используется ОС — добавляем задержки ядра, драйверов и приоритетных служб. Используются библиотеки — добавляем их задержки.
А о том, как устранить лишние задержки в тех или иных устройствах и системах, написано до хренища. Просто оно не стоит на одной полке.
