Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Когда не нужна ОС РВ?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Страницы: 1, 2, 3, 4, 5, 6, 7, 8
Olej
Цитата(Владимир Е. Зюбин @ May 30 2006, 11:58) *
Небольшая революция (ну или большая) грядет (и уже началась) в связи с переходом на многоядерные архитектуры... коренным образом меняются подходы... Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности, по сути же - это преимущество легко теряется. Тем более, что имеющиеся шедулеры-планировщики не особо и подходят для таких архитектур (алгоритмически), и их все равно надо переписывать.


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

Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *
По этому поводу вспоминается далекий 1994-й, когда мне долго расказывали про преимущества QNX,
а на мой вопрос "ну и сколько же у Вас процессов" ответили - два, а на вопрос "а почему не три или четыре", ответили "а больше мы боимся, т.к. можем не успеть"...


Ну так это же вообще ни о чём не говорит - это просто у вас компания такая собралась ... слабая - вот они и боятся.
Даже интересно мне стало за них? : а с чего же это они решили, что успеть/не успеть хоть как-то коррелирует с числом процессов, потоков? из досужих домыслов?
"Не стреляйте в пианиста - он играет как умеет"(с).
Goroshko Egor
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *
Цитата(TMX @ May 30 2006, 15:24) *

По теме.
Любопытно, что отмечается несколько подходов:
1. Использование автоматной логики.
2. Использование обработки событий.


Любопытно еще и то, что некоторые из использующих "автоматный"/FSM подход считают, что они проектируют событийные архитектуры.

И наоборот, кстати. :-)

Для разрешения этого конфликта неплохо было бы определится с понятиями, что такое автоматная логика, а что такое обработка событий.
Простейший пример: Оконная процедура win32 - классический автомат без памяти, в цикле обрабатывающий события окна.
Да любая GUI это автоматная логика обработки событий. Так что объясните пожалуйста что же все таки имелось в виду под этой класификацией.

Может быть речь идет о разнице между циклической обработкой и условно событийной обработкой?
В стиле
for (;;)
{
if(Condition) DoSomthing();
if(AnotherCondition) DoSomthingElse();
}
или
for (;;)
{
SleepUntil(Condition);
DoSomthing();
}
for (;;)
{
SleepUntil(AnotherCondition);
DoSomthingElse();
}
в паралельных потоках.

Я говорю условной, потому что в конечном счете где то for есть в обеих моделях :-)
Только в первой распределение ресурсов вычислительной системы ложится на плечи разработчика, и он должен распределять вычислительный ресурс между своими задачами, а также следить за тем, чтобы выполнение менее важных задач не прпятсвовало выполнению более важных, а во втором случае средсвами ОС (или своими силами если хотите) эта задача отдается подсистеме планирования ОС.
Olej
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *
Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.


А чего ж там совершенно непонятного? wink.gif
Я мог бы назвать вам фирму (не стану я это делать только потому, что не хочу делать никому ни рекламу, ни антирекламу - кто как поймёт), которая уже лет 10 (более) очень успешно внедряет системы диспетчерской централизации на ж/д, но "лабает" это в голой ОС QNX, и делают это очень успешно, и это очень дорогие системы и отрасль, а соответственно - и сложные (существенно сложнее традиционной конвейерной автоматизации).
Это не значит, что так нужно делать, но, как видите, так можно делать.
И всё там будет делаться точно так, как в МЭК реализациях: цикличность опроса, периодичность обработки и т.д. Ведь МЭК со своим runtime - это ничего более чем надстройка, чем голая ОС вам не такая же надстройка, что так "совершенно непонятна": надстройте над этой надстройкой ещё одну - CoDeSys ... похоже?
Владимир Е. Зюбин
Цитата(Goroshko Egor @ May 30 2006, 19:08) *
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *

Цитата(TMX @ May 30 2006, 15:24) *

По теме.
Любопытно, что отмечается несколько подходов:
1. Использование автоматной логики.
2. Использование обработки событий.


Любопытно еще и то, что некоторые из использующих "автоматный"/FSM подход считают, что они проектируют событийные архитектуры.

И наоборот, кстати. :-)

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


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

Цитата(Goroshko Egor @ May 30 2006, 19:08) *
Может быть речь идет о разнице между циклической обработкой и условно событийной обработкой?
В стиле
for (;;)
{
if(Condition) DoSomthing();
if(AnotherCondition) DoSomthingElse();
}
или
for (;;)
{
SleepUntil(Condition);
DoSomthing();
}
for (;;)
{
SleepUntil(AnotherCondition);
DoSomthingElse();
}
в паралельных потоках.


непонятно, в чем тут разница. Т.к. SleepUntilCondition в конечном случае вырождается в if(Condition), разве что где-то в недрах планировщика ОС...

Тут можно говорить об отличиях между многозадачным логическим параллелизмом (ОС) и многопоточным логическим параллелизмом ("лом", round-robin, Stand-alone, кооперативная многопоточность на уровне задачи)... но ни к автоматам, ни к обработке событий это особого отношения не имеет.

Цитата(Goroshko Egor @ May 30 2006, 19:08) *
Я говорю условной, потому что в конечном счете где то for есть в обеих моделях :-)
Только в первой распределение ресурсов вычислительной системы ложится на плечи разработчика, и он должен распределять вычислительный ресурс между своими задачами, а также следить за тем, чтобы выполнение менее важных задач не прпятсвовало выполнению более важных, а во втором случае средсвами ОС (или своими силами если хотите) эта задача отдается подсистеме планирования ОС.


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


Цитата(Olej @ May 30 2006, 19:08) *
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

А чего ж там совершенно непонятного? ;)
Я мог бы назвать вам фирму (не стану я это делать только потому, что не хочу делать никому ни рекламу, ни антирекламу - кто как поймёт), которая уже лет 10 (более) очень успешно внедряет системы диспетчерской централизации на ж/д, но "лабает" это в голой ОС QNX, и делают это очень успешно, и это очень дорогие системы и отрасль, а соответственно - и сложные (существенно сложнее традиционной конвейерной автоматизации).
Это не значит, что так нужно делать, но, как видите, так можно делать.
И всё там будет делаться точно так, как в МЭК реализациях: цикличность опроса, периодичность обработки и т.д. Ведь МЭК со своим runtime - это ничего более чем надстройка, чем голая ОС вам не такая же надстройка, что так "совершенно непонятна": надстройте над этой надстройкой ещё одну - CoDeSys ... похоже?


Насколько я понял, "стратегия" эта в стиле "программирую на Си как придется", (и, прошу прощения, CoDeSys представляет совершенно другой функционал и концептуальные средства программирования, чем обычный Си)...

Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?
для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...

Цитата(Olej @ May 30 2006, 18:51) *
"Слухи сильно преувеличены"(с) ...
"Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности..." - это неверное утверждение, которое должно звучать так: "Архитектурно, ОС типа QNX имеют некое преимущество за счет микроядерности и обмена сообщениями..." - что далеко не то, что было раньше. Именно поэтому: а). микроядерные архитектуры (не только QNX) очень легко вписываются в SMP б). SMP именно в QNX давно и успешно реализовано, и очень эффективно, по оценкам выше, чем в любом другом коммерческом продукте.
Хорошо, пусть вместо "модульности" будет "микроядерность"... нет возражений.

Цитата(Olej @ May 30 2006, 18:51) *
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *

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

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


Он играет как умеет, да и пианино расстроено... Увы, но априорный анализ динамического поведения системы в средах с многозадачной организацией логического параллелизма весьма затруднен. Вот люди и прикидывают шансы...
Olej
Цитата(Olej @ May 30 2006, 19:08) *
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

Насколько я понял, "стратегия" эта в стиле "программирую на Си как придется", (и, прошу прощения, CoDeSys представляет совершенно другой функционал и концептуальные средства программирования, чем обычный Си)...


Ну так вы тогда так и говорите: "стратегия реализации управляющих алгоритмов программирую на Си как придется - совершенно непонятна." И это уже совсем другой разговор, о том, какие средства проектирования подходят, а какие не подходят. Кому то, как я назвал - и С очень даже подходит, кто-то над С сделает технологическую надстройку, как например в системе ДЦ ЮГ, которая более 20 лет успешно шаг за шагом внедряется, кто-то сделает другую надстройку - CoDeSys или ISaGRAF и МЭК, кто-то - Рефлекс wink.gif. Средства изображения целевой алгоритмики ну никакого касательства не имеют к вопросам параллелизмов, диспетчирования, управления ресурсами и всем другим вещам, которые относятся к функциональности ОС или отсутствия таковой.

Цитата(Владимир Е. Зюбин @ May 31 2006, 06:49) *
Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?
для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...


Пусть и для наличия стека TCP/IP. Вы когда-нибудь реально писали что-либо в программировании сетевых обменов? Это на словах "слова.. слова... слова..." - а реально нет такого "стека TCP/IP", а есть только стек TCP/IP в конкретной его реализации: BSD, Windows, ... и каждый включает в себя только какое-то подмножество возможностей из описанных в 3000 RFCs.
И при чём здесь упоминание QNX к месту или не к месту? если мы говорим вообще о принципиальном использовании или не- ОС вообще, всякой.
Надёжность? да, пусть надёжность - этого тоже может быть достаточно: я под QNX совершенно спокойно предположу работу (программ) на одном процессоре: PLC, сервера тэгов, SCADA системы с её HMI компонентой + ... в качестве просто параллельных задач, не сомневаясь, что они не завалят друг-друга и за несколько лет невыключаемого режима... чего даже под Linux/FreeBSD/etc. не представлю, под ... "другими ОС" wink.gif - так это "во сне приснится - не проснёшься"(с).
Вот 1 из "по-быстрому" (не самых свежих) попавшихся переводов, который хоть отчасти объясняет почему так происходит:
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html
Вот такая проза, хотя она, конечно, к высокой девственности теории касательства и не имеет... как и к предмету этого разговора wink.gif, поскольку не о QNX мы говорим, а обо всём сразу - говорить не стоит.

Цитата(Владимир Е. Зюбин @ May 31 2006, 06:49) *
Цитата(Olej @ May 30 2006, 18:51) *

Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *

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

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

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


Во-первых, для того, чтобы "прикидывать шансы" нужно хорошо понимать предмет того, что ты прикидываешь... с QNX, как частность, особая история, с ним достаточно многие "работали", но из всех работающих, может, только 10:1 дали труд себе разобраться что там происходит, и чем это отличается от ... "других ОС" wink.gif ... некоторых, а для того, чтобы это понимать есть только единственнный путь, к сожалению: писать, писать и писать "ручками", и анализировать что из этого получается, и удивляться, что получается не совсем так, как предполагается...

Во-вторых, и с "априорным анализом динамического поведения системы в средах с многозадачной организацией логического параллелизма" не всё так запущено, давно и много сделано "в эту сторону", вот хотя бы только малые намёки:
http://qnxclub.net/files/articles/rta/rta.doc
http://qnxclub.net/files/articles/rms/rms.doc
- но и это не так обязательно, если хорошо представлять, что и как там происходит "на деле", а не на уровне хвалебных описаний производителей каждой из ОС как раз на уровне "слова.. слова... слова...".
Владимир Е. Зюбин
Цитата(Olej @ May 31 2006, 15:12) *
Цитата(Владимир Е. Зюбин @ May 30 2006, 15:39) *

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

Ну так вы тогда так и говорите: "стратегия реализации управляющих алгоритмов программирую на Си как придется - совершенно непонятна."

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

Цитата(Olej @ May 31 2006, 15:12) *
Цитата(Владимир Е. Зюбин @ May 31 2006, 06:49) *

Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?
для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...


Пусть и для наличия стека TCP/IP. Вы когда-нибудь реально писали что-либо в программировании сетевых обменов?


Да не нужно все это. Это системный уровень. Когда я пишу на Рефлексе, мне что TCP/IP, что UDP/IP,
что USB, что RS-485... голова занята алгоритмом, а не протоколами обмена. А сетевые протоколы я реализовывал, и что такое сокет знаю.

Цитата(Olej @ May 31 2006, 15:12) *
Надёжность? да, пусть надёжность - этого тоже может быть достаточно: я под QNX совершенно спокойно предположу работу (программ) на одном процессоре: PLC, сервера тэгов, SCADA системы с её HMI компонентой + ... в качестве просто параллельных задач, не сомневаясь, что они не завалят друг-друга и за несколько лет невыключаемого режима... чего даже под Linux/FreeBSD/etc. не представлю, под ... "другими ОС" ;) - так это "во сне приснится - не проснёшься"(с).


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

Цитата(Olej @ May 31 2006, 15:12) *
Цитата(Владимир Е. Зюбин @ May 31 2006, 06:49) *

Цитата(Olej @ May 30 2006, 18:51) *

...Даже интересно мне стало за них? : а с чего же это они решили, что успеть/не успеть хоть как-то коррелирует с числом процессов, потоков? из досужих домыслов?
"Не стреляйте в пианиста - он играет как умеет"(с).

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

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

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

Цитата(Olej @ May 31 2006, 15:12) *
Во-вторых, и с "априорным анализом динамического поведения системы в средах с многозадачной организацией логического параллелизма" не всё так запущено, давно и много сделано "в эту сторону", вот хотя бы только малые намёки:
http://qnxclub.net/files/articles/rta/rta.doc
http://qnxclub.net/files/articles/rms/rms.doc
- но и это не так обязательно, если хорошо представлять, что и как там происходит "на деле", а не на уровне хвалебных описаний производителей каждой из ОС как раз на уровне "слова.. слова... слова...".

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

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

Ну и вообще, человеку надо создать алгоритм, а ему говорят: Нет! сначала стек протоколов изучи, покопайся в ОС, создай проблемно-ориентированную библиотеку классов и докажи десять теорем по алгоритмам планирования. ;-) Плохой какой-то подход.
Это несерьезно.
Stanislav Sedov
Цитата(Владимир Е. Зюбин @ May 31 2006, 14:33) *
Не понятно, правда, почему у QNX надежность выше, чем у Виндовза или Линукса, ну да ладно.


Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.
В случае микроядра - упавший драйвер может быть перезапущен, по крону, например.
Владимир Е. Зюбин
Цитата(Stanislav Sedov @ May 31 2006, 17:39) *
Цитата(Владимир Е. Зюбин @ May 31 2006, 14:33) *

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


Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.
В случае микроядра - упавший драйвер может быть перезапущен, по крону, например.


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

Я согласен, что теоретически устойчивость ПО при модульном (микроядерном) построении системы выше. Но как это измерить в числах, я не понимаю. Ну, хорошо, есть статистика. Но по статистике, последние версии ОС Виндоуз весьма устойчиво работают, на уровне архитектуры там тоже очень грамотные решения. Есть и специализированные модели ОС, типа CE.
Goroshko Egor
Цитата(Владимир Е. Зюбин @ May 31 2006, 13:33) *
Не сомневаюсь, что люди над этим вопросом работают, пишут докторские и т.д. Кстати, судя по статьям,
вопросы рассматриваются малоинтересные, типа успеет-не успеет, т.е. вопросы функционирования в условиях ограниченных ресурсов. Честно признаться, на практике вообще об этом не задумывался... вернее, задумался один раз, посмотрел на вычислительные ресурсы - запасов >92%, т.е. порядок с лишним... на 300 МГц "Пне"... не будет хватать поставлю 3 гигагерца, не будет хватать, разобью задачу на 10 процессоров... и особых теорем для этого не нужно...


Да похоже у вас довольно простые и не замысловатые задачи :-)
Мы вот в своем проекте вторую неделю байтики считаем и по третьему проходу вычищаем все лишнее. И каждую лишнюю милисекунду выжимаем из алгоритмов. А целевая платформа - 4 процессорный Intel с 4 Гб памяти. А все равно считаем, оптимизируем, переписываем так что бы в кеш вовремя попадало все что надо... Что бы памяти лишней не жрало. Насчет производительности аппаратуры - это миф. По тому что когда вы говорите заказчику - да тут надо проц посильнее поставить, памяти побольше, а он считает, считает... И говорит, знаете, дорогие мои, вы конечно умные ребята, но вон у них работате на более дешевой аппаратуре и куплю я систему наверно все таки у них.
Наше отношение к аппаратным ресурсам вызвано в первую очеред практически полным отсутсвием конкуренции. Там где конкуренция есть - за ресурсы борются изо всех сил.

Поэтому там где конкуренция есть и теоремы изучают (или не изучают и прогорают).
Olej
Цитата(Stanislav Sedov @ May 31 2006, 14:39) *
Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.
В случае микроядра - упавший драйвер может быть перезапущен, по крону, например.


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

Цитата(Владимир Е. Зюбин @ May 31 2006, 15:10) *
Но как это измерить в числах, я не понимаю. Ну, хорошо, есть статистика. Но по статистике, последние версии ОС Виндоуз весьма устойчиво работают, на уровне архитектуры там тоже очень грамотные решения. Есть и специализированные модели ОС, типа CE.


Меня мало вдохновляет "фирменная" статистика: "посмотрите насколько мы круты"...
Я просто знаю (могу перечислить: в какой стране, где и как, в каком проекте):
- QNX системы в необслуживаемом режиме работают не выключаясь а). 14 лет б). 20 лет ... - выходят из строя потому, что вентиляторы за это время насосали в корпус пыли столько, что там стал сплошной "валенок", и все кулера стали;
- Linux в качестве роутера достаточно надёжно себя показывает 3-5-7 лет...
- Windows (из вот "весьма устойчиво работающих" суффиксов) - период полураспада 3-4 мес. - вот только вчера в моей фирме выяснилось, что в уже поставленных crytical mission отрасли SCADA станции умирают, в среднем, за 21 день ... это не мои проекты, но я их предупреждал ... но "нет пророка в своём отечестве"(с) - теперь они по объектам будут ездить на 20-й день ... "накануне"? wink.gif
Владимир Е. Зюбин
Цитата(Goroshko Egor @ May 31 2006, 18:14) *
Цитата(Владимир Е. Зюбин @ May 31 2006, 13:33) *

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


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


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

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

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

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

Цитата(Goroshko Egor @ May 31 2006, 18:14) *
Мы вот в своем проекте вторую неделю байтики считаем и по третьему проходу вычищаем все лишнее.
И каждую лишнюю милисекунду выжимаем из алгоритмов. А целевая платформа - 4 процессорный Intel с 4 Гб памяти. А все равно считаем, оптимизируем, переписываем так что бы в кеш вовремя попадало все что надо... Что бы памяти лишней не жрало.


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

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

Цитата(Goroshko Egor @ May 31 2006, 18:14) *
Насчет производительности аппаратуры - это миф. По тому что когда вы говорите заказчику - да тут надо проц посильнее поставить, памяти побольше, а он считает, считает... И говорит, знаете, дорогие мои, вы конечно умные ребята, но вон у них работате на более дешевой аппаратуре и куплю я систему наверно все таки у них.
Наше отношение к аппаратным ресурсам вызвано в первую очеред практически полным отсутсвием конкуренции. Там где конкуренция есть - за ресурсы борются изо всех сил.

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


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

Впрочем, я могу быть ошибаться, расскажите про свою задачу.
Владимир Е. Зюбин
Цитата(Olej @ May 31 2006, 18:55) *
Меня мало вдохновляет "фирменная" статистика: "посмотрите насколько мы круты"...
Я просто знаю (могу перечислить: в какой стране, где и как, в каком проекте):
- QNX системы в необслуживаемом режиме работают не выключаясь а). 14 лет б). 20 лет ... - выходят из строя потому, что вентиляторы за это время насосали в корпус пыли столько, что там стал сплошной "валенок", и все кулера стали;
- Linux в качестве роутера достаточно надёжно себя показывает 3-5-7 лет...
- Windows (из вот "весьма устойчиво работающих" суффиксов) - период полураспада 3-4 мес. - вот только вчера в моей фирме выяснилось, что в уже поставленных crytical mission отрасли SCADA станции умирают, в среднем, за 21 день ... это не мои проекты, но я их предупреждал ... но "нет пророка в своём отечестве"(с) - теперь они по объектам будут ездить на 20-й день ... "накануне"? ;)


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

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

Лично по моим ощущениям надежность и устойчивость Виндовоза существенно выросла. Или Вы считатете, что она по прежнему находится на уровне Вин95?
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 09:28) *
Впрочем, я могу быть ошибаться, расскажите про свою задачу.


Задача в целом непосредственно касается темы данной дискуссии. Сводится она к необходимости реализации на одном SoftPLC целой группы задач - это и работа самого приложения PLC и SCADA сервера. Почему такие высокие требования - PLC имеет порядка миллиона публичных переменных, значения который должны быть доступны клиентским приложениям. Причем доступна и по чтению и по записи. моя система - это как раз СКАДА сервер, осуществляющий распределенность данных PLC приложения. Латентность обновления данных не более 100 мс. В принципе у нас тоже есть запас производительности и запас по памяти, но оптимизация все равно делается по максимуму. Задача не вычислительная совсем, а чисто алгоритмическая, но при очень большом количестве переменных и достаточно выскоих скоростях. Ведь в 100 мс должен укладываться и цикл PLC и передача данных от PLC к серверу и обслуживание клиентов. в общем времени хватает, но запас все равно требуется. Потому что в определенных ситуациях на том же физическом хосте может подниматься и HMI управляющего клиента и ему тоже нужно время для работы.
А кроме того система должна иметь возможность перепрошивки PLC (изменения алгоритма работы PLC) на лету, без остановки. Когда сервер передает PLC новый, модифицированный код какой-то части его алгоритма и PLC заменят свою часть без срыва цикла, фактически "между" циклами.
А ведь есть еще и резеревирование... и когда поднимается резервный хост и запрашивает полный слепок текущего состояния (миллиона переменных) то вообще жарко становится :-) Ведь остальные задачи не становятся в очередь до окончания синхронизации :-)
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 09:46) *
Лично по моим ощущениям надежность и устойчивость Виндовоза существенно выросла. Или Вы считатете, что она по прежнему находится на уровне Вин95?


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

Ну и наконец наиболее существенный момент, отличающий ОСРВ от ОСОН - это API. В ОСРВ, не только в QNX, системное API намного более соответсвует классу задач систем управления чем API ОСОН - например во всем что связано с установкой таймаутов операций.
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 1 2006, 12:58) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 09:28) *

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


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


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

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

Не понимаю.
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:09) *
Чего-то я ничего не понял... что за алгоритм-то? чем управляете?

Не понимаю.


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

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

На самом деле система весьма дорогая, туда входит масса подсистем, не имеющих прямого отношения к СКАДА и PLC (например система видеонаблюдения) и введение дополнительных аппаратных компонент серьезно влияет на бюджет. Естественно на тунель стоит не один PLC (в зависимости от протяженности), кроме ввода с датчиков и органов управления есть еще данные, приходящие с других PLC (с соседних участков).
Более подробно не отвечу, поскольку задача моей группы несколько другая - обеспечить распределенный доступ к данным PLC и у меня есть на руках ТЗ где указано сколько переменных и с каким периодом должен обслуживать сервер :-) .
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 09:46) *


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


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


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

Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
Во первых это алгоритм свопирования, который даже теоретически нельзя отключить - своп файл в системе присутсвует всегда, даже когда она стартует с CD он созадется в памяти.


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

Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
Второе - плохо предсказуемое (по времени) поведение стека IP протоколов.


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

Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
Теретье - алгоритм планирования - встречаются очень плохо понятные атрефакты.


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

Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
Еще один неприятный недостаток, даже когда вычислительные ресурсы вполне это позволяют у Винды нельзя поменять период прерываний таймера и задачть шаг диспетчеризации отличный от 10 мс.


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

Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
В Линуксе это возможно, но требует пересборки ядра (да и просто по умолчанию в новых версиях это 1 мс) а в QNX - таймер может перенастраиваться в рантайм.


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

Цитата(Goroshko Egor @ Jun 1 2006, 13:37) *
Ну и наконец наиболее существенный момент, отличающий ОСРВ от ОСОН - это API. В ОСРВ, не только в QNX, системное API намного более соответсвует классу задач систем управления чем API ОСОН - например во всем что связано с установкой таймаутов операций.


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

Ну а вообще, у меня такое впечатление, что выбор ОС - это больше дело вкуса. Ну или лучше уж перечислить специфические задачи, которые на Виндовозе не решаются, а на QNX - легко.
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *
Что такое чпец.применения мне так и непонятно. По моему все просто. Есть задача, есть требования, удовлетворяет - вперед. Тем более, что принципиальной разницы между XP и QNX не видно.

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

Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *
Ну и пусть присутствует. Наличие возможности свопа лучше, чем его отсутсвие и крах системы от нехватки ОЗУ.

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

Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *
Не понимаю, чем тут QNX лучше... такая же непредсказуемость... от шести миллисекунд на передачу пакета по TCP/IP.

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

Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *
А в какихъ задачах это нужно? Таких задач не очень много. А там где нужно (какие-нибудь эксперименты) - используются аппаратные решения, а ля дэйта-логгеры.

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

Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *
Не знаю, у нас таймауты операций вообще сняты с системного уровня. Да и API минимально, логика да коммуникации, вот и все АПИ.

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

Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *
Ну а вообще, у меня такое впечатление, что выбор ОС - это больше дело вкуса. Ну или лучше уж перечислить специфические задачи, которые на Виндовозе не решаются, а на QNX - легко.

В основном это те задачи, для которых QNX и была созадна - задачи пром автоматики :-) А на виндоус удобно вести бухгалтерию и набирать документы - она в свою очередь была создана именно для этого. Просто каждая вешь хороша для своего назначения и когда пытаются оседлать корову - ничего особо хорошего, ни корове ни ездоку - не будет. :-)
yuri_t
Инженер, работающий на Западе и создающий некое комплексное
решение, никогда не имеет времени для написания собственных ОС,
компиляторов и уж тем более больших кусков кода на ассемблере...
Есть ошибка в библиотеке(компиляторе,OS) - обойди ТОЛЬКО эту
ошибку своим кодом. Тот кто думает, что уж в его-то коде ошибок
не будет - либо очень юный, либо очень наивный человек...
Другое дело - не ошибиться в выборе библиотеки,компилятора,OS
( и это кстати основная причина, по которой банальные и очень дорогие,
но надежные OS (типа VxWorks) до сих пор продаются,
несмотря на замечательный free Linux)
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 1 2006, 18:15) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *

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

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


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

Цитата(Goroshko Egor @ Jun 1 2006, 18:15) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *

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

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


Так а что делать-то если память кончилась?
Я так понимаю тут два выхода: либо крах системы, либо задержки на своп...
Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...

Цитата(Goroshko Egor @ Jun 1 2006, 18:15) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *

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

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


Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых
входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...
Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.

Цитата(Goroshko Egor @ Jun 1 2006, 18:15) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *

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

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


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

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

Цитата(Goroshko Egor @ Jun 1 2006, 18:15) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *

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

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


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

И если, к примеру, кому-то захочется использовать Рефлекс под ОС QNX (а почему бы и нет), то там тоже не будет необходимости использовать системную службу времени... достаточно одного прерывания от таймера, чтобы организовать тактируемость и все. И параллелизм не выносится на уровень ОС. Сейчас у нас типовые задачи - это 700+ параллельных процессов... в доброй половине из них встречается работа с временными интервалами, часто - несколько раз. И заводить сложную "бодягу" с таймерными переменными просто очень накладно, даже чисто программировать, поэтому у нас даже переменные заводить не надо, конструкция
Код
ТАЙМАУТ <время>{<реакция на таймаут>}
и все.... Да и QNX 4 просто не рассчитана на такой массовый параллелизм. Там пятьсот процессов и все. В 6-ой QNX версии это граничение снято, но все равно, в реальных задачах процессов немного, ну с десяток-другой при всей ейной микроядерности. Да и затраты на обслуживание процесса в QNX на два порядка выше, чем в многопоточных вариантах.

Цитата(Goroshko Egor @ Jun 1 2006, 18:15) *
Цитата(Владимир Е. Зюбин @ Jun 1 2006, 14:35) *

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

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


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

Но опять же, есть задачи, которые требуют других средств, возможно QNX, или там OS9000, или еще чего, вариантов не счесть... одно другому не противоречит... опять же про Stand-alone решения тоже не следует забывать.
Olej
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
Так а что делать-то если память кончилась?
Я так понимаю тут два выхода: либо крах системы, либо задержки на своп...
Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...


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

Неприменимость свопинга в RTOS - это давно требуемая классика.
И крах системы при недостатке памяти (и не системы, а приложения) - это лучше, чем "мягкое" и мало заметное её непредсказуемое поведение - быстрее сообразите, что памяти жалеть не надо wink.gif (это ж ваше утверждение?: ресурсов жалеть не надо).
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
Егор, Вы говорили "о ряде факторов", не могли бы Вы более конкретно их обозначить? Что это за факторы, по Вашему мнению?

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

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
Так а что делать-то если память кончилась?
Я так понимаю тут два выхода: либо крах системы, либо задержки на своп...
Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...

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

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых
входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...
Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.

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

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
В задачах управления и пром.автоматизации - не сталкивался.

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

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
Сейчас у нас типовые задачи - это 700+ параллельных процессов... в доброй половине из них встречается работа с временными интервалами, часто - несколько раз. И заводить сложную "бодягу" с таймерными переменными просто очень накладно, даже чисто программировать, поэтому у нас даже переменные заводить не надо, конструкция
Код
ТАЙМАУТ <время>{<реакция на таймаут>}
и все....

native API QNX дает вам очень похожие конструкции уже готовыми, только в несколько раз богаче по способам уведомления о таймауте и с возможностью очень гибкой настройки выполнения реакции. :-)
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
В 6-ой QNX версии это граничение снято, но все равно, в реальных задачах процессов немного, ну с десяток-другой при всей ейной микроядерности. Да и затраты на обслуживание процесса в QNX на два порядка выше, чем в многопоточных вариантах.

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

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

Я, честно говоря такой тенденции не наблюдал. Судя по выставкам типа CeBIT или EmbededWorld тенденция сейчас идет в сторону Linux решений, что тоже мне не очень нравится. Но это мое субъективное мнение. Объективно же можно отметить что не смотря на весьма дорогие решения от QSSL и WindRiver их системы все равно пользуются очень большим спросом - что демонстрирует их некоторые преимущества перед тем же бесплатным Linux или относительно дешевым Windows.
Владимир Е. Зюбин
Цитата(Olej @ Jun 2 2006, 14:54) *
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *

Так а что делать-то если память кончилась?
Я так понимаю тут два выхода: либо крах системы, либо задержки на своп...
Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы...


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

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

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

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

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

Пояснили бы лучше, почему это в 6-ой версии QNX есть диск-своп, и какой смысл в его отключении, чем по моим наблюдениям QNX-сообщество необычайно гордится и при этом погружается в состояние самодовольного успокоения.
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 2 2006, 15:11) *
'Владимир Е. Зюбин':
"Так а что делать-то если память кончилась?
Я так понимаю тут два выхода: либо крах системы, либо задержки на своп...
Мне почему-то так кажется, что задержки предпочтительнее, чем крах системы..."

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


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

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

Как в анекдоте про молодого брадобрея:
Бреет новичок-парикмахер...
Бреет, бреет, Раз! - порез. Новичок: "Ой, извините.."
Дальше продолжает... опять порез... "Ой, прошу прощения"
Дальше бреет, опять неосторожное движение и порез...
"А-а-а!!! Ничего не получается!!!" (резкие крест-накрест движения бритвой по лицу клиента)

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

Цитата(Goroshko Egor @ Jun 2 2006, 15:11) *
'Владимир Е. Зюбин':
"Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых
входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...
Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС. "

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


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

Цитата(Goroshko Egor @ Jun 2 2006, 15:11) *
'Владимир Е. Зюбин':
"В задачах управления и пром.автоматизации - не сталкивался. "

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


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

Цитата(Goroshko Egor @ Jun 2 2006, 15:11) *
'Владимир Е. Зюбин':
"Сейчас у нас типовые задачи - это 700+ параллельных процессов... в доброй половине из них встречается работа с временными интервалами, часто - несколько раз. И заводить сложную "бодягу" с таймерными переменными просто очень накладно, даже чисто программировать, поэтому у нас даже переменные заводить не надо, конструкция
Код
ТАЙМАУТ <время>{<реакция на таймаут>}
и все.... "

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


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

Цитата(Goroshko Egor @ Jun 2 2006, 15:11) *
'Владимир Е. Зюбин':
"В 6-ой QNX версии это граничение снято, но все равно, в реальных задачах процессов немного, ну с десяток-другой при всей ейной микроядерности. Да и затраты на обслуживание процесса в QNX на два порядка выше, чем в многопоточных вариантах."

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


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

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

Цитата(Goroshko Egor @ Jun 2 2006, 15:11) *
'Владимир Е. Зюбин':
"По мне так ни Виндоуз, ни QNX сами по себе не подходят для задач пром автоматизации и требуют некой надстройки. Ну а с практической точки зрения, проще иметь однородную среду, в которой и документы набираешь и сами программы. Поэтому общая тенденция будет все-таки в сторону Виндовоза смещаться. В общем-то она и наблюдается. HMI - оно на 90% на Виндовозе делается, да и весь т.н. софт-ПЛК. И есть масса задач (их большинство), для которых это приемлемое решение."

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


А я вообще из лидеров продаж не знаю SCADA-пакетов для QNX, все сплошняком Windows. Ничего не имею против Linux, или QNX, но что поделать? Не знаю. Кстати, дороговизна QNX и Ко и в общем-то и говорит за то, что объем продаж у них невысокий...
Olej
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:01) *
А я со своей стороны скажу, что если Вы уж утверждаете, что ваш оппонент не владеет предметом, так уж будьте добры указать в чем. Не в такие уж дебри QNX я забираюсь, а рассуждаю об общей стратегии.


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

1.
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:01) *
Тестовые замеры. По витой паре 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.
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:01) *
В 6-ой QNX версии это граничение снято, но все равно, в реальных задачах процессов немного, ну с десяток-другой при всей ейной микроядерности. Да и затраты на обслуживание процесса в QNX на два порядка выше, чем в многопоточных вариантах.


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

А "затраты на обслуживание процесса в QNX" не "на два порядка выше", чем в многопоточных вариантах, а на несколько процентов, которые и не всегда вы сможете даже специально выделить в тестах. Чтоб не спорить и не давать вам повода затягивать спор "откуда известно" я вам скажу следующее:
- эти результаты и выводы я привожу в своей книге (вместе с Егором Горошко):
http://www.books.ru/shop/books/357604
- а поскольку их пока никто не оспорил и им не возразил - их нельзя считать неверными wink.gif;
- а книга по рейтингам www.books.ru - 3-я позиция "книга 2005г." (из пару тысяч), т.е. её читают и, значит, с ней соглашаются.

4.
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:01) *
Что же касается своппинга и "требуемой классики", то могу открыть Вам секрет, что, вообще говоря, даже не своппинг крайне нежелателен, а вообще динамические операции с ОЗУ, даже если они к своппингу не приводят.


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

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

5.
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:01) *
Пояснили бы лучше, почему это в 6-ой версии QNX есть диск-своп, и какой смысл в его отключении, чем по моим наблюдениям QNX-сообщество необычайно гордится и при этом погружается в состояние самодовольного успокоения.


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

P.S. Я это (и многое ещё мог бы) написал вовсе не для того, чтобы вас, или кого-то ещё, в чём то уличать ... но вы просили? wink.gif.
А для того, что давайте не блистать эрудицией в разделах знаний, которые знаем по-наслышке - а говорить по теме обсуждения - если есть что сказать.

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:01) *
А я вообще из лидеров продаж не знаю SCADA-пакетов для QNX, все сплошняком Windows. Ничего не имею против Linux, или QNX, но что поделать? Не знаю. Кстати, дороговизна QNX и Ко и в общем-то и говорит за то, что объем продаж у них невысокий...


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

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

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

А "все сплошняком Windows" SCADA ... это отдельная песня:
- это "модный" рынок предложения...
- работы немного - а стоимости предожения ого-го...
- при архитектурно-качественных показателях всех их ... ох-ох-ох ...
- а ещё этот рынок разогревает огромное число ... "системных интеграторов" wink.gif, очень сомнительного профессионального уровня, которым очень удобен "конструктор", из которого можно вылеплять "продукт", не очень напрягая себе голову, как там кубики этого конструктора меж собой взаимодействуют ... "доктор сказал в морг - значит в морг"(с) wink.gif
Olej
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:43) *
- это идиотизм (прошу прощения за прямоту).


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

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


А здесь просто ... - не делайте мне смешно... wink.gif

1. если это Ethernet, то минимальный пакет: 46 байт данных + 18 байт заголовок = 64;
2. а вот максимальный пакет Ethernet, что интересно, MTU = 1500 + те же 18 байт заголовок MAC уровня;
3. а при пользовательском "минимальный пакет по 4Кб" (а у вас ещё там и максимальные были? wink.gif) - это сегментация на 3 как минимум IP пакета, а для сегментов IP свои правила задержек передачи, да ещё для каждого сегмента может потребоваться и ARP обмен для разрешения адреса...
4. а при TCP протоколе (у вас же Modbus over TCP?) сегментация может быть и ещё мельче: определяется соотношениями размеров окон приёма и передачи...
5. а обратную посылку подтверждающего сегмента ACK вы учитывали? ("вы обращались к проктологу - правильно ли вы вкладываете свой ваучер?")
6. а алгоритм Нэйгла у вас был включен или выключен? ... он влияет на применение в протоколе отсроченных подтверждений;

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:43) *
Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых
входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...


Может вы бы лучше "засекали" загибая пальцы? wink.gif
Тоже ведь - методика ...
Владимир Е. Зюбин
Цитата(Olej @ Jun 2 2006, 17:23) *
'Владимир Е. Зюбин': "А я со своей стороны скажу, что если Вы уж утверждаете, что ваш оппонент не владеет предметом, так уж будьте добры указать в чем. Не в такие уж дебри QNX я забираюсь, а рассуждаю об общей стратегии."

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


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

Цитата(Olej @ Jun 2 2006, 17:23) *
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 порядочка, чуть-чуть) я видел совсем другие цифры и вам могу показать.

Измерял время. Если Вы не понимаете, как можно измерить интервал в 7 мс при таймслайсе в 10 мс (а я этого тоже не понимаю), так может быть Ваши сведения о 10 мс - не соответствуют действительности?
Не приходило в голову? А то, что Вы с другим прибором связывались? Думаете, не имеет значения?

Уточняю еще раз: цикл в 6-7 мс складывается из двух составляющих - 1 мс на запись, и 5-6 мс на чтение... определялось это установкой таймаутов.

Цитата(Olej @ Jun 2 2006, 17:23) *
2 и 3.'Владимир Е. Зюбин':"В 6-ой QNX версии это граничение снято, но все равно, в реальных задачах процессов немного, ну с десяток-другой при всей ейной микроядерности. Да и затраты на обслуживание процесса в QNX на два порядка выше, чем в многопоточных вариантах."

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

Прошу прощения, нельзя ли чуть менее расплывчато и чуть более конкретно?
Зачем этот субъективизм - "с легкостью уживаются"?

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

Цитата(Olej @ Jun 2 2006, 17:23) *
А "затраты на обслуживание процесса в QNX" не "на два порядка выше", чем в многопоточных вариантах, а на несколько процентов, которые и не всегда вы сможете даже специально выделить в тестах. Чтоб не спорить и не давать вам повода затягивать спор "откуда известно" я вам скажу следующее:
- эти результаты и выводы я привожу в своей книге (вместе с Егором Горошко):
http://www.books.ru/shop/books/357604
- а поскольку их пока никто не оспорил и им не возразил - их нельзя считать неверными ;);
- а книга по рейтингам www.books.ru - 3-я позиция "книга 2005г." (из пару тысяч), т.е. её читают и, значит, с ней соглашаются.


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

Нет данных? Информация об этом тоже важна.

Цитата(Olej @ Jun 2 2006, 17:23) *
4.
'Владимир Е. Зюбин':"Что же касается своппинга и "требуемой классики", то могу открыть Вам секрет, что, вообще говоря, даже не своппинг крайне нежелателен, а вообще динамические операции с ОЗУ, даже если они к своппингу не приводят."

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

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

А Вы почитайте специализированную литературу по вопросу. Например, вот эту:

On Software Languages for use in Nuclear Power Plant Safety Systems/
Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D.,
Ossia K., Pollard J., Shokri E., Sorkin A., Tai A., Tso K.S., Wendelboe D. - NRC, 1997.

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

Цитата(Olej @ Jun 2 2006, 17:23) *
5.
'Владимир Е. Зюбин':"Пояснили бы лучше, почему это в 6-ой версии QNX есть диск-своп, и какой смысл в его отключении, чем по моим наблюдениям QNX-сообщество необычайно гордится и при этом погружается в состояние самодовольного успокоения."

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

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

Цитата(Olej @ Jun 2 2006, 17:23) *
P.S. Я это (и многое ещё мог бы) написал вовсе не для того, чтобы вас, или кого-то ещё, в чём то уличать ... но вы просили? ;).
А для того, что давайте не блистать эрудицией в разделах знаний, которые знаем по-наслышке - а говорить по теме обсуждения.


Я за. Жду конкретики. И не стесняйтесь показывать мои ошибки. У меня по этому поводу комплексов нет. Только спасибо скажу.

Цитата(Olej @ Jun 2 2006, 17:23) *
'Владимир Е. Зюбин':"А я вообще из лидеров продаж не знаю SCADA-пакетов для QNX, все сплошняком Windows. Ничего не имею против Linux, или QNX, но что поделать? Не знаю. Кстати, дороговизна QNX и Ко и в общем-то и говорит за то, что объем продаж у них невысокий..."

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


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

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

Только, чур, не надо уточнять, что кроме RealFlex есть еще пара-тройка скада-пакетов под QNX. Это мне известно.
Владимир Е. Зюбин
Цитата(Olej @ Jun 2 2006, 17:49) *
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:43) *

- это идиотизм (прошу прощения за прямоту).


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


То есть дело настолько сложное, что Вы предлагаете поверить Вам на слово?

И, пожалуйста, не надо критиковать утверждения, которые я не делал... В этом нет никакого смысла...
(это я намекаю на то, что ни про раннее тестирование нехватки ОЗУ, ни про непредсказуемость я ничего не говорил).

Цитата(Olej @ Jun 2 2006, 17:49) *
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:43) *

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


А здесь просто ... - не делайте мне смешно... ;)

1. если это Ethernet, то минимальный пакет: 46 байт данных + 18 байт заголовок = 64;
2. а вот максимальный пакет Ethernet, что интересно, MTU = 1500 + те же 18 байт заголовок MAC уровня;
3. а при пользовательском "минимальный пакет по 4Кб" (а у вас ещё там и максимальные были? ;)) - это сегментация на 3 как минимум IP пакета, а для сегментов IP свои правила задержек передачи, да ещё для каждого сегмента может потребоваться и ARP обмен для разрешения адреса...
4. а при TCP протоколе (у вас же Modbus over TCP?) сегментация может быть и ещё мельче: определяется соотношениями размеров окон приёма и передачи...
5. а обратную посылку подтверждающего сегмента ACK вы учитывали? ("вы обращались к проктологу - правильно ли вы вкладываете свой ваучер?")
6. а алгоритм Нэйгла у вас был включен или выключен? ... он влияет на применение в протоколе отсроченных подтверждений;


Вы увлекаетесь желанием показать свою эрудицию и продемонстрировать некомпетентность оппонента. Я Вам отвечаю честно о результатах своих замеров (возможно, в чем-то ошибаясь, например, в оценке минимального размера пакета). Т.к. передо мной не стоит задача пиарить Виндовоз или КуНаХэ... мне на обе эти ОС и их производителей чихать.

Так вот. По моим замерам посылка пакета от Wintel к модулю УСО занимает 1 мс. Прием - 5 мс. И мне не особенно важно, предусмотрен ли там ACK, или алгоритм Нэйгла. Могу сообщить, что при посылке устанавливается таймаут, который при значении 2-3 мс начинает изредка срабатывать, так что можно предположить, что подтверждение передачи приходит.

Цитата(Olej @ Jun 2 2006, 17:49) *
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 13:43) *

Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых
входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...


Может вы бы лучше "засекали" загибая пальцы? ;)
Тоже ведь - методика ...


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

И что Вы имеете против оценки на глаз? Вполне рабочий вариант для грубой оценки. Или я Вас настолько сильно рассмешил, что Вы уже не можете остановиться? :-)
Olej
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 15:28) *
Цитата(Olej @ Jun 2 2006, 17:23) *

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

Измерял время. Если Вы не понимаете, как можно измерить интервал в 7 мс при таймслайсе в 10 мс (а я этого тоже не понимаю), так может быть Ваши сведения о 10 мс - не соответствуют действительности?
Не приходило в голову? А то, что Вы с другим прибором связывались? Думаете, не имеет значения?

Уточняю еще раз: цикл в 6-7 мс складывается из двух составляющих - 1 мс на запись, и 5-6 мс на чтение... определялось это установкой таймаутов.

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


Уточняю ещё раз wink.gif ... нельзя мерять милиметры линейкой с ценой деления в сантиметр:
- если это был Windows, как вы сказали, то дискретная шкала времени - 10мс. (15мс. для SMP ядра NT/2000), ... 2 события в ОС, разделённые интервалом меньше этой единицы - не различаются как разные события, они "одновременны"; какие бы вы не записывали в таймауты (или задержки в функциях типа delay()) если они меньше шкалы времени, то это всё равно что 0, и срабатывание произойдёт ... в "хороших" ОС - через 1 timeslise, а в "плохих" - на следующем.
Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 15:28) *
Прошу прощения, нельзя ли чуть менее расплывчато и чуть более конкретно?
Зачем этот субъективизм - "с легкостью уживаются"?

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


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

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 15:28) *
У нас беспредметный разговор.
Но нельзя ли привести конкретные данные?
С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс.

У нас предметный разговор wink.gif.
Вы сказали: "эффективность переключения процессов хуже потоков на пару порядков"... я сказал: "это чушь, которая объясняется тем, что это пишут (умозрительно) и в плохих учебниках... эффективность реализации в N процессов практически не хуже, чем N потоков, и более того, и чем простейшей линейной последовательной программы от main() - до exit()".

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 15:28) *
А Вы почитайте специализированную литературу по вопросу. Например, вот эту:

On Software Languages for use in Nuclear Power Plant Safety Systems/
Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D.,
Ossia K., Pollard J., Shokri E., Sorkin A., Tai A., Tso K.S., Wendelboe D. - NRC, 1997.


Читал я всё это, и ещё много другого ... это - мнения, но есть и другие, полностью противоположные мнения...
Это предмет обсуждений.
Тогда посоветуйте всем здесь использующим С++ категорически не использовать STL (который уже стандарт C++), который бессмысленен без неявного динамического управления памятью.
А древний strdup() ? вы никогда не задавались вопросом откуда он берёт память для создания копии?

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 15:28) *
То, что дефрагментация памяти при динамических операциях ведет к потере производительности, не такая уж и революционная мысль... и непонятно, что тут дискуссионного.


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

Цитата(Владимир Е. Зюбин @ Jun 2 2006, 15:28) *
А про "скада-на коленке", не стоило упоминать... под Виндовозом их тоже немеряно клепается.
Есть и хорошие, не сомневаюсь, но мы же об общих тенденциях говорим, о мэйнстриме, а не о приятных исключениях.


Почему не стоило? :
1. в большинстве - они совершеннее коммерческих пакетов для "всех-и-вся"...
2. ... а Windows системы распределённого управления данными - они всё равно "не жильцы" при длительной эксплуатации - это хорошо только на "презентациях с промоушн" показывать...
Goroshko Egor
Цитата('Владимир Е. Зюбин')
А в чем причина-то? Большая политика? Сделали, а потом поняли, что выбивают сами себе почву из-под ног? 8-) В общем не вижу смысла, да и Вы, я вижу, не желаете приоткрывать завесу над этой тайной.


Могу немного приоткрыть завесу. Свопирование данных (не кода) очень важная вешь для работы компиляторов. При переходе на компилятор gcc в 6 QSSL добавили эту функциональность именно для средст разработки и тестированя, кторый требуют обработки больших объемов данных и при этом не обрабатывают ошибки распределения памяти (а кто их обрабатывает? ;-) )
Однако даже тогда режим свопирования данных включался у процесса только после специфических манипуляций и процессы, не производившие таких манипуляций свопирования данных не получали.
В системах ОСРВ нет не свопирования данных и кода приложений, они также не используют механизмов Copy On Write (COW) предназначенных для постепенной подгрузки кода приложения при его запуске, повсеместно применяющегося в ОСОН (и совершенно правильно и обоснованно применяющегося в ОС этого типа), как раз потому, что подгрузка кода после начала его исполнения может приводить к не предсказуемым задержкам его исполнения.

По поводу определений ОСРВ. В свое время работая над статьей для книги "Практика работы в QNX" я перерыл очень большое количество определений ОСРВ. Часть этих определений я приводил и в статье, и все они в целом сводятся к определению задач реального времени как задач коректность выполнения которых связана как с самим результатом выполнения так и с временем этого выполнения. Это краеугольный камень понятия "реальное время" и это весьма очевидно. Ведь согласистесь, когда (очень грубый пример, но все же) поступает команда опустить стержни в реактор, и выполняется она после взрыва реактора - то ее выполнение в принципе уже никому не нужно :-).
Более простой пример. Если по требованиям к системе от момента нажатия кнопки оператором на перевод стрелки до факта перевода стрелки должно пройти не более... ну скажем 10 сек, а система по каким то причинам переводит ее через 100 сек когда поезд уже едет по стрелке - то выполнение этой команды уже явно не имеет смыла - задача не выполнена. Думаю в задачах тех же кристалов вы сами можете привести массу примеров.

Еще один момент
Цитата
У нас беспредметный разговор. Особенно, когда аргументация идет в стиле "читают, значит, согласны".
Вы написали хорошую книгу, искренне поздравляю. Но нельзя ли привести конкретные данные?
С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс.

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

Цитата
Уточняю ещё раз ... нельзя мерять милиметры линейкой с ценой деления в сантиметр:
- если это был Windows, как вы сказали, то дискретная шкала времени - 10мс. (15мс. для SMP ядра NT/2000), ... 2 события в ОС, разделённые интервалом меньше этой единицы - не различаются как разные события, они "одновременны"; какие бы вы не записывали в таймауты (или задержки в функциях типа delay()) если они меньше шкалы времени, то это всё равно что 0, и срабатывание произойдёт ... в "хороших" ОС - через 1 timeslise, а в "плохих" - на следующем.
Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Тут нужно еще кое что уточнить - все это верно, если мы меряем события, разделенные блокированным состоянием потока. (delay(0)) Несомнено используя счетчик циклов процессора можно измерять интервал времени с гораздо большей точностью - но если не было вытеснения потока.
Andrew2000
Цитата(Olej @ Jun 2 2006, 18:19) *
Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Это не совсем так (правда я так и не понял как мерил Зюбин). Но, в виндах есть т.н. Мультимедийный таймер - см. "mmsystem.h"

The timeGetTime function retrieves the system time, in milliseconds. The system time is the time elapsed since Windows was started.
DWORD timeGetTime(VOID);
Windows NT: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine.
Windows 95: The default precision of the timeGetTime function is 1 millisecond.

Может пригодиться кому....
Я при пом. этого таймера генерил 5ms импульсы ногами LPT-порта - Win98 / PentumMMX 166 MHz.
Довольно стабильно, пока к винту обращений нет, но не дай бог мышой по экрану возить ... smile.gif
Olej
Цитата(Goroshko Egor @ Jun 2 2006, 17:50) *
Тут нужно еще кое что уточнить - все это верно, если мы меряем события, разделенные блокированным состоянием потока. (delay(0)) Несомнено используя счетчик циклов процессора можно измерять интервал времени с гораздо большей точностью - но если не было вытеснения потока.


Всё это так, как и то, что дальше добавил Andrew2000, но и это, и другое, и третье ... на других архитектурах отличных от х86 могут быть другие источники и механизмы задатчиков частот ... но:
- всё это не системное время, его можно использовать для измерений, но все системные механизмы, определяющие таймеры, тайм-ауты, пассивные ожидания, шедулирование и др. - все работают только от единого задатчика времени - системных часов;
- и "шаг" этих часов является краеугольным понятием и характеристикой ОС...
- кроме того, неприятность любых других часов в системе, которые можно использовать для измерений, ещё состоит и в том, что они могут "идти" быстрее или медленнее относительно системного времени, потому что используют физически другой задатчик (кварц), и достаточно значительно (я видел в экспериментах порядка 10**-4 для разных экземпляров компьютеров).

P.S. для иллюстрации и разрядки, подумалось:
- все знают, что "движущееся" кино вполне реализуемо при смене кадров порядка 20гц (любительские кино камеры использовали 16кадр./сек., кажется)...
- а теперь представьте, что мы "гоним кино" с дискретностью событий медленнее ... во столько раз, во сколько тик Windows длиннее QNX: 10000/10 = 1000 раз, т.е. период смены кадров стал ... 5 сек.
- вот чисто количественное изменение, но что у нас получилось? вместо кино ... ну, в лучшем случае серия сменяющихся "художественных снимков" для журнала комиксов.
Вот что такое чисто количественное изменение параметра!

Но и помимо разрешающей способности системного времени,есть ещё одно обстоятельство, которое часто забывается, на которое косвенно обратил внимание Егор: "если он не будет вытеснен" - когда вы записываете timeout( 1 ), то это вовсе не означает, что вы отсчитаете интервал времени в 1сек. - это может быть 1, 2, 10, 100 ... вообще бесконечность.
POSIX в этом смысле чётко определяет: любой интервал не может быть меньше заказанного, но сколь угодно больше - пожалуйста... Но не все ОС строятся на POSIX совместимости.
Так что к измерению временных интервалов нужно подходить ох как осторожно!
yuri_t
Насчет реального времени как регламентированного время отклика, проблемы
своппинга и т.д. - все это вещи, хорошо известные тем, кто занимается Real Time...
А вот что действительно интересно было бы услышать от поклонников ONX - почему
Microkernel Systems (QNX,Mach, Unix SVR 4, Minix, etc) так и не получили широкого распостранения?
Все-таки уступают по быстродействию системам с монолитным ядром ?
Olej
Цитата(Владимир Е. Зюбин @ Jun 2 2006, 08:32) *
Тестовые замеры. По витой паре Ethernet. Связь по Modbus over TCP|IP с выносным модулем цифровых
входов/выходов. Т10 или 100 не скажу. Цикл приема-передачи занимает 6-7 мс. Методика измерений - заряжаем в цикле 1000 пакетов и засекаем секундомером. В конце делим секунды на тысячу...
Приложение LabView(Win2000). Уверен, что на другой ОС никаких улучшений не будет. Т.к. дело тут не в ОС.


Вот по этому поводу вспомнил и нашёл - я вот здесь:
http://qnxclub.net/modules.php?name=Forums...er=asc&start=15
- как-то совсем по другому случаю и поводу - замерял время распространения, но с гораздо более точной "линейкой", что и как можете посмотреть по указанному URL, а конечные цифры я сцитирую:
Цитата
В итого, для компьютеров ~500-600мгц и сети Ethernet 10 мбит/сек:
- время задержки ответа (распространения в 2 стороны) порядка 1.15-1.19 мсек.;

- это на 10mbit/sec : ~600мкс. - это ведь не совсем то, что 6-7мс. wink.gif - я не претендую на точность, но вот что происходит в зависимости от методики.
Olej
Цитата(yuri_t @ Jun 2 2006, 21:24) *
А вот что действительно интересно было бы услышать от поклонников ONX - почему
Microkernel Systems (QNX,Mach, Unix SVR 4, Minix, etc) так и не получили широкого распостранения?
Все-таки уступают по быстродействию системам с монолитным ядром ?


А микроядерная архитектура и не должна принципиально уступать в производительности монолитной, при прочих равных ... об этом Таненбаум как-то рассуждал, нет таких фундаментальных ограничений.
Кстати, QNX со своей GUI подсистемой Photon - субъективно весьма "шустрая" ОС, по крайней мере, сравнительно с Windows на том же экземпляре оборудования - гораздо "подвижнее".

А "не получили широкого распостранения?"... На то есть достаточно много причин, но это только IMHO:
- ОС на основе микроядра реально появились в 80-х годах (развитые - даже к середине), а уже развитые монолитные ОС - с 1960 и ранее (IBM 360 - классика): 20-25 лет и 45 есть разница? ... ещё не вечер, просто... wink.gif
- над уже развивающимися проектами (и фирмами) довлеет совместимость: любой проект ОС, который к ~90г. из себя хоть что-то представлял (а представлять он мог только монолитное решение) - обречён был развиваться только в рамках изначально заложенной идеологии;
- монолитные ОС легче в развитии эволюционным путём: MS DOS v.1 - уже была какая-то ОС ... в некотором смысле wink.gif, а потом могла себе позволить эволюционировать в v.3.30 (которая хоть на что-то уже годилась) и далее ... для микроядерных проектов нужна достаточно начальная высокая "ступенька" наработки, когда это можно показать хотя бы как draft-версию ОС.
- микроядерная архитектура - это в значительной мере университетское творение (MTI & ...), монолитное же ядро можно начинать "с коленки", "на хлопский розум" - лучше пример чем Linux здесь и не придумаешь (в этом смысле стоит призадуматься, что ни один проект микроядерной реализации не развивался без поддержки на начальных этапах бюджетной поддержки или госзаказа).
- ... наверное, микроядерная архитектура и не есть наилучшая на все случаи жизни (это только у MS - Windows OS наилучшая для любых применений), в других областях применений могут быть оптимальны и другие архитектуры.
=AK=
Цитата(zltigo @ May 23 2006, 22:20) *
Цитата(Olej @ May 23 2006, 14:43) *

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

А страх, прочно базируется на незнании :-( и нежелании/неспособности постигать новое после
некоторого освоения и изобретения первого "лома".

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

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

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

Я отнюдь не пытаюсь умалить роль "чужих" решений, они нужны, но они не являются панацеей. В сущности я еще раз другими словами сказал то, что здесь много раз говорили разные ораторы, так что довольно странно видеть здесь процитированные реплики. Если уж такие простые вещи и с пятого раза не доходят, то что же можно ожидать от описаний на относительно сложные продукты, сколько раз их придется перечитать, пока информация усвоится?
=AK=
Цитата(Andrew2000 @ Mar 6 2006, 23:34) *
Цитата(=AK= @ Mar 6 2006, 14:42) *

Зюбин - единственный, кто утверждает, что IL произошел от STEP5.

Ясно, спасибо за информацию.
На сайте Фиорда в презенташке нашел: "IL - Подобен SIEMENS (Step 5)"
т.е. наверное Step 5 подобен IL smile.gif

На всякий случай я задал вопрос о том, действительно ли IL произошел от Step5 г-ну von Ingo Rolle, члену IEC от Германии, автору книги "IEC 61131, Wozu?". К сожалению, книга написана на немецком, которым я не владею, однако уважаемый автор не поленился мне ответить. Он пишет: "the book says in chapter 4.2 that German contributions to IEC 61131-3 were DIN 19239 and VDI Richtlinie 2880 which already contained precursors of IL, FBD and LD." Как видим, о сименсовском Step5 речи не идет, т.е., как и ожидалось, Зюбин бредит.
Владимир Е. Зюбин
Цитата(Olej @ Jun 2 2006, 20:19) *
'Владимир Е. Зюбин':"Измерял время. Если Вы не понимаете, как можно измерить интервал в 7 мс при таймслайсе в 10 мс (а я этого тоже не понимаю), так может быть Ваши сведения о 10 мс - не соответствуют действительности?
Не приходило в голову? А то, что Вы с другим прибором связывались? Думаете, не имеет значения?

Уточняю еще раз: цикл в 6-7 мс складывается из двух составляющих - 1 мс на запись, и 5-6 мс на чтение... определялось это установкой таймаутов.

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

Уточняю ещё раз ;) ... нельзя мерять милиметры линейкой с ценой деления в сантиметр:
- если это был Windows, как вы сказали, то дискретная шкала времени - 10мс. (15мс. для SMP ядра NT/2000), ... 2 события в ОС, разделённые интервалом меньше этой единицы - не различаются как разные события, они "одновременны"; какие бы вы не записывали в таймауты (или задержки в функциях типа delay()) если они меньше шкалы времени, то это всё равно что 0, и срабатывание произойдёт ... в "хороших" ОС - через 1 timeslise, а в "плохих" - на следующем.
Так что предполагать вы можите всё что угодно, но различать события в Windows более "плотные", чем 10мс. вы не можете.

Почему Вы не можете предположить, что в Винде можно получать разрешение в 1 мс?
Мои опыты прямо приводят к этому выводу. Почему, когда я устанавливаю таймаут в 4 мс, таймаутов не наблюдается, а когда устанавливаю 2-3 они начинают появляться?

То же самое и про измерение линейками... Вы просто не владеете простыми методиками.
ну а они есть, и секундомером можно измерять миллисекундные времена...
просто измерять надо не единичный процесс, а серию... тысячу, или десять тысяч, или сто тысяч...
задачка-то простая:
Код
Дано: длительность N операций равна T.
Найти: длительность одной операции.

ПОНЯТНО, что измеряется СРЕДНЕЕ время, но если длительность процессов более-менее постоянная, то методика вполне рабочая и для оценки времен вполне годится.

Цитата(Olej @ Jun 2 2006, 20:19) *
'Владимир Е. Зюбин':"Прошу прощения, нельзя ли чуть менее расплывчато и чуть более конкретно?
Зачем этот субъективизм - "с легкостью уживаются"?

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

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

Увы, я опять не увидел, ни чисел, ни данных... "практически не различается" - это малоинтересная лирика. Вам же была дана конкретная цифра "накладные расходы на обслуживание процесса на 1ГГц процессоре составляют приблизительно 200 нс". А Вы в ответ "практически не различается" - это что больше, или меньше, чем 200 нс?

Цитата(Olej @ Jun 2 2006, 20:19) *
'Владимир Е. Зюбин':"У нас беспредметный разговор.
Но нельзя ли привести конкретные данные?
С моей стороны для альтернативных решений числа приведены - это сотни наносекунд на Гигагерцовой частоте на процесс."

У нас предметный разговор ;).
Вы сказали: "эффективность переключения процессов хуже потоков на пару порядков"... я сказал: "это чушь, которая объясняется тем, что это пишут (умозрительно) и в плохих учебниках... эффективность реализации в N процессов практически не хуже, чем N потоков, и более того, и чем простейшей линейной последовательной программы от main() - до exit()".


У нас БЕСПРЕДМЕТНЫЙ РАЗГОВОР, т.к. Вы до сих пор не привели ни одной цифры.

Цитата(Olej @ Jun 2 2006, 20:19) *
'Владимир Е. Зюбин':"А Вы почитайте специализированную литературу по вопросу. Например, вот эту:

On Software Languages for use in Nuclear Power Plant Safety Systems/
Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D.,
Ossia K., Pollard J., Shokri E., Sorkin A., Tai A., Tso K.S., Wendelboe D. - NRC, 1997."

Читал я всё это, и ещё много другого ... это - мнения, но есть и другие, полностью противоположные мнения...
Это предмет обсуждений.
Тогда посоветуйте всем здесь использующим С++ категорически не использовать STL (который уже стандарт C++), который бессмысленен без неявного динамического управления памятью.
А древний strdup() ? вы никогда не задавались вопросом откуда он берёт память для создания копии?

Чего тут обсуждать-то? 8-)
Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...
В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...
Ну, чего тут обсуждать? :-)))

То, что программирование на Си++ менее безопасное, чем на Си? Это секрет Полишенеля, про который
уже везде писано-переписано...

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

Цитата(Olej @ Jun 2 2006, 20:19) *
'Владимир Е. Зюбин':"То, что дефрагментация памяти при динамических операциях ведет к потере производительности, не такая уж и революционная мысль... и непонятно, что тут дискуссионного."

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

А что такое сборка мусора, по Вашему? 8-) По мне, так это источник непредсказуемых задержек.

Цитата(Olej @ Jun 2 2006, 20:19) *
'Владимир Е. Зюбин':"А про "скада-на коленке", не стоило упоминать... под Виндовозом их тоже немеряно клепается.
Есть и хорошие, не сомневаюсь, но мы же об общих тенденциях говорим, о мэйнстриме, а не о приятных исключениях."

Почему не стоило? :
1. в большинстве - они совершеннее коммерческих пакетов для "всех-и-вся"...
2. ... а Windows системы распределённого управления данными - они всё равно "не жильцы" при длительной эксплуатации - это хорошо только на "презентациях с промоушн" показывать...


1. ... только очень дороги в эксплуатации...
2. ... это Ваше личное мнение, которое расходится со статистическими данными.
Olej
Цитата(=AK= @ Jun 3 2006, 06:27) *
Безапелляционность при отсутствии аргументов, то есть голые понты. Кроме пресловутого "страха" (который вообще можно было и не упоминать, т.к. случаев наверняка мало, мне, например, они вообще неизвестны), есть много других, гораздо более веских причин. Например, ограниченность кругозора, когда человек просто не знает о существовании подходящего продукта, или, если и знает, то (ошибочно) думает, что продукт неприменим для его задачи.

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


АК, это я по неосторожности употребил первым термин "страх" ... но совсем в другом смысле: именно опасения взвешивающего альтернативные решение специалиста, и стремление его быть ответственным в своих выборах. И это есть в точности то, что вы описываете.
И только в таком смысле я это употребил... а оно потом "пошло поехало", а поправляться лень было.
Прошу почтенную публику воспринимать термин "страх" в контексте данного разговора - только так cheers.gif


Цитата(Владимир Е. Зюбин @ Jun 3 2006, 10:09) *
Почему Вы не можете предположить, что в Винде можно получать разрешение в 1 мс?
Мои опыты прямо приводят к этому выводу. Почему, когда я устанавливаю таймаут в 4 мс, таймаутов не наблюдается, а когда устанавливаю 2-3 они начинают появляться?


Я не "не могу предположить" (предположить - это вообще из области веры) - а я знаю:
- у каждой ОС есть величина разрешения системного времени;
- и получить системные интервалы меньше - нельзя;
- можно измерять сторонним источником, как здесь справедливо дополнили, но получить интервал - нельзя;
- и я знаю, что в Windows величина этого разрешения - 10мс. (для SMP - 15мс.);
- очень многи разработчики ОС стараются не афишировать эту величину ... но предыдущие цифры найдены в глубине техдокументации MS.

Цитата(Владимир Е. Зюбин @ Jun 3 2006, 10:09) *
То же самое и про измерение линейками... Вы просто не владеете простыми методиками.
ну а они есть, и секундомером можно измерять миллисекундные времена...


Владимир, я владею методиками wink.gif ... по крайней мере такими (по-моему с методикой арифметического усреднения впервые знакомятся в 3-м классе церковно-приходской школы).

Цитата(Владимир Е. Зюбин @ Jun 3 2006, 10:09) *
ПОНЯТНО, что измеряется СРЕДНЕЕ время, но если длительность процессов более-менее постоянная, то методика вполне рабочая и для оценки времен вполне годится.


При одном маленьком "но": если эти ваши "процессы" следуют непрерывной чередой друг за другом, без промежутков ... чего в многозадачной ОС не бывает (за исключением простейших искусственных циклов for(...)), а тем-более - в области TCP/IP стека, где всё в высшей степени асинхронно, и подчиняется множеству дополнительных алгоритмов (сегментация 2-х уровней: и MAC и IP, ARP разрешение, ... некоторые я называл). И вот тут, когда промежутки между иизмеряемыми "процессами" на порядки превосходят по длительности сами "процессы" - усреднение "не стреляет"!

Цитата(Владимир Е. Зюбин @ Jun 3 2006, 10:09) *
Увы, я опять не увидел, ни чисел, ни данных... "практически не различается" - это малоинтересная лирика. Вам же была дана конкретная цифра "накладные расходы на обслуживание процесса на 1ГГц процессоре составляют приблизительно 200 нс". А Вы в ответ "практически не различается" - это что больше, или меньше, чем 200 нс?


Я специально не дал (и не дам wink.gif) цифр, потому что предмет объёмный, не "с кандачка" - а я вам указал источник, где страниц 150 уделено этим вопросам и цифрам ... хотите - посмотрите, не хотите - значит и не очень надо wink.gif.
Но важно то, что здесь логика совершенно другая, чем вы толкуете с 200 нс-ами wink.gif:
- диспетчирование в многозадачной ОС происходит и над одним единственным процессом/потоком, с той же интенсивностью как и при множестве...
- но самое клавное, что в тех же узлах сетки системного времени, где происходит и диспетчирование, происходит обслуживание службы времени ОС (изменение уставок таймеров, статистики использования времени потоками и мн. другое) и эта работа более трудоёмкая, чем переключение или не переключение контекста...

В результате на ваш вопрос: "это что больше, или меньше?" я отвечу, что это примерно не более 10% разницы при переключении процессов по сравнению с работой 1-го процесса. Но уж никак не на "пару порядков" которыми вы пугали, и которые кочуют также из одного плохого учебника в другой. Кроме того, и это "больше, или меньше?" сильно (25%-50%) зависит от величины всё того же системного тика, установленного в системе (там, где его можно менять).

Цитата(Владимир Е. Зюбин @ Jun 3 2006, 10:09) *
Чего тут обсуждать-то? 8-)
Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...
В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...
Ну, чего тут обсуждать? :-)))


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

P.S. посмотрите, как динамическое управление было сделано в pSOS - и вас возникнет много вопросов к тому, что вы утверждаете.

А утечнки памяти ... это зависит от вашего качества исполнения, и выходного контроля (тестирования) вашего продукта (потому что наличие утечек достаточно легко тестировать, но этого никто не хочет делать).

Цитата(Владимир Е. Зюбин @ Jun 3 2006, 10:09) *
То, что программирование на Си++ менее безопасное, чем на Си? Это секрет Полишенеля, про который
уже везде писано-переписано...


Более безопасно! ... Хотя что вы называете "безопасно"? Я знаю только 1 опасность - скрытые ошибки.
В С++ их будет меньше. Главный фактор: строгая и именная (не структурная!) типизация. Всё остальное - как следствие.
Goroshko Egor
Цитата(yuri_t @ Jun 2 2006, 21:24) *
Насчет реального времени как регламентированного время отклика, проблемы
своппинга и т.д. - все это вещи, хорошо известные тем, кто занимается Real Time...
А вот что действительно интересно было бы услышать от поклонников ONX - почему
Microkernel Systems (QNX,Mach, Unix SVR 4, Minix, etc) так и не получили широкого распостранения?
Все-таки уступают по быстродействию системам с монолитным ядром ?

Естественно уступают. Только надо уточнять в чем и почему. Теоретически микроядерные системы с обменом сообщениями должны работать медленнее чем момнолитные по следующим причинам:
1. При высокой степени модульности возникают IPC взаимодействия там где в монолитной ОС их нет.
- С другой стороны - в микроядерной системе благодаря все той же модульности само взаимодействие между системными модулями проще и, соответсвенно, быстрее.
2. В QNX например, благодаря модульности системы, работа разных подсистем ОС выполняется в разных "кругах" защиты х86 процессора - следовательно получаем дополнительные задержки на переключения контекста.
- Опять же с другой стороны - поскольку только ядро, отвечающее за весьма узкий круг функций находится в 0 кольце защиты благодаря такой распределенности отдельные подсистемы могут быть легко остановлены и перезапущены.

В общем если еще раз процитировать старую поговорку - "Что русскому в радость - немцу смерть" :-)
И вообще попробуйте провести другую аналогию по типу Винда - QNX. Почему не рассматривается вопрос написания систем реального времни на Visual Basic ? Почему обсуждается С или С++? Давайте тогда уже и Visual Basic примем! А что, он тоже по сравнению с обычным Basic стал намного лучше :-)
И что? Почему то такие идеи не возникают... (Тьфу, тьфу, тьфу, что бы не сглазить)

А насчет получения широкого примения микроядерными системами. Дело в том что почти сразу (лет 10) :-) после их появления началась новая волна, развивающая идеи микроядерных ОС - объектные ОС.
В этом плане очень интерестным примером развития является Singularity от Microsoft Reseach:
http://rsdn.ru/article/singularity/singularity.xml
Хотя это и не имеет отношения к теме этой дискуссии - просто илюстрирует развитие ОС.
Goroshko Egor
Цитата('Владимир Е. Зюбин')
Чего тут обсуждать-то? 8-)
Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...
В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...
Ну, чего тут обсуждать? :-)))


Цитата('Владимир Е. Зюбин')
А что такое сборка мусора, по Вашему? 8-) По мне, так это источник непредсказуемых задержек.


Оба утверждения настолько очевидны.... что мало кто задумывается над их смыслом. А ведь все далеко не так просто.
Да, кстати, речь конечно идет не о Дефрагментации, а о Фрагментации :-) памяти. С чем это связано? С алгоритмом аллокации и деаллокации памяти. Это алгоритм ничего общего с языками С или С++ не имеет, поэтому речь не о них. То, что в СРВ необходимо избегать в критических местах динамической аллокации памяти - это довольно прописные истины, уже хотя бы по тому, что это медленные операции, а зачем их вызывать в критически опасных местах? ;-)
С другой стороны чем принципиально отличается статическое распределение памяти от динамического? Да принципиально - ничем. Закажите всю необходимую приложению память динамически, одним куском, напишиет свой аллокатор, который будет распределять память под конкретные данные приложения (и соответсвенно освобождать) и его работа будет совершенно предсказуемой. Если подумать над пробелмой под таким углом все довольно очевидно - сделать поток аллокатора высокоприоритетным, деаллокатора - низкоприоритетным ( это собственно и будет сборщик мусора) и непредсказуемых задержек у вас не будет.
Я не агитирую за динамическую работу с памятью, не утверждаю, что сборщик мусора - это всегда очень хорошо. Я просто стараюсь обратитть ваше внимание на тот факт, что некторые весьма очевидные вещи на проверку могут быть не столь очевидными. Постоянно развиваются алгоритмы работы аллокаторов памяти, алгоритмы сборщиков мусора. Инструменты нашей отрасли все время меняются и все чаще приходится пересматривать сложившиеся взгляды.
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 5 2006, 19:49) *
Цитата('Владимир Е. Зюбин')

Чего тут обсуждать-то? 8-)
Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...
В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...
Ну, чего тут обсуждать? :-)))


Цитата('Владимир Е. Зюбин')
А что такое сборка мусора, по Вашему? 8-) По мне, так это источник непредсказуемых задержек.


Оба утверждения настолько очевидны.... что мало кто задумывается над их смыслом. А ведь все далеко не так просто.
Да, кстати, речь конечно идет не о Дефрагментации, а о Фрагментации :-) памяти.


Спасибо за поправку. Принимаю.

Цитата(Goroshko Egor @ Jun 5 2006, 19:49) *
С чем это связано? С алгоритмом аллокации и деаллокации памяти. Это алгоритм ничего общего с языками С или С++ не имеет, поэтому речь не о них. То, что в СРВ необходимо избегать в критических местах динамической аллокации памяти - это довольно прописные истины, уже хотя бы по тому, что это медленные операции, а зачем их вызывать в критически опасных местах? ;-)


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

Вот и все.

Цитата(Goroshko Egor @ Jun 5 2006, 19:49) *
С другой стороны чем принципиально отличается статическое распределение памяти от динамического? Да принципиально - ничем. Закажите всю необходимую приложению память динамически, одним куском, напишиет свой аллокатор, который будет распределять память под конкретные данные приложения (и соответсвенно освобождать) и его работа будет совершенно предсказуемой. Если подумать над пробелмой под таким углом все довольно очевидно - сделать поток аллокатора высокоприоритетным, деаллокатора - низкоприоритетным ( это собственно и будет сборщик мусора) и непредсказуемых задержек у вас не будет.
Я не агитирую за динамическую работу с памятью, не утверждаю, что сборщик мусора - это всегда очень хорошо. Я просто стараюсь обратитть ваше внимание на тот факт, что некторые весьма очевидные вещи на проверку могут быть не столь очевидными. Постоянно развиваются алгоритмы работы аллокаторов памяти, алгоритмы сборщиков мусора. Инструменты нашей отрасли все время меняются и все чаще приходится пересматривать сложившиеся взгляды.


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

Я это опять к тому, что позиция т.н. РТ-сообщества (QNX-сообщества) по диск-своппингу какое-то невразумительное... особенно когда в QNX 6.0 появился диск-своппинг... все стали петь песню, про то, что это здорово, а по сравнению с Windows, его можно и отключить... а теперь диск-своппинг исчез из QNX (как заявляет Олег) по непонятным причинам... и диск-своппинг опять стал абсолютным злом. Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны. "Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

Я, вообще говоря, нисколько не против QNX, но фанатизм сообщества лично меня просто пугает.
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *
Вопрос это связан еще и с диск-своппингом... который тоже не возникает просто так.
Изначальный же тезис о том, что диск-своппинг и дефрагментация памяти (сборка мусора) - принципиально ничем не отличаются, т.е. являются источником задержек.

Вот и все.

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

Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *
Ровно то же самое можно сказать и про диск-своппинг: скорость доступа к данным постоянно растет.
А чтобы не было диск-своппинга - ставьте больше памяти. А уж коли кончилась оперативная память, не отправляйте критическое приложение в заведомо аварийное состояние, а попытайтесь что-нибудь сделать... Лучше поздно, чем никогда.

Ну пойми те же - нет в РТ такого понятия - в РТ "поздно" и "никогда" - равнозначны. Если это критическая система, там к моменту "поздно" давно уже врубилась система резервирования, а "опоздавший" хост перезапущен каким-нибудь watch-dog таймером.

Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *
Я это опять к тому, что позиция т.н. РТ-сообщества (QNX-сообщества) по диск-своппингу какое-то невразумительное... особенно когда в QNX 6.0 появился диск-своппинг... все стали петь песню, про то, что это здорово, а по сравнению с Windows, его можно и отключить... а теперь диск-своппинг исчез из QNX (как заявляет Олег) по непонятным причинам... и диск-своппинг опять стал абсолютным злом.

НУ почему же невразумительное - я же уже писал об этом выше. В QNX 6.0 вводился свопинг данных для работы разработческих приложений - например gcc. И разрешался свопинг данных только для специальных приложений, типа того же gcc. Фактически свопирование данных (не кода, заметьте - свопирования кода не было вообще никогда) присутсвовало в системе исключительно опционально.
Я не знаю насчет положения с последними версиями QNX 6.3 SP2 - по видимому они нашил решение этой проблемы и окончательно убрали свопирование. Даже как опциональную возможность.
Еще раз подчеркну - его не "можно и отключить", а его нужно очень постараться что бы включить!

Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *
Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны. "Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

Почему на смерть? Я же говорил, да динамических операций аллокации лучше избегать. Выполнять их в некритических участках.
А вот насчет С++.... :-) Я могу еще дискутировать насчет скорости, производительности... но надежность по сравнению с С? Да все не надежные механизмы присутсвующие в С++ были унаследованны от С! Как же так С может быть надежнее чем С++?
Olej
Цитата(Goroshko Egor @ Jun 5 2006, 19:49) *
С чем это связано? С алгоритмом аллокации и деаллокации памяти. Это алгоритм ничего общего с языками С или С++ не имеет, поэтому речь не о них. То, что в СРВ необходимо избегать в критических местах динамической аллокации памяти - это довольно прописные истины, уже хотя бы по тому, что это медленные операции, а зачем их вызывать в критически опасных местах? ;-)


Вот когда истины прописные, то это часто и есть побудительный мотив иногда в них засомневаться wink.gif... я совершенно не согласен с утверждением на все случаи жизни, что динамическое управление памятью - такое уж принципиальное зло там где РВ.
Во-первых, многое зависит от базового механизма распределения, который использует конкретная ОС - я уже обращал внимание: посмотрите на pSOS, как там управляется память (а pSOS одна из лучше зарекомендовавших себя РТОС).
Во-вторых, и в С и в С++ вы можете (но совершенно разным способом) реализовать своё управление памятью, которое будет оптимально для этого класса задач...
В-третьих, обращу внимание на деталь, которую часто упускают из виду:
- динамическое распределение С - malloc()/free() - использует память heap;
- динамическое распределение С++ - new()/delete - использует (по стандарту) совершенно другой класс памяти - "динамически распределяемая", который в реализации многих ОС совпадает с heap, но это совершенно не обязательно...
- таким образом, у вас есть и 2 механизма, надстроенных один над другим - надстройте и наворотите над ними всё что угодно...

Цитата(Goroshko Egor @ Jun 5 2006, 19:49) *
С другой стороны чем принципиально отличается статическое распределение памяти от динамического? Да принципиально - ничем. Закажите всю необходимую приложению память динамически, одним куском, напишиет свой аллокатор, который будет распределять память под конкретные данные приложения (и соответсвенно освобождать) и его работа будет совершенно предсказуемой.


... вот так, если достаточно грубо описывать процесс.

Цитата(Goroshko Egor @ Jun 5 2006, 19:49) *
Если подумать над пробелмой под таким углом все довольно очевидно - сделать поток аллокатора высокоприоритетным, деаллокатора - низкоприоритетным ( это собственно и будет сборщик мусора) и непредсказуемых задержек у вас не будет.


Ну, это было бы слишком просто wink.gif - но может закончиться тем, что при наличиии дофига освобождённой (но ещё не деаллокированной на низком приоритете) памяти, высокоприоритетный аллокатор уже не сможет ничего добыть...
Кроме того, "ручное" управление памятью в стиле С/С++ (malloc()/free(), new()/delete), которое тоже требует аллокаторов/деаллокаторов, и автоматическая сборка "неиспользуемого мусора", основанная на признаках неиспользуемости (напр., счётчике ссылок, но не только) - это очень разные по сложности механизмы.

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

Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *
"Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...


Со словом "надёжность" к ПО нужно подходить с большой тщательностью - в ПО нет стареющих или изнашивающихся частей, чтобы к нему можно было применять положения теории надёжности.
Но в нём всегда есть скрытые ошибки, которые и выявляются как "не надёжность"...
Теперь смотрите сюда wink.gif :
- С является подмножеством С++, программа С будет всегда (ну, почти всегда wink.gif, на 99.999%) синтаксически совместима с С++ (несовместимости - описаны, они все - из разряда казусов, и могут быть устранены)...
- программу, написанную на чистом С вы можете компилировать командой: "gcc ...", но её же и командой "g++ ..." - в режиме синтаксических правил С++...
- будет та же программа, скомпилированная во втором случае - надёжнее 1-й? (т.е. в смысле - содержать меньше скрытых ошибок). Будет! - по очень простой причине: гораздо более строгий типизированный контроль ... того же исходного кода (я иногда развлекаюсь так, компилируя pure C в режиме C++).
- это относительно одного и того же файла кода... т.е. того же подмножества языка, которое общее...
- будет ли "безошибочнее" надмножество, которое выводит С++ за пределы С ... а безошибочнее чего? с чем вы собираетесь сравнивать, если эквивалента нет?

Я нигде не говорил, что "надежность Си++ выше всего", я говорил: надёжности С++ при прочих равных не с чего быть ниже, чем С. И только.

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

Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *
Я это опять к тому, что позиция т.н. РТ-сообщества (QNX-сообщества) по диск-своппингу какое-то невразумительное... особенно когда в QNX 6.0 появился диск-своппинг... все стали петь песню, про то, что это здорово, а по сравнению с Windows, его можно и отключить... а теперь диск-своппинг исчез из QNX (как заявляет Олег) по непонятным причинам... и диск-своппинг опять стал абсолютным злом. Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны.

Я, вообще говоря, нисколько не против QNX, но фанатизм сообщества лично меня просто пугает.


Владимир, а). "т.н. РТ-сообщество" wink.gif и QNX-сообщество - это далеко не одно и то же - 1-е намного шире 2-го; б). нет как такового и "QNX-сообщества" - есть совершенно разрознённые, хотя их и достаточно много уже, специалисты, практически работающие с QNX ... с гораздо большими основаниями можно было бы говорить об Linux-сообществе, FreeBSD-сообществе, MAC-сообществе ... там это хоть "клуб по интересам" напоминает wink.gif...
Так что пусть это вас так сильно не пугает wink.gif - вам никто не угрожает.
Olej
А вообще то, разговор уехал несколько в сторону от заданной теме, и теперь он должен был бы называться: "Какая РТОС мне бы нужна, когда она мне не нужна". wink.gif
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 6 2006, 16:20) *
Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *

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

Вот и все.

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


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

Я это опять не к тому, что я диск-своппинг люблю, мне что диск-своппинг, что фрагментация памяти. все едино. Не пользуемся, да и все. И код стараемся компактно разместить в кэше.
Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).
Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет. Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.

Цитата(Goroshko Egor @ Jun 6 2006, 16:20) *
Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *

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

Ну пойми те же - нет в РТ такого понятия - в РТ "поздно" и "никогда" - равнозначны. Если это критическая система, там к моменту "поздно" давно уже врубилась система резервирования, а "опоздавший" хост перезапущен каким-нибудь watch-dog таймером.


Это Ваше личное определение РТ. Есть и много других определений и точек зрения. В частности, есть и такая точка зрения, что проблема РТ - чисто маркетинговая фишка, не имеющая ни строгого определения, ни смысла. Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".

Поздно/не поздно, мягко/жестко... бла-бла-бла... даже внятного определения для "реального времени" не существует. Одни пузыри. Отсюда и постоянные глупые споры, holly-wars.

Самые мудрые слова, которые мне встретились по поводу РВ были:
Цитата
"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"


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

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

Цитата(Goroshko Egor @ Jun 6 2006, 16:20) *
Цитата(Владимир Е. Зюбин @ Jun 6 2006, 11:54) *

Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны. "Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

Почему на смерть? Я же говорил, да динамических операций аллокации лучше избегать. Выполнять их в некритических участках.
А вот насчет С++.... :-) Я могу еще дискутировать насчет скорости, производительности... но надежность по сравнению с С? Да все не надежные механизмы присутсвующие в С++ были унаследованны от С! Как же так С может быть надежнее чем С++?


По-моему к таким выводам эксперты пришли на основании трех фактов:
1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.
Goroshko Egor
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Я это опять не к тому, что я диск-своппинг люблю, мне что диск-своппинг, что фрагментация памяти. все едино. Не пользуемся, да и все. И код стараемся компактно разместить в кэше.
Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).
Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

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

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет. Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.

Да конечно ничего страшного, да замечательно что становится надежнее. Только меня изумляют попытки прилепить ее к месту и не к месту исключительно из тех соображений что разработчики с ней знакомы. Почему разработчки самой XP не позиционируют ее для РТ применения? Если уж они сами считают что она для этого не подходит, почему же все таки пытаются ее наклонить на выполнение не свойственных ей функций? Я лично ничего против виндоуса как настольной, офисной, даже разработческой системы против не имею, но как сказал один мой знакомый - когда делаешь что-то серьезное, хочется положить его в простое и надежное место. И это место может быть совсем не обязательно QNX, есть масса ОС которые находятся гораздо ближе к области РТ чем Виндоус.

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Это Ваше личное определение РТ. Есть и много других определений и точек зрения. В частности, есть и такая точка зрения, что проблема РТ - чисто маркетинговая фишка, не имеющая ни строгого определения, ни смысла. Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".

Поздно/не поздно, мягко/жестко... бла-бла-бла... даже внятного определения для "реального времени" не существует. Одни пузыри. Отсюда и постоянные глупые споры, holly-wars.

Самые мудрые слова, которые мне встретились по поводу РВ были:
Цитата
"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"


По поводу формулировок
http://qnxclub.net/files/articles/rtos/rtos.html
Ваша цитата лишь еще одно перефразирование определений СРВ. Фактически все они именно к этому и сводятся.
Вот и давайте разберемся с этим определением - что ж в нем говорится.
Что означает "порядок обработки информации предопределяется ходом процессов вне ЭВМ"? Это значит что по наступлению какого-то внешнего события не позднее некоторого срока должна наступить какая-то реакция программы. Так? Причем срок реакции и сама длительность реакции должны быть не длинне заданного - иначе следующее событие не будет вовремя обработано.
Именно об этом я все время и говорю.
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Сами понимаете, что это интересное определение идет вразрез с установкой т.н. РТ-сообщества, типа QNX сообщества и прочих нескольких. ;-) Т.к. там не предусматривается всякая чушь типа шедулеров, прерываний, приоритетов, работы при недостатке выч.ресурсов и "быстрых" времен.

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

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.
К сожалению, особое место ОС тут не предусмотрено, более того, решать задачи управления, проще специализированными средствами (теми же языками МЭК 61131-3), чем средствами ОС, которые тут играют лишь вспомогательную (хотя и часто полезную) роль: драйверы, работа с ОЗУ, файлы, протоколы связи и т.п.

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

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
По-моему к таким выводам эксперты пришли на основании трех фактов:
1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.

1. Сразу возникает вопрос - какие экперты?
2. В чем заключается более высокая прозрачность структурного языка перед объектным? Ведь он заведомо дальше от предметной области!
3. В Си операции с указателями это исключение? А зачем тогда его вообще использовать? Он ведь как раз для этого и создавался!
4. Статистика..... замечательная вешь. :-) Но это невероятно слабый аргумент особенно в таком виде.
Учитывая что значительная часть моей карьеры прошла в качестве физика-экспериментатора, я очень хорошо представляю себе что такое статистические данные :-)
Olej
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
а еще есть кэширование и спекулятивные вычисления... источники всякой непредсказуемости...
кстати, работы с кэш-памятью очень сильно напоминают диск-своппинг.


Есть wink.gif.

Только вот в чём дело, когда вы выполняете операцию с адресуемой в RAM областью, типа оператора:
int i;
i = 0;
- то в зависимости от того, попадает она в кэш или нет, вы имеете разницу во времени операции отличающуюся в лучшем случае в 2-3 раза (я реально это смотрел), и операцию (если x86) на 5-8 машинных тактов (десяток-другой нсек.), если вы последовательно выполняете операции над наукад 1000 переменными, скажем, если очень грубо считать что 50% их попадает в кэш, а 50% - нет, то разброс у вас (по сравнению с оптимумом) будет 1.5-2 раза.

Физческие операции загрузки-выгрузки на диск - на 2-3 порядка медленнее...
Но и это не самое худшее, когда вы выполняете ту же операцию, которую я выписал выше, и i находится на выгруженной странице, то загрузка-выгрузка производится страницами RAM, в x86 - 4K "туда" + 4К "обратно" - вот вам ещё 1 порядок непредсказуемости на времени тривиальной операции - до 4-х порядков.

Неопределённость (дисперсия) времён 50-100% - это одно, а 4 порядка - это, согласитесь, несколько другое... Это не я придумал wink.gif, и именно из подобных соображений на кэширование и другие подобные "ускорители" (те же спекулятивные вычисление, опережающее конвейерное выполнение etc.) смотрят в обсуждениях и публикациях об РВ "сквозь пальцы", а такие возможности как виртуализация страниц RAM - отвергаются категорически.

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).
Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.


"Медленнее/быстрее" - вообще к РВ не имеет касательства, общепризнанно и с этим уже, кажется, смирились wink.gif, что система (ОС или целевая система вообще), удовлетворяющая требованиям РВ будет, при прочих равных, несколько медленнее, чем аналогичная, к которой такие требования не предъявлялись (GPOS, например).

А вот то, что "зато система живет, а не рушится" ... это достаточно сомнительное достоинство в системах, требующих критической по времени реакции ... Goroshko Egor затронул это...
Ну представьте, к примеру, РЛС системы ПВО/ПРО, как одну из систем РВ ... в чём разница между тем, что она пропустит отметку цели, или обнаружит её с сильно превышенным подлётным временем?
Разве только в том, что в 1-м случае система "накроется" в полностью благодушном неведении, а во 2-м - в стоп-кадре "паническое разбегание персонала кто-куда"...

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет.


"Жизнь становится лучше, товарищи. Жизнь становится веселее"(с) - автор известен...
Ничего страшного в том, что "Виндовоз становится все надежнее и надежнее", конечно, нет ... несколько настораживает, правда, то, что он "становится надежнее" уже порядка 20-ти лет, и ... "завтра вот-вот ...".
А, в принципе, Виндовоз - хорошая офисная система ... каждая вещь разрабатывается под свои техусловия ... мне только совершенно непонятно желание обязательно притулить не делавшуюся для этого вещь "на все случаи жизни"... как-то малоуместно пытаться ездить на "Шевроле" по пахоте, ровно так же, как БТР странно смотрится перед "навороченным" офисом в центре города...

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.


Конечно не надо wink.gif - если бы это было время реакции, время ответа ... и т.д. - но это единица шкалы, неточность определения, а минимальные разрешимые интервалы будут в несколько раз больше единицы шкалы ... а это уже "не не надо" wink.gif.

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Это Ваше личное определение РТ. Есть и много других определений и точек зрения. В частности, есть и такая точка зрения, что проблема РТ - чисто маркетинговая фишка, не имеющая ни строгого определения, ни смысла.


Есть и такая точка зрения ... только она тоже не "строго определённая" - отмечается, что и такой компонент есть в терминологии "РВ" wink.gif...

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".


Почему же нет? Есть - безупречная success story более 25-лет - всегда безотказной работы, годами в необслуживаемом режиме... (это 25 лет - ~ столько, сколько вся история MS DOS + Windows с уговорами, что "завтра будет лучше чем вчера").

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
Самые мудрые слова, которые мне встретились по поводу РВ были:
Цитата
"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"



Хорошее определение ... только "масло маслянное": а что, в IBM 360 60-х годов - порядок обработки информации не предопределялся ходом процессов вне ЭВМ? начиная с того, как пользователь вложил коложу перфокарт?, и как он правильно их вложил? ... и до того места, провернулся ли уже барабан АЦПУ до положения, когда следует печатать следующую строчку "простыни"? ...

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.


Да пожалуйста ... описывайте. Кто ж возбраняет?
Только, по возможности, воздержитесь от непреодолимого желания его продавать как "средства описания режимов работы в реальном масштабе времени" - тем, кому может прийти в голову начать описывать такие режимы wink.gif...

Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *
По-моему к таким выводам эксперты пришли на основании трех фактов:
1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.


1.
- Так выпьем же за то, что грузины лучше чем армяне...
- Ну чем, чем лучше?
- ... чем армяне.
(с).

С "более прозрачен" для тех, кто не знает С++, так же как и наоборот.

2. "операции с тем же ОЗУ" ... ? (я не заню какое это "то же" ОЗУ - это С & C++ работают с одним и тем же ОЗУ wink.gif) ... наверное имелись в виду динамические операции? - так их "плотность" определяется желаниями пишущего использовать или не использовать, а не то, на чём он выражает свои желания...
А кстати - как на счёт strdup()? wink.gif - многие ли задумываются что они при этом делают?
А если так wink.gif :
Код
void func( char* S1 ) {
   char* S2 = S1;
   ...
   return( strdup( S2) );
};


3. где она - эта статистика? и уровень её адекватности? - URL в студию!

P.S. сравнивать С/С++ по критерию "плотности ошибок" вообще неблагодарное занятие - слишком близкие эти 2 клона, и оба предрпсположенные к ошибкам... а хотите принципиально другую защищённость от ошибок - учите Ada wink.gif!


Ну ладно ...
Повеселились, покуражились - и будя!
Владимир Е. Зюбин
Цитата(Goroshko Egor @ Jun 7 2006, 19:35) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

Я это опять не к тому, что я диск-своппинг люблю, мне что диск-своппинг, что фрагментация памяти. все едино. Не пользуемся, да и все. И код стараемся компактно разместить в кэше.
Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).
Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

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


Ну, а в Рефлексе а ля стэнд-элон - все очень просто. Никаких замедлений просто нет и быть не может.
Цитата
ОБЕСПЕЧЕНО КОНСТРУКТИВНО


Цитата(Goroshko Egor @ Jun 7 2006, 19:35) *
Владимир Е. Зюбин:"Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет."

Да конечно ничего страшного, да замечательно что становится надежнее. Только меня изумляют попытки прилепить ее к месту и не к месту исключительно из тех соображений что разработчики с ней знакомы. Почему разработчки самой XP не позиционируют ее для РТ применения?

Все очень просто. Виндовоз предоставляет: 1) однородность среды разработки/исполнения 2)
Видндовоз предоставляет несоизмеримо большую функциональность, т.к. это MAINSTREAM.

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

Может, дело в том, что тема реального времени давно устарела? Не думали над этим?

Цитата(Goroshko Egor @ Jun 7 2006, 19:35) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

Самые мудрые слова, которые мне встретились по поводу РВ были:
Цитата
"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"


По поводу формулировок
http://qnxclub.net/files/articles/rtos/rtos.html
Ваша цитата лишь еще одно перефразирование определений СРВ. Фактически все они именно к этому и сводятся.
Вот и давайте разберемся с этим определением - что ж в нем говорится.
Что означает "порядок обработки информации предопределяется ходом процессов вне ЭВМ"? Это значит что по наступлению какого-то внешнего события не позднее некоторого срока должна наступить какая-то реакция программы. Так? Причем срок реакции и сама длительность реакции должны быть не длинне заданного - иначе следующее событие не будет вовремя обработано.
Именно об этом я все время и говорю.


Кроме этого это значит, что ПО не содержит ошибок, нет перебоев с питанием, проц не глючит, у датчиков погрешность в норме (метрологически аттестованы), исполнительные органы не заклинило... и т.д. и т.п.

проблема выч.ресурсов - это одна из возможных причин отклонений от заданных режимов работы.
и на настоящий момент не самая актуальная... для 99% случаев.

Цитата(Goroshko Egor @ Jun 7 2006, 19:35) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

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

Нигде в определении термина РВ нет слов о шедулерах, вы наверно не внимательно читали (я имею в виду не определения Васи Пупкина, а определения принятые стандартами).


Разумеется, я нигде об этом не читал. Просто личные наблюдения за дискуссиями на тему РТ, которые QNX-адепты часто сводят к алгоритмам планирования и тайм слотам... А что еще есть в QNX отличного от? Ничего. Надежность? При чем тут РТ вообще?

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

Что осталось? ;-)

Вы вот пишете...
"Одним из наиболее спорных и сложных терминов систем автоматизации является английское выражение «realtime»", а потом встаете ложную тропинку - дать наконец-то определение этому РТ... и пардон, опять с нулевым эффектом (как и многие до Вас).

А ответ-то прост - нет в этом словосочетании смысла, придуман и использовался он чисто в маркетинговых целях - наделить продаваемый продукт отличительными признаками. Вот и все.
Технически для ОС QNX более правильная характеристика - ОС с микроядерной архитектурой. ;-)
Конечно же кисло с точки зрения маркетинговой привлекательности... ну, а что делать? :-)

Цитата(Goroshko Egor @ Jun 7 2006, 19:35) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

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

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


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

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

Цитата(Goroshko Egor @ Jun 7 2006, 19:35) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

По-моему к таким выводам эксперты пришли на основании трех фактов:
1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.

1. Сразу возникает вопрос - какие экперты?
2. В чем заключается более высокая прозрачность структурного языка перед объектным? Ведь он заведомо дальше от предметной области!
3. В Си операции с указателями это исключение? А зачем тогда его вообще использовать? Он ведь как раз для этого и создавался!
4. Статистика..... замечательная вешь. :-) Но это невероятно слабый аргумент особенно в таком виде.
Учитывая что значительная часть моей карьеры прошла в качестве физика-экспериментатора, я очень хорошо представляю себе что такое статистические данные :-)


Тут просто нужно понимать проблемную ориентацию Си++. Тогда все встанет на свои места.
А Си++ предназначен для группового и скоростного проектирования WIMP-интерфейсов.
Вот и все. Так и используется в MS. WIMP - это по сути GES (good enough software). Надежность тут сами понимаете, отнюдь не на первом месте. Гораздо важнее скорость разработки и модифицируемость.

Ну а насчет вопроса, "а судьи кто?" - Не знаю что сказать. В печатном и прямом виде это утверждение встречал в "Открытых системах". Номер не помню.
Владимир Е. Зюбин
Цитата(Olej @ Jun 8 2006, 14:53) *
Физческие операции загрузки-выгрузки на диск - на 2-3 порядка медленнее...
Неопределённость (дисперсия) времён 50-100% - это одно, а 4 порядка - это, согласитесь, несколько другое...


Где в определении РТ об этом?! Или Вы перекинулись в лагерь адептов наивного определения реального времени... "РТ=быстро"? Какая разница 1 наносекунда или 1 час? Какая разница в сто раз или в два раза... для мифического и любимого QNX-сообществом самолета, врезавшегося во взлетно-посадочную полосу?

Кстати, не глупо ли, вести самолет в режиме, когда жизнь и смерть пассажиров разделяет задержка в одну миллисекунду? по-моему, так это высшая степень идиотизма.


Цитата(Olej @ Jun 8 2006, 14:53) *
А вот то, что "зато система живет, а не рушится" ... это достаточно сомнительное достоинство в системах, требующих критической по времени реакции ...


Да про какие Вы системы толкуете-то? Я толкую про пром.автоматизацию... где основная проблема сложность алгоритма, где основная сложность, чтобы все ПРАВИЛЬНО работало.

А Вы про какую-то военную технику все рассуждаете.. ПРО/ПВО... ставьте там двуядерный процессор или десятиядерный... или десять процессоров... Задачи-то вы обсуждаете чисто вычислительные...
"кто быстрее вычислит". Это для пром.автоматизации не самое интересное из.

Вот:
Цитата(Olej @ Jun 8 2006, 14:53) *
Goroshko Egor затронул это...
Ну представьте, к примеру, РЛС системы ПВО/ПРО, как одну из систем РВ ... в чём разница между тем, что она пропустит отметку цели, или обнаружит её с сильно превышенным подлётным временем?
Разве только в том, что в 1-м случае система "накроется" в полностью благодушном неведении, а во 2-м - в стоп-кадре "паническое разбегание персонала кто-куда"...


Это именно ВАШЕ "сильно/слабо"... и не надо обижаться на меня за "быстро/медленно"...

Цитата(Olej @ Jun 8 2006, 14:53) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.


Конечно не надо ;) - если бы это было время реакции, время ответа ... и т.д. - но это единица шкалы, неточность определения, а минимальные разрешимые интервалы будут в несколько раз больше единицы шкалы ... а это уже "не не надо" ;).


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

Цитата(Olej @ Jun 8 2006, 14:53) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

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


Есть и такая точка зрения ... только она тоже не "строго определённая" - отмечается, что и такой компонент есть в терминологии "РВ" ;)...


Это строгое определение, хоть и метауровневое (с выходом над проблемой):
смысл термина "реальное время", не сложен и запутан, а равен нулю.

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

Цитата(Olej @ Jun 8 2006, 14:53) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".


Почему же нет? Есть - безупречная success story более 25-лет - всегда безотказной работы, годами в необслуживаемом режиме... (это 25 лет - ~ столько, сколько вся история MS DOS + Windows с уговорами, что "завтра будет лучше чем вчера").


статистика нужна, а не success stories, рожденные в рекламных отделах QNX... а статистика такова, что основная масса аварий с участием QNX (и без оного) происходит за счет ошибок программирования, зачастую просто логических, невнятного интерфейса, отсутствия защит от неверных действий оператора и т.д.

Цитата(Olej @ Jun 8 2006, 14:53) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

Самые мудрые слова, которые мне встретились по поводу РВ были:
Цитата
"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"



Хорошее определение ... только "масло маслянное": а что, в IBM 360 60-х годов - порядок обработки информации не предопределялся ходом процессов вне ЭВМ? начиная с того, как пользователь вложил коложу перфокарт?, и как он правильно их вложил? ... и до того места, провернулся ли уже барабан АЦПУ до положения, когда следует печатать следующую строчку "простыни"? ...


Зачем путать функционирование системы и ее загрузку? Или Вы не различаете вычислительные задачи и задачи управления? Режим штатного функционирования и отказ аппаратной части?

Цитата(Olej @ Jun 8 2006, 14:53) *
Цитата(Владимир Е. Зюбин @ Jun 7 2006, 14:14) *

В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.


Да пожалуйста ... описывайте. Кто ж возбраняет?
Только, по возможности, воздержитесь от непреодолимого желания его продавать как "средства описания режимов работы в реальном масштабе времени" - тем, кому может прийти в голову начать описывать такие режимы ;)...


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

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

Цитата(Olej @ Jun 8 2006, 14:53) *
А кстати - как на счёт strdup()? ;) - многие ли задумываются что они при этом делают?
А если так ;) :
Код
void func( char* S1 ) {
   char* S2 = S1;
   ...
   return( strdup( S2) );
};


насчет strdup, "я такой умный вещь скажу, ты только не обижайся"(с):
в алгоритмах управления strdup-ы не встречаются. Ни к чему они там.
(а что делают strdup, malloc и calloc я себе прекрасно представляю).

Кстати, и просто strcpy употреблять не рекомундуется... подумайте на досуге, почему.
ключевое слово - устойчивость (robustness).

Что примечательно: к теме критических систем strcpy имеет прямое отношение, а вот с РТ никак не связано... ;-)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.