[vetal 0]

Не согласен.

п.1. Неправильная постановка вопроса. Оченку необходимо производить по параметру вероятность безотказной работы.

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

 

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

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

[AlexandrY 3]

Я не согласен. Я не вижу логики в ваших аргументах.

1) Какую причину вы озвучивали ранее? Какие сбои в динамическом озу? Какая взаимосвязь между озу и ос? какие сбои ячейках в динамическом озу?

 

2)опятьже нету тут логики. Что надежнее - 1000 строк кода без ошибок или 10 строк кода с ошибками? Какая взаимосвязь между динамическим ОЗУ и ос? Почему эта связка ненадёжна?

 

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

 

Вот TI выпускает серию микроконтроллеров TMS570 , сверх надежные на Cortex с двойным синхронным выполнением на двух ядрах и сверкой результатов, с ЕЕС на каждый тип памяти.

Так во первых у них нет интерфейса к DDR, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.

Буквально сегодня мне пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!

Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?

Ответ ясен, они его собирались использовать без RTOS в обычном понимании.

Т.е. в критически надежных системах RTOS не используют. Вот и вся связь

[sasamy 9]

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

 

Сегодня уже процессорные ядра специально оптимизируют под конкретные операционные системы а вы все какие-то наблюдения из космоса приводите :)

http://www.imgtec.com/meta/meta-technology.asp

 

 

[juvf 10]

Вот и вся связь

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

 

Вот чипs TMS570LS: Так во первых у них нет DAC, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.

Буквально сегодня вам пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!

Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?

 

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

 

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

[AlexandrY 3]

Я не вижу связи. Какая связь между DDR и ОС?

 

Таймер в TMS570 пришел от ядра Cortex. Это не вина TI.

DAC хотя и нет, но можно подключить внешний.

А DDR не подключить никаа...ак ;)

С DDR не дружит надежность. Большим RTOS которые действительно экономят время и деньги своим мощным middleware (VxWorks, QNX, Symbian, ....) нужна DDR, тоже каждый знает.

Вывод - большие RTOS проектируются не для повышения надежности как минимум.

И можно сказать снижают надежность своим размером и требованием к объему памяти.

 

Сегодня уже процессорные ядра специально оптимизируют под конкретные операционные системы а вы все какие-то наблюдения из космоса приводите :)

http://www.imgtec.com/meta/meta-technology.asp

 

Этот пример только подтверждает, что RTOS-ам не доверяют и делают аппаратные реализации многозадачности.

Я еще помню эту технологию со времен Scenix когда они конкурировали с PIC-ами.

Не пошло. Ограниченная аппаратная многозадачность удобна только для ограниченного круга задач.

[juvf 10]

Вывод - большие RTOS проектируются не для повышения надежности как минимум.

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

[_Pasha 0]

Я еще помню эту технологию со времен Scenix когда они конкурировали с PIC-ами.

Не пошло. Ограниченная аппаратная многозадачность удобна только для ограниченного круга задач.

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

[vshemm 0]

Мои доводы:

1. Если в устройстве используется динамическое ОЗУ для исполнения программы, то снижается надёжность работы устройства в целом. Причину я озвучивал ранее.

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

С этим кто-то не согласен?

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

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 в космос полететь :)

 

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

Чтобы так говорить, опыт должен быть всеоблемлющим и должны быть проведены все возможные в принципе наблюдения.

Очевидно, что таких людей на планете Земля нет, поэтому остается только искать логику.

 

...

Т.е. в критически надежных системах RTOS не используют. Вот и вся связь

...

Этот пример только подтверждает, что RTOS-ам не доверяют и делают аппаратные реализации многозадачности.

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

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

авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.

И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,

а входить в состав СДУ, т.е. помогать рулить. Да что там авиация, если даже в наших современных ракетах, которые

все еще объективно одни их лучших в мире перешли от жесткой логики к вычислителю с памятью + ос - о чем-то это

говорит (только тсс, это гостайна :).

 

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

 

Как-то так.

 

[Enthusiast 0]

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

[AlexandrY 3]

А крутится там сами знаете какая ось, и это неспроста. Так что если сильно

захотеть, можно и с ненадежной DRAM в космос полететь :)

 

Есть известные стандарты авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.

И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,

а входить в состав СДУ, т.е. помогать рулить.

 

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

 

Как-то так.

 

Да, тут крыть нечем. ;)

Это я упустил.

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

И тогда несколько другие законы начинают работать.

[Enthusiast 0]

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

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

авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.

И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,

а входить в состав СДУ, т.е. помогать рулить. Да что там авиация, если даже в наших современных ракетах, которые

все еще объективно одни их лучших в мире перешли от жесткой логики к вычислителю с памятью + ос - о чем-то это

говорит (только тсс, это гостайна :).

 

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

 

Как-то так.

Если рассуждать в том же духе, то на международной космической станции у космонавтов ноутбуки вообще работают под "Виндой". Теперь "Винда" стала космически надёжной осью что-ли?

Парни, может пора уже научиться думать своей головой, опираясь на факты и здравый смысл?

А через показательные полёты в космос эти "сверхнадёжные" операционные системы оседают в головах доверчивых руководителей и инженеров на радость довольным маркетологам.

Применять операционные системы с исполнением из динамического ОЗУ в задачах управления в электронных устройствах недопустимо.

[a9d 0]

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

 

Вот TI выпускает серию микроконтроллеров TMS570 , сверх надежные на Cortex с двойным синхронным выполнением на двух ядрах и сверкой результатов, с ЕЕС на каждый тип памяти.

Так во первых у них нет интерфейса к DDR, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.

Буквально сегодня мне пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!

Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?

Ответ ясен, они его собирались использовать без RTOS в обычном понимании.

Т.е. в критически надежных системах RTOS не используют. Вот и вся связь

 

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

 

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

[vshemm 0]

Гугл отдельная тема. Данная статистика просто пища для размышлений. У МС тоже есть публичная статистика по фолтам

в винде :) Но тут другое. Гугл (я сейчас очень утрированно скажу) применяет ненадежное оборудование для построения

надежной системы. Т.е. он применяет дешевый шлак для построения надежной и робастной системы. Как им это удается?

Математика. Map reduce, сейчас вот spanner, причем это уже устаревшие технологии для гугла. Посмотрите на данную

статистику с другой стороны - гугл вопреки ошибкам в дешевой DRAM выдает на гора надежные решения.

Но и задача у гугла другая, не сравнимая с мелкосерийным производством межпланетных аппаратов (грубо говоря, у них

миллиарды микросхем памяти, в отличие от единичных аппаратов). Так что мимо.

 

 

Мой поинт в том, что люди, постоянно выдающие тезисы типа "винда говно", "линукс говно", "QNX - RTOS, остальное говно",

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

Адвентисты седьмого дня. Особенно "программисты QNX", почему то. И они сами себя зашоривают, не видя альтернатив.

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

про выбор, выбор ОС, выбор без-ОС, выбор своя-ОС. Каждой задаче - свое решение. Чем бОльшим инструментарием владеет

исполнитель, тем эффективнее будет решена задача в среднем. Технико-экономическое обоснование должен писать не фанатик.

Но фанатики больше всех орут, и это печально :(

 

 

Если рассуждать в том же духе, то на международной космической станции у космонавтов ноутбуки вообще работают под "Виндой". Теперь "Винда" стала космически надёжной осью что-ли?

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

я на МКС засунул флешку в комп и винда восстановилась". И ничо, летит щас из перигея в апогей, и восстанавливает. И я руку

даю на отсечение, что восстановит.

 

[sasamy 9]

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

 

Ну вы как и AlexandrY упростили настолько что исказили суть. Во первых аппаратные потоки там могут исполняться одновременно используя свободные ресурсы, а во вторых планировщик ресурсов там приоритетный благодаря чему например возможна работа RTOS совместно с GPOS без всякой виртуализации.

http://www.imgtec.com/factsheets/meta/Meta...re_Overview.pdf

 

Применять операционные системы с исполнением из динамического ОЗУ в задачах управления в электронных устройствах недопустимо.

 

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

Изменено 14 декабря, 2012 пользователем sasamy

[juvf 10]

Применять операционные системы с исполнением из динамического ОЗУ в задачах управления в электронных устройствах недопустимо.

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

 

Ещё раз спрашу: Почему ос+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 компе - ни каких сбоев. Ща ртосы внедрил в проекты, тоже в такие системы, где связанно с жизнями - все работает и ни каких сбоев. Вот вам факт.