1) почему микроядро — это хорошо ?
2) почему микроядро не медленнее традиционных ядер ?
3) каким (эффективным) образом реализуется механизм доставки сообщений серверам ?
4) есть ли реализации микроядра второго поколения (микромикроядра) ?
А кто сказал, что микроядро, это есть хорошо? Я не вижу смысл создавать систему с микроядром. Многие утверждают, что если система основана на микроядре, она более устойчива. Я не вижу в этом смысла. Да, система иожета завершить процесс вызвавший фатальную ошибку без "синих экранов". Но будет ли система без жизненно важного процесса нормально (в полном смысле этого слова) продолжать функционировать? Да, возможно разработка компонентов ядра станет задачей полее просто, но стоит ли игра свеч?
DAS>Пара вопросов по архитектуре микроядра.
DAS>1) почему микроядро — это хорошо ? DAS>2) почему микроядро не медленнее традиционных ядер ? DAS>3) каким (эффективным) образом реализуется механизм доставки сообщений серверам ? DAS>4) есть ли реализации микроядра второго поколения (микромикроядра) ?
Здравствуйте, htfv, Вы писали:
H>А кто сказал, что микроядро, это есть хорошо? Я не вижу смысл создавать систему с микроядром. Многие утверждают, что если система основана на микроядре, она более устойчива. Я не вижу в этом смысла. Да, система иожета завершить процесс вызвавший фатальную ошибку без "синих экранов". Но будет ли система без жизненно важного процесса нормально (в полном смысле этого слова) продолжать функционировать? Да, возможно разработка компонентов ядра станет задачей полее просто, но стоит ли игра свеч?
Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, htfv, Вы писали:
H>>А кто сказал, что микроядро, это есть хорошо? Я не вижу смысл создавать систему с микроядром. Многие утверждают, что если система основана на микроядре, она более устойчива. Я не вижу в этом смысла. Да, система иожета завершить процесс вызвавший фатальную ошибку без "синих экранов". Но будет ли система без жизненно важного процесса нормально (в полном смысле этого слова) продолжать функционировать? Да, возможно разработка компонентов ядра станет задачей полее просто, но стоит ли игра свеч?
VD>Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
Гы!
В классической системе на основе микроядра основные компоненты операционной системы (диспетчеры памяти, процессов, ввода-вывода) выполняются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами микроядра.
Теперь рассмотрим следующую ситуацию. Допустим, в коде файловой системы (или, например, в диспетчере памяти) имеется ошибка, которая время от времени приводит к краху системы. В истинной ОС на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому теоретически ошибка приведет лишь к завершению процесса соответствующего компонента. Но на практике такая ошибка все равно вызовет крах системы, так как восстановление после сбоя столь критически важного процесса невозможно.
Вот, что я пытался сказать. Только уже поздно было, и голова гудела . По моему, системы, построенные строго по принципу микроядра, непрактичны из-за слишком низкой эффективности.
Здравствуйте, VladD2, Вы писали:
VD>Т.е. ты считаешь что Фришка и NT 3.51 (да и XP) менее быстры чем Линукс? Или под эффектвностью ты понимешь нечто другое?
XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Т.е. ты считаешь что Фришка и NT 3.51 (да и XP) менее быстры чем Линукс? Или под эффектвностью ты понимешь нечто другое?
AVK>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
XP вообще не микроядро. Вот. Возьми любую книгу описывающую ядро (например, Соломона и Руссиновича) и найдешь много подтверждений тому. Вообще, с NT3.51 и до .NET Server Microsoft все больше и больше кода переносит в ядро (в том смысле, что он работает в Kernel Mode). Например, в Windows2000 появились спец. сервисы для IIS 5.0. IIS 6.0 в .NET Server'е уже наполовину в Kernel Mode.
Здравствуйте, htfv, Вы писали:
VD>>Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
H>Гы!
Ты не даешь определения микроядра.
H>В классической системе на основе микроядра основные компоненты операционной системы (диспетчеры памяти, процессов, ввода-вывода) выполняются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами микроядра.
Основная идея микроядра — оно предоставляет только самые базовые функции — файлы, память, процессы, потоки, обмен данными и тд.
H>Теперь рассмотрим следующую ситуацию. Допустим, в коде файловой системы (или, например, в диспетчере памяти) имеется ошибка, которая время от времени приводит к краху системы. В истинной ОС на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому теоретически ошибка приведет лишь к завершению процесса соответствующего компонента. Но на практике такая ошибка все равно вызовет крах системы, так как восстановление после сбоя столь критически важного процесса невозможно.
Такая же ситуация возникает и без микроядра.
А вот реалтайм без микроядерной архитектуры почти невозможен.
Здравствуйте, AndrewVK, Вы писали:
VD>>Т.е. ты считаешь что Фришка и NT 3.51 (да и XP) менее быстры чем Линукс? Или под эффектвностью ты понимешь нечто другое?
AVK>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
Драйвера и так работают в нулевом кольце, иначе издержки на переключение контекста обходятся очень дорого.
В Nt,2000,XP двухколечная архитектура ОС. Пользователь сидит в 3м кольце.
Здравствуйте, htfv, Вы писали:
AVK>>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
H>XP вообще не микроядро. Вот. Возьми любую книгу описывающую ядро (например, Соломона и Руссиновича) и найдешь много подтверждений тому. Вообще, с NT3.51 и до .NET Server Microsoft все больше и больше кода переносит в ядро (в том смысле, что он работает в Kernel Mode).
Kernel Mode — это не ядро. Это режим такой. А само ядро — ntoskrnl + hal.
Запусти depends ntoskrnl.exe и посмотри, что экспортируется.
Драйверами занимается целая подсистема — это Kernel Mode но уже не ядро.
А в Линуксах всяких в ядре сидят и драйвера всякие, и много всякого мусора.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>А вот реалтайм без микроядерной архитектуры почти невозможен.
Логично. Хотя если сильно урезать количество сервисов то можно и без. Вобще понятие реалтайм растяжимое. Все зависит от того какое устраивает время реакции. В NT4 гарантировано для реалтайм процесса лаги не более 150мс. Если реалтайм задача допускает такие лаги то и NT в этом случае реалтайм-система.
Здравствуйте, AndrewVK, Вы писали:
AVK>Логично. Хотя если сильно урезать количество сервисов то можно и без. Вобще понятие реалтайм растяжимое. Все зависит от того какое устраивает время реакции. В NT4 гарантировано для реалтайм процесса лаги не более 150мс. Если реалтайм задача допускает такие лаги то и NT в этом случае реалтайм-система.
Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы.
А в NT отклик системы — случайная величина и 150мс это среднее значение.
Ответа при большой загрузке можно и не дождаться.
Для реалтайма делают ядра сверхлегкие, чтобы они были прерываемы.
NT не прерываема в системной секции, поскольку ядро этого не позволяет.
Реалтаймные системы позволяет за счет этого работать при пиковой загрузке (в корень из двух раза выше рабочей), а обычные(многозадачные) — только на рабочей (в корень из двух раза выше средней)
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы.
Нет. Реалтайм это когда гарантированно непревышение времени отклика определенной величины.
OE>А в NT отклик системы — случайная величина и 150мс это среднее значение.
Максимальное.
OE>Ответа при большой загрузке можно и не дождаться.
Для realtime priority не может быть большой нагрузки, все стоят и курят. В этот момент даже мыша по экрану не ездит.
Можно конечно сделать несколько реалтайм потоков, но тут уж ты сам себе злобный буратина.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, htfv, Вы писали:
AVK>>>XP это не чистое микроядро. Начиная с NT4 как минимум драйвера видео работают в нулевом кольце
H>>XP вообще не микроядро. Вот. Возьми любую книгу описывающую ядро (например, Соломона и Руссиновича) и найдешь много подтверждений тому. Вообще, с NT3.51 и до .NET Server Microsoft все больше и больше кода переносит в ядро (в том смысле, что он работает в Kernel Mode).
OE>Kernel Mode — это не ядро. Это режим такой. А само ядро — ntoskrnl + hal. OE>Запусти depends ntoskrnl.exe и посмотри, что экспортируется. OE>Драйверами занимается целая подсистема — это Kernel Mode но уже не ядро. OE>А в Линуксах всяких в ядре сидят и драйвера всякие, и много всякого мусора.
ntoskrnl+hal всего лишь реализуют основные сервисы ядра. Остальные компоненты не работают в защищенном пространстве. Они не являются процессами, что противоречит концепции микроядра. В Линуксах драйвера в ядре потому, что они туда слинкованы. При компиляции ядра ты запросто можешь сказать, что тот или иной драйвер должен грузиться динамически. Архитектура у Линукса просто другая (менее ли она гибкая или нет не является темой данного разговора). В Windows NT просто все драйвера грузятся динамически на основании данных в реестре. Все связи осуществляются на стадии исполнения. Вот и вся разница. Конечно, с приходом WDM все стало еще интереснее. Грубо говоря, загружаемые драйвера определяются самими устройствами, а не наоборот.
В общем, принципиальной разницы между ядром NT и Linux я не вижу. Linux тоже не является системой основанной на микроядре. Вот.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, htfv, Вы писали:
VD>>>Слушай, а что такое по-твоему микроядро? Ты его часом с защищенным адресным пространством не путаешь?
H>>Гы!
OE>Ты не даешь определения микроядра.
H>>В классической системе на основе микроядра основные компоненты операционной системы (диспетчеры памяти, процессов, ввода-вывода) выполняются как отдельные процессы в собственных адресных пространствах и представляют собой надстройки над примитивными сервисами микроядра.
OE>Основная идея микроядра — оно предоставляет только самые базовые функции — файлы, память, процессы, потоки, обмен данными и тд.
Повторяю. В классической системе на основе микроядра основные компоненты операционной системы выполняются как отдельные процессы в собственных адресных пространствах. Это включает в себя и менеджер памяти, и файловые системы (которые, кстати, можно реализовать в user mode'е и в NT), и менеджер потоков (примерно как fiber'ы в NT).
H>>Теперь рассмотрим следующую ситуацию. Допустим, в коде файловой системы (или, например, в диспетчере памяти) имеется ошибка, которая время от времени приводит к краху системы. В истинной ОС на основе микроядра подобные компоненты выполняются в пользовательском режиме, поэтому теоретически ошибка приведет лишь к завершению процесса соответствующего компонента. Но на практике такая ошибка все равно вызовет крах системы, так как восстановление после сбоя столь критически важного процесса невозможно.
OE>Такая же ситуация возникает и без микроядра.
Я пр это и говорю. Микроядро не является сколько-нибудь более стабильной системой.
OE>А вот реалтайм без микроядерной архитектуры почти невозможен.
Вопрос о realtime OS серьезно не изучал. Это довольно специфичный предмет. Сказать, что без микроядра реалтайма нет, я не могу. Не вижу причин. Просто NT не разрабатывалась как реалтайм ОС и не преследует такой цели. Вот и все.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы. OE>А в NT отклик системы — случайная величина и 150мс это среднее значение. OE>Ответа при большой загрузке можно и не дождаться.
Вот и подумай о том что ты говоришь.
OE>А вот реалтайм без микроядерной архитектуры почти невозможен.
ДОС построеный вообще без архитиктуры прекрасно подходит для реалтайм-задач. А NT построеная по микроядерной архитектуре для релтайма не пододит.
Еще раз тебе говорю, ты путаешь защиту адресных пространств и микроядерную архитектуру. Вся линейка NT и все чистокровные Юниксы основаны на микроядерной архитектуре. А вот Линукс как раз выходит из этого ряда. Микроядерность влияет исключительно на переносимость ОС. Микроядро — это та часть ОС которая полностью зависит от железа и которую обычно пишут на ассемблере.
Здравствуйте, htfv, Вы писали:
H>ntoskrnl+hal всего лишь реализуют основные сервисы ядра. Остальные компоненты не работают в защищенном пространстве. Они не являются процессами, что противоречит концепции микроядра. В H>Линуксах драйвера в ядре потому, что они туда слинкованы.
Потому оно и не является микроядром, потому что предполагает макрофункциональность- сервис предоставляемый драйвером.
H>При компиляции ядра ты запросто можешь сказать, что тот или иной драйвер должен грузиться динамически. Архитектура у Линукса просто другая (менее ли она гибкая или нет не является темой данного разговора). В Windows NT просто все драйвера грузятся динамически на основании данных в реестре. Все связи осуществляются на стадии исполнения. Вот и вся разница. Конечно, с приходом WDM все стало еще интереснее. Грубо говоря, загружаемые драйвера определяются самими устройствами, а не наоборот.
В том то и разница, что к ядру драйвера не имеют никакого отношения. Это и отличает не только NT от Linux, но и микроядро от модульного.
Здравствуйте, VladD2, Вы писали:
OE>>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы. OE>>А в NT отклик системы — случайная величина и 150мс это среднее значение. OE>>Ответа при большой загрузке можно и не дождаться. VD>Вот и подумай о том что ты говоришь.
Все правильно, для реалтайма загрузка не должна иметь влияния.
OE>>А вот реалтайм без микроядерной архитектуры почти невозможен. VD>ДОС построеный вообще без архитиктуры прекрасно подходит для реалтайм-задач. А NT построеная по микроядерной архитектуре для релтайма не пододит.
Удинственно, что можно сделать с ДОС для реалтайма — переключиться в защищенный режим
(EMM386, DOS4GW,DPMI ) и самому написать реалтайм ядрышко — но это уже не ДОС.
Сам ДОС — это монолитная архитектура с модульным уклоном. Причем архитектура весьма четкая и простая.
Время отклика не детерминировано и нет многозадачности встроенной.
Многозадачность довольно сложно реализовать из-за нереентерабельности ДОС.
Я пять лет программил под ДОС на всем почти, что было — TP,BP,TC,BC,ASM + машинные коды и реалтайма нашел не очень много.
О каком реалтайме может идти речь, если в момент, когда дос внутри себя,
не будет отклика ни на что ?
В ДОС такая парадигма —
1. Во время инициализации нужно перепрограммировать таймер, сесть на 8h,9h,16h,10h,13h,21h,28h,33h, 70h + желательно еще несколько перерываний. Это нужно что бы увеличить шанс срабатывания.
1а. функция 34h прерывания 21h возвращает адрес флага занятости системы.
1б. функцию не помню точно — возвращает состояние текущей задачи — файловые буфера и внутренние переменные и тд — это надо скопировать себе где нибудь.
2. по аппаратному прерыванию взводится флаг, показывающий, что нужна обработка.
3. В каждом обработчике вызывается функция для проверки занятости прерывания. В 28h это можно не делать.
4. Переключаем сегмент стека, сегмент данных
5. Подменяем состояние ттекущей задачи
6. Делаем свое черное дело
7. Возвращаем управление обратно с восстановлением всего контекста задачи и тд.
Итого
1. пункты с 3го по 7й выполняются довольно долго. В это время никакой обработки вложенных прерываний не будет.
2. Отклик системы — время с 2го по 7й пункт весьма велико. Интервал между 2 — 3 стремятся уменьшить за счет большого количества перехваченных прерываний — количество оказий. Если есть возможность, программируются прерывания от портов последовательного и параллельного портов — еще два таймера.
Здравствуйте, htfv, Вы писали:
H>Повторяю. В классической системе на основе микроядра основные компоненты операционной системы выполняются как отдельные процессы в собственных адресных пространствах. Это включает в себя и менеджер памяти, и файловые системы (которые, кстати, можно реализовать в user mode'е и в NT), и менеджер потоков (примерно как fiber'ы в NT).
То что ты повторил, это ничего не объясняет.
Ядра различаются по структуре в первую очередь.
Далее по функцинальной начинке.
А ты рассказываешь про реализацию.
Микроядро — микро означает микрооперации. Размер ядра — это косвенный показатель. Обычно микроядра меньше модульных. Если из ядра от линукса выбросить все подрят, это не значит, что он станет микро.
Все процессы Процесыы — вне ядра. H>Вопрос о realtime OS серьезно не изучал. Это довольно специфичный предмет. Сказать, что без микроядра реалтайма нет, я не могу. Не вижу причин. Просто NT не разрабатывалась как реалтайм ОС и не преследует такой цели. Вот и все.
Вот и изучи ядра QNX,Chorus, Mesh и расскажи нам, почему они микро (а QNX — микромикро — нейтринное)
Здравствуйте, AndrewVK, Вы писали:
OE>>Тут не время играет роль. Для реалтайма строго детерминированное время отклика системы.
AVK>Нет. Реалтайм это когда гарантированно непревышение времени отклика определенной величины.
Непревышение времени — это растяжимое понятие.
Случайная величина характеризуется матожиданием и дисперсией.
Детерминированное время отклика — это теоретический прием.
Реально дисперсия времени отклика стремится к нулю.
AVK>Максимальное.
OE>>Ответа при большой загрузке можно и не дождаться.
AVK>Для realtime priority не может быть большой нагрузки, все стоят и курят. В этот момент даже мыша по экрану не ездит.
Вот это и означает, что отклика не детерминировано. Иначе мыша бы двигалась, хоть с запозданием.
AVK>Можно конечно сделать несколько реалтайм потоков, но тут уж ты сам себе злобный буратина.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Удинственно, что можно сделать с ДОС для реалтайма — переключиться в защищенный режим OE> (EMM386, DOS4GW,DPMI ) и самому написать реалтайм ядрышко — но это уже не ДОС.
ДОС позволяет отдать все ресурсы одной задаче и уж точно не может выполнять паралеллно ничего лишнего. Я слышал о многих реалтайм-проектамх на ДОС.
OE>Время отклика не детерминировано и нет многозадачности встроенной.
Время отклика зависит исключительно от прикладного кода. Потому и для задач таких подходит. Не шик конечно, но зато все под контролем.
OE>Многозадачность довольно сложно реализовать из-за нереентерабельности ДОС.
Зачастую это и не нужно. Ну зачем многозадачность, например, для считывания и предварительной обработки неготорого аппаратного датчика?
OE>Я пять лет программил под ДОС на всем почти, что было — TP,BP,TC,BC,ASM + машинные коды и реалтайма нашел не очень много.
Т.е. все таки нашел?
OE>О каком реалтайме может идти речь, если в момент, когда дос внутри себя, OE>не будет отклика ни на что ?
Дык ОС так мало делает сама, что почти все время отдается под задачу. В конце концов для конкретной задачи важно чтобы задержка была детерминированной. Если она приемлема, то и вопростов нет. В NT же в пользовательском режиме нет кикаких гарантий. Извартиться конечно можно, но не просто.
Здравствуйте, VladD2, Вы писали:
OE>>Удинственно, что можно сделать с ДОС для реалтайма — переключиться в защищенный режим OE>> (EMM386, DOS4GW,DPMI ) и самому написать реалтайм ядрышко — но это уже не ДОС.
VD>ДОС позволяет отдать все ресурсы одной задаче и уж точно не может выполнять паралеллно ничего лишнего. Я слышал о многих реалтайм-проектамх на ДОС.
1.Реал тайм под ДОС реализуются с помощью специальных библиотек для защищенного режима. Иначе не выйдет.
2. Сам ДОС не является ядром системы реального времени — только как вспомогательный элемент для файловых операций ввиду простоты.
Я как то работал в реал-тайм проете под ДОС. Сама система была примерно из сотни 8086 и 80286.
ДОС там использовался только как монитор событий и хранилище.
Надо конкретнее.
OE>>Время отклика не детерминировано и нет многозадачности встроенной.
VD>Время отклика зависит исключительно от прикладного кода. Потому и для задач таких подходит. Не шик конечно, но зато все под контролем.
1. Здесь нужна реакция на внешние прерывания, а их можно и не получить под ДОС.
2. Контекст приходится переключать самому — это довольно долго. В защищенном режиме это делается аппаратно.
3. ДОС — медленная 16ти разрядная система. Для 32х разрядов нужен защищенный режим.
OE>>Многозадачность довольно сложно реализовать из-за нереентерабельности ДОС.
VD>Зачастую это и не нужно. Ну зачем многозадачность, например, для считывания и предварительной обработки неготорого аппаратного датчика?
Аппраратный датчик может быть опрошен только тремя способами
Вввод-вывод без прерываний — если ДОС занят, то никак не опросишь
Ввода-вывод по прерываниям — в прерывании, если прервали ДОСю, много не сделаешь, для это и есть int 21h ah=34h
Ввода-вывод с DMA — это занятие для самоубийцы, и во время обработки ничего
Один аппаратный датчик — это вырожденный случай.
Обычно надо опрашивать устройство или несколько датчиков.
OE>>Я пять лет программил под ДОС на всем почти, что было — TP,BP,TC,BC,ASM + машинные коды и реалтайма нашел не очень много.
VD>Т.е. все таки нашел?
Только в средствах реального времени, которые ДОСом то и не являются.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Сам ДОС — это монолитная архитектура с модульным уклоном. Причем архитектура весьма четкая и простая. OE>Время отклика не детерминировано и нет многозадачности встроенной. OE>Многозадачность довольно сложно реализовать из-за нереентерабельности ДОС. OE>Я пять лет программил под ДОС на всем почти, что было — TP,BP,TC,BC,ASM + машинные коды и реалтайма нашел не очень много.
Слушай, у тебя реалтайм это чаша грааля какая то получается. Т.е. нечто недостижимое. Реалтайм это когда решаются задачи в реальном времени. И ничего более. Управление составом смеси фризера это реалтайм? Реалтайм. Работает под ДОС 3.3.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>1.Реал тайм под ДОС реализуются с помощью специальных библиотек для защищенного режима. Иначе не выйдет.
В упоминаемом мною фризере никаких защищенных режимов.
OE>Один аппаратный датчик — это вырожденный случай. OE>Обычно надо опрашивать устройство или несколько датчиков.
Для нескольких датчиков ставится такая железка, которая их собирает, а наружу смотрит один цифровой порт.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>Нет. Реалтайм это когда гарантированно непревышение времени отклика определенной величины.
OE>Непревышение времени — это растяжимое понятие.
Так и реалтайм понятие тоже растяжимое
AVK>>Для realtime priority не может быть большой нагрузки, все стоят и курят. В этот момент даже мыша по экрану не ездит.
OE>Вот это и означает, что отклика не детерминировано. Иначе мыша бы двигалась, хоть с запозданием.
Нет, это означает что все потоки остановлены, окромя твоего. Приоритет мышерисовальщика ниже, вот ему процессор и не дается.
На время отклика для самого потока сказываются только задержки в микроядре.
Здравствуйте, AndrewVK, Вы писали:
OE>>Сам ДОС — это монолитная архитектура с модульным уклоном. Причем архитектура весьма четкая и простая. OE>>Время отклика не детерминировано и нет многозадачности встроенной. OE>>Многозадачность довольно сложно реализовать из-за нереентерабельности ДОС. OE>>Я пять лет программил под ДОС на всем почти, что было — TP,BP,TC,BC,ASM + машинные коды и реалтайма нашел не очень много.
AVK>Слушай, у тебя реалтайм это чаша грааля какая то получается. Т.е. нечто недостижимое. Реалтайм это когда решаются задачи в реальном времени. И ничего более. Управление составом смеси фризера это реалтайм? Реалтайм. Работает под ДОС 3.3.
Если аггрегат генерирует события раз в пол часа и время отклика достаточно 10 минут, это не означает, что любая система, которая будет обрабатывать события, станет реалтайм.
ДОС — это не система реального времени. При чем здесь твой фризер ?
А операционная система реального времени — это действительно чаша грааля. Их есть только несколько, и те не всегда удовляют требованиям реалтайма.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, это означает что все потоки остановлены, окромя твоего. Приоритет мышерисовальщика ниже, вот ему процессор и не дается. AVK>На время отклика для самого потока сказываются только задержки в микроядре.
Приоритет в системе реального времени определяет задержку обработки события.
Высой приоритет — малая задержка. Низкий — большая.
Если процессор не дается вообще — это дрянь, а не реалтайм.
И все.
А в Виндах события, сообщения имеют свойство теряться.
Пример — OS/2 при сколь угодно большой загрузке процессора(ну почти) можно перегрузить нажатием клавиш Ctrl-Alt-Del.
OS/2 — не является ОС РВ. Но ОС с элементами РВ. И это уже чувтвуется. Мультизадачность гораздо лучше, чем в NT.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Если аггрегат генерирует события раз в пол часа и время отклика достаточно 10 минут, это не означает, что любая система, которая будет обрабатывать события, станет реалтайм.
Нет, не раз в полчаса. Хорошо, рассказываю что такое фризер.
Это некий аппарат, на вход которого подается молочная смесь, ароматизаторы и наполнители. Внутрях смесь смешивается с воздухом в строго определенной пропорции, потом к смеси добавляются ароматьизаторы, красители и наполнители, тоже, понятное дело, строго определенное количество. Производительность этого чудо-агрегата — сотня литров в минуту. Вот при времени отклика 10 мин ты и получишь куб отходов.
OE>ДОС — это не система реального времени. При чем здесь твой фризер ?
Если она позволяет решать реалтайм задачи значит она система реального времени. Остальное демагогия.
OE>А операционная система реального времени — это действительно чаша грааля. Их есть только несколько, и те не всегда удовляют требованиям реалтайма.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Если процессор не дается вообще — это дрянь, а не реалтайм.
Это называется вытесняющая многозадачность.
OE>А в Виндах события, сообщения имеют свойство теряться.
Пошел, поехал. События тут при чем? Это уже не ядро, а пользовательская user32
OE>Пример — OS/2 при сколь угодно большой загрузке процессора(ну почти) можно перегрузить нажатием клавиш Ctrl-Alt-Del. OE>OS/2 — не является ОС РВ. Но ОС с элементами РВ. И это уже чувтвуется. Мультизадачность гораздо лучше, чем в NT.
Здравствуйте, AndrewVK, Вы писали:
OE>>А в Виндах события, сообщения имеют свойство теряться.
AVK>Пошел, поехал. События тут при чем? Это уже не ядро, а пользовательская user32
Так и на сеть она также реагирует. И на COM порт и на любой другой порт точно также.
На такой загрузке, когда ложится Винда, ОС РВ нормально работают. Потому их и сложно повалить дос-атакой.
А когда исследуются ядерные превращения, за доли секуны до взрыва как раз пиковая загрузка будет — надо все датчики опросить разом и отослать куда надо, перед тем как все вокруг испарится.
Основное требование в реализации ОС РВ — прерываемость в системной секции, отсутвует во всех Виндах, почти во всех юниксах и линуксе.
А вот в OS/2 это есть. (Вернее было, издохла эта система)
Здравствуйте, AndrewVK, Вы писали:
OE>>ДОС — это не система реального времени.
AVK>Если она позволяет решать реалтайм задачи значит она система реального времени. Остальное демагогия.
Она не решает задач РВ. ТОлько задачи, похожие на фризер — простые, не требующие паралелизма с достаточно большим временим отклика. Для каких еще РВ можно применить ДОС ?
Задачи реального времени:
— задача должна быть выполнена на коротком отрезке времени и через гарантированное время от нее должен быть получен ответ (режим работы в реальном времени),
— различные по времени и логике работы задачи подчинены друг другу и должны выполняться одновременно.
Как решаеются две эти задачи ?
Гарантированный ответ и параллелизм ?
Гарантированный ответ, если больше какого то минимума, вполне сойдет. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд — где это в ДОС ?
Там счет идет на десятки милисекунд, что на порядок больше.
И парраллелизма не будет
Итак
Дос — система, которая может решить некоторые задачи реального времени, не требующие малого времени отклика и парралелизма.
Значит, если система решает не все задачи РВ, является ОС РВ ?
Из моего опыта — ДОС применяли везде. Даже многооконные оболочки писали под него.
Единственное оправдание — простота, дешевизна, открытость консмтрукции.
Здравствуйте, AndrewVK, Вы писали:
OE>>ДОС — это не система реального времени. При чем здесь твой фризер ?
AVK>Если она позволяет решать реалтайм задачи значит она система реального времени. Остальное демагогия.
Здравствуйте, AndrewVK, Вы писали:
OE>>1.Реал тайм под ДОС реализуются с помощью специальных библиотек для защищенного режима. Иначе не выйдет.
AVK>В упоминаемом мною фризере никаких защищенных режимов.
OE>>Один аппаратный датчик — это вырожденный случай. OE>>Обычно надо опрашивать устройство или несколько датчиков.
AVK>Для нескольких датчиков ставится такая железка, которая их собирает, а наружу смотрит один цифровой порт.
Данные — это не один бит.
Всегда минимум два порта — состояния и данных.
Они могут быть совмещены, если статус только читается, а данные только записываются — но это вырожденный случай.
Здравствуйте, AndrewVK, Вы писали:
OE>>ДОС — это не система реального времени. При чем здесь твой фризер ?
AVK>Если она позволяет решать реалтайм задачи значит она система реального времени. Остальное демагогия.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>Пошел, поехал. События тут при чем? Это уже не ядро, а пользовательская user32
OE>Так и на сеть она также реагирует. И на COM порт и на любой другой порт точно также.
Да счас прям. Обычно пользуемый TCP — блокирующие вызовы, неблокирующими сегодня никто не пользуется. COM — блокирующие вызовы.
OE>А когда исследуются ядерные превращения, за доли секуны до взрыва как раз пиковая загрузка будет — надо все датчики опросить разом и отослать куда надо, перед тем как все вокруг испарится.
Какое то у тебя все черное белое. Раз система реалтайм, значит ядерные взрывы считать. Я тебе который раз уж говорю — нет такой жесткой границы — реалтайм/нереалтайм. Просто те или иные системы в разной степени пригодны для реалтайм задач, какие то больше (QNX), какие то средне (BeOS),какие то меньше(NT). Но суть от этого не меняется. Я же тебе говорю — реально решали реалтайм задачи на NT4, видео в реальном времени перелопачивали. И ничего, удавалось с задержками бороться. Так что все зависит от задачи, все равно универсальной ОС под все реалтайм-задачи нет.
Так что спор какой то глупый получается.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Данные — это не один бит. OE>Всегда минимум два порта — состояния и данных. OE>Они могут быть совмещены, если статус только читается, а данные только записываются — но это вырожденный случай.
Один порт, один. RS-232 или его промышленные разновидности или Ethernet.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Пошел, поехал. События тут при чем? Это уже не ядро, а пользовательская user32
OE>>Так и на сеть она также реагирует. И на COM порт и на любой другой порт точно также.
AVK>Да счас прям. Обычно пользуемый TCP — блокирующие вызовы, неблокирующими сегодня никто не пользуется. COM — блокирующие вызовы.
При чем здесь TCP — система не выдерживает напора сети.
Интервал времени между ISR и DSR слишком велик.
OE>>А когда исследуются ядерные превращения, за доли секуны до взрыва как раз пиковая загрузка будет — надо все датчики опросить разом и отослать куда надо, перед тем как все вокруг испарится.
AVK>Какое то у тебя все черное белое. Раз система реалтайм, значит ядерные взрывы считать. Я тебе который раз уж говорю — нет такой жесткой границы — реалтайм/нереалтайм. Просто те или иные системы в разной степени пригодны для реалтайм задач, какие то больше (QNX), какие то средне (BeOS),какие то меньше(NT). Но суть от этого не меняется. Я же тебе говорю — реально решали реалтайм задачи на NT4, видео в реальном времени перелопачивали. И ничего, удавалось с задержками бороться. Так что все зависит от задачи, все равно универсальной ОС под все реалтайм-задачи нет.
Я же говорю — единицы милисекунды — это уже реалтайм. Иначе — интерактивный режим.
А в QNX — микросекунды.
Настоящее (Реальное) время непрерывно — вот этого и добиваются в ОС РВ.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Она не решает задач РВ. ТОлько задачи, похожие на фризер — простые, не требующие паралелизма с достаточно большим временим отклика. Для каких еще РВ можно применить ДОС ?
Во блин, начинается. В начале ОС были не такие, теперь задачи. Хорошо, обработка видеопотока 768х576х8 бит тебя устроит. Сперва сделали под ДОС, потом под NT4.
OE>- задача должна быть выполнена на коротком отрезке времени и через гарантированное время от нее должен быть получен ответ (режим работы в реальном времени),
Вот, тебе и говорят что если поток в NT имеет realtime приоритет то тебе гарантированно ядро съест не более 150 мс. Понятно?
OE>- различные по времени и логике работы задачи подчинены друг другу и должны выполняться одновременно.
OE>Как решаеются две эти задачи ? OE>Гарантированный ответ и параллелизм ?
OE>Гарантированный ответ, если больше какого то минимума, вполне сойдет. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд — где это в ДОС ? OE>Там счет идет на десятки милисекунд, что на порядок больше.
OE>И парраллелизма не будет
Так я тоже могу. Сам придумать такое определение что я один прав окажусь.
обработка в реальном масштабе времени
обработка в реальном масштабе времени (Real time processing) — режим компьютерной обработки информации, при котором скорость обработки подчиняется заданному темпу поступления информации в компьютер. Применительно к системам коллективного пользования с разделением времени (Time sharing system) -ситуация, когда реакция системы на очередное действие человека не превышает 1-2 секунд.
Открытая энциклопедия рубрикона
OE>Значит, если система решает не все задачи РВ, является ОС РВ ?
Здравствуйте, AndrewVK, Вы писали:
OE>>Реальное время — это милисекуны.
AVK>Это зависит от задачи.
НЕТ. Настоящее время непрерывно, этим и должна обладать ОС РВ. Но идеала не достигается никогда.
OE>>Если нет — это интерактивная система. Вот ей то ДОС и является
AVK>Почитай в словаре определение слова интерактивная.
Я тебе штук пять линков бросил, ты их читал ?
Классификация ОС по времени отклика
Реального мастаба времени — до десятка милисекунд
Интерактивная (диалоговая) — до десятка секунд
Пакетной обработки — более 10 секунд
У ОСРВ должен быть также такой парамент, как паралеллизм и надежность.
Где это у ДОС ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>>>Пошел, поехал. События тут при чем? Это уже не ядро, а пользовательская user32
OE>>>Так и на сеть она также реагирует. И на COM порт и на любой другой порт точно также.
AVK>>Да счас прям. Обычно пользуемый TCP — блокирующие вызовы, неблокирующими сегодня никто не пользуется. COM — блокирующие вызовы.
OE>При чем здесь TCP — система не выдерживает напора сети. OE>Интервал времени между ISR и DSR слишком велик.
Ты о чем вобще? Речь о событиях и сообщенияв в NT. Ты ведь заявил что они используются для работы с сетью и СОМ-портом.
OE>Я же говорю — единицы милисекунды — это уже реалтайм. Иначе — интерактивный режим.
Сам придумал?
интерактивный режим
интерактивный режим (interactive mode) — то же, что диалоговый режим.
диалоговый режим
диалоговый режим (conversational mode, Interactive mode) — режим работы пользователя с ЭВМ, при котором человек и машина обмениваются данными в темпе, соизмеримом с темпом обработки данных человеком.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Я тебе штук пять линков бросил, ты их читал ?
Ты считаешь что ради того чтобы доказать тебе что то буду кучу статей читать? Я тебя тоже линками закидать могу.
OE>Классификация ОС по времени отклика
OE>Реального мастаба времени — до десятка милисекунд OE>Интерактивная (диалоговая) — до десятка секунд OE>Пакетной обработки — более 10 секунд
Здравствуйте, AndrewVK, Вы писали:
AVK>Во блин, начинается. В начале ОС были не такие, теперь задачи. Хорошо, обработка видеопотока 768х576х8 бит тебя устроит. Сперва сделали под ДОС, потом под NT4.
Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
Но сьъем кадра гарантировано за время до 5 милисекунд — устроит.
OE>>- задача должна быть выполнена на коротком отрезке времени и через гарантированное время от нее должен быть получен ответ (режим работы в реальном времени),
AVK>Вот, тебе и говорят что если поток в NT имеет realtime приоритет то тебе гарантированно ядро съест не более 150 мс. Понятно?
Это много. Надо единицы милимекунд и гарантированно ! А в NT время отклика — случайная величина.
Она не является ОСРВ.
OE>>- различные по времени и логике работы задачи подчинены друг другу и должны выполняться одновременно.
OE>>Как решаеются две эти задачи ? OE>>Гарантированный ответ и параллелизм ?
OE>>Гарантированный ответ, если больше какого то минимума, вполне сойдет. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд — где это в ДОС ? OE>>Там счет идет на десятки милисекунд, что на порядок больше.
OE>>И парраллелизма не будет
AVK>Так я тоже могу. Сам придумать такое определение что я один прав окажусь.
Это не я придумал, прочитай об этом в тех ссылках, что я привел.
Есть "Теория операционных систем", где четко все описано и классифицировано.
Все это оттуда.
AVK>[q] AVK>обработка в реальном масштабе времени AVK> AVK>обработка в реальном масштабе времени (Real time processing) — режим компьютерной обработки информации, при котором скорость обработки подчиняется заданному темпу поступления информации в компьютер.
Применительно к системам коллективного пользования с разделением времени (Time sharing system) -ситуация, когда реакция системы на очередное действие человека не превышает 1-2 секунд.
В этом определении ошибка — это определение годится для диалоговых ОС.
Я тебе приводил классификацию — там и смотри.
OCРВ — это физические процессы, ракеты, самолеты, конвейеры, реакторы.
А про Рубикон — почему ты не полез в толковый словарь Даля ?
Данный вопрос надо стотреть в научной литературе и только.
OE>>Значит, если система решает не все задачи РВ, является ОС РВ ?
AVK>Ни одна ОС РВ не решает всех задач РВ
QNX решает большинство насущных проблем.
Есть системы, у которых время отклика еще меньше чем QNX.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>>Данные — это не один бит. OE>>Всегда минимум два порта — состояния и данных. OE>>Они могут быть совмещены, если статус только читается, а данные только записываются — но это вырожденный случай.
AVK>Один порт, один. RS-232 или его промышленные разновидности или Ethernet.
Я говорю про аппаратный порт — через него и идет общение.
Дать тебе список портов RS-232 ?
AVK>Сам придумал?
AVK>интерактивный режим
AVK>
AVK>интерактивный режим (interactive mode) — то же, что диалоговый режим.
AVK>
AVK>диалоговый режим
AVK>
AVK>диалоговый режим (conversational mode, Interactive mode) — режим работы пользователя с ЭВМ, при котором человек и машина обмениваются данными в темпе, соизмеримом с темпом обработки данных человеком.
Это было в одной из тех ссылок, что тебе посылал. Съел ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты считаешь что ради того чтобы доказать тебе что то буду кучу статей читать? Я тебя тоже линками закидать могу.
OE>>Классификация ОС по времени отклика
OE>>Реального мастаба времени — до десятка милисекунд OE>>Интерактивная (диалоговая) — до десятка секунд OE>>Пакетной обработки — более 10 секунд
AVK>Источник плиз.
А вот это уже из конспекта по "Теории операционных систем" — специальность у меня такая была. Вычислительные машины, системы и сети.
Любая система, в которой существенную роль играет время генерации выходного сигнала. Это обычно связано с тем, что входной сигнал соответствует каким-то изменениям в физическом процессе, и выходной сигнал должен быть связан с этими же изменениями. Временная задержка от получения входного сигнала до выдачи выходного сигнала должна быть небольшой, чтобы обеспечить приемлемое время реакции. Время реакции является системной характеристикой: при управлении ракетой требуется реакция в течении нескольких миллисекунд, тогда как для диспетчерского управления движением пароходов требуется время реакции, измеряемое днями. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд; диалоговыми считаются системы с временем реакции порядка нескольких секунд, а в системах пакетной обработки время реакции измеряется часами или днями. Примерами систем реального времени являются системы управления физическими процессами с применением вычислительных машин, системы торговых автоматов, автоматизированные системы контроля и автоматизированные испытательные комплексы.
Re[16]: микроядро
От:
Аноним
Дата:
01.12.02 17:11
Оценка:
Не путайте вы hard real-time с soft real-time. Это принципиально разные вещи. Вот как раз обработка видеопотока и есть натуральный софт реалтайм. И для этого действително подойдет NT и т.п.
И даже существуют несколько проектов реализаций hard на той же NT. Вот только в одной из них крутится VxWorks, который и решает реал-тайм задачи, а NT используется только для визуализации и управления системой. В другом проекте вообще взяли и переписали ядро нтишное. Но как вы понимаете это уже стала совсем не та NT, которая стоит на моей машине.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
OE>Но сьъем кадра гарантировано за время до 5 милисекунд — устроит.
Ты не понял наверное. Схема такая — сигнал с видеокамеры идет в комп, в компе обрабатывается и идет дальше. Все в реальном времени.
OE>Это много.
Блин, ну достал ты уже? Что значит много? Мешок картошки это много? Для ужина очень много, а на год мизер. Так и здесь — много или мало зависит от задачи, а не от того что тыы постановил что по сю пору считать мало, а далее много.
OE> Надо единицы милимекунд и гарантированно !
Кому надо?
OE>А в NT время отклика — случайная величина.
Тебе тоже статей накидать? Читать будешь?
OE>Это не я придумал, прочитай об этом в тех ссылках, что я привел.
Мне это сейчас не интересно
OE>Есть "Теория операционных систем",
Во как! Я вот первый раз о такой слышу. Теория! Звучит!
OE>где четко все описано и классифицировано. OE>Все это оттуда.
Кто автор?
OE>В этом определении ошибка — это определение годится для диалоговых ОС.
Ну да, я хоть источник привел. Но в определении конечно ошибка. Вот это и есть самая настоящая демагогия.
OE>Я тебе приводил классификацию — там и смотри.
Ты сюда давай.
OE>OCРВ — это физические процессы, ракеты, самолеты, конвейеры, реакторы.
Вот я и говорю — раз РВ так сразу самолеты, реакторы, ракеты. Фигню ты говоришь.
Ладно, вот тебе еще один проект, который я лично делал. Как раз с физическим процессом.
Система обнаружения утечек. Обнаруживает место утечки в трубопроводе с нефтепродуктом по разности времени прихода волны давления в разные точки. В ТЗ точность определения 500м. Скорость звука в керосине почти 900 м/с. Вот и посчитай. Работало на NT.
Да, фризер это тоже часть роботизированного конвеера, так что под твое определение подходит.
OE>А про Рубикон — почему ты не полез в толковый словарь Даля ? OE>Данный вопрос надо стотреть в научной литературе и только.
Статьи в в поплулярных журналах тоже на научную литературу не катят. У тебя есть более авторитетное мнение — приводи, только не забывай источники указывать. А то прям сказал как отрезал.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>А вот это уже из конспекта по "Теории операционных систем" — специальность у меня такая была. OE>Вычислительные машины, системы и сети.
Ты удивишься наверное, но у меня такая же была. Нам только такой чепухи никто не говорил.
В любом случае — конспекты штука не доказательная, пока где нибудь официально не опубликованы.
OE>Вот кое что похоже — http://www.ci.ru/inform15_97/kovrigin.htm
OE>Любая система, в которой существенную роль играет время генерации выходного сигнала. Это обычно связано с тем, что входной сигнал соответствует каким-то изменениям в физическом процессе, и выходной сигнал должен быть связан с этими же изменениями. Временная задержка от получения входного сигнала до выдачи выходного сигнала должна быть небольшой, чтобы обеспечить приемлемое время реакции. Время реакции является системной характеристикой: при управлении ракетой требуется реакция в течении нескольких миллисекунд, тогда как для диспетчерского управления движением пароходов требуется время реакции, измеряемое днями. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд; диалоговыми считаются системы с временем реакции порядка нескольких секунд, а в системах пакетной обработки время реакции измеряется часами или днями. Примерами систем реального времени являются системы управления физическими процессами с применением вычислительных машин, системы торговых автоматов, автоматизированные системы контроля и автоматизированные испытательные комплексы.
Гы. Здорово от твоих заявлений однако отличается.
А насчет диалоговых чешуя редкостная. Диалоговые, это когда работа системы определяется взаимодействием с человеком. Попытки привязать это ко времени реакции — это такая иждея фикс была, что если компьютер реагирует за 1-2 секунды то она диалоговая. Связь именно такая, а не наоборот. Т.е. если комп реагирует за 1-2 секунды это не означает что система диалоговая. Слово само какое, ДИАЛОГ.
А еще наверное системы торговых автоматов это то где несомненно требуется реакция до десятка микросекунд.
Ладно, следующее определение еще интереснее
Режим реального времени [real time processing]. Режим обработки данных, при котором обеспечивается взаимодействие вычислительной системы с внешними по отношению к ней процессами в темпе, соизмеримом со скоростью протекания этих процессов.
ИМХО очень неплохое определение. Вот от него и отталкивайся.
Здравствуйте, Аноним, Вы писали:
А>Не путайте вы hard real-time с soft real-time. Это принципиально разные вещи. Вот как раз обработка видеопотока и есть натуральный софт реалтайм. И для этого действително подойдет NT и т.п. А>И даже существуют несколько проектов реализаций hard на той же NT. Вот только в одной из них крутится VxWorks, который и решает реал-тайм задачи, а NT используется только для визуализации и управления системой. В другом проекте вообще взяли и переписали ядро нтишное. Но как вы понимаете это уже стала совсем не та NT, которая стоит на моей машине.
Жесткий реалтайм — это микросекунды, здесь только QNX.
Видеопоток — это уже не диалоговый режим, но еще не реалтайм.
Для реалтайма нужна точность в единицы милисекунд.
Здравствуйте, <Аноним>, Вы писали:
А>Не путайте вы hard real-time с soft real-time. Это принципиально разные вещи. Вот как раз обработка видеопотока и есть натуральный софт реалтайм. И для этого действително подойдет NT и т.п.
Гы, дочитал твою статейку до конца. До выводов. Сам их читал?
Выводы
--------------------------------------------------------------------------------
Из приведенных выше цитат можно сделать выводы:
термин «система реального времени» в настоящее время может быть записан так: “Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в которое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы”.
Для того, чтобы система могла удовлетворить требованиям, предъявляемым к системам реального времени, аппаратные, программные средства и алгоритмы работы системы должны гарантировать заданные временные параметры реакции системы. Время реакции не обязательно должно быть очень маленьким, но оно должно быть гарантированным (и отвечающим поставленным требованиям);
использование термина «система реального времени», определенного выше, для обозначения интерактивных и высокопроизводительных систем неверно;
термин «квазиреальное время» (soft real-time) хотя и используется, но четко не определен. До его четкого определения вряд ли возможно его применение в документах (кроме рекламных).
Все, далее спорить не буду, сам почитай свои же ссылки.
OE>>Любая система, в которой существенную роль играет время генерации выходного сигнала. Это обычно связано с тем, что входной сигнал соответствует каким-то изменениям в физическом процессе, и выходной сигнал должен быть связан с этими же изменениями. Временная задержка от получения входного сигнала до выдачи выходного сигнала должна быть небольшой, чтобы обеспечить приемлемое время реакции. Время реакции является системной характеристикой: при управлении ракетой требуется реакция в течении нескольких миллисекунд, тогда как для диспетчерского управления движением пароходов требуется время реакции, измеряемое днями. Системы обычно считаются системами реального времени, если время их реакции имеет порядок миллисекунд; диалоговыми считаются системы с временем реакции порядка нескольких секунд, а в системах пакетной обработки время реакции измеряется часами или днями. Примерами систем реального времени являются системы управления физическими процессами с применением вычислительных машин, системы торговых автоматов, автоматизированные системы контроля и автоматизированные испытательные комплексы.
AVK>Гы. Здорово от твоих заявлений однако отличается.
Нюню. А посмотри, как я выделил
AVK>А насчет диалоговых чешуя редкостная. Диалоговые, это когда работа системы определяется
В твоей теории возможно и чушь.
AVK>взаимодействием с человеком. Попытки привязать это ко времени реакции — это такая иждея фикс была, что если компьютер реагирует за 1-2 секунды то она диалоговая. Связь именно такая, а не наоборот. Т.е. если комп реагирует за 1-2 секунды это не означает что система диалоговая. Слово само какое, ДИАЛОГ.
AVK>А еще наверное системы торговых автоматов это то где несомненно требуется реакция до десятка микросекунд.
Требуется ! Потому что они в огромную сеть объединены(от 1000 штук). Вот система управления этой сетью и является РВ.
AVK>
AVK>Режим реального времени [real time processing]. Режим обработки данных, при котором обеспечивается взаимодействие вычислительной системы с внешними по отношению к ней процессами в темпе, соизмеримом со скоростью протекания этих процессов.
AVK>ИМХО очень неплохое определение.
Неплохое, но не достаточное. По нему — 1 день уже реал тайм.
Нужно точно определить, в каком именно темпе. Мне нужен темп — 500 раз в секунда грабить видео поток. Как это сделать на NT, DOS или Linux ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Реальное время — это милисекуны. OE>Если нет — это интерактивная система. Вот ей то ДОС и является OE>Вот статья OE>http://www.ci.ru/inform15_97/kovrigin.htm
Т.е. по твоему ДОС на современном железе не в силах обеспечить время реакции измеряемое в милисекундах? Нда...
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Она не решает задач РВ. ТОлько задачи, похожие на фризер — простые, не требующие паралелизма с достаточно большим временим отклика. Для каких еще РВ можно применить ДОС ?
А что все на свете задачи сложные и требуют паралеллизма?
Здравствуйте, AndrewVK, Вы писали:
OE>>Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
AVK>А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
А попиксельно никогда не грабится. Все грабится блоками 24 раза в секунду.
OE>>Но сьъем кадра гарантировано за время до 5 милисекунд — устроит.
AVK>Ты не понял наверное. Схема такая — сигнал с видеокамеры идет в комп, в компе обрабатывается и идет дальше. Все в реальном времени.
Реальный мастаб требует описания времени задержки.
Реальный — НЕ ДИСКРЕТНЫЙ. Посколько в компьютере нельзя устранить дискретность, реальное время аппроксимируется малой дискретностью.
OE>>Это много.
AVK>Блин, ну достал ты уже? Что значит много? Мешок картошки это много? Для ужина очень много, а на год мизер. Так и здесь — много или мало зависит от задачи, а не от того что тыы постановил что по сю пору считать мало, а далее много.
Я тебе сказал меньше 10 милисекунд — это реалтайм.
150 милисекунд — это не реалтайм. Здесь все точно.
OE>> Надо единицы милимекунд и гарантированно ! AVK>Кому надо?
OE>>А в NT время отклика — случайная величина.
AVK>В любой многозадачной ОС время отклика случайная величина.
Естественно, только в ОСРВ дисперсия времени отклика стремится к нулю.
OE>>http://www.rts-ukraine.com/QNXvsNT.htm
AVK>Тебе тоже статей накидать? Читать будешь?
Буду, если по теме.
OE>>Это не я придумал, прочитай об этом в тех ссылках, что я привел. AVK>Мне это сейчас не интересно
OE>>Есть "Теория операционных систем", AVK>Во как! Я вот первый раз о такой слышу. Теория! Звучит!
OE>>В этом определении ошибка — это определение годится для диалоговых ОС. AVK>Ну да, я хоть источник привел. Но в определении конечно ошибка. Вот это и есть самая настоящая демагогия.
OE>>Я тебе приводил классификацию — там и смотри. AVK>Ты сюда давай.
OE>>OCРВ — это физические процессы, ракеты, самолеты, конвейеры, реакторы.
AVK>Вот я и говорю — раз РВ так сразу самолеты, реакторы, ракеты. Фигню ты говоришь. AVK>Ладно, вот тебе еще один проект, который я лично делал. Как раз с физическим процессом. AVK>Система обнаружения утечек. Обнаруживает место утечки в трубопроводе с нефтепродуктом по разности времени прихода волны давления в разные точки. В ТЗ точность определения 500м. Скорость звука в керосине почти 900 м/с. Вот и посчитай. Работало на NT.
Меня интересует время отклика в системе. В твоем случае 500/900 ~ 0.5c.
Это не реалтайм.
Вообще, я не понял, по твоему NT — ОСРВ? Это уже новость !
AVK>Да, фризер это тоже часть роботизированного конвеера, так что под твое определение подходит.
OE>>А про Рубикон — почему ты не полез в толковый словарь Даля ? OE>>Данный вопрос надо стотреть в научной литературе и только.
AVK>Статьи в в поплулярных журналах тоже на научную литературу не катят. У тебя есть более авторитетное мнение — приводи, только не забывай источники указывать.
Я тебе привел, ты их проигнорировал.
А от тебя ссылок, кроме Рубикона, я не видел.
Здравствуйте, VladD2, Вы писали:
OE>>Она не решает задач РВ. ТОлько задачи, похожие на фризер — простые, не требующие паралелизма с достаточно большим временим отклика. Для каких еще РВ можно применить ДОС ?
VD>А что все на свете задачи сложные и требуют паралеллизма?
Для одного датчика не надо паралеллизма. А если 100 датчиков ?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
VD>Ты бы свой же линк прочел. Но не формально. Заметил там слово "обычно".
А ты мои остальные линки прочитай еще.
Там точные цифры есть
Еще раз РВ — непрерывное время, но, в силу дискретности компьютера, мелкодискретное время.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Пример — OS/2 при сколь угодно большой загрузке процессора(ну почти) можно перегрузить нажатием клавиш Ctrl-Alt-Del. OE>OS/2 — не является ОС РВ. Но ОС с элементами РВ. И это уже чувтвуется. Мультизадачность гораздо лучше, чем в NT.
Нда. Маразм крепчал... Полуось пол жизни имела одну очередь сообщений на все задачи. И если кто-то вис, то ее не то что перегрузить, ее даже окликнуть нельзя. Да и "перегрузить" — это конечно зачатки РВ. Так на каждой машине есть резет, значичь они все...
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
OE>А попиксельно никогда не грабится. Все грабится блоками 24 раза в секунду.
Грабится так как необходимо. В этом конкретном случае грабилось блоками по паре килобайт.
OE>Реальный мастаб требует описания времени задержки. OE>Реальный — НЕ ДИСКРЕТНЫЙ. Посколько в компьютере нельзя устранить дискретность, реальное время аппроксимируется малой дискретностью.
Скажем так, результат вычислений использовался для приведение в действие некоего механизма с определенной скорострельностью. Большего не скажу.
OE>Я тебе сказал меньше 10 милисекунд — это реалтайм. OE>150 милисекунд — это не реалтайм. Здесь все точно.
Ну раз ты сказал, то падаем ниц.
OE>Это не реалтайм.
Ну раз ты сказал то см. выше
OE>Вообще, я не понял, по твоему NT — ОСРВ? Это уже новость !
Нет, я тебе просто пытаюсь объяснить что нет никаких таких ОС реального времени. Есть ОС, больше или меньше приспособленые к задачам РВ.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>Да мне как то не надо сейчас. А непрерывного времени в цифровых системах не может быть в принципе.
OE> OE>Естественно !
Здравствуйте, VladD2, Вы писали:
VD>Нда. Маразм крепчал... Полуось пол жизни имела одну очередь сообщений на все задачи. И если кто-то вис, то ее не то что перегрузить, ее даже окликнуть нельзя. Да и "перегрузить" — это конечно зачатки РВ. Так на каждой машине есть резет, значичь они все...
Да, я вот пытался намекнуть, мол не надо про полумуха, человек толи не услышал толи не захотел. В качестве ОС РВ полумух много хуже NT, там точно нифига не гарантировано.
Здравствуйте, AndrewVK, Вы писали:
AVK>Выводы AVK>-------------------------------------------------------------------------------- AVK>Из приведенных выше цитат можно сделать выводы:
AVK>термин «система реального времени» в настоящее время может быть записан так: “Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в которое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы”. AVK>Для того, чтобы система могла удовлетворить требованиям, предъявляемым к системам реального времени, аппаратные, программные средства и алгоритмы работы системы должны гарантировать заданные временные параметры реакции системы. Время реакции не обязательно должно быть очень маленьким, но оно должно быть гарантированным (и отвечающим поставленным требованиям);
очень маленьким — это насколько маленьким ? милисекунды — это не много.
Очень малое в QNX, например, микросекунды — одно из самых маленьких.
Вот из этой же статьи
"Временная задержка от получения входного сигнала до выдачи выходного сигнала должна быть небольшой, чтобы обеспечить приемлемое время реакции"
диалоговыми считаются системы с временем реакции порядка нескольких секунд
AVK>использование термина «система реального времени», определенного выше, для обозначения интерактивных и высокопроизводительных систем неверно;
Вот я вот и думаю, что раз ты назвал NT ОСРВ, то не спутал ли ты что ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>А насчет диалоговых чешуя редкостная. Диалоговые, это когда работа системы определяется
OE>В твоей теории возможно и чушь.
При чем тут моя теория. В третий раз уже советую тебе посмотреть в словаре слово интерактивный.
AVK>>взаимодействием с человеком. Попытки привязать это ко времени реакции — это такая иждея фикс была, что если компьютер реагирует за 1-2 секунды то она диалоговая. Связь именно такая, а не наоборот. Т.е. если комп реагирует за 1-2 секунды это не означает что система диалоговая. Слово само какое, ДИАЛОГ.
Ы?
AVK>>А еще наверное системы торговых автоматов это то где несомненно требуется реакция до десятка микросекунд.
OE>Требуется ! Потому что они в огромную сеть объединены(от 1000 штук). Вот система управления этой сетью и является РВ.
А чего 1000? Давай уж 100000.
AVK>>ИМХО очень неплохое определение.
OE>Неплохое, но не достаточное. По нему — 1 день уже реал тайм.
Ты знаешь, да.
OE>Нужно точно определить, в каком именно темпе.
У блин. ОТ ЗАДАЧИ ЭТО ЗАВИСИТ!!! Рекламу билайна видел? Столько сколько надо. Не больше и не меньше
OE>Мне нужен темп — 500 раз в секунда грабить видео поток. Как это сделать на NT, DOS или Linux ?
... Полуось пол жизни имела одну очередь сообщений на все задачи. И если кто-то вис, то ее не то что перегрузить, ее даже окликнуть нельзя. Да и "перегрузить" — это конечно зачатки РВ. Так на каждой машине есть резет, значичь они все...
Не спутал ли ты ее с Win 3.11 ?
Цифры, цифры — какую версию ты юзал и сколько ? Начиная с Warp 3.0 Connect свалить ее очень сложно.
OS/2 Warp 4 Merlin более устойчивая, чем WinNT4.
Под ней специально написаны отладчики для ДОС — в окошко можно загрузиться с дискеты и из другого окна продебажить все что угодно.
Можно виртуальный IPX устроить.
Там даже WIN311 лучше работает.
А Presentation Manager гораздо устойчивее Виндошного GUI.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, я тебе просто пытаюсь объяснить что нет никаких таких ОС реального времени. Есть ОС, больше или меньше приспособленые к задачам РВ.
А ты набери в Гугле "операционная ситема реального времени".
Неужели есть такая система — QNX?
Здравствуйте, AndrewVK, Вы писали:
VD>>Нда. Маразм крепчал... Полуось пол жизни имела одну очередь сообщений на все задачи. И если кто-то вис, то ее не то что перегрузить, ее даже окликнуть нельзя. Да и "перегрузить" — это конечно зачатки РВ. Так на каждой машине есть резет, значичь они все...
AVK>Да, я вот пытался намекнуть, мол не надо про полумуха, человек толи не услышал толи не захотел. В качестве ОС РВ полумух много хуже NT, там точно нифига не гарантировано.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Под ней специально написаны отладчики для ДОС — в окошко можно загрузиться с дискеты и из другого окна продебажить все что угодно. OE>Можно виртуальный IPX устроить.
OE>Там даже WIN311 лучше работает.
OE>А Presentation Manager гораздо устойчивее Виндошного GUI.
Ты баки не забивай. Плавали, знаем. Одна и та же машинка раз в неделю под замечательным мерлином валилась, а под NT4 потом месяцами работала.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>взаимодействием с человеком. Попытки привязать это ко времени реакции — это такая иждея фикс была, что если компьютер реагирует за 1-2 секунды то она диалоговая. Связь именно такая, а не наоборот. Т.е. если комп реагирует за 1-2 секунды это не означает что система диалоговая. Слово само какое, ДИАЛОГ.
Ты кредиткой пользуешься ? Если банкомат заставит карточку ждать пол часа из-за того, что в Москве или еще где перегружена сеть, тебе понравится ? Или гарантирует через неделю, после инкассации ?
Потому и требуется малое время отклика для системы банкоматов, торговых автоматов и всяких других
OE>>Неплохое, но не достаточное. По нему — 1 день уже реал тайм.
AVK>Ты знаешь, да.
Нет. Ты разницу между целыми числами и с плавающей запятой видишь ?
Те, что с плавающей запятой тоже дискретные. Но они больше похожи на реальные числа, например на абсолютной оси координат.
Здравствуйте, AndrewVK, Вы писали:
OE>>очень маленьким — это насколько маленьким ? милисекунды — это не много.
AVK>Вот вот. Задумайся над этим.
OE>>Очень малое в QNX, например, микросекунды — одно из самых маленьких.
AVK>Ага, а завтра на новых компах с какой нибудь ОС обеспечили реакцию единицы наносекунд? QNX резко перестанет быть ОСРВ?
Не переживай, это будет именно QNX.
Сейчас для РВ нужны милисекунды. Часы, дни — это уже прошлый этап.
Здравствуйте, AndrewVK, Вы писали:
OE>>Там даже WIN311 лучше работает.
OE>>А Presentation Manager гораздо устойчивее Виндошного GUI.
AVK>Ты баки не забивай. Плавали, знаем. Одна и та же машинка раз в неделю под замечательным мерлином валилась, а под NT4 потом месяцами работала.
Вообще OS\2 более капризна к железу.
На нормальном все было путем. Я за два года ни разу не переставлял свою.
Хотя использовал каждый день.
Здравствуйте, AndrewVK, Вы писали:
OE>>Неужели в твоем фризере был только один датчик ?
OE>>Еще, ты можешь мне временные параметры дать ?
AVK>Зачем? Порядка сотни миллисекунд.
Это уже не реалтайм, извини. ((
Единицы милисекунд — это тот порог, который надо перешагнуть, чтобы получить ралтайм
Здравствуйте, AndrewVK, Вы писали:
OE>>Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
AVK>А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
А попиксельно никогда не грабится. Все грабится блоками 24 раза в секунду.
OE>>Но сьъем кадра гарантировано за время до 5 милисекунд — устроит.
AVK>Ты не понял наверное. Схема такая — сигнал с видеокамеры идет в комп, в компе обрабатывается и идет дальше. Все в реальном времени.
Реальный мастаб требует описания времени задержки.
Реальный — НЕ ДИСКРЕТНЫЙ. Посколько в компьютере нельзя устранить дискретность, реальное время аппроксимируется малой дискретностью.
OE>>Это много.
AVK>Блин, ну достал ты уже? Что значит много? Мешок картошки это много? Для ужина очень много, а на год мизер. Так и здесь — много или мало зависит от задачи, а не от того что тыы постановил что по сю пору считать мало, а далее много.
Я тебе сказал меньше 10 милисекунд — это реалтайм.
150 милисекунд — это не реалтайм. Здесь все точно.
OE>> Надо единицы милимекунд и гарантированно ! AVK>Кому надо?
OE>>А в NT время отклика — случайная величина.
AVK>В любой многозадачной ОС время отклика случайная величина.
Естественно, только в ОСРВ дисперсия времени отклика стремится к нулю.
OE>>http://www.rts-ukraine.com/QNXvsNT.htm
AVK>Тебе тоже статей накидать? Читать будешь?
Буду, если по теме.
OE>>Это не я придумал, прочитай об этом в тех ссылках, что я привел. AVK>Мне это сейчас не интересно
OE>>Есть "Теория операционных систем", AVK>Во как! Я вот первый раз о такой слышу. Теория! Звучит!
OE>>В этом определении ошибка — это определение годится для диалоговых ОС. AVK>Ну да, я хоть источник привел. Но в определении конечно ошибка. Вот это и есть самая настоящая демагогия.
OE>>Я тебе приводил классификацию — там и смотри. AVK>Ты сюда давай.
OE>>OCРВ — это физические процессы, ракеты, самолеты, конвейеры, реакторы.
AVK>Вот я и говорю — раз РВ так сразу самолеты, реакторы, ракеты. Фигню ты говоришь. AVK>Ладно, вот тебе еще один проект, который я лично делал. Как раз с физическим процессом. AVK>Система обнаружения утечек. Обнаруживает место утечки в трубопроводе с нефтепродуктом по разности времени прихода волны давления в разные точки. В ТЗ точность определения 500м. Скорость звука в керосине почти 900 м/с. Вот и посчитай. Работало на NT.
Меня интересует время отклика в системе. В твоем случае 500/900 ~ 0.5c.
Это не реалтайм.
Вообще, я не понял, по твоему NT — ОСРВ? Это уже новость !
AVK>Да, фризер это тоже часть роботизированного конвеера, так что под твое определение подходит.
OE>>А про Рубикон — почему ты не полез в толковый словарь Даля ? OE>>Данный вопрос надо стотреть в научной литературе и только.
AVK>Статьи в в поплулярных журналах тоже на научную литературу не катят. У тебя есть более авторитетное мнение — приводи, только не забывай источники указывать.
Я тебе привел, ты их проигнорировал.
А от тебя ссылок, кроме Рубикона, я не видел.
Здравствуйте, AndrewVK, Вы писали:
OE>>Неужели в твоем фризере был только один датчик ?
AVK>Нет, их там десятка два наверное.
OE>>Еще, ты можешь мне временные параметры дать ?
AVK>Зачем? Порядка сотни миллисекунд.
Для Solaris время "захвата" лежит в диапазоне 10-50 мксек в зависимости от версии ОС и является необходимым условием при работе в режиме реального времени, так называемый "мягкий" режим реального времени. Требования к ОС , способной работать в таком режиме, описываются стандартом POSIX 1003.1b и ОС Solaris удовлетворяет требованиям этого стандарта (POSIX 1003.1b, draft 14).
Здравствуйте, AndrewVK, Вы писали:
OE>>Неужели в твоем фризере был только один датчик ?
AVK>Нет, их там десятка два наверное.
OE>>Еще, ты можешь мне временные параметры дать ?
AVK>Зачем? Порядка сотни миллисекунд.
Вот сравни фризер с этой штукой
Общая характеристика (для одного узла):
— общее число двоичных датчиков в системе — до 5000 ;
— общее число исполнительных устройств — до 3200;
— число независимых процессов, работающих одновременно — до 70;
— максимальное регламентируемое время реакции системы
— не более 0.5сек (реальное время до 0.2сек);
Первая реализация АСУТП на основе CF-MNTR — 1989-1990гг.
В настоящее время на основе CF-MNTR реализовано 9 подобных систем на предприятиях, перерабатывающих сельскохозяйственные продукты.
В первой реализации применялись технологические контроллеры, разработанные и изготовленные фирмой, внедрявшей автоматичесую систему управления технологическими процессами (АСУТП) на предприятии. В 1994г. при модернизации системы установлены контроллеры на базе процессоров i8086. В других реализациях вместе с этими контроллерами применялись контроллеры, разработанные на базе процессоров фирмы Microchip PIC16C64/PIC16C74. Линии связи в этих реализациях используют стандарт RS485 (в первой реализации RS232).
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, AndrewVK, Вы писали:
OE>>>Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
AVK>>А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
OE>А попиксельно никогда не грабится. Все грабится блоками 24 раза в секунду.
Тогда, извини, данные ядерных испытаний грабятся раз в несколько месяцев. Это не реальное время.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Ты кредиткой пользуешься ? Если банкомат заставит карточку ждать пол часа из-за того, что в Москве или еще где перегружена сеть, тебе понравится ? Или гарантирует через неделю, после инкассации ? OE>Потому и требуется малое время отклика для системы банкоматов, торговых автоматов и всяких других
???? Какое там время отклика? Ты банкоматом пользовался хоть раз? Там речь вообще не идет ни о каких миллисекундах. Термин "реальное время" означает только то, что сказал AVK. То есть значение времени отклика определяется задачей. В бизнес-системах (например, для тех же банкоматов) реальное время означает реакцию в пределах нескольких секунд. Практика это подтверждает. Так что приведенные тобою аргументы свидетельствуют не в твою пользу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Здравствуйте, AndrewVK, Вы писали:
VD>>>Т.е. по твоему ДОС на современном железе не в силах обеспечить время реакции измеряемое в милисекундах? Нда...
OE>Обеспечить можно, гарантировать ответ нельзя.
Можно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
S>???? Какое там время отклика? Ты банкоматом пользовался хоть раз? Там речь вообще не идет ни о каких миллисекундах. Термин "реальное время" означает только то, что сказал AVK. То есть значение времени отклика определяется задачей. В бизнес-системах (например, для тех же банкоматов) реальное время означает реакцию в пределах нескольких секунд. Практика это подтверждает. Так что приведенные тобою аргументы свидетельствуют не в твою пользу.
ОСРВ стоит не в банкомате — а на сервере, который обрабатывает запросы с банкоматов. Вот там — критично время отклика
Здравствуйте, Sinclair, Вы писали:
OE>>Здравствуйте, AndrewVK, Вы писали:
VD>>>>Т.е. по твоему ДОС на современном железе не в силах обеспечить время реакции измеряемое в милисекундах? Нда...
OE>>Обеспечить можно, гарантировать ответ нельзя.
S>Можно.
Тогда приведи мне мне средство ДОС благодаря которому ты можешь гарантировать ответ.
В ДОС реалтайм не благодаря, а вопреки. Потому, что ДОС не защищает ничего и ты имеешь полный доступ к аппаратуру.
А в самом ДОС нет ни одного встроенного средства для обеспечения РВ !
Здравствуйте, Sinclair, Вы писали:
OE>>Ты кредиткой пользуешься ? Если банкомат заставит карточку ждать пол часа из-за того, что в Москве или еще где перегружена сеть, тебе понравится ? Или гарантирует через неделю, после инкассации ? OE>>Потому и требуется малое время отклика для системы банкоматов, торговых автоматов и всяких других
S>???? Какое там время отклика? Ты банкоматом пользовался хоть раз? Там речь вообще не идет ни о каких миллисекундах. Термин "реальное время" означает только то, что сказал AVK. То есть значение времени отклика определяется задачей. В бизнес-системах (например, для тех же банкоматов) реальное время означает реакцию в пределах нескольких секунд. Практика это подтверждает. Так что приведенные тобою аргументы свидетельствуют не в твою пользу.
У меня VISA Electron. Пользуюсь постоянно. Так вот.
Система бонкоматов != система в банкомате.
Система управления всеми банкоматами — сетевая система РВ.
И эта система РВ постоена на ОСРВ.
Для одного банкомата — секунды. А для сервера — гораздо меньше.
Здравствуйте, Sinclair, Вы писали:
OE>>>>Видеопоток — нужна производительность и только, частота опроса — 24 раза в секунду — это не реальный режим времени.
AVK>>>А чего это ты кадры считаешь? Ты пиксельную частоту посчитай.
OE>>А попиксельно никогда не грабится. Все грабится блоками 24 раза в секунду. S>Тогда, извини, данные ядерных испытаний грабятся раз в несколько месяцев. Это не реальное время.
Ты с чем не согласен ? AVK сам сказал, что грабится пачками. Только несколько позже
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>У меня VISA Electron. Пользуюсь постоянно. Так вот. OE>Система бонкоматов != система в банкомате. OE>Система управления всеми банкоматами — сетевая система РВ. OE>И эта система РВ постоена на ОСРВ. OE>Для одного банкомата — секунды. А для сервера — гораздо меньше.
Ну да. В принципе, добавляется еще время на доставку пакета туда-обратно, плюс тормоза локального проца при проворачивании интерфейса.
Так вот, как человек, который занимался интеграцией с системами платежей в реальном времени, я тебе скажу, что типичное время обработки одной транзакции от 200 до 1500 миллисекунд. На сервере. И никто не собирается делать его сильно меньше. Потому, что там критична пропускная способность, а не время одной транзакции. То, что сервак протягивает 10000 транзакций в секунду не означает, что длительность каждой равна 100мкс. И такие большие, с твоей точки зрения, времена не означают, что это "не риал тайм". С точки зрения бизнеса это — самый что ни на есть риалтайм.
Пользуюсь RSDN@Home 1.0 alpha 15, слушая C uibul — Cuibul
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
VD>>Т.е. по твоему ДОС на современном железе не в силах обеспечить время реакции измеряемое в милисекундах? Нда...
AVK>Да я вобще непонимаю из какого пальца высосали эти единицы миллисекунд.
Если бы ты просмотрел хотя бы ссылки мои:
Принято различать системы "мягкого" и "жесткого" реального времени (РВ). Система "Жесткого" РВ — система, где неспособность обеспечить реакцию на какие-либо события в заданное время является отказом и ведёт к невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами "мягкого" РВ называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы "мягкого" РВ могут не успевать решать задачу, но в зависимости от функции, выполняемой системой, задержка выполнения может быть различной.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
AVK>>Да я вобще непонимаю из какого пальца высосали эти единицы миллисекунд.
OE>Если бы ты просмотрел хотя бы ссылки мои:
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Да я вобще непонимаю из какого пальца высосали эти единицы миллисекунд. OE>>Если бы ты просмотрел хотя бы ссылки мои: AVK>Вот в твоих ссылках тое все из пальца высосано.
Та ссылка, что я тебе дал — это специализированный сайт по системам реального времени и QNX.
Укажи тогда источник, который позволит считать обратное — только не рубикон и не словарь Даля.
Я топик както кинул по реальному времени. Можешь туда глянуть для общего развития.
Здравствуйте, Dmitry A. Sustretov, Вы писали:
DAS>Пара вопросов по архитектуре микроядра.
DAS>1) почему микроядро — это хорошо ? DAS>2) почему микроядро не медленнее традиционных ядер ? DAS>3) каким (эффективным) образом реализуется механизм доставки сообщений серверам ? DAS>4) есть ли реализации микроядра второго поколения (микромикроядра) ?
Друзья, а не переливаете ли вы из пустого в порожнее?
Давайте условимся, что:
1. Система реального времени — эта такая система, для которой предельное время отклика на каждое событие детерминировано. И не статистически, а жестко.
2. Система жесткого реального времени — это система, не нарушающая предельное время отклика ни при каких обстоятельствах. Система мягкого реального времени — может нарушать.
3. Соответственно, ОС жесткого реального времени строятся по совсем другим законам, нежели обычные: статическая архитектура, статическое планирование и т.д. Ни одна из перечисленных вами систем (за исключением QNX, да и то не совсем) системой жесткого реального времени не является.
4. ОС мягкого реального времени — любая ОС. В зависимости от принятой схемы диспетчеризации и планирования, "реальность" может варьироваться от "очень мягкой" до "весьма неплохой". Но в любом случае система, не гарантирующая 100% детерминизм предельного времени отклика не может использоваться для задач жесткого реального времени.
5. Задачи жесткого реального времени — преимущественно задачи управления критическими процессами. Задачи обработки видео и вообще большинство "обычных" задач — задачи мягкого РВ. Соответственно в большей или меньшей степени для этих задач подходят юниксы, линуксы и виндоусы всех мастей.
6. Кстати, NTшные реалтайм потоки — это попытка создать "почти жесткое" реальное время. Вот только спецификация диспетчера все равно не гарантирует детерминизма предельного времени отклика (хотя на практике оно и обеспечивается), а планировщик не рассчитан на статическое планирование.
Здравствуйте, WildCat, Вы писали:
WC>Друзья, а не переливаете ли вы из пустого в порожнее?
Уважаемый, не могли бы Вы не кричать в форуме? Если Вы думаете, что без употребления жирного шрифта Вас никто читать не будет — лучше уделите время качеству постингов. Спасибо.
... << RSDN@Home 1.0 beta 2 | слушаю Limp Bizkit — No sex>>
Вообще в литературе нет четкого определения "мягкого" реального времени. Все в основном относится к жесткому, он же просто реалтайм.
Нашел более менее нормальное определение:
Система реального времени — система массового обслуживания с жестко детерминированным временем ответа.
В случае нарушения этого условия система выходит из строя.
Мягкий — допускаются некоторые задерки, сказывающиеся лишь на качестве выхода и к выходу системы из строя не ведут.
WC>2. Система жесткого реального времени — это система, не нарушающая предельное время отклика ни при каких обстоятельствах. Система мягкого реального времени — может нарушать.
В точку.
WC>3. Соответственно, ОС жесткого реального времени строятся по совсем другим законам, нежели обычные: статическая архитектура, статическое планирование и т.д. Ни одна из перечисленных вами систем (за исключением QNX, да и то не совсем) системой жесткого реального времени не является.
Согласен. ОС реального времени должна соответсвовать куче стандартов и требований.
WC>4. ОС мягкого реального времени — любая ОС. В зависимости от принятой схемы диспетчеризации и планирования, "реальность" может варьироваться от "очень мягкой" до "весьма неплохой". Но в любом случае система, не гарантирующая 100% детерминизм предельного времени отклика не может использоваться для задач жесткого реального времени.
Вот-вот !
WC>5. Задачи жесткого реального времени — преимущественно задачи управления критическими процессами. Задачи обработки видео и вообще большинство "обычных" задач — задачи мягкого РВ. Соответственно в большей или меньшей степени для этих задач подходят юниксы, линуксы и виндоусы всех мастей.
И фризер туда же, и датчик, и трубопровод. Для них и ДОС хватит.
WC>6. Кстати, NTшные реалтайм потоки — это попытка создать "почти жесткое" реальное время. Вот только спецификация диспетчера все равно не гарантирует детерминизма предельного времени отклика (хотя на практике оно и обеспечивается), а планировщик не рассчитан на статическое планирование.
Нужен кроме этого детерминизм всех системных вызовов и совсем другая схема диспетчеризации.
Для NT не указаваются временные параметры, например такие, как задержка обработки прерывания и тд.
А для ОС РВ это крайне важно.
А не указываются потому, что нет способа обеспечить это.
Для мелких задач NT сгодится. Особливо там, где задержка не играет роли.
Здравствуйте, orangy, Вы писали:
WC>>Друзья, а не переливаете ли вы из пустого в порожнее? O>Уважаемый, не могли бы Вы не кричать в форуме? Если Вы думаете, что без употребления жирного шрифта Вас никто читать не будет — лучше уделите время качеству постингов. Спасибо.
Здравствуйте, AndrewVK, Вы писали:
OE>>Что скажет AVK и Рубикон по этому поводу ?
AVK>А то что никто не говорил что ОС РВ это обязательно жесткий реалтайм.
Именно жесткий.
Под "мягкий" подойдет почти любая оса, дося или муха. Стоит ли говорить об этом ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Именно жесткий. OE>Под "мягкий" подойдет почти любая оса, дося или муха. Стоит ли говорить об этом ?
Когда разговор шел, он шел о просто реальном времени, а значит и о мягком тоже. Не надо стрелки теперь переводить. Под NT и DOS могут решаться задачи реального времени. С остальным никто и не спорил.
Здравствуйте, AndrewVK, Вы писали:
AVK>Когда разговор шел, он шел о просто реальном времени, а значит и о мягком тоже. Не надо стрелки теперь переводить. Под NT и DOS могут решаться задачи реального времени. С остальным никто и не спорил.
Реальное время обычно жесткое. Посмотри мои примеры и ссылки(хотя бы ту одну, что ты цитировал).
А то, что "Под NT и DOS могут решаться задачи реального времени"
1. Есть такие штаны, которые одеваются через голову. Натягиваешь их, застегиваешь и все. Замок просто хитрый — была юбка, стали штанины.
2. ДОС является только загрузчиком программного кода. И реалтайм обеспечивается не благодаря, а вопреки — сам ДОС для РВ ничего не предоставляет.
3. NT в чистом виде может использоваться не многим лучше ДОС.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
OE>Реальное время обычно жесткое. Посмотри мои примеры и ссылки(хотя бы ту одну, что ты цитировал).
Обычно не катит. Я тебе гору примеров привел.
OE>1. Есть такие штаны, которые одеваются через голову. Натягиваешь их, застегиваешь и все. Замок просто хитрый — была юбка, стали штанины.
Задачи РВ не сами по себе живут. Написание удобных интерфейсов под wxWorks тоже надевание штанов через голову.
OE>3. NT в чистом виде может использоваться не многим лучше ДОС.
Надоел уже. Тебе говорят что решали задачи реального времени времени. А уж какое оно там — мягкое или жесткое это уже другой вопрос.
Все, надоела мне эта демагогия — не хочешь признавать реальные факты, не признавай. Мне все равно.
Здравствуйте, AndrewVK, Вы писали:
OE>>Реальное время обычно жесткое. Посмотри мои примеры и ссылки(хотя бы ту одну, что ты цитировал). AVK>Обычно не катит. Я тебе гору примеров привел.
Три — фризер + газопровод + видеопоток.
Нет оснований считать это реалтаймом.
Ибо система не выйдет из строя в случае задержки. В случае с реактором — задержка введения графитовых стержней чревата ядерным взрывом — налицо выход системы из строя.
То, что ты привел — это "мягкий". Такие реалтаймы везде есть. Незачем выделять группу систем по какомуто параметру, если этим параметром обладают все системы.
AVK>Надоел уже.
Что поделаешь, я сварливый чел и люблю докапываться до истины.
AVK>Тебе говорят что решали задачи реального времени времени. А уж какое оно там — мягкое или жесткое это уже другой вопрос.
Вот на него я хочу найти ответ. С моей точки зрения реальное время — только жесткое. Это диктует не разработчик, а внешняя среда.
Все остальное — не считается таковым.
AVK>Все, надоела мне эта демагогия — не хочешь признавать реальные факты, не признавай. Мне все равно.
. По моему, системы, построенные строго по принципу микроядра, непрактичны из-за слишком низкой эффективности.
Так на каждой машине есть резет, значичь они все... 
((
