> Но вообще-то в статье говорилось о _конкретной_ нагрузке.

Ну тогда можно смело утверждать, что при данной конкретной нагрзке LINUX - RTOS :)))) c max откликом 27мкс. Ура товарисчи!!!!

> Это для linux'a нормально плюс минус лапоть (11-27мкс)...

Что еще интересного знаете про реалтаймовость линукса? 8-)

> а ничего, что иногда приоритет прерываний от вообще оборудования зависит?

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

>>обычно именно так и бывает, но вряд ли показатели interrupt latency меряются в таких условиях

> вот и я про то же, в VxWorks заявляется по даташиту 10mks, а по факту постоянно что-то отваливается

Консенсус :)

>>Нормальная RTOS тем и отличается, что в ней ты сам назначаешь приоритеты прерываний.

>а ничего, что иногда приоритет прерываний от вообще оборудования зависит?

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

> плюс к тому, что ты будешь делать, когда у тебя на PCI с четырьмя линиями прерываний двадцать устройств сидит?

Здесь, если тебя не устроят 4 уровня приритетов (по IRQ), ничего не поделаешь - остается уповать на то, что драйверы быстро определяют, относится ли пришедшее прерывание к ним.

> ну да, 100-200 mks, подумаешь...

Такая вот хреновая RTOS 8)

> потому как за BSP отвечает не поставщик RTOS

Знаю, брат! Когда после трепа об ограниченных задержках и минимальном времени блокирования прерываний в ядре видишь в блокировки прерываний в BSP - иногда хочется взять в руки пулемет.

>> Но вообще-то в статье говорилось о _конкретной_ нагрузке.

>Ну тогда можно смело утверждать, что при данной конкретной нагрзке LINUX - RTOS :)))) c max откликом 27мкс. Ура товарисчи!!!!

В realtime-системах очень часто нагрузка конкретная и неизменная. Так что воистину ура! 8)

> В realtime-системах очень часто нагрузка конкретная и неизменная. Так что воистину ура! 8)

Так то оно так, но вот фирма A купила RTOS, у неё одна нагрузка (неизменная) в конторе В - другая нагрузка (неизменная), про С - вообще помолчу... Так. что Linux для каждой из контор - RTOS, а в целом... Но всеравно УРААА!!!!

>>а ничего, что иногда приоритет прерываний от вообще оборудования зависит?

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

ух... если бы

как правило такая схема работает только для ограниченного количества оборудования типа RS и таймеров, а все остальное делается топором производителем BSP, и все устройства которые сидят на PCI или VME шине бессовестно отрубаются прерыванием от таймера, которое еще и scheduling иногда не стесняется делать внаглую.

Ура! Теперь зюзероутеры будут риалтаймовыми!

> как правило такая схема работает только для ограниченного количества оборудования типа RS и таймеров

А что за операционка? В ветке -rt Linux'а и OC2000 (ЕМНИП) именно так и делается, причем для всех устройств.

> и все устройства которые сидят на PCI или VME шине бессовестно отрубаются прерыванием от таймера

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

>> как правило такая схема работает только для ограниченного количества оборудования типа RS и таймеров

>А что за операционка?

например такое в VxWorks бывает

>В ветке -rt Linux'а и OC2000 (ЕМНИП) именно так и делается, причем для всех устройств.

а много устройств RtLinux поддерживает? раз два и обчелся. К тому же там практически нет RT функциональности вроде сетевых стеков, файловых систем, менеджеров распределенной памяти, графических библиотек, и т.п. Так что RTLinux не конкурент.

а что это за зверь OC2000 (ЕМНИП)?

> а что это за зверь OC2000 (ЕМНИП)?

ОС2000 - это специальная ОС РВ для российских военных, вроде как сертифицированная по самое не балуйся (но я подозреваю, сделана на основе VxWorks), а ЕМНИП == IIRC :D

> а много устройств RtLinux поддерживает? раз два и обчелся.

Я не о RtLinux производства FSM Labs, а о ветке -rt, которую ведет Ingo Molnar из RedHat и еще куча народу (Montavista и др). В этой ветке поддерживаются все те же устройства, что и в обычном Linux

> К тому же там практически нет RT функциональности вроде сетевых стеков, файловых систем, менеджеров распределенной памяти, графических библиотек

Сетевой стек реального времени разработан в рамках RTAI (это проект, чем-то похожий на RtLinux), правда, поддерживаются всего несколько карт. А при словах "файловая система реального времени" (а тем более "графическая библиотека реального времени") мне просто смешно. Может, я просто с такими задачами не сталкивался.

> Объясните мне что такое Real Time OS. Не станут же программы более шустрыми только от того что мы обзовём операционную систему "рилтаймовой"? Что такое время транзакции и время реакции? И кому всё это надо.

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

> Транзакция - экономический процессс, например, перечисление денег с одного счета на другой. СЛЕРТ справился с 28 млн транзакций за 11 мкс. По-моему все ясно.

Да ты гонишь. Объясняю на пальцах - 28 миллонов хаккеров неплохо подогрелись за неизвестный промежуток времени, а система тратила 11 мкс на отклик о готовности предоставить бабло очередному хаккеру.

> Или по-прежнему есть люди, считающие, что Интернет придумал Б.Г.?

Ой, не грузи. Как только Билли озаботится созданием реал-тайм-венды, то рекордом будут считаться десятки секунд, а откликом - "ну что тебе нада, сцуко?" от манагера техподдержки M$ ;)

> Билли озаботится созданием реал-тайм-венды, то рекордом будут считаться десятки секунд

Как минимум одна из версий WinCE - сертифицированная операционка жесткого реального времени.

> Как минимум одна из версий WinCE - сертифицированная операционка жесткого реального времени.

Байки из склепа или просто, Геть-зе-факс-2? ;)

Оно "has real-time capabilities", но хз, кто из реально независимых от M$ контор ее тестил и кто может подписаться под своими словами ;)

И вообще - на авианосцы вендов уже понаставились, хрен кто доверит теперь ответственные задачи сей поделке ;)

>> Как минимум одна из версий WinCE - сертифицированная операционка жесткого реального времени.

>Байки из склепа или просто, Геть-зе-факс-2? ;)

Нет, просто факты

Вот из Wikipedia: "Windows CE conforms to the definition of a real-time operating system, with a deterministic interrupt latency. It supports 256 priority levels and uses priority inheritance for dealing with priority inversion."

> кто из реально независимых от M$ контор ее тестил

Степень независимости тестировщика я определить не берусь. А ты берешься?

> на авианосцы вендов уже понаставились

IIRC, это был ракетный крейсер.

> хрен кто доверит теперь ответственные задачи сей поделке

Увы, увы. Доверяют...

>ОС2000 - это специальная ОС РВ для российских военных, вроде как сертифицированная по самое не балуйся (но я подозреваю, сделана на основе VxWorks), а ЕМНИП == IIRC :D

а-а-а, это для Багетов, я тоже слышал что они VxWorks содрали, ничего от нее хорошего не ожидаю, сертифицировать и ржавый болт можно по самое не балуйся ;-)

>Я не о RtLinux производства FSM Labs, а о ветке -rt, которую ведет Ingo Molnar из RedHat и еще куча народу (Montavista и др). В этой ветке поддерживаются все те же устройства, что и в обычном Linux

интересно, как там вообще возможно hard-RT

>Сетевой стек реального времени разработан в рамках RTAI (это проект, чем-то похожий на RtLinux)

я знаю про RTAI, но сетевой стек там похоже в зачаточном состоянии, причем только UDP, кажется. Но даже если и TCP есть, я имел в виду кучу разных сетевых стеков, в особенности беспроводных (Blootooth, ZigBee, ...)

> А при словах "файловая система реального времени"

очень дяже нужна, наглядный пример - задача описываема в топике, или ты думаешь там СУБД в /dev/null пишет ;-)

>(а тем более "графическая библиотека реального времени") мне просто смешно.

а зря, батенька, интерфейсную панель в истребителе именно такими штуками и делают, что такое VAPS не слышали? Можно конечно ее и не RT делать, но тогда сопрягать с датчиками замучаешься, разработка в копеечку влетит...

>> В этой ветке поддерживаются все те же устройства, что и в обычном Linux

>интересно, как там вообще возможно hard-RT

А в чем принципиальная проблема? Наследование приоритетов, вытесняемые спинлоки, отказ от явного запрещения прерываний.

>> А при словах "файловая система реального времени"

>очень дяже нужна, наглядный пример - задача описываема в топике, или ты думаешь там СУБД

По-моему, это не в кассу. Во-первых, СУБД сама по себе файловая система (я даже подозреваю, что тот Ingres работал на raw-разделе ;)), во-вторых, СУБД внутри себя - ни разу не реального времени.

>(а тем более "графическая библиотека реального времени") мне просто смешно.

> а зря, батенька, интерфейсную панель в истребителе именно такими штуками и делают, что такое VAPS не слышали?

Не слышал (другими вещами занимаюсь).

> Можно конечно ее и не RT делать, но тогда сопрягать с датчиками замучаешься, разработка в копеечку влетит...

А причем сопряжение с датчиками к графической библиотеке?

>А причем сопряжение с датчиками к графической библиотеке?

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

>А в чем принципиальная проблема? Наследование приоритетов, вытесняемые спинлоки, отказ от явного запрещения прерываний.

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

>По-моему, это не в кассу. Во-первых, СУБД сама по себе файловая система

вовсе не всегда, а очень даже редко

> во-вторых, СУБД внутри себя - ни разу не реального времени.

и тем не менее рынок RT-СУБД довольно таки приличен, а RT filesystem - в стандартной поставке у многих RTOS

>> Можно конечно ее и не RT делать, но тогда сопрягать с датчиками замучаешься, разработка в копеечку влетит...

>А причем сопряжение с датчиками к графической библиотеке?

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

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

>>А причем сопряжение с датчиками к графической библиотеке?

>Типичная фишка в любой графической библиотеке - это синхронизация перерисовки и изменения данных.

Настолько общая фраза, что с ней не поспоришь.

> в том, что так удастся переписать всю помойку драйверов я катастрофически сомневаюсь.

Фишка в том, что переписывать не придется. То, что правильно работает на SMP, будет правильно работать и в -rt.

>>По-моему, это не в кассу. Во-первых, СУБД сама по себе файловая система

>вовсе не всегда, а очень даже редко

У всех SQL-серверов, которые я знаю (Postgres, Oracle, DB2, Informix, Ingres). Только называется это у них не "файловая система", а как-нибудь вроде "storage layer", и он поддерживает не файлы и каталоги, а более специфичные структуры данных. Но сути это не меняет.

> тем не менее рынок RT-СУБД довольно таки приличен

Имена? (а так же явки, пароли 8))

> а RT filesystem - в стандартной поставке у многих RTOS

думаю, правильнее будет сказать, что в стандартную поставку входит нечто, называемое "RT filesystem"

>>А причем сопряжение с датчиками к графической библиотеке?

>а это такая штука, если у тебя софт работает по стандарту VAPS

Интересно. Да, о таком в RTAI не слышал. Но для Linux оно просто обязано быть :)

>Фишка в том, что переписывать не придется. То, что правильно работает на SMP, будет правильно работать и в -rt.

на SMP и глобальный лок на 10 секунд будет правильно работать ;-)

>> тем не менее рынок RT-СУБД довольно таки приличен

>Имена? (а так же явки, пароли 8))

да набираешь в google "realtime database" и можешь звонить Алексу, или Юстасу, не помню уже :-)

>Интересно. Да, о таком в RTAI не слышал. Но для Linux оно просто обязано быть :)

может и есть, но уже не RT, сам понимаешь

Suseuser теперь обновит свой Suse-router :)

>>Фишка в том, что переписывать не придется. То, что правильно работает на SMP, будет правильно работать и в -rt.

>на SMP и глобальный лок на 10 секунд будет правильно работать ;-)

Это проблема того же порядка, что и запрещение прерываний в BSP. Такое не мешает VxWorks бить себя пяткой в грудь о вещать о своей рилтаймовости.

> может и есть, но уже не RT, сам понимаешь

Я так понял, что это всего лишь технология разработки. Запустишь результирующе приложение на RTOS - будет realtime, запустишь не на RTOS - не будет. А то, что Linux будет давать realtime - я лично не сомневаюсь.

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

Или в в Зюзе осилили HZ ?

>про $100 млн - очень похоже на грязный пеар.

Просто написано там коряво, имеется в виду наверное что-то вроде $100 млн. в год или типа того?

ну тебе оно ненужно, незнаешь и понятия не имеешь, что это такое - сиди молчи, зачем "умничать?" :) прочти лучше, что это такое http://www.nextaz.com/shownew.php?id=1108676192

> Посмотреть бы в глаза главного маздайщега Билла, на то как он смотрит на такие системы, и мечтает создать подобное.. Прикрутить еще десяток "патчей" на Ви$ту и в бой )

Риалтаймовую Windows Mobile вы конечно же забыли упомянуть как подобает истинному грязному пеарщику?

> И вообще - на авианосцы вендов уже понаставились, хрен кто доверит теперь ответственные задачи сей поделке ;)

И кто там был виноват? Криворукие кодеры, переписавшие свое поделие, которое валилось на делении на нуль, под NT. Если это - проблема операционки, то Linux угробил Томми.

> Фишка в том, что переписывать не придется. То, что правильно работает на SMP, будет правильно работать и в -rt.

Интересно, как SMP обойдет медленно работающий драйвер?

Time — money, real-time — real money.

Таки в чём прикол с рилтаймовыми ОС? Как себя поведёт SLERT из топика если заказать не 28 миллионов, а 28 миллиардов запросов?

Чем пришлось пожертвовать чтобы сделать ОС рилтаймовой? Что плохо?

>> Фишка в том, что переписывать не придется. То, что правильно работает на SMP, будет правильно работать и в -rt.

>Интересно, как SMP обойдет медленно работающий драйвер?

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

> Таки в чём прикол с рилтаймовыми ОС?

В том, что они мало кому нужны ;) Но тем, кому они таки нужны - они очень нужны.

> Чем пришлось пожертвовать чтобы сделать ОС рилтаймовой? Что плохо?

_Обычно_ считается, что из-за того, что в РВ стараются уменьшить время реакции (latency), то страдает общая пропускная способность (throughput). Но первые эксперименты с preemptible kernel в Linux показали _увеличение_ пропускной способности. Так что жертвовать, IMHO, ничем не пришлось. Хотя доработка ядра до realtime - процесс трудоемкий, даже с учетом использования наработок от SMP (первые версии того, что стало сейчас веткой -rt, появились 2 года назад, IIRC).

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

> Я не о RtLinux производства FSM Labs, а о ветке -rt, которую ведет Ingo Molnar из RedHat и еще куча народу (Montavista и др). В этой ветке поддерживаются все те же устройства, что и в обычном Linux

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

Да. Modulo bugs, как говорится.

> Посмотреть бы в глаза главного маздайщега Билла, на то как он смотрит на такие системы, и мечтает создать подобное.. Прикрутить еще десяток "патчей" на Ви$ту и в бой )

Иди и смотри :)

http://www.ardence.com/embedded/products.aspx?ID=70

>Linux угробил Томми

Сцуко....

>Хотя доработка ядра до realtime - процесс трудоемкий

В оригинальной статейке на ZDNet написано, что в Wind River думают, что Preempt RT патч будет принят в майнстрим к версии 2.6.19/20.

> Иди и смотри :)

> http://www.ardence.com/embedded/products.aspx?ID=70

По-моему, это _совсем_ другая вещь. И разработана не в M$. Просто работает под Виндой (в буквальном смысле). Так что поставить это в заслугу Билли - всё равно, что поставить ему в заслугу Firefox 8)

> на ZDNet написано, что в Wind River думают, что Preempt RT патч будет принят в майнстрим к версии 2.6.19/20

В 2.6.19 - не верю ни разу (Мортон недавно опубликовал план по .19, а Мольнар выпустил -rt патч для 2.6.18, и ни один из них не заикнулся о слиянии в mainline). И вообще, почему-то kernel hacker'ы не особо любят эту ветку :(

> По-моему, это _совсем_ другая вещь. И разработана не в M$. Просто работает под Виндой (в буквальном смысле). Так что поставить это в заслугу Билли - всё равно, что поставить ему в заслугу Firefox 8)

Да понятно. Вопрос был в "прикручиваемости". А у мс своя есть система для этого - СЕ.

> Вопрос был в "прикручиваемости"

В современном мире достигнута абсолютная "прикручиваемость" - гонишь нужную ОС в Xen или VMware на правильной ОС 8) По-моему, так гораздо надежней, чем подсовывать под Винду subkernel'ы реального времени.

Кстати, видел ли кто-нибудь WinCE для обычных PC? Есть ли такая вообще в природе?

Я видел. Есть.

Где ее можно взять "на поиграться" (с SDK) ?