= Сообщение: 6448 из 8279 ========================================= RU.LINUX =
От : Alexey Vissarionov 2:5020/545 28 Nov 20 19:05:00
Кому : Eugene Muzychenko 28 Nov 20 19:05:00
Тема : Реальное время в Linux
FGHI : area://RU.LINUX?msgid=2:5020/545+5fc27d4e
На : area://RU.LINUX?msgid=2:5000/14+5fc213f0
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX?msgid=2:5000/14+5fc2ccbe
==============================================================================
Доброго времени суток, Eugene!
28 Nov 2020 09:39:50, ты -> мне:
AV>> Ты объем этих исходников видел? Там где-то порядка гигабайта.
EM> Гигабайт - это весь линукс. Для реализации сколь угодно жесткого RT
EM> достаточно доработать лишь ядро, а это несколько десятков мегабайт
EM> максимум.
А "весь Linux" - это и есть ядро. Как я уже написал в прошлом сообщении, монолитное модульное.
AV>> Переписывать, конечно, нужно не все, но многое.
EM> Многое-то зачем? Или там в ядре полно мест, где слишком долго держат
EM> блокировки, многократно ходят по одним и тем же спискам, и т.п.?
Да об этом в принципе никто не задумывался. Есть таймер, который срабатывает CONFIG_HZ раз в секунду (на серверах - 100, на десктопах - 250, 300 или 1000 ценой небольшой потери производительности): получили квант времени - работаем; закончили досрочно - вернули управление, планировщик разберется; не успели - опаньки, ждем следующего кванта времени.
gremlin@ws:~ > zgrep ^CONFIG_HZ= /proc/config.gz
CONFIG_HZ=100
Да, я использую серверное значение на десктопе. Мне можно, ибо я точно знаю, зачем мне именно такая настройка :-)
AV>> Производительность != быстродействие
EM> Сейчас я говорю исключительно о времени реакции на события, а оно
EM> пропорционально прежде всего тактовым частотам.
Нет - оно (точнее, его матожидание) пропорционально
AV>> Напомню, писюшный флоп - это чистейшее GPIO-устройство.
EM> Hе только писюшный - их таких немало было в те времена.
Писюшный - самый известный.
EM> Hо интеллектуальный контроллер флопа с DMA появился еще при DOS,
Где-то во времена пней-2...пней-3, если правильно помню. Лет 20 назад.
И работать с ним можно было только через int 0x13 - это сразу убило все говнозащиты от копирования, использовавшие дискеты в качестве ключевого носителя.
EM> а анекдот про "истинно многозадачную систему Windows" описывает
EM> DOS-based версии винды. В любой NT флоп работал так же независимо,
EM> как и HDD.
Независимо, ага... но медленно и печально.
AV>> Лично я эту поебень даже в ядро вкомпилячивать не буду. Ибо
AV>> кроилово, традиционно ведущее к попадалову.
EM> Ты не понял. Я не предлагаю делать программно то, что занимает
EM> достаточно много ресурсов (обмен большими массивами данных,
EM> формирование сигналов заданной формы и т.п.). Основная идея - это
EM> получение от ОС предсказуемого времени реакции на событие,
EM> определяемого только быстродействием железа и разумными накладными
EM> расходами на поиск обработчика прерывания, переключение контекста и
EM> т.п.
Да не будет оно предсказуемым... во всяком случае, при условии сохранения адекватной производительности.
EM> Сейчас, насколько я понимаю, в линуксе этой предсказуемости нет, как
EM> и в винде.
Угадай, почему.
EM> Событие по схеме "сигнал-прерывание-драйвер-процесс" в одном случае
EM> может быть передано процессу через 100 мкс, а в другом - через 5 или
EM> 20 мс.
Это вполне нормально. Если тебе нужно гарантированное время отклика - ставь лошадьтроллер, который будет работать с оборудованием в realtime, а данными с системой обмениваться асинхронно.
То есть, не "произошло событие, что делать?", а "тут было вот такое событие, отреагировал вот так, что делать дальше?". Но это дуууумать наааадо...
EM> Даже если у тебя есть спецконтроллер для критичной ко времени
EM> периферии, который сам ведет обмен на микросекундных интервалах, в
EM> этих условиях ты не сможешь обеспечить бесперебойное взаимодействие
EM> линуксового процесса с контроллером на интервалах, меньших
EM> единиц-десятков миллисекунд.
И не надо - это забота софта, работающего внутри лошадьтроллера.
EM> А железо позволяет делать это на интервалах даже в сотни микросекунд,
EM> но система, из-за недостатков ядра, этого не тянет. Hеужто не досадно?
А с чего мне должно быть досадно?
EM> Идея отнюдь не в том, чтобы регулярно дрочить регистры десятки-сотни
EM> тысяч раз в секунду, а в том, чтобы обработать разумное (максимум -
EM> сотни-тысячи в секунду) количество событий максимально близко к
EM> моментам их возникновения.
Это аппаратная задача и решать ее нужно аппаратными же средствами.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Вопрос понял, ответ думаю
--- /bin/vi
* Origin: ::1 (2:5020/545)
|
