Не согласен.
п.1. Неправильная постановка вопроса. Оченку необходимо производить по параметру вероятность безотказной работы.
п.2. Не показатель. Даже в 10 строчках кода могут быть фатальные ошибки. Зависит в первую очередь от "классности" программиста и корректности постановки задачи.

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

Логику искать не надо здесь. Все чисто на опыте и наблюдениях.

Вот TI выпускает серию микроконтроллеров TMS570 , сверх надежные на Cortex с двойным синхронным выполнением на двух ядрах и сверкой результатов, с ЕЕС на каждый тип памяти.
Так во первых у них нет интерфейса к DDR, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.
Буквально сегодня мне пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!
Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?
Ответ ясен, они его собирались использовать без RTOS в обычном понимании.
Т.е. в критически надежных системах RTOS не используют. Вот и вся связь

Сегодня уже процессорные ядра специально оптимизируют под конкретные операционные системы а вы все какие-то наблюдения из космоса приводите
http://www.imgtec.com/meta/meta-technology.asp

Я не вижу связи. Какая связь между DDR и ОС? В их чипе нет ддр и какаято невнятная связь между какой-то фичей lockstep и ртос. Что из этого следует? что ддр с ртос не дружит?

Вот чипs TMS570LS: Так во первых у них нет DAC, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.
Буквально сегодня вам пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!
Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?

Согласно вашей логики наблюдениям, использование ос в чипах с DAC - снижает надёжность.

ps в тойже TMS570LS есть Real-Time Interrupt (RTI) OS Timer.

Таймер в TMS570 пришел от ядра Cortex. Это не вина TI.
DAC хотя и нет, но можно подключить внешний.
А DDR не подключить никаа...ак
С DDR не дружит надежность. Большим RTOS которые действительно экономят время и деньги своим мощным middleware (VxWorks, QNX, Symbian, ....) нужна DDR, тоже каждый знает.
Вывод - большие RTOS проектируются не для повышения надежности как минимум.
И можно сказать снижают надежность своим размером и требованием к объему памяти.



Этот пример только подтверждает, что RTOS-ам не доверяют и делают аппаратные реализации многозадачности.
Я еще помню эту технологию со времен Scenix когда они конкурировали с PIC-ами.
Не пошло. Ограниченная аппаратная многозадачность удобна только для ограниченного круга задач.

вывод за уши притянут.

Упрощенка, напр. пропеллер: там разделение аппаратных ресурсов за счет "бегущего 0 или 1", в итоге 160МГц - 8 ядрышек на 20МГц. Видимо, просто не дали им пойти дальше.

Я, как вы понимаете, тоже не согласен. К предыдущим ораторам хотелось бы добавить следующее:
1. Чтобы так утверждать, нужно сначала определиться с методикой измерения надежности и то, по сравнению
с чем надежность ниже. Конечно, введение ненадежного элемента в систему при прочих равных снижает общую
надежность, но тут ключевые слова - при прочих равных. Понятно, что мигать светодиодом можно из-под
Windows, а можно и простенькой схемой на 155 серии, но ведь некоторые задачи без ОЗУ решить невозможно
(при разумных сроках и стоимости). Опять же, вопрос применения ОС по сравнению с не-ОС абсолютно
ортогонален надежности DRAM.
2. Логика правильная, но посылка ложная. Начиная с некоторой сложности задачи, при использовании ОС
количество кода уменьшается (при условии, что задача корректно решается).

Вообще, если уже кто-то представил себе ОС как библиотеку с неким функциональным набором, уже может сделать
вывод, что как только человек в суперлупе применяет такие понятия как многозадачность, синхронизация,
память,... - он уже реализует ОС, которая, правда, размазана по пользовательскому коду. И тогда спор
суперлуп вс ОС отпадет сам собой. Действительно, нет принципиальной разницы между решением применять
libc для printf(), например, или rtos.lib для schedule() - просто функционал разный. И физическое отделение
данных сущностей в отдельный слой выглядит весьма логичным.

Другой аспект - физическая ненадежность электроники. Это тоже решается применением всяких SOI, сапфировых
подложек для исключения тиристорного защелкивания, triple-well технологией для того же, ЕСС на всех уровнях,
мажоритарной логикой, дублированием, троированием и прочими архитектурными радостями. И это все работает.
Пример - curiosity. Там стоят два RAD750, один из которых в резерве, абсолютно не подверженных тиристорному
защелкиванию (latchup-immune), выдерживающих миллион рад суммарной дозы, с надежностью 1.6Е-10 ошибок
(single-event upset) в день. Плюс 256Kib EEPROM, 256Mib DRAM (sic!) и куча флеш памяти. Плюс физическая защита,
разумеется. В результате, расчетная надежность данного комплекса примерно 1 failure в 15 лет. Хз, много это
или мало, но точно что достаточно. А крутится там сами знаете какая ось, и это неспроста. Так что если сильно
захотеть, можно и с ненадежной DRAM в космос полететь


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



Данные выражения ложны. Чтобы их опровергнуть, достаточно привести один контрпример - см. выше. Если куриосити
не работает в сложных условиях и там нет критически важных задач, приведу другой пример. Есть известные стандарты
авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.
И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,
а входить в состав СДУ, т.е. помогать рулить. Да что там авиация, если даже в наших современных ракетах, которые
все еще объективно одни их лучших в мире перешли от жесткой логики к вычислителю с памятью + ос - о чем-то это
говорит (только тсс, это гостайна .

Так что RTOS применяются и им доверяют.

Как-то так.

По просьбам трудящихся я приведу здесь ссылку на отчёт североамериканских сотрудников "Гугла" об отказах в работе динамической памяти на серверах: "DRAM Errors in the Wild: A Large-Scale Field Study".

Да, тут крыть нечем.
Это я упустил.
Но с другой стороны, как я понял, рассматривался наш земной контекст, с комплектацией из Digi-Key и с минимально достаточным бюджетом.
И тогда несколько другие законы начинают работать.

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

Это не совсем так. Почти весь софт (включая оф. сайт) разрабатывается и поддерживается индусами. Ti это никак не скрывает. Вот отсюда и растут все ихние проблемы.

После нового года поступят в продажу SoC CC2538(он же CC2580 Cortex+ZigBee). Первоначально они анонсировали поддержку FreeRTOS но вот совсем недавно они заявили, что FreeRTOS поддерживаться не будет. Они не смогли портировать Z-Stack на RTOS. И это не вызвано соображениями надежности. Они ответили, что Z-Stack для запуска на FreeRTOS нужно переписать а они это делать не будут. Хотя перед этим они пытались это сделать.

Гугл отдельная тема. Данная статистика просто пища для размышлений. У МС тоже есть публичная статистика по фолтам
в винде Но тут другое. Гугл (я сейчас очень утрированно скажу) применяет ненадежное оборудование для построения
надежной системы. Т.е. он применяет дешевый шлак для построения надежной и робастной системы. Как им это удается?
Математика. Map reduce, сейчас вот spanner, причем это уже устаревшие технологии для гугла. Посмотрите на данную
статистику с другой стороны - гугл вопреки ошибкам в дешевой DRAM выдает на гора надежные решения.
Но и задача у гугла другая, не сравнимая с мелкосерийным производством межпланетных аппаратов (грубо говоря, у них
миллиарды микросхем памяти, в отличие от единичных аппаратов). Так что мимо.


Мой поинт в том, что люди, постоянно выдающие тезисы типа "винда говно", "линукс говно", "QNX - RTOS, остальное говно",
"суперлуп решает" и прочее (не обязательно прямым текстом, но косвенно... и это очень хорошо видно), - фанатики.
Адвентисты седьмого дня. Особенно "программисты QNX", почему то. И они сами себя зашоривают, не видя альтернатив.
Поэтому действительно серьезных задач они решать не могут. Вот я уже подчеркивал, что НАСА в своей памятке говорит
про выбор, выбор ОС, выбор без-ОС, выбор своя-ОС. Каждой задаче - свое решение. Чем бОльшим инструментарием владеет
исполнитель, тем эффективнее будет решена задача в среднем. Технико-экономическое обоснование должен писать не фанатик.
Но фанатики больше всех орут, и это печально



Будете смеяться, но и так было. Т.е. тупо подходит будущий космонавт (с начальством, разумеется) и говорит: "надо что бы
я на МКС засунул флешку в комп и винда восстановилась". И ничо, летит щас из перигея в апогей, и восстанавливает. И я руку
даю на отсечение, что восстановит.

Ну вы как и AlexandrY упростили настолько что исказили суть. Во первых аппаратные потоки там могут исполняться одновременно используя свободные ресурсы, а во вторых планировщик ресурсов там приоритетный благодаря чему например возможна работа RTOS совместно с GPOS без всякой виртуализации.
http://www.imgtec.com/factsheets/meta/Meta...re_Overview.pdf



Про какое управление вы говорите ? Я знаю массу примеров промышленных установок под управлением OS/2 например станки с ЧПУ, АСУТП и маркетологам типа вас ничего подобного не сделать.

Сообщение отредактировал sasamy - Dec 14 2012, 06:51

Это уже религия. ))

Ещё раз спрашу: Почему ос+DRAM менее надёжнее чем oc+SRAM или чем чем суперлуп+DRAM?

Вам уже др учасники форума объясняют, что ос или суперлуп - в конечном счете одно и тоже. что schedule или что организация многозадачности в суперпуле - это одно и тоже. И ни как не связанно с ОЗУ.

Я вас призываю опираться на здравый смысл и научиться думать своей головой. Какие факты? Если бы была бы такая машинная команда, например с мнемоникой "ramJamp a,b;". И всё ртос используют эту команду, но эта команда ненадёжно работает с DRAM, а в суперпуле ни кто эту команду не вызывает - вот это был бы факт. Есть подобные факты? Код ос, например FreeRTOS, присутствует впроекте в виде исходников на си. код задач также написан на си. компилятор собрал исполняемый код. почему он на DRAM будет работать хуже менее надёжно?

А то, что ti не поставило в какойто чип контроллер ддр или что нет порта RTOS на чип - это ни чего не значит.
В мосгорсуде используют бумагу "снегурочка". Но это не значит что "SvetoCopy" ненадёжна.
Позвоните в ti и спросите "Почему нету ддр в таком чипе? Потому что ртос менее надёжна на ддр?" Если они скажут - "да, Применять операционные системы с исполнением из динамического ОЗУ в задачах управления ", ну вот тут будет пища, и то это не будет факт, это будет только мнение ti.

Сделайте эксперемент: запилите какойнить девайс.... напишите несколько задач и загрузите задачи вычислениями, пусть ПИ считают, да передают друг другу массивы большие. и запустите сие чудо на DRAM разных типов, например ddr, ddr2, ddr3, ... и при чем разных производителей..... каждых типов по 3-5 производителей. напишите программу с ос и без ос. и потестите. И причем для чистоты эксперемента пусть будет около 3 RTOS ну и 3 неRTOS. ну и потом всё тоже самое, только на статическом озу. - ну вот будет вам детальное исследование и факты.

ну из моей практики: около 12 лет крутится ос в системах, где ошибка=человеческая жизнь, круглые сутки на DRAM, в некоторых местах ещё на 386 компе - ни каких сбоев. Ща ртосы внедрил в проекты, тоже в такие системы, где связанно с жизнями - все работает и ни каких сбоев. Вот вам факт.