[Владимир Е. Зюбин 0]

Не сомневаюсь, что люди над этим вопросом работают, пишут докторские и т.д. Кстати, судя по статьям,

вопросы рассматриваются малоинтересные, типа успеет-не успеет, т.е. вопросы функционирования в условиях ограниченных ресурсов. Честно признаться, на практике вообще об этом не задумывался... вернее, задумался один раз, посмотрел на вычислительные ресурсы - запасов >92%, т.е. порядок с лишним... на 300 МГц "Пне"... не будет хватать поставлю 3 гигагерца, не будет хватать, разобью задачу на 10 процессоров... и особых теорем для этого не нужно...

 

Да похоже у вас довольно простые и не замысловатые задачи :-)

 

Ну, или сложность там не в оптимизации вычислительных ресурсов...

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

Выкопать яму 10м х 10м х 10м тоже сложно... а это из той же оперы.

 

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

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

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

 

Разумеется, мы не разбрасываемся ресурсами как попало (вопросы системной организации очень хорошо проработаны), но и не занимаемся вылизыванием битиков на локальном уровне.

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

 

А с выч.ресурсами проблем нет, запас в один порядок, да и то, основные затраты - это общение с модулями УСО. А ОС как класс ликвидирована, чтобы не умничала и не сжирала лишние ресурсы. ;-)

 

Мы вот в своем проекте вторую неделю байтики считаем и по третьему проходу вычищаем все лишнее.

И каждую лишнюю милисекунду выжимаем из алгоритмов. А целевая платформа - 4 процессорный Intel с 4 Гб памяти. А все равно считаем, оптимизируем, переписываем так что бы в кеш вовремя попадало все что надо... Что бы памяти лишней не жрало.

 

Судя по Вашему описанию, у Вас вычислительная задача, а не уравляющая.

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

 

Даже не могу представить, чем можно управлять с такими ресурсами... централизованное управление ГПС цеха, что ли?

 

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

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

 

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

 

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

 

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

[Владимир Е. Зюбин 0]

Меня мало вдохновляет "фирменная" статистика: "посмотрите насколько мы круты"...

Я просто знаю (могу перечислить: в какой стране, где и как, в каком проекте):

- QNX системы в необслуживаемом режиме работают не выключаясь а). 14 лет б). 20 лет ... - выходят из строя потому, что вентиляторы за это время насосали в корпус пыли столько, что там стал сплошной "валенок", и все кулера стали;

- Linux в качестве роутера достаточно надёжно себя показывает 3-5-7 лет...

- Windows (из вот "весьма устойчиво работающих" суффиксов) - период полураспада 3-4 мес. - вот только вчера в моей фирме выяснилось, что в уже поставленных crytical mission отрасли SCADA станции умирают, в среднем, за 21 день ... это не мои проекты, но я их предупреждал ... но "нет пророка в своём отечестве"(с) - теперь они по объектам будут ездить на 20-й день ... "накануне"? ;)

 

К сожалению, приведенные числа слабопоказательны, т.к. не содержат необходимой информации.

 

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

 

Лично по моим ощущениям надежность и устойчивость Виндовоза существенно выросла. Или Вы считатете, что она по прежнему находится на уровне Вин95?

[Goroshko 0]

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

 

Задача в целом непосредственно касается темы данной дискуссии. Сводится она к необходимости реализации на одном SoftPLC целой группы задач - это и работа самого приложения PLC и SCADA сервера. Почему такие высокие требования - PLC имеет порядка миллиона публичных переменных, значения который должны быть доступны клиентским приложениям. Причем доступна и по чтению и по записи. моя система - это как раз СКАДА сервер, осуществляющий распределенность данных PLC приложения. Латентность обновления данных не более 100 мс. В принципе у нас тоже есть запас производительности и запас по памяти, но оптимизация все равно делается по максимуму. Задача не вычислительная совсем, а чисто алгоритмическая, но при очень большом количестве переменных и достаточно выскоих скоростях. Ведь в 100 мс должен укладываться и цикл PLC и передача данных от PLC к серверу и обслуживание клиентов. в общем времени хватает, но запас все равно требуется. Потому что в определенных ситуациях на том же физическом хосте может подниматься и HMI управляющего клиента и ему тоже нужно время для работы.

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

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

[Goroshko 0]

Лично по моим ощущениям надежность и устойчивость Виндовоза существенно выросла. Или Вы считатете, что она по прежнему находится на уровне Вин95?

 

Да ХР надежность значительно вырасла по сравнению с Win95. Она правда стала весьма требовательна к ресурсам, но это отдельная тема. И тем не менее есть ряд факторов, по которым до спец применения ей еще очень далеко.

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

Второе - плохо предсказуемое (по времени) поведение стека IP протоколов.

Теретье - алгоритм планирования - встречаются очень плохо понятные атрефакты.

Еще один неприятный недостаток, даже когда вычислительные ресурсы вполне это позволяют у Винды нельзя поменять период прерываний таймера и задачть шаг диспетчеризации отличный от 10 мс. В Линуксе это возможно, но требует пересборки ядра (да и просто по умолчанию в новых версиях это 1 мс) а в QNX - таймер может перенастраиваться в рантайм.

 

Ну и наконец наиболее существенный момент, отличающий ОСРВ от ОСОН - это API. В ОСРВ, не только в QNX, системное API намного более соответсвует классу задач систем управления чем API ОСОН - например во всем что связано с установкой таймаутов операций.

[Владимир Е. Зюбин 0]

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

 

Задача в целом непосредственно касается темы данной дискуссии. Сводится она к необходимости реализации на одном SoftPLC целой группы задач - это и работа самого приложения PLC и SCADA сервера. Почему такие высокие требования - PLC имеет порядка миллиона публичных переменных, значения который должны быть доступны клиентским приложениям. Причем доступна и по чтению и по записи. моя система - это как раз СКАДА сервер, осуществляющий распределенность данных PLC приложения. Латентность обновления данных не более 100 мс. В принципе у нас тоже есть запас производительности и запас по памяти, но оптимизация все равно делается по максимуму. Задача не вычислительная совсем, а чисто алгоритмическая, но при очень большом количестве переменных и достаточно выскоих скоростях. Ведь в 100 мс должен укладываться и цикл PLC и передача данных от PLC к серверу и обслуживание клиентов. в общем времени хватает, но запас все равно требуется. Потому что в определенных ситуациях на том же физическом хосте может подниматься и HMI управляющего клиента и ему тоже нужно время для работы.

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

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

 

Чего-то я ничего не понял... что за алгоритм-то? чем управляете? Что это за миллион переменных?

Ведь миллион переменных можно получить и с обычного цифрового фотоаппарата... А для обработки изображений, действительно языки типа МЭК не предназначены. Такое впечатление, что работаете Вы с массивами данных, а не с переменными... их же просто описать, с ума сойдешь... а что-то разумное с ними сделать, так и вообще... в общем такое впечатление, что Ваши миллион переменных самым естественным образом можно разделить на 10 куч по сотне тысяч, или сто куч по десятку тысяч...

 

В общем, прошу прощения, задача у Вас, конечно же, серьезная, но управления никакого я не разглядел. Судя по всему, у Вас в системе гигантские потоки данных (10^7-10^8 байтов/с) порядка гигабайта в минуту, и что делать с этой информацией совершенно неясно... и какая SCADA такое "тянет"? ну сотню параметров на экран поместили... (а реально это от силы пара десятков)...

это ж... хгм... не менее 10 тысяч экранов...

 

Не понимаю.

[Goroshko 0]

Чего-то я ничего не понял... что за алгоритм-то? чем управляете?

 

Не понимаю.

 

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

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

За то с одной проще эксплуатационщикам, а ведь именно их руководство принимает решение у кого заказывать систему.

 

И еще отмечу - миллион переменных, это не значит что они все меняются одновременно. Меняется не так много, и не очень часто. Но физически они МОГУТ поменяться и система должна это выдержать.

 

На самом деле система весьма дорогая, туда входит масса подсистем, не имеющих прямого отношения к СКАДА и PLC (например система видеонаблюдения) и введение дополнительных аппаратных компонент серьезно влияет на бюджет. Естественно на тунель стоит не один PLC (в зависимости от протяженности), кроме ввода с датчиков и органов управления есть еще данные, приходящие с других PLC (с соседних участков).

Более подробно не отвечу, поскольку задача моей группы несколько другая - обеспечить распределенный доступ к данным PLC и у меня есть на руках ТЗ где указано сколько переменных и с каким периодом должен обслуживать сервер :-) .

[Владимир Е. Зюбин 0]

 

Лично по моим ощущениям надежность и устойчивость Виндовоза существенно выросла. Или Вы считатете, что она по прежнему находится на уровне Вин95?

 

Да ХР надежность значительно вырасла по сравнению с Win95. Она правда стала весьма требовательна к ресурсам, но это отдельная тема. И тем не менее есть ряд факторов, по которым до спец применения ей еще очень далеко.

 

Что такое чпец.применения мне так и непонятно. По моему все просто. Есть задача, есть требования, удовлетворяет - вперед. Тем более, что принципиальной разницы между XP и QNX не видно.

 

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

 

Ну и пусть присутствует. Наличие возможности свопа лучше, чем его отсутсвие и крах системы от нехватки ОЗУ.

 

Второе - плохо предсказуемое (по времени) поведение стека IP протоколов.

 

Не понимаю, чем тут QNX лучше... такая же непредсказуемость... от шести миллисекунд на передачу пакета по TCP/IP.

 

Теретье - алгоритм планирования - встречаются очень плохо понятные атрефакты.

 

Непонятная претензия.

 

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

 

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

 

В Линуксе это возможно, но требует пересборки ядра (да и просто по умолчанию в новых версиях это 1 мс) а в QNX - таймер может перенастраиваться в рантайм.

 

Это какая-то редковстречающаяся специфика.

 

Ну и наконец наиболее существенный момент, отличающий ОСРВ от ОСОН - это API. В ОСРВ, не только в QNX, системное API намного более соответсвует классу задач систем управления чем API ОСОН - например во всем что связано с установкой таймаутов операций.

 

Не знаю, у нас таймауты операций вообще сняты с системного уровня. Да и API минимально, логика да коммуникации, вот и все АПИ.

 

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

[Goroshko 0]

Что такое чпец.применения мне так и непонятно. По моему все просто. Есть задача, есть требования, удовлетворяет - вперед. Тем более, что принципиальной разницы между XP и QNX не видно.

Наверно я не так выразился - в задачах промышленной (в отличии от офисной) автоматизации. Приведу пример - был в одной фирме, занимающейся разработкой систем видео рекламы. Может видели - когда стоит несколько десятков терминалов и синхронно крутят видео ролики. Работают под ХР Embedded - таже ХР только чуть чуть образанная для встроенных приложений. В принципе ее для таких задач должно хватать с головой особенно учитывая возможности DirectX, хотя сами разработчики в серьез обсуждают переход на Linux. Но дело не в этом. И вот при нас выясняется что была накануне презентация какая-то рекламная и прямо посреди презентации на одном из терминалов вываливается окошко с системным сообщением о нехватке виртуальной памяти. Говорят выглядит - замечательно.

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

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

 

Ну и пусть присутствует. Наличие возможности свопа лучше, чем его отсутсвие и крах системы от нехватки ОЗУ.

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

 

Не понимаю, чем тут QNX лучше... такая же непредсказуемость... от шести миллисекунд на передачу пакета по TCP/IP.

Очень интерестно - приведите пожалуйста источник информации.

 

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

А зачем использовать такое решение, если можно просто поставить обычный РС и не морочить себе голову. А задач и не так уж мало, может просто вы не сталкивались?

 

Не знаю, у нас таймауты операций вообще сняты с системного уровня. Да и API минимально, логика да коммуникации, вот и все АПИ.

Вот видите - на системном уровне их в ОСОН вообще нет. Их по любому надо строить на уровень выше. А в системах ОСРВ - они есть готовые, бери да пользуйся. На любой вкус. Это я и имел в виду под богатством API :-)

 

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

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

[yuri_t 0]

Инженер, работающий на Западе и создающий некое комплексное

решение, никогда не имеет времени для написания собственных ОС,

компиляторов и уж тем более больших кусков кода на ассемблере...

Есть ошибка в библиотеке(компиляторе,OS) - обойди ТОЛЬКО эту

ошибку своим кодом. Тот кто думает, что уж в его-то коде ошибок

не будет - либо очень юный, либо очень наивный человек...

Другое дело - не ошибиться в выборе библиотеки,компилятора,OS

( и это кстати основная причина, по которой банальные и очень дорогие,

но надежные OS (типа VxWorks) до сих пор продаются,

несмотря на замечательный free Linux)

[Владимир Е. Зюбин 0]

Что такое чпец.применения мне так и непонятно. По моему все просто. Есть задача, есть требования, удовлетворяет - вперед. Тем более, что принципиальной разницы между XP и QNX не видно.

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

 

Егор, Вы говорили "о ряде факторов", не могли бы Вы более конкретно их обозначить? Что это за факторы, по Вашему мнению?

 

Ну и пусть присутствует. Наличие возможности свопа лучше, чем его отсутсвие и крах системы от нехватки ОЗУ.

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

 

Так а что делать-то если память кончилась?

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

Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...

 

Не понимаю, чем тут QNX лучше... такая же непредсказуемость... от шести миллисекунд на передачу пакета по TCP/IP.

Очень интерестно - приведите пожалуйста источник информации.

 

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.

 

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

А зачем использовать такое решение, если можно просто поставить обычный РС и не морочить себе голову. А задач и не так уж мало, может просто вы не сталкивались?

 

В задачах управления и пром.автоматизации - не сталкивался. Ни в теплоэнергетике, ни в АСУ энергоблоков гидроэлектростанций, ни в системах ЧПУ, ни в ростовых установках такого нет...

и дело в том, что механика "пропускает", ну 100 Гц максимум. А у человека (которого пытаются заменить при автоматизации) время реакции и того меньше - 200-300 мс.

 

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

 

Не знаю, у нас таймауты операций вообще сняты с системного уровня. Да и API минимально, логика да коммуникации, вот и все АПИ.

Вот видите - на системном уровне их в ОСОН вообще нет. Их по любому надо строить на уровень выше. А в системах ОСРВ - они есть готовые, бери да пользуйся. На любой вкус. Это я и имел в виду под богатством API :-)

 

Не совсем так. Дело не в том, что их нет, а в том, что в задачах массового параллелизма так удобнее.

 

И если, к примеру, кому-то захочется использовать Рефлекс под ОС QNX (а почему бы и нет), то там тоже не будет необходимости использовать системную службу времени... достаточно одного прерывания от таймера, чтобы организовать тактируемость и все. И параллелизм не выносится на уровень ОС. Сейчас у нас типовые задачи - это 700+ параллельных процессов... в доброй половине из них встречается работа с временными интервалами, часто - несколько раз. И заводить сложную "бодягу" с таймерными переменными просто очень накладно, даже чисто программировать, поэтому у нас даже переменные заводить не надо, конструкция

ТАЙМАУТ <время>{<реакция на таймаут>}

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

 

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

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

 

По мне так ни Виндоуз, ни QNX сами по себе не подходят для задач пром автоматизации и требуют некой надстройки. Ну а с практической точки зрения, проще иметь однородную среду, в которой и документы набираешь и сами программы. Поэтому общая тенденция будет все-таки в сторону Виндовоза смещаться. В общем-то она и наблюдается. HMI - оно на 90% на Виндовозе делается, да и весь т.н. софт-ПЛК. И есть масса задач (их большинство), для которых это приемлемое решение.

 

Но опять же, есть задачи, которые требуют других средств, возможно QNX, или там OS9000, или еще чего, вариантов не счесть... одно другому не противоречит... опять же про Stand-alone решения тоже не следует забывать.

[Olej 0]

Так а что делать-то если память кончилась?

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

Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...

 

Владимир, не со зла будет сказано, но здесь, и ещё нескольких аспектах относительно "мира RTOS", вы ... настолько не владеете предметом, что обсуждать здесь альтернативы - это только годы на обсуждение терять... Это как если бы я стал обсуждать выращивание кристаллов ;).

 

Неприменимость свопинга в RTOS - это давно требуемая классика.

И крах системы при недостатке памяти (и не системы, а приложения) - это лучше, чем "мягкое" и мало заметное её непредсказуемое поведение - быстрее сообразите, что памяти жалеть не надо ;) (это ж ваше утверждение?: ресурсов жалеть не надо).

[Goroshko 0]

Егор, Вы говорили "о ряде факторов", не могли бы Вы более конкретно их обозначить? Что это за факторы, по Вашему мнению?

Я же их выше перечислял и мы как раз их и обсуждаем, разве нет?

 

Так а что делать-то если память кончилась?

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

Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...

По определению систем реального времени - а их в промавтоматике очень много - выполнение задачи после наступления ее deadline означает не выполнение задачи в принципе. Ну не нужна она уже никому если она опаздала. Именно поэтому использование свопа в таких системах просто запрещается.

 

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.

Увы в данном случае ваша уверенность ничем не обоснована. В том же линуксе времена уже будут другие. А в QNX - третьи. Не стоит обощать без проверки такие вещи.

 

В задачах управления и пром.автоматизации - не сталкивался.

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

 

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

ТАЙМАУТ <время>{<реакция на таймаут>}

и все....

native API QNX дает вам очень похожие конструкции уже готовыми, только в несколько раз богаче по способам уведомления о таймауте и с возможностью очень гибкой настройки выполнения реакции. :-)

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

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

 

По мне так ни Виндоуз, ни QNX сами по себе не подходят для задач пром автоматизации и требуют некой надстройки. Ну а с практической точки зрения, проще иметь однородную среду, в которой и документы набираешь и сами программы. Поэтому общая тенденция будет все-таки в сторону Виндовоза смещаться. В общем-то она и наблюдается. HMI - оно на 90% на Виндовозе делается, да и весь т.н. софт-ПЛК. И есть масса задач (их большинство), для которых это приемлемое решение.

Я, честно говоря такой тенденции не наблюдал. Судя по выставкам типа CeBIT или EmbededWorld тенденция сейчас идет в сторону Linux решений, что тоже мне не очень нравится. Но это мое субъективное мнение. Объективно же можно отметить что не смотря на весьма дорогие решения от QSSL и WindRiver их системы все равно пользуются очень большим спросом - что демонстрирует их некоторые преимущества перед тем же бесплатным Linux или относительно дешевым Windows.

[Владимир Е. Зюбин 0]

Так а что делать-то если память кончилась?

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

Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...

 

Владимир, не со зла будет сказано, но здесь, и ещё нескольких аспектах относительно "мира RTOS", вы ... настолько не владеете предметом, что обсуждать здесь альтернативы - это только годы на обсуждение терять... Это как если бы я стал обсуждать выращивание кристаллов ;).

 

Неприменимость свопинга в RTOS - это давно требуемая классика.

И крах системы при недостатке памяти (и не системы, а приложения) - это лучше, чем "мягкое" и мало заметное её непредсказуемое поведение - быстрее сообразите, что памяти жалеть не надо ;) (это ж ваше утверждение?: ресурсов жалеть не надо).

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

 

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

 

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

 

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

[Владимир Е. Зюбин 0]

'Владимир Е. Зюбин':

"Так а что делать-то если память кончилась?

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

Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы..."

 

По определению систем реального времени - а их в промавтоматике очень много - выполнение задачи после наступления ее deadline означает не выполнение задачи в принципе. Ну не нужна она уже никому если она опаздала. Именно поэтому использование свопа в таких системах просто запрещается.

 

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

 

Предпочесть крах системы задержке в выполнении - это идиотизм (прошу прощения за прямоту).

 

Как в анекдоте про молодого брадобрея:

Бреет новичок-парикмахер...

Бреет, бреет, Раз! - порез. Новичок: "Ой, извините.."

Дальше продолжает... опять порез... "Ой, прошу прощения"

Дальше бреет, опять неосторожное движение и порез...

"А-а-а!!! Ничего не получается!!!" (резкие крест-накрест движения бритвой по лицу клиента)

 

Также и тут... не хватает ОЗУ, - херакс! Останов системы... 8-) Поезда под откос, самолеты в пике, пробки на дорогах, взрыв на производстве... "А-а-а!!! Ничего не получается!!!" :-)

 

'Владимир Е. Зюбин':

"Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС. "

 

Увы в данном случае ваша уверенность ничем не обоснована. В том же линуксе времена уже будут другие. А в QNX - третьи. Не стоит обощать без проверки такие вещи.

 

С какой стати? Если ограничения - это не Виндовоз, а Ethernet и "моторольный" конец (может еще и с OS-9)??? если есть у Вас 10Мбод, и минимальный пакет по 4Кб, тут уж никуда не деться ... да, не сказал, что послылка занимает примерно миллисекунду, а прием около пяти мс. Тоже информация к размышлению.

 

'Владимир Е. Зюбин':

"В задачах управления и пром.автоматизации - не сталкивался. "

 

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

 

Я вполне удовлетворен ответом. На этом можно и закончить обсуждение этого пункта.

 

'Владимир Е. Зюбин':

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

ТАЙМАУТ <время>{<реакция на таймаут>}

и все.... "

 

native API QNX дает вам очень похожие конструкции уже готовыми, только в несколько раз богаче по способам уведомления о таймауте и с возможностью очень гибкой настройки выполнения реакции. :-)

 

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

 

'Владимир Е. Зюбин':

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

 

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

 

Многопоточный вариант затраты на обслуживание потока - это порядка 150-200 машинных циклов и 6 байтов ОЗУ. Плюс компактность, позволяющая весь код разместить в кэше. Считайте. На 1 ГГц - это порядка 200 нс. Основная проблема (затраты ресурсов) - это обмен с УСО.

 

Тут уже называлось 2-4*10^7 б/с, (миллион входов за 100 мс) и я не представляю, как эти данные планируется собирать... какие АЦП использовать, в каком виде и куда их цеплять... вот где действительная проблема.

 

'Владимир Е. Зюбин':

"По мне так ни Виндоуз, ни QNX сами по себе не подходят для задач пром автоматизации и требуют некой надстройки. Ну а с практической точки зрения, проще иметь однородную среду, в которой и документы набираешь и сами программы. Поэтому общая тенденция будет все-таки в сторону Виндовоза смещаться. В общем-то она и наблюдается. HMI - оно на 90% на Виндовозе делается, да и весь т.н. софт-ПЛК. И есть масса задач (их большинство), для которых это приемлемое решение."

 

Я, честно говоря такой тенденции не наблюдал. Судя по выставкам типа CeBIT или EmbededWorld тенденция сейчас идет в сторону Linux решений, что тоже мне не очень нравится. Но это мое субъективное мнение. Объективно же можно отметить что не смотря на весьма дорогие решения от QSSL и WindRiver их системы все равно пользуются очень большим спросом - что демонстрирует их некоторые преимущества перед тем же бесплатным Linux или относительно дешевым Windows.

 

А я вообще из лидеров продаж не знаю SCADA-пакетов для QNX, все сплошняком Windows. Ничего не имею против Linux, или QNX, но что поделать? Не знаю. Кстати, дороговизна QNX и Ко и в общем-то и говорит за то, что объем продаж у них невысокий...

Изменено 2 июня, 2006 пользователем Владимир Е. Зюбин

[Olej 0]

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

 

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

А указать? да пожалуйста:

 

1.

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых

входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...

Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.

 

- эта иллюзия определяется только ОС с использованием timeslice=10мс. (шкала разрешения времени), если вы при 2-х измерениях получили 10мс. (1 слайс), а в 3-м - 0 (вообще слайс не истёк), то среднее вы и оцениваете в 6-7мс. Только вопрос при этом: а что же это вы такое меряли?

В QNX с возможностью уменьшения timeslice до 10мкс. (на 3 порядочка, чуть-чуть) я видел совсем другие цифры и вам могу показать.

 

2 и 3.

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

 

В микроядерной архитектуре с лёгкостью "уживаются" тысячи процессов, и тем более потоков (десятки тысяч). И такая много-параллельная структура, закладываемая в проект, часто намного улучшает его ТТД.

 

А "затраты на обслуживание процесса в QNX" не "на два порядка выше", чем в многопоточных вариантах, а на несколько процентов, которые и не всегда вы сможете даже специально выделить в тестах. Чтоб не спорить и не давать вам повода затягивать спор "откуда известно" я вам скажу следующее:

- эти результаты и выводы я привожу в своей книге (вместе с Егором Горошко):

http://www.books.ru/shop/books/357604

- а поскольку их пока никто не оспорил и им не возразил - их нельзя считать неверными ;);

- а книга по рейтингам www.books.ru - 3-я позиция "книга 2005г." (из пару тысяч), т.е. её читают и, значит, с ней соглашаются.

 

4.

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

 

Именно свопинг - страшен, и не свопинг даже, а виртуализация страниц памяти на дисковое пространство через механизм MMU (а свопинга, в первородном его смысле - давно уже нет во всех ОС).

 

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

 

5.

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

 

Нет его.

Был в ранних версиях линии 6, но на сегодня - вообще нет.

 

P.S. Я это (и многое ещё мог бы) написал вовсе не для того, чтобы вас, или кого-то ещё, в чём то уличать ... но вы просили? ;).

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

 

А я вообще из лидеров продаж не знаю SCADA-пакетов для QNX, все сплошняком Windows. Ничего не имею против Linux, или QNX, но что поделать? Не знаю. Кстати, дороговизна QNX и Ко и в общем-то и говорит за то, что объем продаж у них невысокий...

 

"Не знаю" это вовсе не аргумент того, что так оно и есть...

RealFlex, например - система, на базе которой >20 лет.(!) строились и строятся сотни крупных распределённых проектов в крупнейших индустриальных странах... можно и другие упомнить.

 

P.S. (добавлено позже) а здесь как раз и "сон в руку" ;) - разработчики RealFlex (из-за широты именно внедрений "не лидеров" RealFlex на просторах xUSSR) только несколько дней как сделали русскоязычный сайт ... за 20 лет - спромоглись ;) - вот:

http://www.realflex.ru/

 

Но состояние дел то в том, что большое множество СУ отраслевых - делаются на a'la SCADA инструментальных средствах, "затачиваемых" под отрасль ... и почти все такие tools - под QNX: вся нефте-газоперекачка России, железнодорожный транспорт, авиационное двигателестроение...

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

 

А "все сплошняком Windows" SCADA ... это отдельная песня:

- это "модный" рынок предложения...

- работы немного - а стоимости предожения ого-го...

- при архитектурно-качественных показателях всех их ... ох-ох-ох ...

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