Olej

Много полезного вспомнил и узнал . Про АЭС знал но вот про МКС первый раз слышу.


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



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

Собрано полностью из сорцов? Так сказать from scratch? Впрочем, это вопрос времени.


Какие эксперименты? Описанный Вами случай при постоянном N показывает оверхед IPC и переключения контекстов. А вот если заглянуть в \services\system\ker\nano_sched.c то можно увидеть циклы по тредам (правда, только в SMP варианте)



Пусть используют Кстати, там какая версия?



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

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

К применениям QNX (степени их критичности) могу добавить, вспомнилось, что весьма многие СУ в мире деланы на SCADA RealFlex (Ирландия ... но люди там "наши" ), вот только некоторые из:

- система согласованного управления всеми маяками Ирландии;
- система управления всем "напольным оборудованием" (а это стрелки, светофоры и т.д.) национальной ж/д транспортной системы Новой Зелландии (делал, кстати, Сименс ... и решил делать на "чужой" системе);

В этих системах может и не фигурировать QNX, а фигурирует RalFlex, но RalFlex "живёт" только и исключительно на одной ОС - QNX.

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

P.S. а, кстати, вспомнил ... здесь много со знанием дела говорили про "ракеты"? так вот, я вам маленькую гос.тайну выдам (точнее здесь их 2 ): а). что вся "наземка" и значительная часть "борта" последних пусков ("Булава" - помните? или "Египсат"?) - сделаны в QNX б). потому что делаются они в Харькове (НИИ РИ ... это уже 3-я военная тайна ).
И, кстати, что интересно - в версии QNX 6, и переход с 4-ки на 6-ку очень тщательно обосновывался и утверждался техсоветом института ... года 2 назад ... это к попыткам противопоставлять QNX 2 / QNX 4 / QNX 6 - архитектурной разницы между ними нет.


Собирается procnto, всё что "вокруг" микроядра + libstd ... для "того" практически ничего больше и не надо.
А остальное - это теперь действительно вопрос времени.


Я думаю что 2, судя по времени, когда система ещё не подлежала коммерческим продажам.


Нет, инверсия не "недостаток самой парадигмы треды-приоритеты"© - точно то же самое будет, если в любой ОС слова "тред" заменить на "процесс" или "задача", только синхронизироваться (в смысле захватывать) они будут в этом случае на именованном семафоре ... или на любом примитиве синхронизации в shared memory.
Кстати, если это проделать в MINIX 3 (которая "очень-и-очень" похожа на QNX по структуре), где вообще нет тредов (не сделали ещё), то там практически наверняка ситуация эта и возникнет...

А вообще, здесь споров много возникло о "реалтаймовости" ... а споры то - пустые, говорится просто - о разном.
Вы сами, кажется, где-то в предыдущих постах (искать лень) почти дошли до:
- ОС вообще не может быть "реалтайм" (такой она называется только как коммерческий трюк) - реалтайм может быть (или не быть ) только целевая разрабатываемая система...
- разные ОС могут только предоставлять механизмы, которые обеспечат целевой системе реалтаймовость (или не обеспечат) ... вот QNX - обеспечит, а Windows & Linux - не обеспечат...
- и говорить о реалтаймовости можно только тогда когда возникают параллельность (потоки, процессы, синхронизации)...
- однонитиевое ПО не может быть (но не может и не быть) реалтайм - это циклический конечный автомат: либо он успевает за время критического цикла, либо не успевает... это прекрасно реализуется в SWITCH-технологии проф.Шалыть;
- и если целевая задача не обладает выше некоторого уровня разветвлённостью-параллельностью (и степенью сложности) - то и копья ломать об реалтаймовость нет резона ... и ОС реалтайм для этого не нужна.

и вот это


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



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

А если искать синоним "реалтайм" - то ближайший и будет "надёжность" ... predictable, а вот само абсолютное значение времени реакции - ну просто никакого отношения к реалтайм и не имеет, и вот в этом и состоит самое частое заблуждение относительно риалтайм.
И вот именно поэтому всем им Linux не сгодился


Вот вы знаете, а я - не знаю куда она "стремится"(с) ... наверное, в задницу...
А тайна то и есть в том, что для всех самых "звучащих" российских пусков вся наземка (но и не только) делается а). в QNX + б). в 6-м + в). в Украине - так что это к тому, что "может или не может в ракете?"

С этим двумя руками согласен.
А вот с этим что делать даже не знаю

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

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

Это всё - "скорость" ... но к "реалтаймовости" и pedictable - скорость не имеет никакого касательства, и даже не коррелирована с ними...
Может быть "быстрая" система и "медленная" (так же как и процессор) ... может быть pedictable & non pedictable ... - сделайте из них линейную комбинацию, и получите полный спектр систем .
Более того, при прочих равных, realtime OS будет медленне чем general purpose OS - в ней всё приходится делать тщательнее ... поэтому, скорее, скорость и реалтаймовость - отрицательно коррелированы


Вот здесь был перевод, который девочка сделала с отчёта Dedicated Systems:
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html

... но к сожалению, авторы испугались и его спрятали
Зайдите на сайт Dedicated Systems (URL его очень легко найти по названию - это крупнейший независимый тестер) - там много обстоятельных отчётов-сравнений (30-50 стр. и более)...
Вот там доказывается, что надёжностные/риалтаймовые показатели Linux (RT-Linux ) - на порядки хуже аналогичных показателей QNX.


А вот здесь вы, пожалуй, правы... не так однозначно, может, O( n ) ... O( f( n ) )
Я по вашему утверждению понаделал тестов как это выглядит со стороны конечного пользователя ("чёрный ящик")...
Чтоб не пересказывать много - здесь:
http://qnxclub.net/modules.php?name=Forums...topic&t=472
- всё детально описано.

Но всё это вовсе не так страшно:
- шедулирование (по крайней мере round-robin / sporadic, а не "кооперативное" ) всегда происходит в момент системного тика (одного из) и его время суммируется с обслуживанием службы времени ... которое а). ~const б) >> времени шедулирования...
- а само шедулирование - очень коротко...

Кстати, здесь ещё одно интересное отличие RTOS vs GPOS:
- есть размер системного тика ... многие производители ОС берегут его значение как "тайну мадридского двора"...
- из разных источников: Windows - 10мс. (15мс. при SMP); Linux - 10мс. ... в ядрах 2.6.х может изменяться (перекомпиляцией ядра!) ... до 1 (?) мс.; QNX - 1мс. by default, может изменяться runtime вплоть до 10мкс.
- интервал шедулирования round-robin - таймслайс - всегда кратен тиксайз со множителем N ... - это ещё большая тайна производителя : в QNX - 4, Windows - 13, ... Linux - не знаю
- итого, минимальный временной квант диспетчеризации QNX составляет 40мкс., а в Windows - 130мс. - 3.5 порядка, впечатляет? Это как если бы на вашем мониторе установить частоту развёртки не 100гц., а 100 / 3000 = 0.03гц - как, не слабо? , не хочется за таким поработать?

Так, давайте разделим понятия "скорость", "детерминированность" и "реалтаймовость". Первые два - характеристики ОС, в то время как третье - интегральная характеристика и зависит от задачи. Так же не совсем верно, что RTOS обычно медленнее GPOS, скорее микроядерные всреднем медленнее монолитных, а это совсем другое.

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

По шедулеру. Для однопроцессорного варианта - все нормально, масштабирование отличное, т.е. O(1). Для SMP - тут явно сыровато. И проблема даже не в том, что шедулер зависит от количества нитей (это важнее для всяких серверов с огромным количевством запросов), а в том, что он может исполняться только на одном процессоре. Т.е. другие процессоры будут блокироваться на нем. Более того, все говорит о том, что и с микроядром тоже самое, как только один процессор вошел в него, все остальные будут ждать. Учитывая, что каждый чих происходит через микроядро, оно может стать узким местом. Честно говоря, еще не въехал в Ваши тесты, но у меня ощущение, что тестируется что то другое

Далее. Шедулирование происходит не только в момент системного тика (тут речь уже не только о QNX, а вообще об ОС в целом). Есть еще много мест: принудительный вызов шедулера в коде, блокировка на мьютексах/семафорах и т.п., различные сигналы, в т.ч. и из обработчика прерываний. И это хорошо, т.к. повышает скорость срабатывания логики. А вот небольшой системный тик не нужен вообще (достаточно возможности его менять в некоторых пределах), т.к. при этом повышается (и очень сильно) оверхед. И правда, общение с внешним миром происходит либо асинхронно по ивентам, либо по циклограммам, тут принудительное шедулирование не нужно, можно обойтись своими силами. А вот для организации "параллельного" выполнения задач - да. На сцене появляется квант времени (time slice), т.к. классический алгоритм FIFO никогда не допустит вытеснения более приоритетной задачи менее приоритетной (в RR тоже есть time slice, но мы рассмотрим "супер быстрый" алгоритм, где даже самая низкоприоритеная нить получает время). И зачем тут малый квант? Более того, обычно чем выше приоритет у нити, тем ее квант больше. В линуксе он меняется гдето от 5мс до 800мс. Кстати, в нем же недавно появилась опция TICKLESS - холостых тиков вообще нет (по задумке). Очень интересная опция, жаль пока нет времени разобраться

P.S. Оффтоп, конечно, но что поделать

Собственно, открытие кода QNX, с чего и началась вся тема, поимело свой результат (или начинает иметь?):
http://www.qnx.com/news/pr_2471_1.html
http://www.rts.ua/rus/news/manufacturer/0/93/


Т.е., ясное дело, что акция эта была направлена никак не на open community, а на брандовых производителей оборудования в классе prom-PC.

http://www.dedicated-systems.com/encyc/pub...time_definition

There are _several_ definitions of real-time, most of them contradictory. Unfortunately the topic is controversial, and there doesn't seem to be 100% agreement over the terminology.

1. The canonical definition of a real-time system (from Donald Gillies mailto:gillies@ee.ubc.ca ), is the following:

"A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred."

2. POSIX Standard 1003.1 defines "real-time" for operating systems as:
"Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time"

там есть еще другие определения. А мне вот это понравилось

4. One will also see references to "real-time" systems when what is meant is just "fast". It might be worth pointing out that "real-time" is not necessarily synonymous with "fast"; that is, it is not the latency of the response per se that is at issue (it could be of the order of seconds), but the fact that a bounded latency sufficient to solve the problem at hand is guaranteed by the system. In particular, frequently, algorithms that guarantee bounded latency responses are less efficient overall than algorithms that don't.

и вот это

5. One will also occasionally see discussions of "soft" vs. "hard" real-time systems. In many of these discussions, "hard" real-time means the type of real-time system discussed above, and "soft" real-time means systems which have reduced constraints on "lateness" but still must operate very quickly and repeatably. However, the definition is controversial, as some mean by "hard" and "soft" the degree of time constraints. For instance, a real-time process attempting to recognize images may have only a few hundred microseconds in which to resolve each image, but a process that attempts to position a servo-motor may have tens of milli-seconds in which to process its data.

там еще много чего интересного.

это всё только определения...

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

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

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

Вот это стоит быть прочитанным.

Ну главного события еще не произошло.
QNX пока еще расхваливаем авансом.
Middleware еще не выложено, а без него QNX грош цена.

Сейчас альтернатив QNX как ядру навалом. Тут недалеко выложены и Montavista, и ThreadX, и ARTX, и Nucleus, и VxWorks, и uCOS, и eCOS. И большинство с кой каким middleware.

Однако обнаружил тренд.
Появляются чипы с ядрами такие как ARM Cortex-M3, S08 где MMU мягко говоря сделано не так как его представяляет QNX.
Т.е. почти все выше перечисленные ядра на них встанут, а QNX не встанет.
Может этим вызвана суета QNX?

Извините, что встреваю в разговор специалистов на далёкую от моих повседневных задач тему.
Но, человек спрашивал про «визуальность» QNX и IDE.


Вспомнил, что где-то в архивах у меня валяются скриншоты от экспериментов 4-х летней давности с QNX 6.2 для x86. Нашёл вот их случайно.










---
P.S. поставил сегодня на закачку QNX Momentics Development Suite 6.3.2 - 523.41 MB.
Хочется посмотреть, что нынче раздают в комплекте.

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

Если не ошибаюсь, то Nucleus, uCOS и eCOS - MMU и не нада, для VxWorks - тоже не обязательно.
Про ThreadX и ARTX ничего не скажу - не знаю, но есть подозрение, что ThreadX-у MMU тоже не нада.
Montavista - Linux вид сбоку.
Вопщем... че-то я альтернатив QNX-у все равно не вижу.