Здравствуйте, 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)
}
