= Сообщение: 6448 из 8619 ========================================= 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) |