LINUX.ORG.RU

Real Time Linux


0

0

Тихо и незаметно, 9 октября 2004г. Montavista представила свои патчи в lklm для превращения linux kernel 2.6 в ядро реального времени.

Это явилось результатом того, что Montavista в течение нескольких лет занималась активным портированием Linux на встроенные устройства.

"Цель этого предложения- дальнейшее уменьшение задержки прерываний и очень сурово уменьшить время ожидания выгрузки (preemtion) задачи." - заявили пацаны из Motavista. "Our broad objective is to achieve preemption latency bounded by the worst case IRQ disable." - добавили они.

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

>>> Подробности



Проверено: ivlad ()

> Цель этого предложения- дальнейшее уменьшение задержки прерываний и очень сурово уменьшить время ожидания выгрузки (preemtion) задачи.
А как это относится к RT?

Irsi
()

ммм... Уже много лет есть RTLinux, который вполне себе стабилен и надежен. Не пойму, зачем анонсировать патчи, которые "под нагрузкой" глючат.

anonymous
()
Ответ на: комментарий от anonymous

Они не глючат. Они даже не ставятся (по крайней мере, у меня) :-P

// SK //

anonymous
()
Ответ на: комментарий от Shaman007

2Shaman007: прямо? ДА? Определение RT в студию плиз, раз прямо...:) HINT - RT никаким образом не относится к скорости...:)

Irsi
()
Ответ на: комментарий от anonymous

> А что там нового на фронте многопоточных ФС?
Давно используются всем прогресивным человечеством, появились первые потуги сделать это под линуксом. Лет через 5-10 линуксоиды будут гордится и орать что они впереди планеты всей, что у них FS - многопоточные... А что?

Irsi
()
Ответ на: комментарий от Irsi

Да так. Вижу разговор про реалтайм не пошел, а своими знаниями тебе похвастать охота. Давай еще про POSIX поговорим.

anonymous
()
Ответ на: комментарий от Irsi

> 2Shaman007: прямо? ДА? Определение RT в студию плиз, раз прямо...:) HINT - RT никаким образом не относится к скорости...:)

Irsi, дорогой, вы по-английски читаете? или только пацанский перевод?

vnp
()
Ответ на: комментарий от dn2010

> от правильный link

Интерестно... Патчики-то Ingo Molnar делал. Не Alan Cox, но тже известная личность... ;-)

atrus ★★★★★
()

> "Цель этого предложения- дальнейшее уменьшение задержки прерываний и
> очень сурово уменьшить время ожидания выгрузки (preemtion) задачи." -
> заявили пацаны из Motavista. "Our broad objective is to achieve
> preemption latency bounded by the worst case IRQ disable." - добавили они.

``пацаны'' говорят на двух языках?

anonymous
()

правильные пацаны заказывают персональное ядро

anonymous
()
Ответ на: комментарий от Irsi

> Давно используются всем прогресивным человечеством, появились первые потуги сделать это под линуксом. Лет через 5-10 линуксоиды будут гордится и орать что они впереди планеты всей, что у них FS - многопоточные... А что?

А что, XFS не многопоточная FS? И ее нельзя поставить на Linux?

faustus
()
Ответ на: комментарий от faustus

>А что, XFS не многопоточная FS? И ее нельзя поставить на Linux?

Нафиг нам эта многопоточность, когда однопоточная (?) Reiser её делает по скорости?

anonymous
()
Ответ на: комментарий от anonymous

Для начала - не надо ставить знак равенства между EA и MDSF... А далее - может я плохо делал rtfm по XFS, но имхо http://www.namesys.com/whitepaper.html довольно похоже на MDSF...

Irsi
()
Ответ на: комментарий от anonymous

> А че такое EA и MDSF? не все тут эксперты :)
Ой как все запущено... Это вообще-то базовые понятия, когда речь заходит о всех современных FS...
Extendet Attributes и Multiple Data Stream per File это... :) Только умоляю - не надо опять начинать с истрои появление FS & DB, их взаимосввязи, почему они были разделены и почему они неизбежно сольются воедино... Кто сказал SQL? RTMF мля! :)

Irsi
()
Ответ на: комментарий от Irsi

> Для начала - не надо ставить знак равенства между EA и MDSF... А далее - может я плохо делал rtfm по XFS, но имхо http://www.namesys.com/whitepaper.html довольно похоже на MDSF...

Другими словами, когда ты говоришь о развитии Линукса, тебя надо игнорировать.

Спасибо.

faustus
()
Ответ на: комментарий от faustus

2faustus: о развитии чего простите? где вы видите развитие, простите? сплош сдирание того, что уже было реализованно в коммерческих система и список отсылок, приведенных по вышеуказанной ссылке - лишнее тому подтверждение...:)

Irsi
()

Онанимус побеситесь, побеситесь, Вам полезно...:) А что, всем слабо дать определение "Какая система является RT-системой?" :) Я это к тому что может начнем постить новости из тех областей, в которых хотя бы базовые понятия знаем? :)

Irsi
()
Ответ на: комментарий от Irsi

> 2faustus: о развитии чего простите? где вы видите развитие, простите? сплош сдирание того, что уже было реализованно в коммерческих система и список отсылок, приведенных по вышеуказанной ссылке - лишнее тому подтверждение...:)

Ага, реализовано в Микрософте. Не смешите мои тапочки. Все дерут у всех, просто от Open Source идет польза всем, а не только какому-то CEO.

Ты сказал: в Линуксе мультипоточные файловые системы будут только через сто лет. Я сказал: в Линуксе XFS есть уже сейчас. Какое к этому имеет отношение кто у кого сдирает?

Когда научимся говорить по существу?

faustus
()
Ответ на: комментарий от faustus

2faustus: А когда научимся читать что написано по приведенным ссылкам? Внимательно читать... А еще бы неплохо было бы читать что пишут другие... Вообщем - ссылку в доках на XFS, где говорится о поддержке именно MDSF, а не EA, можете привести? Серьезно, интересно было бы почитать...
"просто от Open Source идет польза всем" - ну-ну... Этот бред я даже обсуждать не буду...:)

Irsi
()
Ответ на: комментарий от Irsi

Ирси, зайди в поиск. Полгода назад эта тема уже поднималась. Есть там критерий скорости переключения задач. Скорость у тебя есть всегда. Если они могут ужесточить критерии - им плюс.

jackill ★★★★★
()

Смешно наблюдать за ирсей... Сначала он ляпнул не подумав, просто шоб обосрать всех

>А как это относится к RT?

потом, когда ему указали на некорресктность его заявления, он перешел на провокационные методы

>2Shaman007: прямо? ДА? Определение RT в студию плиз, раз прямо...:)

Требуя с других каких-то определений, как будто говоря что он единственный это знает, а все остальные -- пионеры, и сообщает известный факт

>HINT - RT никаким образом не относится к скорости...:)

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

> А что там нового на фронте многопоточных ФС?

И тут же сам себе отвечает

> Давно используются всем прогресивным человечеством, появились первые потуги сделать это под линуксом. Лет через 5-10 линуксоиды будут гордится и орать что они впереди планеты всей, что у них FS - многопоточные... А что?

После разумного замечания об очередном некорректном утверждении, ирси начинает бравировать техническими терминами

> Для начала - не надо ставить знак равенства между EA и MDSF... А далее - может я плохо делал rtfm по XFS, но имхо http://www.namesys.com/whitepaper.html довольно похоже на MDSF...

Еще у ирси ничего нельзя спрашивать

>Ой как все запущено... Это вообще-то базовые понятия, когда речь заходит о всех современных FS...

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

> Extendet Attributes и Multiple Data Stream per File это... :) Только умоляю - не надо опять начинать с истрои появление FS & DB, их взаимосввязи, почему они были разделены и почему они неизбежно сольются воедино...

Никто и не начинал истории. Я понимаю, ирси бы очень хотелось, шоб кто-ньть начал, но...

> Кто сказал SQL? RTMF мля! :)

Заметьте, тоже никто не говорил. "6. Imago (здесь: подмена - лат.) - шестой прием. Заключается в том, что читателю подсовывается некое невообразимое чучело, не имеющее ничего общего с действительным противником, после чего этот вымышленный противник изничтожается. Например, опровергаются мысли, которые противнику никогда и не приходили в голову и которых он, естественно, никогда не высказывал; ему показывают, что он болван и глубоко заблуждается, приводя в примеры действительно глупые и ошибочные тезисы, которые, однако, не принадлежат ему."

>Я это к тому что может начнем постить новости из тех областей, в которых хотя бы базовые понятия знаем? :)

Вот это клевый совет. Как бы ирси этим советом самому воспользоваться...

> "просто от Open Source идет польза всем" - ну-ну... Этот бред я даже обсуждать не буду...:)

Что тоже аргумент силы необычайной. Главное -- объективный.

del
()

У меня в своё время на системе с rtai-патчами постоянно иксы валились :( . Причём именно из-за них: на непатченом эти же иксы до сих пор работают...

bugmaker ★★★★☆
()
Ответ на: комментарий от Irsi

> Определение RT в студию плиз, раз прямо...:) HINT - RT никаким образом не относится к скорости...:)

RTC - режим реального времени - работа цифровых вычислительных устройств по управлению реальными физическими процессами, которые нельзя прервать, остановить, или отложить во времени...

anonymous
()
Ответ на: комментарий от anonymous

2anonymous (*) (11.10.2004 7:34:18): ок, и как на основе это определения можно определить какая система является RT, а какая нет? :) Положим мы управляем процессами А, В и С. Обслуживаем процесс А, и тут пришел запрос на обслуживание от процесса В... Что делаем - прерываем обслуживание процесса А или говорим процессу Б "ждите ответа"? Какая реакция будет соотвествовать RT-системе? :)

Irsi
()
Ответ на: комментарий от Irsi

Во взрослых РТ системах (например RTEMS) У всех трех процессов могут быть разные приоритеты, поэтому информации недостаточно.

Oval
()
Ответ на: комментарий от Oval

2Oval: hint - не просто недостаточно, это неверный путь, прямо проистекающий из некорректного определения. Точнее - неточного. :) Цель - продемонстрировать неполноту определения. :)

Irsi
()
Ответ на: комментарий от Irsi

Ну грубо говоря одно из определений - не просто малое время переключения задач, а гарантированно малое (Малое всеж оставляю).

Oval
()
Ответ на: комментарий от Oval

>Ну грубо говоря одно из определений - не просто малое время переключения задач, а гарантированно малое (Малое всеж оставляю).

Насколько я помню ключевое слово в определении ОСРВ или RTOS то, что управление перейдет к нужной задачие в течение гарантированного промежутка времени, и этот промежуток времени достаточно мал. Ядра NT и linux kernel 2.6 AFAIK обеспечивают гарантированное время, но не беспечивают его малость. Эти патчи как раз и обеспечивают меньшее время переключения.

dn2010 ★★★★★
()

по поводу спора с Irsi: http://lib.ru/SOCFANT/CHAPEK/gazeta.txt

А так новость появилась как раз вовремя и разрешила мой спор с группой товарищей, является ли ядро 2.6 без RTAI ядром ОСРВ. Теперь точно является. ;)

dn2010 ★★★★★
()
Ответ на: комментарий от Irsi

>2Oval: hint - не просто недостаточно, это неверный путь, прямо проистекающий из некорректного определения. Точнее - неточного. :) Цель - продемонстрировать неполноту определения. :)

Определение Oval'а абсолютно верно - это постановка задачи. Hint: аппаратно-программный комплекс для управления процессами обычно зависит от процессов, которыми надо управлять. Даже RTOS в него необязательно входит.

ivan_gur
()
Ответ на: комментарий от Irsi

> RT никаким образом не относится к скорости...:)

Irsi, специально для тебя.

RT - это система с гарантировнным временем реакции на внешние события. RT бывает "мягким" (примеры - Solaris, местами - Windows), где это формально не следует из организации OS, но за счет управления задачами и ресурсами системы, "обычно" получается то, что требуется. RT бывает "жестким" (QNX) - когда организация OS такова, что время гарантированной реакции соблюдается в 100% случаев.

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

ivlad ★★★★★
()
Ответ на: комментарий от Irsi

> 2jackill: не скорости, уважаемый, не скорости (latency)... а времени... разницу понимаешь? :)

Ой, Irsi не начинай тут вакханалию невежества. Ну не разбираешься в RT - ну помолчи, а? Не неси тут чуши про EA и multiple stream, это здесь не в кассу.

ivlad ★★★★★
()

"зависаниями можно столкнуться при большой нагрузке и недостатке памяти."

Эта фраза займёт первое место на anekdot.ru.

"заявили пацаны из Motavista"

Конкретные пацаны используют чисто Windows CE.

anonymous
()
Ответ на: комментарий от ivlad

2oxonian: я-то разбираюсь, а ты мне всю развлекуху попортил. :) От тебя ответ неинтересно получить - я в курсе что ты в курсе. :)

P.S. Имхо мягкий RT чем-то сродни немного беременной девушке, извини. :)

Irsi
()
Ответ на: комментарий от anonymous

2anonymous (*) (11.10.2004 10:28:26): мягкая разумеется, которая строго говоря "настоящей RT" и не является - чтоб жесткую получить все ядро с нуля переделать придется.

Irsi
()
Ответ на: комментарий от ivlad

2oxonian: еще раз - RT это система обладающая гарантированным временем реакции на события. Все, точка. Мягкая RT это приблизительно тоже самое что многозадачность в 9х...

Irsi
()
Ответ на: комментарий от Irsi

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

Ктоб внес ясности? Еще ни одной статьи толковой не видел.

Oval
()
Ответ на: комментарий от Oval

2Oval: во первых RTOS без специально заточенного под RT железа это тот самый сферический конь в вакуцуме. А во вторых гарантируется не время обработки запроса, а время реакции системы на запрос, а эта реакция может быть не только в виде готовых резултатотов обработки запроса, но и ответа "атстань я занята"...:)

Irsi
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.