Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.LINUX
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.LINUX с датами от 24 Jan 02 06:01:34 до 29 Oct 24 22:11:24, всего сообщений: 8619
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 6446 из 8619 ========================================= RU.LINUX =
От   : Eugene Muzychenko                2:5000/14          28 Nov 20 09:39:50
Кому : Alexey Vissarionov                                  28 Nov 20 09:39:50
Тема : Реальное время в Linux
FGHI : area://RU.LINUX?msgid=2:5000/14+5fc213f0
На   : area://RU.LINUX?msgid=2:5020/545+5fc1ae9e
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX?msgid=2:5020/545+5fc27d4e
==============================================================================
Привет!

28 Nov 20 04:44, you wrote to me:

AV> Ты объем этих исходников видел? Там где-то порядка гигабайта.

Гигабайт - это весь линукс. Для реализации сколь угодно жесткого RT достаточно доработать лишь ядро, а это несколько десятков мегабайт максимум.

AV> Переписывать, конечно, нужно не все, но многое.

Многое-то зачем? Или там в ядре полно мест, где слишком долго держат блокировки, многократно ходят по одним и тем же спискам, и т.п.?

AV> Производительность != быстродействие

Сейчас я говорю исключительно о времени реакции на события, а оно пропорционально прежде всего тактовым частотам.

AV> Напомню, писюшный флоп - это чистейшее GPIO-устройство.

Hе только писюшный - их таких немало было в те времена. Hо интеллектуальный контроллер флопа с DMA появился еще при DOS, а анекдот про "истинно многозадачную систему Windows" описывает DOS-based версии винды. В любой NT флоп работал так же независимо, как и HDD.

AV> Лично я эту поебень даже в ядро вкомпилячивать не буду. Ибо кроилово,
AV> традиционно ведущее к попадалову.

Ты не понял. Я не предлагаю делать программно то, что занимает достаточно много ресурсов (обмен большими массивами данных, формирование сигналов заданной формы и т.п.). Основная идея - это получение от ОС предсказуемого времени реакции на событие, определяемого только быстродействием железа и разумными накладными расходами на поиск обработчика прерывания, переключение контекста и т.п. Сейчас, насколько я понимаю, в линуксе этой предсказуемости нет, как и в винде. Событие по схеме "сигнал-прерывание-драйвер-процесс" в одном случае может быть передано процессу через 100 мкс, а в другом - через 5 или 20 мс.

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

Идея отнюдь не в том, чтобы регулярно дрочить регистры десятки-сотни тысяч раз в секунду, а в том, чтобы обработать разумное (максимум - сотни-тысячи в секунду) количество событий максимально близко к моментам их возникновения.

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Fox Tracks, Servoz, France (2:5000/14)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.071410 секунды