LINUX.ORG.RU

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


0

2

Особенно интересует для применения в промышленном секторе.
Сейчас я вижу такие варианты:
1. nice
2. cpulimit для других процессов
3. CFQ с заданием RT для этого процесса

Но, может, есть что-нибудь ещё? :)

P.S. RTLinux и Xenomai не предлагать, мне нужно решение вообще без изменения кода.

Процесс читает данные из диска/сети?
Если читает из диска, поместить данные в ТМПФС, синхронизировать, например, по крону.

Что делает процесс?

Но, может, есть что-нибудь ещё? :)

Проц по мощнее.

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

Если читает из диска, поместить данные в ТМПФС

зачем?

Если интенсивно и часто читает данные, увеличится скорость.
Если ТС меняет nice чтоб быстрее работало, то это увеличит скорость.

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

ему не нужна скорость, ему нужен реалтайм

нет таких реалтаймовых задач, которые бы фейлились из-за io, если конечно чтение не идёт с дискеты или если не нужно читать гигабайты данных в секунду

mlyaghost
()

Всякие RT и псевдо-RT надо обеспечивать для начала на уровне приложения, а не операционки. Толку от твоих настроек, если приложение будет лезть в базу и застревать там на 5 секунд?

no-dashi ★★★★★
()

RTLinux и Xenomai не предлагать

Патч -rt? Хотя, конечно, зависит от временнЫх требований задачи - может быть, просто задрать приоритет до FIFO и разумно спроектировать rt-часть.

CFQ с заданием RT для этого процесса

Не вижу смысла.

tailgunner ★★★★★
()

Эта... Реалтайм - это не мгновенная реакция на прерывание, а гарантированное время этой реакции. Оно может быть вполне приличным, а общее быстродействие даже может быть ниже, чем не-реалтайм.

anonymous
()

Нет в линуксе такого и не будет никогда.

В принципе, можно взять rt-патч, изменить планировщик и т.п. - в общем, превратить линукс в однозадачную систему. Тогда, возможно, какое-то подобие «настоящего» RT и будет...

Eddy_Em ☆☆☆☆☆
()

RTLinux и Xenomai не предлагать, мне нужно решение вообще без изменения кода.

ССЗБ

В промышленности используют специализированные решения всегда. Только идиоты или неимущие ресурсов на такое дело не используют специализированные решения.

Quasar ★★★★★
()

А вот этого я не заметил:

RTLinux и Xenomai не предлагать, мне нужно решение вообще без 
изменения кода.

Покупайте уже QNX!

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

Реалтайм - это не мгновенная реакция на прерывание, а гарантированное время этой реакции

одно другому не мешает

mlyaghost
()

Кнопку Power уже предлагали?

опишите работу приложения , пожалуйста.

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

одно другому не мешает

Хех, ещё как мешает. Чудес не бывает, М.Ч., увы. Если бы не мешало, все операционные системы были бы давно RTOS. Так что дибо быстрая (в большистве случаев) реакция, либо детерменированность реакции (гарантированное время).

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

Патч -rt?

но rt-часть приложения полностью должна быть заново переписана?

просто задрать приоритет до FIFO

объясните, пожалуйста, между чем и чем у Вас FIFO? :)

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

Патч -rt?

но rt-часть приложения полностью должна быть заново переписана?

Ответ на этот вопрос не зависит от использования -rt.

объясните, пожалуйста, между чем и чем у Вас FIFO? :)

Между нитями.

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

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

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

я хочу сделать так, чтобы если какое-нибудь сраное приложение в ведре начнет грузить проц, а другое - жрать хард, чтобы эта программа (для ЧПУ) обработалась без каких-либо задержек.

Может сначала посмотришь в сторону sched_setscheduler с SCHED_FIFO? Вдруг оно тебя устроит.

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

эм, господа, вы меня не совсем правильно поняли

Это потому, что ты плохо объясняешь.

я хочу сделать так, чтобы если какое-нибудь сраное приложение начнет грузить проц, а другое - жрать хард, чтобы эта программа (для ЧПУ) обработалась без каких-либо задержек.

cgroups, не? http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

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

чтобы эта программа (для ЧПУ) обработалась без каких-либо задержек

nice --20 не достаточно?

что будет, если нить уровня ядра (бажное ядро, например) начнет жрать проц

А что, были прецеденты?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

были. с подвисанием при использовании tar'а 100% загрузкой проца тредом ведра. причём решилось только более новым ведром. какого хрена оно случалось в ведре, не понятно. хочу заметить, что это был именно баг ведра, т.е. даже при 10кб архиве даже за полчаса ничего хорошего не происходило

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

так тебе приоритеты задать или рт надо?
если приоритеты, то кури nice/renice + ionice + schedtool
последний позволяет много чего, в том числе привязать процесс к ядру, задать планировщик и т.д.
на фоне schedtool chrt выглядит как-то смешно

megabaks ★★★★
()

P.S. RTLinux не предлагать,
мне нужно решение вообще без изменения кода.

Шашечки или ехать? Ты ещё морковку без каротина попроси. Для жесткого realtime есть rt-ядра. Зачем дуру то валяешь?

darkshvein ☆☆
()
Ответ на: комментарий от Eddy_Em

Нет в линуксе такого и не будет никогда.

тут из зала подсказують, что размер rt-патча всё меньше с каждым релизом. к чему бы ето

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

к тому, что в ведре уже много всего

ktulhu666 ☆☆☆
() автор топика

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

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

кстати, а раньше все эти вещи SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_ISO, SCHED_IDLEPRIO были только в rt- ? в чём на данный момент главное отличие от ванильного?

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

Должен, вопрос лишь в том - как. Использование bfs само по себе может вызвать проблемы, поэтому никто ничего не гарантирует.

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

я понимаю, но у меня не космическая промышленность же :)

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