И все 100 критических прерываний будут переданы Линусу Торвальдсу ?

и как только включается своп от реалтайма остается одно воспоминание

хотя конечно смотря что они имели в виду под Hard RealTime это сколько по времени? пару часов или пару милисекунд?

если не ошибаюсь на Pentium100 QNX гарантировал ответ на событие в течении 4мс

> хотя конечно смотря что они имели в виду под Hard RealTime это сколько по времени?

98 микросекунд

Подскажите какую нибудь статью на русском про RTOS. Хочу повысить собственное образование. Что значит ответ на событие 4мс. А на какие события RTOS так обязаны отвечать. На аппаратные прерывания?

>98 микросекунд

и на каком железе? время без железа ничего не значит

кстати откуда цифра? по рисунку вычислил? в сообщениях не видать

на русском сайте посвящненном QNX был ряд статей

к сожелению не помню названия фирмы - от QNX отошел давненько

> кстати откуда цифра?

http://news.com.com/MontaVista+beats+real-time+Linux+deadline/2100-7344_3-581...

Сама идея RT заключена строгом регламенте, а не в минимальном времени отклика, хотя последнее часто становится первым.

>и на каком железе? время без железа ничего не значит http://www.mvista.com/products/realtime_benchmarks.html

Aristarch.

2 anonymous (*) (03.08.2005 11:06:38):

Ну не надо тогда включать своп. Уж как минимум каждый процесс, претендующий на риэлтайм, может сделать mlockall (), и после этого все страницы этого процесса ни в какой своп не попадут.

А если этому процессу вредит общение с диском других процессов - то тогда надо пинать разработчиков аппаратуры (у меня, к примеру, на AMD Elan SC520 контроллер IDE вообще ISA-шный, без поддержки всяких DMA и busmaster), или можно вообще с винтом не общаться ни в каком виде (систему на RAM-диск и вперед).

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

/vap

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

>> у меня, к примеру, на AMD Elan SC520 контроллер IDE вообще ISA-шный, без поддержки всяких DMA и busmaster)

Бедненькиййй... ;)

>на русском сайте посвящненном QNX был ряд статей

>к сожелению не помню названия фирмы - от QNX отошел давненько

qnx.org.ru - русскоязычный QNX портал

> Так что проблемы с риэлтаймом в линуксе все же глубже лежат, чем своп и подобные мелочи

Абсолютно верно. Хуже того: Linux - это вообще неуклюжий архитектурный монстр. Ядро нуждается в полном переписывании, что влечёт изменения вообще всей идеологии. Но старым П. это уже не по силам, а новым - лениво. Ужас...

>а своп не нужен. когда я купил себе 512 памяти я забыл что такое своп. >сейчас с гигом и с двумя на работе даже и не вспоминаю что такое своп. >его нет, и все тут. своп - это прошлое.

У меня тоже 1,25 Гига - но своп есть. Открываю 85 xml ( в нем данные для переноса от 1С 8.0) в редакторе XML - и вуаля! Кстати никто не подскажет редактор XML, который бы более-менее шустро работал с такими большими файлами? А то открывает минут 20, после изменения минут 40 записывает и т.д. Все редакторы пытаются файл полность в память закачать. А так, чтобы окнами работать.....

2 anonymous (*) (03.08.2005 13:08:40):

Для банального soft-риэлтайм (и очень даже многих задач hard-realtime), идеологии нынешнего линукса имхо вполне достаточно. Существование hard-realtime-патчей это доказывает.

Другой вопрос, что не все API являются в достаточно степени удобными для того, чтобы их применять в realtime-задачах. Например, RT-расширения файловых систем (XFS вроде как могла бы такое?).

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

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

/vap

А скриптом не пробовал? ну или grep юзать?

2 Megabit ** (*) (03.08.2005 13:04:02):

Да я не жалуюсь, мне-то как раз всего хватает :)))

133 MHz - это, на самом деле, дофига как много, особенно если гуй не нужен. Видеопоток, чай, успевает разгребать и очень даже кое-что с результатами делать.

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

/vap

stilet scite notepad

Принудительное переключение контекста

А никто не подскажет, в каком именно месте (файл, метод, условия) инициируется принудительное переключение процесса, когда он сожрал всё время?

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

Hint: прерывание таймера.

> Другими словами, если процесс в бесконечном цикле и ничего из системных потрахов не дёргает, то как он теряет управление?

По прерыванию по таймеру. Управление возвращается шедулеру, а он уже решает что делать дальше.

>the_one >По прерыванию по таймеру.

Очень сомнительно! По таймеру можно только слайсы считать. А в шедулере даже проверка есть на контекст прерывания... Если шедулер вызнан из прерывания -- гаплык!!! Должен быть другой способ.

ЗЫ Если бы было по таймеру, то нужен код, который бы сохранял состояние до прерывания, а такого кода тоже нет :(

>Хуже того: Linux - это вообще неуклюжий архитектурный монстр. Ядро нуждается в полном переписывании, что влечёт изменения вообще всей идеологии. Но старым П. это уже не по силам, а новым - лениво. Ужас...

Так возьми и перепиши, если ты такой умный.

При чём тут хард нах? Это софт, фтопку!

Как показала ныне дохлая QNX, RT на PC на самом деле никому нафиг не нужен. Так, пиписьками померяться разве что (у кого быстрее встает).

>Очень сомнительно!

господи прочитай что-нибудь и не пори больше полную чушь.

>>Очень сомнительно!

>господи прочитай что-нибудь и не пори больше полную чушь.

"Полную чушь"? Перепланировка процессов в Linux выполняется еще и при
выходе из сиcтемного вызова или прерывания, и при блокировке задачи
(на вызове чего нибудь вроде copy_from_user/get_user_pages или
up/down), не говоря уже о явных вызовах wake_up_xxx и schedule_xxx,
которые делаются и из прерываний ввода/вывода. Так что не надо
"полной чуши". Твои знания планирования процессов в Unix устарели
лет на 20, если не на 30.

> Как показала ныне дохлая QNX, RT на PC на самом деле никому нафиг не нужен.

Ну во-первых, показала не QNX, а QSSL (читай "тупая политика руководства"), а во-вторых, может реалтайм и не необходим, но ОЧЕНЬ УДОБЕН при работе. Например, WinXP при хорошей нагрузке на диск просто ДОХНЕТ. В Linux я такого не замечал, но таки подтормаживало иногда. Кроме того, реалтайм - это не только удобство для десктопа, но и возможность унифицировать Embedded системы единой OS. Как результат, единая инфраструктура - как клиентов, так и управляющих систем.

> Ну во-первых, показала не QNX, а QSSL (читай "тупая политика руководства"), а во-вторых, может реалтайм и не необходим, но ОЧЕНЬ УДОБЕН при работе. Например, WinXP при хорошей нагрузке на диск просто ДОХНЕТ. В Linux я такого не замечал, но таки подтормаживало иногда.

ну QNX4/6 то-же дохнет при хорошей нагрузке на жесткий диск.. ;)

// wbr

Эх, еще бы в ванильном ядре эти "ошибки" исправили. Всем польза была бы.

А по поводу общения со свопом - дык не все в него просится.. систему и правда настроить как следует - и вот вам ракетный двигатель под столом (или еще где).

"Это было в то время, когда компьютеры были большими, а программы маленькими" © Кабы из софта мусор повыкидывать - вот и скорость возрастет. ИМХО

> ну QNX4/6 то-же дохнет при хорошей нагрузке на жесткий диск.. ;)

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

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

значительно веселее - это распаковка толстого tar мегабайт этак на 500. например, syssrc.tgz от NetBSD где море мелких файлов.

// wbr

>Все редакторы пытаются файл полность в память закачать. А так, чтобы окнами работать.....

Эхххх... вот я тоже об этом думал. Если кто помнит, была такая iS-DOS для Спектрума. Так вот там работа с большими текстовыми фалами так и происходила, прозрачно и по кусочкам :-)

> Очень сомнительно!

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

Вот здесь есть немного: http://www.embedded.com/showArticle.jhtml?articleID=55301875

> Если бы было по таймеру, то нужен код, который бы сохранял состояние до прерывания

Не нужен, вроде, процессор занимается этим сам при смене контекста (context switch).

>the_one >Не нужен, вроде, процессор занимается этим сам при смене контекста (context switch).

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

От сюда и проблема, шедулер из прерывания дёргать нельзя ибо куда девать следующее прерывание :() Актуально для 2.4.х

2.6.х не смотрел

>"Полную чушь"?

да именно полная чушь.

> Перепланировка процессов в Linux выполняется еще и при

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

> при блокировке задачи
> прерываний ввода/вывода

это было и в древних unix

> Проц его держит только пока ты остаёшься в контексте прерывания, если ты не возвращаешься по-нормальному

Сходи по линку. Там этот вариант описан. Выход из прерывания происходит нормально по IRET. Только перед этим подменяется задача, в которую будет произведен возврат. Так, кажется :)

>>>> Другими словами, если процесс в бесконечном цикле и ничего из
>>>> системных потрахов не дёргает, то как он теряет управление?

>>>По прерыванию по таймеру.

>>Очень сомнительно!

>господи прочитай что-нибудь и не пори больше полную чушь.

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

>the_one > Только перед этим подменяется задача

А что тогда происходит с тем процессом который попался на прерывании ;) А если серьёзно, то именно этого кода в обработчике я и не обнаружил. За статейку спасибо. Жаль только пендосы не могут писать без воды ;)

>(или это вы?)

нет это не я; вот это я; а то не я; то есть там был я, но не там, а ТАМ; чёрт, может это шиза?; впрочем, даже если шаза, то это точно не Я; хотя возможно и мы; вобщем, вы поняли, или объяснить исчо ;)

> Как я понял, для вас потеря управления
> не по прерыванию от таймера -- полная чушь.

и как ты это понял?

ты вообще по-русски читаешь?
а как у тебя с логикой?

Ты дебил или мудак? Промышленных контроллеров на PC - хоть жопой жуй. Правда почему-то vxworks популярнее.

> то именно этого кода в обработчике я и не обнаружил

В обработчике линукса или в том примере в статье?

> нет это не я; вот это я; ...

Это не я спрашивал :D Я писал только от the_one. Anonymous -- это не я.

А где собственно патчи? или просто просматрели код и всё=))

>> Как я понял, для вас потеря управления
>> не по прерыванию от таймера -- полная чушь.

>и как ты это понял?

А как иначе это можно было понять?

> ты вообще по-русски читаешь?
А ты вообще по-русски пишешь?

>Кстати никто не подскажет редактор XML, который бы более-менее шустро работал

Microsoft XML Notepad beta 1.5 - freeware

>А как иначе это можно было понять?

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

тут ты встрял со своими идиотскими коментариями

Поздравляю тебя, шарик, ты балбес! Риалтайм на десктопе и тем более на сервере нафик никому не нужен, ибо тормоза будут ещё больше! Риалтайм нужет только для встроенных систем, где важна не производительность, а время реакции системы, потому как производительность риалтайм-систем по определению ниже! А в твоём случае тормоза из за IDE-контролёра, риалтайм тут не поможет. Тебя scsi нужен.

> Hard RealTime Это вообще философский вопрос Я пробовал на своем duron 650 минимальное время переключения контекста . Так вот в QNX4.25 он составил 4 мкс (МИКРО). Ну а понта от этого? Когда операционка недаделаная.