Есть такая штука, как планировщик. Это если брать многозадачные ОС.

Так вот сроки выполнения зависят во многом ещё и от планировщика. И обычно realtime (soft|hard) называют такие системы, у которых планировщик позволяет выполнить задачу в предсказуемые сроки (+-) при прочих равных. Не поверишь, но есть системы, у которых планировщик не позволяет предсказать срок выполнения даже если известно, что железо всё успеет.

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

(Reply to this) (Thread)

По опыту, в WinNT 5 минимальный квант при переключении порцессов что-то около 40мс. Но это неустойчиво и не всегда срабатывает.

(Reply to this) (Parent)

Не поверишь, но есть системы, у которых планировщик не позволяет предсказать срок выполнения даже если известно, что железо всё успеет.

Не поверю. Даже не имея ровным счетом никаких представлений ни об этих системах, ни о компьютерах вообще, я совершенно точно могу предсказать, что если задаче не будет выполнена в течении ближайших четырех миллиардов лет, она не будет выполнена никогда. И что?

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

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

(Reply to this) (Parent) (Thread)

возьмём винду и следующую задачу:
сделать программу-ЦАП на писюке.
ЦАП характеризуется своей частотой.

так вот, сделать ЦАП хотя б 1 кГц
под ней невозможно - нестабильность.
и даже 25 Гц (исходя из 20 мс кванта)
невозможно - кванты не выделяются
стабильно, т.е. даже при условии
выставленного высокого приоритета,
на (много) более, чем 20 мс винда будет
(иногда) переключаться куда-то "туда".

(Reply to this) (Parent) (Thread)

А это ничего, что ЦАП с частотой до 44КГц имеются в любом компьютерном магазине в ассортименте и стоят от $10 - для тех кому недостаточно встроенного в материнскую плату?

И предназначены они, как не трудно понять, в первую очередь как раз для пользователей винды.

(Reply to this) (Parent) (Thread)

для этих ЦАП и драйвер нужен соответствующий.
а без драйвера/кэширования на каком-то уровне
или, скажем, DMA, не получится никакого ЦАП.
винду с помощью хака можно превратить в RTOS.

(Reply to this) (Parent) (Thread)

Скажем DMA есть, как раз, железо а не OS.

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

(Reply to this) (Parent) (Thread)

не понимаю твоего непонимания.
думая о RTOS, в частном случае,
представляю взлёт\посадку шатла.
винда не даст гарантированных
задержек при обработке ситуации,
и поэтому она неприменима там.

ЦАП - реальный пример, сам делал,
но RTOS сам не применял никогда,
поэтому будем считать, я не смог
объяснить, может кто другой смогёт

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

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

в случае ЦАП на осциллографе это будет
выглядеть как спорадические подвисания
потенциала на одном (предыдущем) уровне.

(Reply to this) (Parent)

порядков так на 5 более сложное?

В старые времена этот термин имел больше смысла поскольку hw было куда как медленнее и были вопросы жестких временных параметров обработки событий.

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

И граница безусловно стирается но все еще существует.

(Reply to this) (Parent)

ЦАП - это лишь пример того что можно сделать на RTOS, и что нельзя сделать на не-RTOS.

(Reply to this) (Parent) (Thread)

Ну так плохой пример.

(Reply to this) (Parent)

С другой стороны несомненно что RTOS - это маркетинговый термин, и когда-нибудь компьютеры "вырастут" и все ОС будут, по современным меркам, RTOS :)

(Reply to this) (Parent) (Thread)

Я полагаю, что это "когда-нибудь" произошло лет 30 назад, когда была выпущена последняя система пакетной обработки. С тех пор брэнд раскручивается вхолостую.

(Reply to this) (Parent)

(Reply to this) (Thread)

О существовании термина я, как бы, в курсе. Я _смысла_ в нем не нахожу.

(Reply to this) (Parent) (Thread)

ну, фиксированные задержки ("не более, чем")
при обработке определённых событий - вот
вроде и всё определение, и смысл вроде есть.

(Reply to this) (Parent) (Thread)

(Reply to this) (Parent)

Смысл в нем вполне конкретный - ОС, в которой возможны точные оценки сверх времен операций. Скажем в RSX-11M формальным требованием к драйверам устройств было открытие прерываний не более, чем через 200mks.

(Reply to this) (Thread)

Я не наблюдаю, каким образом возможность делать оценки зависит от архитектуры системы.

(Reply to this) (Parent) (Thread)

Наличие разумных оценок (200mks от 2 cекунд отличаются именно разумностью оценки) позволяет планировать нагрузки. Если говорить проще - то в RT OS для проигрывания cd будет достаточно 1-скоростного проигрывателя и относительно маломощного проца. Винда переставала запинаться на 8-скоростном.

(Reply to this) (Parent) (Thread)

В свое время у меня не было ровным счетом никаких проблем с просмотром CD на односкоростном сидюке на тогдашней винде (3.11, кажется). При условии, разумеется, что bitrate был меньше 150 кб/сек а процессор в принципе тянул используемый кодек.

Если система не способна отдать все ресурсы компутера единственной запущенной программе - так это грубый баг в дизайне независимо от "реалтаймовости".

(Reply to this) (Parent) (Thread)

Если что-то делать она запиналась при явной достаточности ресурсов. Собственно нынешняя винда грешит тем же самым - если процессор загрузить на 100%, то даже нересурсоемкие интерактивные приложения начинают заметно подтормаживать.

Вот примерно в этом смысл RTOS

(Reply to this) (Parent) (Thread)

PS: Проще говоря - стандартная довольно ситуация - датчик генерирует сигнал 200,000 раз в секунду. Если не успеть обработать очередное прерывание - следущий отсчет потрет предыдущий. Мощности на обработку хватает - но задача - суметь обрабатывать сигналы без потерь.

(Reply to this) (Parent)

ОС с гарантированным (и известным) ограничением сверху на время обработки прерывания в ядре.

(Reply to this) (Thread)

"Настоящую гарантию вам может дать только страховой полис". О гарантиях какого рода идет речь?

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Вот допустим у компутера выдернули шнур питания. Следует ли понимать твои слова таким образом, что под обычной ОС компьютер просто выключится, а под Realtime OS он сначала начнет обрабатывать событие и только потом выключится?

(Reply to this) (Parent)

Насколько "несколько передвинуть" и есть основное различие.

OS может просто не позволять делать действия, время выполнения которых сверху не ограничено. Например, может отсутствовать виртуальная память.

И там по мелочи.

(Reply to this) (Thread)

Кастрировать ОС, как правило, особого ума не надо. Но ведь "Realtime" позиционируется не как уродство, а как важная специфика и даже преимущество?

(Reply to this) (Parent) (Thread)

Да, это важная специфика и преимущество там, где это необходимо. В своей нише.

"Кастрировать ОС много ума не надо" - ну, как. Вот Windows CE/Mobile написана заново, MacOS для iPod тоже урезали не один год.

(Reply to this) (Parent)

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

Также и с real-time'ом. Понятно, что если операционка позволяет процессу полностью захватить ресурсы, то в ней можно самому написать любую real-time'овость.

Но real-time'овые системы (или расширения систем, была такая real-time'овая нашлёпка на Дебиан) предоставляют сервис, с помощью которого на том же оборудовании реализовывать задачи по управлению физическими процессами несколько удобнее. Более того, у таких систем могут быть свои требования к оборудованию — отличные от, скажем, мультимедийных домашних систем.

Но по сути это обычное деление рынка, отсюда и огромное гудение маркетологов.

(Reply to this)

Определение: операционной системой реального времени называется такая система в которой переключение задач происходит за предсказуемое время.

(Reply to this) (Thread)

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

(Reply to this) (Parent) (Thread)

Всё с точностью до наоборот: rt планирование времени означает, что *любой rt процесс* получит гарантированное число квантов за цикл. В результате все процессы независимо от приоритета (в том числе по возможности модули ядра!) отработав свои кванты освобождает процессор.

(Reply to this) (Parent) (Thread)

Вы заблуждаетесь.

(Reply to this) (Parent) (Thread)

o'k. Не менее, чем гарантированное.

Ещё раз: нет никакого "специально дрессированного процесса с наивысшим приоритетом". По крайней мере уже лет тридцатьпять как нет - как только в rt системах разделение времени появилось. Уже на таких распостранённых в совке управлялках как клоны hp1000 кванты очень даже жёстко делились. АСПО до сих пор на заводах работает ;-)

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

Можно ограничиться ссылками на цитируемое Вами определение ;-)

Я нигде не указывал, что одна задача что-то будет получать "за счёт" другой. Она получит *свои* кванты. А чужие - на основе добровольности (свободные остались).

Более того, далеко не во всех rt системах используется само понятие приоритетов. Например есть системы на основе циклограмм. Но даже если приоритеты есть, то *самая высокоуровневая* задача (в том числе ядро) отработав свои кванты времени, идёт отдыхать. Потому как мы гарантируем реальное время *всем* rt задачам.

(Reply to this) (Parent) (Thread)

Вы путаете понятия "ОС реального времени" и "ОС разделения времени"
Кванты процессора выделяются всем процессам в последней; в ОС реального времени задача с высоким уровнем приоритетов не отдает процессор никому, в отличие от ОС разделения времени, где приоритетов может и не быть.

Именно такое устройство ОС и позволяет гарантировать время выполнения критических задач.

(Reply to this) (Parent) (Thread)

Вы путаете однозадачную os rt и многозадачную.

Однозадачные os rt имели смысл во времена dec rt11fb. Даже простенькая turbo task времён z80 умела round-robin. В современных osrt (например CMX-RTS ) priority arbiter раздаёт io, а вот task switching всего rt на round robin'е. Собственно для 1750A что в idris'е, что в mate насколько я помню тоже robin (не помню у кого именно он с микроциклами). Так что отдаст и уступит. Я разве что на творчестве Юлия Шварца не смотрел, уж очень паскалеобразы не любю ;-)

(Reply to this) (Parent) (Thread)

( Устало ) В последний раз объясняю: свойством, отличающим ОС реального времени от иных ОС, являетсе следующее: задача более высокого приоритета никогда не уступает задаче более низкого. Вот выполнение задач одинакового приоритета действительно может быть организовано на основе round-robbin, а может и не быть.

(Reply to this) (Parent)

Предсказания - это, однако, из области астрологии.

(Reply to this) (Parent) (Thread)

Я оценил Ваш юмор.
Мне дальше рассказывать или Вы и так все знаете?

(Reply to this) (Parent) (Thread)

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

И еще. Я ведь просил про (возможный) _технический_ смысл термина. Слова "гарантия", "уверенность", "предсказание" - это все не технические термины, они указывают на отношения между людьми.

(Reply to this) (Parent) (Thread)

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

Предположим, у нас есть цикл суммирования элементов массива.

int i;
int sum=0;

for (i=0;i<1000;i++) {
   sum = data[i];
}

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

Далее, если мы пишем программное обеспечение для задачи в которой нам надо гарантировать время выполнения определенного фрагмента кода, нам требуется следующее:
1. Планировщик задач который не будет передавать управление другим, менее важным задачам, пока выполняется наш код.
2. Планировщик задач который гарантирует нам фиксированное время переключения задачи, не зависящее от состояния виртуальной памяти и иных параметров ядра.

Вот это и есть технические свойства ОС реального времени, отличающиее ее от ОС иных архитектур.

(Reply to this) (Parent) (Thread)

q>Предположим,</q>

Ну и какое отношение этот абстрактый пример имеет к решению реальных задач на реальных железных компьютерах?

Планировщик задач который гарантирует нам

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

На практике, полагаю, вся гарантия сводится к традиционному "Мамой клянус!!".

(Reply to this) (Parent) (Thread)

Этот упрощенный пример бы попыткой объяснить Вам смысл слов "предказание" и "фарантия" в данном контексте. Из этого примера видно что мы в сосотянии предсказать гарантированное время выполнения фрагмента кода, и что в данном контексте нас интересует не среднее и не медианное, а максимальное время выполнения кода.
Планировщик не может ничего гарантировать.
Возьмем для примера тот же самый фрагмент кода. Предположим, на данном процессоре максимальное время его выполнения X микросекунд. Можем ли мы, выполнея этот кода в рамках пользовательского процесса в обыхной системе разделелния времени вроде Линукса или Виндоуз, быть уверены в том что его выполнение займет не больше X секунд? Нет, не может, поскольку ядро устроено так что в процессе выполнения ядро отдать процессор другому процессу или заняться упорядочиванием своих внчутренних структур.
Поэтому про системы разделения времени говорят что они не гарантируют времени выполнения кода, в отличие от ОС реального времени.
Тесхническим могн бы быть способ , которым они это гарантируют.
Да, разумеется. И эти способы включают в себя свойства планировщика задач , механизма управления памятью, синхронизации и т.п.
На практике, полагаю, вся гарантия сводится к традиционному "Мамой клянус!!".
Если Вас интересует ознакомление с новыми и неизвестными Вам понятиями, возможно, наша беседа была бы более содержательна если бы Вы несколько изменили свой тон. В незнании каких-то вещей нет ничего страшного.

(Reply to this) (Parent)

Попробую я объяснить. Вот работает пивоваренный завод, сейчас они почти полностью автоматизированые. Предположим, что автомат который разливает у нас пиво в бутылки управляется обычным компьютером (для удешевления и унификации). Когда бутылка подъехала к крану надо открыть кран на 200 милисекунд и закрыть. Но открыв кран винда обнаруживает, что пришло обновление, и начинает рисовать окошко с сообщением. Как известно графика в винде в нулевом ринге поэтому остальные задачи ждут. Окошко сложное и рисуется 1 секунду. 4 бутылки льются на конвеер. Realtime OS - спроектирована таким образом, чтобы время когда управление передаётся процессу было гарантированным, не маленьким (оно и больше может быть чем иногда в винде) но гарантированным, что позволяет использовать компьютер в промышленном оборудовании, или там в автомобилях/авиации. Realtime OS не нужна на домашнем компе, да и на сервере я не могу придумать зачем бы она пригодилась. Это довольно нишевое решение, но необходимое. Производительность у Realtime OS кстати ниже чем у обычной при прочих равных. На гарантирование задержек тоже тратятся ресурсы.

(Reply to this) (Thread)

И откуда бы, по вашему, на технологическом контроллере появился бы интернет, необходимый для скачивания сих обновлений?

(Reply to this) (Parent) (Thread)

у меня вот как-то "рулилка технологическим оборудорудованием" (несколько ЦАП'ов и шаговых двигателей) одновременно была рабочей машиной :) Интернета, правда не было, но по другой причине.

конечно, можно сказать что это от бедности.

(Reply to this) (Parent)

Да просто какая-нибудь кроновская задача. Любая. Или даже нужная именно для этого технологчсекого процесса - сбор статистики, например.

(Reply to this) (Parent)

Ну можно кастрировать ОС, а можно кастрировать окружение. На мой взгляд, требование отрезать интернет и требование отрезать виртуальную память абсолютно равнозначны.

Можно себе представить задачу, в которой сочетание гарантированного времени отработки от железяк с интернетом будет необходимо. Например система собирающая информацию с метеорологических датчиков. И через интернет отправляющая их в центр обработки. Почему не по выделенному каналу? А потому что у нас денег хватит только на десять выделенных каналов, но на тысячу метеостаций, подключенных к интернет.

(Reply to this) (Parent)

Гарантировано максимальное время выполнения процесса. Не важно, насколько оно велико. Главное - оно заранее известно и его можно точно ограничить (если нет аппаратных сбоев).

Пример: имеется шаровая мельница. Она вращается медленно, но неотвратимо. Раз в оборот выполняется взвешивание поступающего материала и проверяется на переполнение. Переполнять нельзя. Неважно что какое-нибудь глюкалово может обработать данные с датчиков за 1 микросекунду. Важно, чтобы оно *всегда* тратило меньше 1 секунды.

Понятно?

(Reply to this) (Thread)

А почему бы например оно стало тратить больше одной секунды?

Это не риторический вопрос.

(Reply to this) (Parent) (Thread)

Например потому, что ядро читает с диска большой файл по запросу другого процесса.

Вообще, характерные фичи современной РТОС таковы:
1. Класс планирования реального времени с приоритетами выше чем у ядра.
2. Средства предотвращения инверсии приоритета при исполнении системных вызовов такими процессами (в первую очередь асинхронный ввод/вывод).
3. Отсутствие диспетчера памяти или возможность выключать своп (лочить в ОЗУ) отдельные регионы адресного пространства задач.
4. Нано- или микросекундные таймеры.

(Reply to this) (Parent) (Thread)

Например потому, что ядро читает с диска большой файл по запросу другого процесса.

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

(Reply to this) (Parent) (Thread)

Ну так системе же ведь и этот файл нужно дочитать "за гарантированное максимальное время", не так ли?
Не обязательно. И даже, скорее всего, нет. Для разных операций гарантированное максимальное время различно, и для чтения файла оно не может быть таким же, как для чтения значения из датчика.

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

(Reply to this) (Parent)

Система занялась чем-то необычайно важным. Например решила почистить диски, спросить о к-л смысле жизни, кто-то заштормил на сетевом интерфейсе, пришёл update из-за которого почесалось перегрузиться, драйвер fs увидел странность и решил откинуть копыта. Мало ли чего может произойти. Так вот мельница продолжает вращаться. Если её разнесёт, то весь коллектив разработчиков п/о будет привезён на комбинат и будет похоронен в назидание потомкам ;-)

(Reply to this) (Parent)

man sched_setscheduler

грубо говоря, на обычной оси можно нагрузить задачами, и они не позволят выполниться Главной Задаче. А с rt шедулированием планировщик всех распихает, но таки даст ей время.

Ну и на писюковом желези практически любой IO несовместим с realtime. По крайней мере, диск и ethernet сетка.

(Reply to this)

(Reply to this)

В управлении ядерным реактором, станком с ЧПУ и пр. не позволительно "слегка передвинуть границы". Время реакции должно быть гарантировано, "либеральный" планировщик общего назначения этого не даёт.

(Reply to this)

1. Скорость против надёжности.

Хороший пример — алгоритм quicksort, которым все пользуются, потому что он простой и в большинстве случаев хорошо работает; он имеет неприятный worst case в n² операций, на который, однако, тяжело попасть. И есть какая-нибудь кучевая сортировка, которая в среднем в разы медленнее, но сбалансированно даёт n log n. Возникает дилемма, что выбрать. В первом случае получаем классический подход, во втором — real-time.

Таких примеров полно: хеш таблицы против сбалансированных деревьев, Ethernet против Token Ring, стандартное динамическое выделение памяти не имеет хорошей оценки сверху, даже если известно, что памяти хватит. В real-time системе все критические модули так оцениваются. И поэтому real-time системы всегда медленнее классических.

2. Банальный инструментарий.

Скажем, в винде нельзя реализовать real-time приложение, поскольку она в любой момент может отсвопить непонравившийся ей процесс, и никакого контроля над этим нет. Да, в шаттле пасьянса не будет, и она не должна ничего отсвопить. Но это не доказуемо. Никто, грубо говоря, не знает, что там есть, в любой момент этот пасьянс могут запустить. Должно быть чёткое разделение на критические компоненты и не критические. Должен быть способ заблокировать VM. Должны быть чётко заданные приоритеты.

Тогда, имея известный набор программ и зная характеристики железа, можно оценить время отклика.

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

(Reply to this)

Фёдор, это затравка на пофлеймить, что ли?
Я тебе даже скажу больше -- есть такие ОС, для которых формально доказывается факт, например, возврата из ядра за ограниченное сверху время. Кропотливым анализом каждого используемого алгоритма.

(Reply to this) (Thread)

Это я проверяю, найдется на мои слова убедительное возражение или нет. Пока не нашел.
есть такие ОС, для которых формально доказывается факт, например, возврата из ядра за ограниченное сверху время.

Извини, не поверю. Очевидный контрпример - если я выполняю ядро под [хардверным] отладчиком, я всегда могу поставить брекпойнт на команде возврата, и задержать исполнение на любое заданое время :-) Это пример самый очевидный, но отнюдь не единственный.

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

В достаточно отвлеченной от реальности математической модели несложно доказать все что нужно.

(Reply to this) (Parent) (Thread)

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

А что, бывает как-то иначе?

Да, анализ алгоритмов всегда происходит в рамках абстрактной модели. И эта модель обычно не предполагает, что компьютер сгорит, а программиста ударят по голове молотком.

Зато в ней сделаны предположения о скорости процессора, размере памяти, количестве задач, объёме данных и т.п. И исходя из этих данных, можно оценить время отклика, как для RT-системы, так и для обычной.

(Reply to this) (Parent)