QNX opensource! Опции

[Nixon]

Сегодня QSSL открыла исходные коды QNX 6 (правда под собственной лицензией, но все равно для всех).
Более подробно -> www.qssl.com

[prog_sun]

Olej

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

(prog_sun @ Oct 21 2007, 12:27) *

А вот на счет того что поставить такую ось на ракету такое не слышал,


да? а вся система телеметрии МКС ? wink.gif

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

и не только как HMI, а как системой управления всей навигацией

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

[Olej]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[prog_sun]

+ АСУТП литейными и близкими к ним производствами ... Магнитогорск и др.

и вот это

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

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

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

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

[Olej]

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

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

Какая же это тайна? Вроде Украина в Нато стремиться .

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

[prog_sun]

А если искать синоним "реалтайм" - то ближайший и будет "надёжность" ... predictable,

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

а вот само абсолютное значение времени реакции - ну просто никакого отношения к реалтайм и не имеет

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

И вот именно поэтому всем им Linux не сгодился

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

[Olej]

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

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

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

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

Перевод известного отчёта Dedicated Systems по тестированию QNX Neutrino 6.2.0. Перевод выложен на сайте ЦНИИЛ и выполнен, как сказано на сайте "...студенткой группы 5057/2 Ксенией Некрасовой."

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

Как уже говорил, шедулер QNX масштабируется как O(n) на количество нитей. Другими словами, время его отработки линейно возрастает с их количеством.

А вот здесь вы, пожалуй, правы... не так однозначно, может, 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гц - как, не слабо? , не хочется за таким поработать?