Hard real-time patch

ну смех и грех

что такое glxgears для такой машины ? да нагрузка там вряд-ли будет больше процента. А что пинг-флуд для такой машинкы даже по 100 мегабитной сетке?

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

Ты откуда пришел такой? Glxgears на 100% грузит проц на такой "машинке"

на любой машине будет 100% загрузки, различаться будут только количество fps

Мне вот интересно. Вроде как realtime патчи такого рода общую работоспособность linux не ухудшают, т.е. в отсутствие RT-событий он выглядит как обычная система (десктоп скажем :). Почему эти патчи не включают в ядро в качестве опций?

то есть как, заменяется код с более сложным алгоритмом, учитывающим preemption, какие-то локи, отжирающие такты, и перфоманс ядра не меняется?!

> то есть как, заменяется код с более сложным алгоритмом, учитывающим preemption, какие-то локи, отжирающие такты, и перфоманс ядра не меняется?!

Был у меня как-то пару месяцев десктоп с RTLinux ядром, вообще никакой разницы не замечал с обычным ядром.

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

Так если бы за клавиатурой был бы не ты, а скажем, система управлением боя летательного аппарата/станком-роботом с ЧПУ, то они бы сразу почувствовали.

AlexxZ

ни я ни ты (да?) не специалисты по ядрам осей, спорить бессмысленно. Давно уже был на лоре спор по поводу preemptive kernel. Да, время реакции на прерывания растёт, но _общая_ performance падает, что для сервера, например, более критично, чем время реакции (для десктопа наоборот).

>latency - от 0.4 до 5.2 микросекунд

ну вот, сначала мерялись аптаймами, теперь вот задержкой прерываний. при чём тут реалтайм? RT - это в первую очередь предсказуемость, которой нет и не будет..

> Почему эти патчи не включают в ядро в качестве опций?

Потому что они часто снижают безопасность системы. Впрочем, почему не включают? В 2.6.x есть один такой патч.

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

Полностью с вами согласен: латентность прерываний совсем не показатель реалтаймности. 
И вообще, интеловая архитектура и микросекундный реалтайм - понятия несовместимые. В этом убедился на собственном опыте, когда на базе rtlinux и microPC Octagon 5066 делал систему сбора и обработки данных с периодом  100-150 мкс. Несмотря на то, что и плата сбора была достаточно быстрой, и обработка несложной, при периоде менее 120 мкс система просто рассыпалась. Но самое неприятное было в том, что имели место лаги длительностью до десятков мс, причина которых, как аппаратные, так и программные.
 

Причем тут безопасность?

yes > /dev/null &

И если из этого ты выйдешь без ресета, то это не реал-тайм система :)

> И если из этого ты выйдешь без ресета, то это не реал-тайм система :)

Запустил, увидел в top, что загружен проц на 99%, порадовался и убил этот процесс.

Что-то я не понял, нафига тут ресет и при чём тут реал-тайм?

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

Прежде чем что-то ляпать, наверное надо хотя бы почитать про эту тему. Например Столингс "Операционные системы" или Таненбаум "Современные ОС", для начала.

так фича RT-патча и состоит в том, что с ним latency становится _предсказуемой_ (практически не меняется при разной нагрузке на процессор).

> yes > /dev/null &

8))))

хохмы ради "рилтайм-тест" v.2 :

yes `cat /bin/ls` > /dev/null &

> Да, время реакции на прерывания растёт, но _общая_ performance падает, что для сервера, например, более критично, чем время реакции (для десктопа наоборот).

блин, прочитал что написал, время реакции на прерывания конечно падает, и общая performance должна падать тоже. Но не важно, как было уже замечено, для rt важна предсказуемость, точнее гарантированное время отклика.

> И вообще, интеловая архитектура и микросекундный реалтайм - понятия несовместимые.

расскажи об этом создателям QNX: http://www.qnx.com/products/ps_rtosv4/index.html IMHO от лукавого все потуги превратить линух в hard-rt kernel. Ну нельзя добавить системе фундаментальные свойства, которые не закладывались дизайном (в общем случае любой, не только ядрам осей. Появление нового свойства у сложной системы, состоящей из простых, не обладающих новым свойством это отдельный случай). Да и не нужно это, у линухового ядра своя ниша, ведь это же здорово, когда есть общий стандарт - POSIX, который довольно хорошо гарантирует совместимость на интерфейсы сисколов, и портирование приложений им значительно облегчается, так пусть каждое ядро используется там, где оно лучше всего подходит.

Да уж, linux всёрвано посасывает по сравнению с настоящими ОСРВ

http://qnxclub.net/files/articles/rtos/rtos.html
http://qnxclub.net/files/articles/RemarksOnTheMargins/RemarksOnTheMargins.html
http://www.asutp.ru/?p=600354

> http://www.asutp.ru/?p=600354

Заgарили жёлтой прессой, изобилующей словами "опаздает" и проч.