Что такое «мягкое» реальное время?

https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_comp...

Очень много непонятных слов.

Тем, что GC, который убил Томми.

Можно просто примеры привести? Без глубокого вникания в вопрос.

Очень много непонятных слов.

Тогда тебе рано еще на такие темы думать, и тем более спорить.

Попробуй хотя бы реализовать виртуалку BytePusher. Когда получится реализовать её правильно, поймёшь, что такое жёсткое реальное время.

1. IOT не обязательно требует RT
2. в микроконтроллерах используется не рефересный тормознутый CPython, а micropython

«MicroPython поддерживает синтаксис Python 3, а большинство

скриптов занимают гораздо меньше ОЗУ и выполняются заметно быстрее, по сравнению с CPython.»

А зачем использовать CPyton?

https://www.edn.com/electronics-blogs/embedded-basics/4440447/Using-MicroPyth...

Для детсада: жесткое реальное время гарантирует реакцию системы за жестко заданный интервал времени. Мягкое - за мягко заданный. Причем к скорости и быстродействию это всё не имеет никакого отношения.

Спрошу иначе. Управление видеокартой это какое реальное время?

Все участники спора, в котором одновременно присутствуют питон и хоть какое-то реальное время - сказочные долбоебы.

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

Просто сложился стереотип, что системы реального времени это что-то сверхбыстрое. Но это не всегда так.

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

Определяется масштабом? 10 миллисекунд - жесткое время, а 100 мягкое?

Управление видеокартой - это неопределенная форма, инфинитив.

Нет, хоть час. Главное чтоб фиксированное было.

Вопрос возник в рамках одного спора, где на мои рассуждения о тормозах в питоне предъявили, что его используют в программах для интернет-вещей.

Отличный агрумент. Еще бы предъявили, что «питон используют, а значит он не тормозит» - вообще было бы огонь.

А тем временем тот же ютьюб на питоне не может достаточно быстро опубликовать коммент, и вместо этого тебе единственному его показывает энное кол-во минут. Шел 2019 год. Вообще, с таким же успехом можно писать комменты себе в блокнот (что я и делаю) - у меня пока что не возникало ощущения, что мои комменты на ютьюбе кто-то читает.

Hard – missing a deadline is a total system failure.
Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

Показывай какое слово не понятно.

Тогда непонятно. Получается что если последствия смертельны, например остановилось сердце, как в случае с прибором, то жесткое? А если никто не умер от перегрева, то мягкое?

Система реального времени это система,которая работает в рамках времени того процесса которым управляет.

Ух, жжошь. QNX - система реального времени. В рамках какого процесса она работает?

на Питоне вполне можно будет построить систему реального жесткого времени

А я и не говорил, что это невозможно. Я говорил, что это сразу выдает СД.

Просто сложился стереотип, что системы реального времени это что-то сверхбыстрое. Но это не всегда так.

СРВ при прочих равных всегда медленнее чем обычная. Просто потому, что к ней предъявляется больше требований.

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

Аааааа, держите меня!!!11

Все правильно он написал. Как я это понимаю: жесткое - система не среагировала в течении дедлайна, это катастрофа и поезд сошел с рельсов, мягкое - не среагировала и фиг с ней, ничего страшного, как-нибудь в следующий раз.

Жёсткое реальное время это когда нужно получить отклик только в заданном интервале времени, и точка, иначе будет фатальная ошибка или даже отказ системы.

Мягкое реальное время это когда интервал отклика соблюдается не абсолютно всегда, а в среднем.

Определяется масштабом? 10 миллисекунд - жесткое время, а 100 мягкое? Масштаб не суть, важно лишь соблюдение политик.

Понятный пример жесткого реального времени = управление подушкой безопасности в автомобиле (нужно не раньше и не позже, а вовремя).

IoT к реальному времени отношения примерно не имеет, ибо подразумевается беспроводная сеть с неизбежными ошибками и повторами. Поэтому разве что совсем soft в каких-то отдельных случаях.

Python, Java, C# и т.п. не подходят для задач реального времени, ибо сборка мусора и прочие «радости слабых» исключающие детерминированное поведение. Т.е. их можно использовать в сопутствующих задачах, но не в самом пути выполнения realtime.

При этом есть масса народа упрямо сующего пальцы в розетки, причем с умным видом.

Размер интервала времени отклика никак не связан с типом реалтайма. У жёсткого реалтайма интервал может быть равен секунде, а у мягкого - 10 мс, например.

емнип, micropython не полностью совместим с CPython и имеет меньше пакетов в базовой установке

Значит получается, если питон успевает среагировать за 1 секунду, то это жесткое время.

Не получается

Все правильно он написал.

Ну и отлично. Теперь ты тоже можешь объяснять всем, что такое системы реального времени. Поздравляю.

Почему? Что ему помешает?

Предположим, что система в среднем выполняет запрос за 900 милисекунд. Вроде как укладывается в Realtime, но гарантировать, что внезапно не появится 150 лишних милисекунд на сборку мусора - не может.

Поэтому программа не может гарантировать hard realtime.

С другой стороны сишка - выделил буфер и переиспользуешь его сколько угодно раз. Вероятность того, что появится деградация скорости обращения к памяти в системе реального времени - мала и является ошибкой.

С другой стороны сишка - выделил буфер и переиспользуешь его сколько угодно раз. Вероятность того, что появится деградация скорости обращения к памяти в системе реального времени - мала и является ошибкой.

А в этот момент из-за перегрева материнка тормознула процессор... Большинство современных систем аппаратно не могут быть жёсткого реального времени.

, мягкое - не среагировала и фиг с ней, ничего страшного, как->нибудь в следующий раз.

Это типа получается... на время насрать, не среагировал и шут с ним? В этом случае ни о какой системе RT речь не идёт.:-)

Я бы не сел в аппарат ОС которого писали на питоне.

Например надо следить за пульсом пациента. Он быстро не меняется, скажем система должна успеть среагировать за 300 секунд. Опрашиваем его каждую секунду - это дедлайн. И какая разница сколько будет отсчетов 300 или 200? Система все равно среагирует правильно. Вот так я понимаю мягкое время.

То есть, при остановке сердца аппарат может тупить 5 минут, прежде чем начать принимать меры? Это правильно. Примерно так я и представляю систему, спректированную экспертами по всему.

Например надо следить за пульсом пациента. Он быстро не меняется, скажем система должна успеть среагировать за 300 секунд. Опрашиваем его каждую секунду - это дедлайн. И какая разница сколько будет отсчетов 300 или 200? Система все равно среагирует правильно. Вот так я понимаю мягкое время.

Нет. Жётское время — система должна успеть среагировать за 300 секунд. Если не успеет, то поциент подохнет. Подыхание неприемлемо — надо успеть.

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

«Реальное время» это баззворд чтобы продукт продать подороже.

Ух, жжошь. QNX - система реального времени. В рамках какого процесса она работает?

Ты резко сузил вопрос. Автор спросил разницу между жестким и мягким временем, а ты приводишь в пример ОС реального времени. Чувствуешь разницу? Ты мешаешь близкие, но разные понятия. Хочешь показаться умнее чем ты есть?

А работает она в масштабе времени того процесса которым управляет. Или ты реально думаешь, что поставил QNX и у тебя уже готова АСУ ТП? Там кроме ОС еще много чего нужно. Так что подумай, прежде чем писать.

А я и не говорил, что это невозможно. Я говорил, что это сразу выдает СД.

Ну так если это возможно (и эта система будет отвечать заданным требованиям), то почему они сказочные долбоебы, а не ты?

СРВ при прочих равных всегда медленнее чем обычная. Просто потому, что к ней предъявляется больше требований.

Соглашусь. Но при чем здесь это?

Аааааа, держите меня!!!11

Держите долбоеба! (Прости, вырвалось)

Хотя ты прав в том, что количество СРВ, которые имеет смысл писать на Питоне, катастрофически мало. Я больше отреагировал на твой радикализм про сказочных долбоебов.

Я бы мягкое охарактеризовал так - продукт работает и приносит прибыль, если мы укладываемся в обработку события в 100 мкс. Мы реально укладываемся в эти 100 мкс, всегда. Все, считаем что система жесткого времени. Затем пришли умники, разработали новую стратегию в рамках которой если мы будет завершать обработку в 70 мкс, то прибыль будет на 25% больше, но мы в 70 мкс укладываемся только в 83% случаев. Поэтому с точки зрения новых умников у нас уже система мягкого времени.

В общем получается это во многом игра слов. Без дополнительной информации фраза «реальное время» довольно туманна.

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

Понятный пример жесткого реального времени = управление подушкой безопасности в автомобиле (нужно не раньше и не позже, а вовремя).

Ещё один пример реального времени - управление форточками в теплице. Днём, когда очень много солнца - проветриваем, иначе растения перегреются и помрут. Дело к вечеру - форточки закрываем, иначе растения переохладятся и толку от теплицы будет мало.

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

ибо сборка мусора и прочие «радости слабых» исключающие детерминированное поведение

как уже достали эти мифы. Насколько детерминированным будет в С++ освобождение дерева? Вот вышел у нас из скоупа shared_ptr на корень дерева. Какие гарантии нам дает С++, что время освобождения, скажем, не превысит N микросекунд? Радость сильных, блин. shared_ptr в С++ это тоже автоматическая сборка мусора и она имеет все те же недостатки что и трассирующий сборщик мусора плюс свои особенности. Не нужно рассказывать сказки. Ничто не мешает выделить всю необходимую память перед началом работы и потом вообще ее не выделять и сборщик даже не запустится (хотя это от языка конечно зависит)

Маняоправдания любителя опаздывать

Полностью поддерживаю этого господина. Управлять форточками в теплице вполне можно на Питоне. И это будет система реального времени.

в системе реального времени Понятное дело, что не на домашней машинке и даже не на сервере.

Причем к скорости и быстродействию это всё не имеет никакого отношения.

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

Насколько детерминированным будет в С++ освобождение дерева?

Разве при этом блокируются все потоки, как в питоне?

Значит получается, если питон успевает среагировать за 1 секунду, то это жесткое время.

Нет, если операция гарантированно в 100% случаев занимает ровно 1секунду это хард рилтайм, если хоть один вылет - это фатальный сбой системы.

Если операция гарантированно в n% случаев занимает ровно 1секунду, где n => 100% и зависит от требований, это мягкий рилтайм.

Под операцией может пониматься как шаг алгоритма, так и обработка какого-то внешнего события. Что по сути одно и то же если копнуть глубже.

Фокус в том, что это не больше и не меньше, это ровно столько сколько нужно с заданным распределением вероятности вылета.

Т.е. 0.999999s это вылет, 1.000001s это вылет(погрешность разумеется выбирается исходя из требований).

Например: ты не смог ввести стержень с заданной скоростью(не быстрее и не медленнее) на атомной электростанции - станция взорвалась, это hard. Пользователь обогнал других участников торгов биржи из-за того, что его система работает быстрее, произошёл вылет и пакет тоже прилетел быстрее - это soft(при определённом превышении количества вылетов в единицу времени в любую сторону биржа получит счёт за упущенную прибыль от других участников рынка). В большинстве случаев на практике всё и правда выливается в то, что ты вписываешься в deadline, остаток слота - очень точно спишь, потом производишь i/o за детерминированное время которое гарантирует уже железка(если речь идёт о ПО).

Реальное время не допускает таких состояний как зависание, притормаживание и прочее если сказано что начать выполнять **эту ** задачу прямо сейчас значит она будет выполняться сразу как только это станет физически возможным, то есть задержка выполнения только та что требуется на сами действия для выполнения. И всё пока задача выполняется ничто не должно иметь право явно или косвенно приостанавливать сам процесс выполнения задачи. Мягкое реальное время это всё тоже самое, но допускается к примеру пролаг (в том или ином виде).

Всё это обеспечивает ОС и в принципе может ли она это обеспечивать, одни задачи может в жёсткий реалтайм, другие нет и это уже нет.Вот и всё.

Короче первое это гарантия, второе возможность. Типа, я могу и буду vs Я могу, но ничё не обещаю =)

Насколько детерминированным будет в С++ освобождение дерева? Вот вышел у нас из скоупа shared_ptr на корень дерева. Какие гарантии нам дает С++, что время освобождения, скажем, не превысит N микросекунд?

Если сделать допущение, что каждая операция в алгоритме выполняется константное время и сделать переход «реальное время» -> «шаг алгоритма», то задача сводится к исследованию сложности алгоритма. Так как константа N - это О(1), то алгоритмы реального времени - это алгоритмы со сложностью O(1). То есть алгоритмы независящие от количества обрабатываемых элементов.

Например, алгоритмы поиска не для систем реального времени.

Хеш-таблица с средним временем доступа О(1) подходит для систем (мягкого) реального времени.