Современные технологии автоматизации» («СТА») —  журнал для квалифицированных специалистов по промышленной автоматизации Форум СТА — современные технологии автоматизации Домашняя страница
Домашняя страница форума CTA Домашняя страница форума CTA > II. АСУТП и SCADA > Архив
  Активные темы Активные темы
  FAQ FAQ  Искать в форуме   Зарегистрироваться Зарегистрироваться  Вход в систему Вход в систему

реал тайм осы

 Ответить Ответить Страница  <1 2223242526 36>
Автор
Сообщение
Draggan Смотреть выпадающим
Участник
Участник


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Тема сообщения: реал тайм осы
    Опубликовано: 22 Ноябрь 2003 18:28
Первоначально опубликовано Olej



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

Не думаю, что в системах, где самым важным фактором является надежность, причем не статистическая, а 100% надежность в ряде случаев, можно применять понятия дисперсии или СКО, Посмотрите пункт 5 моего сообщения: МАКСИМАЛЬНОЕ время реакции должно быть постоянным в при любых условиях! Именно максимум, точнее не превышение его является параметром, гарантирующим надежность системы.
Draggan
Kharkov, QNX Seminars
Наверх
Draggan Смотреть выпадающим
Участник
Участник


Присоединился: 31 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 52
Свойства публикации Свойства публикации   Ответить, цитируя автора - Draggan Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 22 Ноябрь 2003 18:31
Первоначально опубликовано Sergey Sorokin


Я думаю Вы не случайно написали вслед этому дополненительное сообщение. Странно выглядит попытка определить термин "реальное время" без терминов относящихся просто ко "времени" (это слово составляет 50% от  термина "реальное время" :-)). Если бы для понимания термина понятие "время" было бы не нужно, то это слово в термине и не употреблялось бы (вместо "ОС Реального Времени" было бы что нибудь типа - "Реальная ОС" :-)).



Простите я не совсем понимаю, зачем определять темин сам через себя. Пожалуйста обратите внимание на это определение, в нем ведь действительно говорится о времени(только не прямо :) ) НО! Там не говорится о скорости!
Draggan
Kharkov, QNX Seminars
Наверх
Olej Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 22 Ноябрь 2003 22:02
Первоначально опубликовано Draggan

Не думаю, что в системах, где самым важным фактором является надежность, причем не статистическая, а 100% надежность в ряде случаев, можно применять понятия дисперсии или СКО, Посмотрите пункт 5 моего сообщения: МАКСИМАЛЬНОЕ время реакции должно быть постоянным в при любых условиях! Именно максимум, точнее не превышение его является параметром, гарантирующим надежность системы.


При некотором уровне сложности - детерминистские и вероятностные характеристики поведения системы - становятся "одно и то же самое".
Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 22 Ноябрь 2003 22:05
Первоначально опубликовано Draggan

Первоначально опубликовано evgen



Как раз это тут и подвергалось критике - и в отношении беспристрастности, качества, точности и т.п.
Если кратко и повторно - лапшу на уши можно вешать кому угодно, только не программистам (system programmer, system analitic) Без раскрытия методики, без исходников тестов - это однозначно лапша на уши. Или, если угодно - развесистая клюква.


Для сведений. Цитата взята из выложеной на сайте ДС статьи из Real-Time Magazine за 1998 год 3 номер. Автор Martin Timmerman главный редактор этого журнала.
Это первое.
Второе: На сайте ДС, адрес которого я указывал, присутствуют для свободного скачивания ряд документов, описывающих методику тестирования, в частности EVALUATION REPORT DEFINITION. Закачайте посмотрите. Масса вопросов отпадет сама собой.

И третье. Это здесь уже обсуждалось http://forum.cta.ru/forum_posts.asp?TID=122&PN=1&TPN=3
Для вас персональнов повторяю: Закачал и посмотрел. Ничего никуда не отпало, кроме вопроса об ангажированности.

При желании могу написать развернутую рецензию. Но с оплатой потраченного на это времени.
SY,
EK
Наверх
Olej Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 22 Ноябрь 2003 22:16
Первоначально опубликовано evgen

При желании могу написать развернутую рецензию. Но с оплатой потраченного на это времени.


Бог подаст.
Сын мой.
Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 22 Ноябрь 2003 22:21
Первоначально опубликовано Olej

Первоначально опубликовано evgen

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


А если, простите, ваша "система/аппарат, которой управляют не критична ко времени реакции" - то она никоим боком не относится к realtime.
И тогда вам с вашей системой - в другое место ;-) ... т.е. в другой форум нужно.


Я понял в чем ваши проблемы - вы категорически игнорируете тему микропроцессорных контроллеров, "умных" датчиков и исполнительных механизмов, сетей контроллеров и т.п. Т.е. видимо используете архитектурные решения двадцатилетней давности, где все делается в одном центральном компьютере.
А все что не укладывается в эту схему - тупые "механизированные матрешки", недостойные внимания высоколобых интеллектуалов.
SY,
EK
Наверх
Olej Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 14 Октябрь 2003
Категория: Ukraine
Online Status: Offline
Публикации: 267
Свойства публикации Свойства публикации   Ответить, цитируя автора - Olej Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 22 Ноябрь 2003 23:34
Первоначально опубликовано evgen


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


Где-то примерно так...
Но в этом - не "мои проблемы", в этом - проблемы механизированных матрёшек.
Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 23 Ноябрь 2003 00:52
Первоначально опубликовано Olej

Первоначально опубликовано evgen


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


Где-то примерно так...
Но в этом - не "мои проблемы", в этом - проблемы механизированных матрёшек.

Флаг в руки и барабан на шею. "И эти пещерные люди будут учить меня риалтайму" ?

Тот же горячо любимый вами dedicated-systems занимается более чем наполовину "механизированными матрешками", но зачем вам это знать ? У вас более глобальные проблемы - гады админы, понимаешь, поломали настройки "механизированной матрешки" - модема.
SY,
EK
Наверх
evgen Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 08 Сентябрь 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 178
Свойства публикации Свойства публикации   Ответить, цитируя автора - evgen Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 23 Ноябрь 2003 01:36
Первоначально опубликовано Draggan

Первоначально опубликовано evgen



Как раз это тут и подвергалось критике - и в отношении беспристрастности, качества, точности и т.п.
Если кратко и повторно - лапшу на уши можно вешать кому угодно, только не программистам (system programmer, system analitic) Без раскрытия методики, без исходников тестов - это однозначно лапша на уши. Или, если угодно - развесистая клюква.


Для сведений. Цитата взята из выложеной на сайте ДС статьи из Real-Time Magazine за 1998 год 3 номер. Автор Martin Timmerman главный редактор этого журнала.
Это первое.
Второе: На сайте ДС, адрес которого я указывал, присутствуют для свободного скачивания ряд документов, описывающих методику тестирования, в частности EVALUATION REPORT DEFINITION. Закачайте посмотрите. Масса вопросов отпадет сама собой.

Вот самые наивные, "детские" вопросы:
1) на каком компьютере проводились тесты ?
2) на какой конфигурации OSов проводились тесты ? Я вот например, люблю проводить тесты на домашнем компьютере, с кучей драйверов, звуком, сетью, интернетом, GUI-ем, кучей программ работающих одновременно. Ясен пень, что чем меньше всего загружено, тем меньше потерь на переключение задач.
3) какие такие проприетарные файловые системы использовались ?
4) что означает загадочная фраза "2 We were not able to mount a Hard Drive on the system" ? и о каком таком корректном сравнении может идти речь (см п2)
5) Какие кеши файловых систем использовались ?
6) Почему приведены только средние и максимальные значения измеренных величин ? дисперсия и минимальные значения тоже имеют значение, в частности, для оценки корректности теста
7) где исходники тестов и где есть гарантия, что в них нет ошибок ? Ну не знают люди тонкости линукса может быть, как не смогли прикрутить hdd к VxWorks
8) какой компилятор и с какими параметрами в каждом случае использовался ? Ну хотя бы для сборки тестов, ( хорошо бы знать это и для ядра ОС, библиотек и драйверов). Например, опции с использованием оптимизации, ММХ и прочего очень даже могут влиять на производительность
SY,
EK
Наверх
Sergey Sorokin Смотреть выпадающим
Действительный член
Действительный член


Присоединился: 27 Март 2003
Категория: Russian Federation
Online Status: Offline
Публикации: 240
Свойства публикации Свойства публикации   Ответить, цитируя автора - Sergey Sorokin Ответить, цитируя автора -  ОтветитьОтвет Прямая ссылка на эту публикацию Опубликовано: 23 Ноябрь 2003 02:15
Первоначально опубликовано Draggan

Первоначально опубликовано Sergey Sorokin


Я думаю Вы не случайно написали вслед этому дополненительное сообщение. Странно выглядит попытка определить термин "реальное время" без терминов относящихся просто ко "времени" (это слово составляет 50% от  термина "реальное время" :-)). Если бы для понимания термина понятие "время" было бы не нужно, то это слово в термине и не употреблялось бы (вместо "ОС Реального Времени" было бы что нибудь типа - "Реальная ОС" :-)).



Простите я не совсем понимаю, зачем определять темин сам через себя. Пожалуйста обратите внимание на это определение, в нем ведь действительно говорится о времени(только не прямо :) ) НО! Там не говорится о скорости!

Так и я нигде не говорил про скорость. Что касается определения терминов, то я постараюсь перефразировать мою мысль. Определять понятие "реальное время" без использования понятия "время", все равно что определять понятие "радиационная стойкость" не используя понятие "радиация".

 Не хотел я ввязываться опять в эту дискуссию :-).

 

>Системы реального времени: Системы, которые предсказуемо реагируют на

>непредсказуемые события. (Real-time systems: systems that respond in a predictable way to

>unpredictable external events.)

>Что можно сказать, кратко и красиво! И уже не попадают сюда текстовые редакторы.

>Всякая неопределенность связанная со временем исчезла. РВ действительно в первую

>очередь подразумевает не скорость, а надежность, причем невероятно высокую,

>>>>>>>>>>>>>>>>>>>>>>>>

Да, сказано красиво. Примерно как «коммунизм = советская власть + электрификация всей страны». Велик соблазн иметь простые определения для сложных понятий.

1)       Текстовые редакторы под это определение как раз хорошо подходят. Если я нажимаю клавишу, то на экране вполне предсказуемо появится буква (программа просто не знает точно КОГДА я эту клавишу нажму).

2)       Не понял где Вы увидели в этом определении хотя бы намек на надежность. «Предсказуемость», «надежность» и «безошибочность» не являются синонимами. Кроме того РВ как таковое ничего не подразумевает пока его не приклеить к какому нибудь существительному (ОСРВ или СРВ).

3)       Действительно неопределенность со временем исчезла вместе с самим упоминанием времени. В определении можно косвенно угадать что существует прошлое и будущее и не более того. Этого совсем не достаточно.

4)       Как понять что такое «предсказуемость» и «непредсказуемость» внешних событий? Например тот же редактор знает (ожидает) что пользователь может нажать клавишу. То есть это событие само по себе является «предсказуемым». Редактор только не знает точно когда это событие произойдет.  Аналогично в АСУ ТП котла событие превышения значения температуры в котле является предсказуемым в том смысле, что система разрабатывается с учетом возможности этого события. Неизвестно только время когда оно произойдет. То есть это событие нельзя назвать не только непредсказуемым, но даже и неожиданным.  Непредсказуемым для АСУ ТП можно назвать такое событие, возможность которого не учитывалась при разработке АСУ ТП (скажем удар молнии в контроллер).

5)       Теперь про «предсказуемость» реакции системы. Это не то же самое что «детерминированность» или точнее «временнАя детерминированность».  Скажем при превышении температуры котла система предсказуемо уменьшит подачу топлива. Однако если это уменьшение произошло не ВОВРЕМЯ, то котел взорвется. Часто требуется временнАя детерменированность не только в смысле максимального времени задержки, но и в смысле попадания во временнОй интервал. Скажем реакция системы должна последовать в интервале между 5 и 6 мсек после какого либо события.  То есть если не определить, что понятие предсказуемости относятся именно ко времени возникновения событий, то это определение вообще не имеет смысла. С точки зрения русского языка этот термин неудачен так как ассоциируется с гадалками. Более удачен термин «детерминированность», который к тому же ассоциируется с определенной метрикой. То есть ее можно измерить и на этой основе классифицировать различные системы. Словосочетание «измерить степень предсказуемости» у меня например вызывает отторжение. Хотя конечно – это дело вкуса.

 

 

>Однако такое определение не раскрывает параметров RTOS системы. Смотрим

>следующий раздел: MINIMUM RTOS FEATURES

>>>>>>>>>>>>>>>>>>>>>>>>>.

Хочу отметить, что предыдущее определение давалось для СРВ, а не для ОСРВ.



>Для обеспечения предсказуемости системы ДС считают необходимым наличие у нее

>следующий свойств:
>1. Многозадачность (или поточность) и вытесняющее управление приоритетами. (Multi-

>tasked (or threaded) and pre-emptible priority driven.)

>>>>>>>>>>>>>>>>>>>>>>

Это никак не связано с предсказуемостью или детерминированностью. Однозадачная система является предсказуемой, многозадачная система с планировщиком time slicing является предсказуемой. Любая программная система является предсказуемой покуда не использует для планирования своих действий аппаратных датчиков случайных чисел. Другое дело, что анализ многозадачной системы в условиях отсутствия подробной документации по ОС, и/или в условиях применения программ третьих производителей является очень трудной задачей. Более того, предсказуемость поведения ОС еще не означает предсказуемости поведения какого либо конкретного процесса, так как процесс делит ресурсы и сервисы ОС с другими процессами,  активность которых может зависеть от случайно сложившихся внешних факторов. В системах с вытесняющей многозадачностью в общем случае только одна задача, имеющая наивысший по сравнению со всеми другими задачами приоритет, может быть предсказуемой/детерминированной (с точностью до возможных проблем с инверсией приоритетов). 

>2.Должно существовать понятие приоритетов задач (потоков) и должно быть доступно

>достаточно большое количество уровней приоритетов (количество зависит от сложности

>задачи). (The notion of task (thread) priority has to exist and sufficient priority levels need to be

>available (depends on the complexity of the application).)

>>>>>>>>>>>>>>>>>>>>>>>>>

Это так же не связано с предсказуемостью. Наилучшая общая предсказуемость (не скорость) у одноприоритетных процессов с планировкой в стиле round-robin. Я бы советовал там, где можно, использовать не более 3 приоритетов (задачи «жесткого реального времени», «мягкого реального времени» и «фоновые» задачи). Иначе при большом количестве задач с приоритетами можно «перемудрить» и в результате какая нибудь нужная задача будет «поражена в правах».


>3. Операционная система должна поддерживать прогнозируемые механизмы

>синхронизации потоков (семафоры, мютексы, события и т.д.). (The OS has to support

>predictable thread synchronization mechanisms (semaphores, mutexes, events, etc).)

>>>>>>>>>>>>>>>>>>>>>>>>>>

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


>4. Необходимо наличие механизмов решения задачи инверсии приоритетов. (A mechanism >to prevent priority inversion has to exist.)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Это нужно для планировщика задач вполне определенного типа.



>5. Поведение ОС должно быть известным и предсказуемым (латентность прерываний,

>переключение задач, латентность памяти, латентность драйверов и т.д. ) Это означает,

>что должно быть постоянным максимальное время реакции при любых обстоятельствах

>загрузки системы.

>The OS behavior (metrics) should be known and predictable (interrupt latencies, task switches,

>memory latencies, driver latencies, etc.). This means that there should be a maximum response

>time under all system load circumstances.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Я не очень понимаю что такое латентность памяти, да и драйверы можно отнести к ОС с определенной натяжкой. Но даже если все эти латентности известны, это не значит что  максимальное время реакции будет постоянным и/или детерминированным. Обычно для решения проблемы происходит ее декомпозиция по различным прикладным и системным задачам.  В этом случае очевидно, что время реакции в рамках алгоритмов какой нибудь одной задачи зависит от других задач. Например в «чистом»  планировании с вытеснением (без адаптивности приоритетов) средне-приоритетная задача не выдаст вообще никакой реакции пока есть работа для высокоприоритетной задачи. Если скажем в «одиночестве» какая либо низкоприоритетная задача обеспечивает реакцию за 5мсек, то в условиях когда одна высокоприоритетная задача загружает компьютер на 90%, а другая среднеприоритетная задача загружает компьютер еще на 9%, низкоприоритетная задача получит в среднем 1% вычислительных ресурсов и выдаст реакцию в среднем за 500мсек вместо 5мсек. Конкретные цифры зависят от характера нагрузок (вероятности их возникновения и вероятностного распределения их длительности), а соответствующие статистические распределения времени реакции могут быть расчитаны на основе теории массового обслуживания.  Другими словами пожелания данного пункта в общем случае невыполнимы.

 

>Давайте попробуем отталкиваться от этого.

>>>>>>>>>>>>>>>>>>>>>

Я не вижу от чего здесь отталкиваться. Характерные черты ОСРВ в форуме даже более подробно уже приводил Olej, а определение СРВ мне кажется неудачным.

 

С Уважением,

 

Сергей Сорокин

 

Наверх
 Ответить Ответить Страница  <1 2223242526 36>

Переход на форум Права доступа на форуме Смотреть выпадающим

Bulletin Board Software by Web Wiz Forums® version 9.64
Powered by Web Wiz Forums Free Express Edition
Copyright ©2001-2009 Web Wiz