LINUX.ORG.RU

Hard real-time patch


0

0

Bernhard Kuhn - программист из компании Metrowerks, создал
"real time interrupt patch" (rtirq-patch), который позволяет
использовать ядро linux в приложениях жесткого реального времени,
например в контроллерах с обратной связью.

Достигнуты характеристики

(Athlon XP2400+ on an ASUS A7N8X under ping-flood condition and with "glxgears" running on an Nvidia GeForce 4200 at the same time.)

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

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

Re: Hard real-time patch

ну смех и грех

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

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

anonymous ()
Ответ на: Re: Re: Hard real-time patch от anonymous

Re: Re: Re: Hard real-time patch

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

anonymous ()

Re: Hard real-time patch

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

anonymous ()
Ответ на: Re: Hard real-time patch от anonymous

Re: Re: Hard real-time patch

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

anonymous ()
Ответ на: Re: Re: Hard real-time patch от anonymous

Re: Re: Re: Hard real-time patch

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

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

anonymous ()
Ответ на: Re: Re: Re: Hard real-time patch от anonymous

Re: Re: Re: Re: Hard real-time patch

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

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

AlexxZ

anonymous ()
Ответ на: Re: Re: Re: Hard real-time patch от anonymous

Re: Re: Re: Re: Hard real-time patch

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

anonymous ()

Re: Hard real-time patch

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

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

anonymous ()
Ответ на: Re: Hard real-time patch от anonymous

Re: Re: Hard real-time patch

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

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

PitStop ()
Ответ на: Re: Hard real-time patch от anonymous

Re: Re: Hard real-time patch

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

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



NewComer ()
Ответ на: Re: Re: Hard real-time patch от PitStop

Re: Re: Re: Hard real-time patch

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

yes > /dev/null &

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

anonymous ()
Ответ на: Re: Re: Re: Hard real-time patch от anonymous

Re: Re: Re: Re: Hard real-time patch

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

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

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

Vond ★★ ()
Ответ на: Re: Re: Re: Hard real-time patch от anonymous

Re: Hard real-time patch

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

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

anonymous ()
Ответ на: Re: Hard real-time patch от anonymous

Re: Re: Hard real-time patch

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

anonymous ()
Ответ на: Re: Hard real-time patch от anonymous

Re: Re: Hard real-time patch

> yes > /dev/null &

8))))

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

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

loki ()

Re: Hard real-time patch

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

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

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

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

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