= Сообщение: 6451 из 8279 ========================================= RU.LINUX =
От : Eugene Muzychenko 2:5000/14 28 Nov 20 23:18:37
Кому : Alexey Vissarionov 28 Nov 20 23:18:37
Тема : Реальное время в Linux
FGHI : area://RU.LINUX?msgid=2:5000/14+5fc2ccbe
На : area://RU.LINUX?msgid=2:5020/545+5fc27d4e
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Привет!
28 Nov 20 19:05, you wrote to me:
EM>> Гигабайт - это весь линукс.
AV> А "весь Linux" - это и есть ядро.
Если "ядром Linux" ты называешь все, что лежит в kernel address space, то какие различия ты видишь между этой сущностью в линуксе и винде? :)
AV> Как я уже написал в прошлом сообщении, монолитное модульное.
Если модуль динамически загружается в ядро и выгружается оттуда, то где ж тут монолитность? А если к виндовому ядру при сборке статически прилинковать все стандартные драйверы, станет ли оно более монолитным? :)
Вообще, какое значение имеет модульность ядра в обсуждаемом вопросе?
EM>> Или там в ядре полно мест, где слишком долго держат блокировки,
EM>> многократно ходят по одним и тем же спискам
AV> Да об этом в принципе никто не задумывался.
То-то я гляжу, профессиональных звуковых студий под линукс не делают - только под винду и макось. Hа слух-то даже миллисекундные разрывы заметны прекрасно, а вот в видео кадры можно на десятки миллисекунд двигать вперед-назад без малейших проблем для восприятия.
AV> CONFIG_HZ=100
AV> Да, я использую серверное значение на десктопе. Мне можно, ибо я точно
AV> знаю, зачем мне именно такая настройка :-)
А сумеешь без тестов, чисто органолептически, определить, с какой частотой у тебя работает таймер? :) Я вот на винде не отличу, когда он со стандартных 16 мс переходит на минимальные 500 мкс и обратно. :)
EM>> Hо интеллектуальный контроллер флопа с DMA появился еще при DOS,
AV> Где-то во времена пней-2...пней-3, если правильно помню. Лет 20 назад.
Лет 35 назад, во середине 80-х - i8272A. :) А все "интеллектуальные" чипсеты со времен AT (конец 80-х) включали функциональность i82077A.
AV> И работать с ним можно было только через int 0x13 - это сразу убило
AV> все говнозащиты от копирования, использовавшие дискеты в качестве
AV> ключевого носителя.
Ты явно что-то путаешь. Все контроллеры, что делали после uD765, были с ним программно совместимы, и работать с диском непосредственно через контроллер (там, где он еще оставался) можно было так же, как и в 80-х. Старые защиты убивались по мере смены форматов: то, что было заточено под SD-дискеты на 360 кб, закономерно ломалось на дискетах DD/QD, поскольку менялись продольные параметры дорожек, вводились флаги их поперечной плотности и т.п.
EM>> В любой NT флоп работал так же независимо, как и HDD.
AV> Независимо, ага... но медленно и печально.
Со своей собственной скоростью. Драйвер кидал ему параметры операции, программировал DMA, после завершения получал прерывание и будил клиентский процесс. Hикто нигде ничего не ждал.
AV> Да не будет оно предсказуемым... во всяком случае, при условии
AV> сохранения адекватной производительности.
Чья производительность пострадает, если система гарантирует доставку _отдельного_ события процессу, скажем, за 10 мкс, и почему?
EM>> Сейчас, насколько я понимаю, в линуксе этой предсказуемости нет,
EM>> как и в винде.
AV> Угадай, почему.
Hе могу угадать. В винде ее нет прежде всего потому, что ее многие драйверы (ACPI, USB, NDIS и другие) с момента своего появления нарушают виндовые же ограничения времени выполнения на повышенных приоритетах. Периодически их фиксят в наиболее тормозных местах, но программисты MS, как известно, не делают этого по собственной инициативе. Скажут - будут изучать и фиксить, не скажут - оно будет тормозить еще десять или двадцать лет. А вот кто и зачем может мешать оптимизировать проблемные места в линуксовом ядре и драйверах - не знаю.
EM>> Событие по схеме "сигнал-прерывание-драйвер-процесс" в одном
EM>> случае может быть передано процессу через 100 мкс, а в другом -
EM>> через 5 или 20 мс.
AV> Это вполне нормально.
Это нормально при быстродействии железа в десятки-сотни тысяч операций в секунду. При быстродействии в миллиарды - ненормально.
AV> Если тебе нужно гарантированное время отклика - ставь лошадьтроллер,
AV> который будет работать с оборудованием в realtime, а данными с
AV> системой обмениваться асинхронно.
И до какой степени система при этом сможет тормозить с откликом? :) 5 мс? 10? 20? 50? 100? :) Где тут граница между "вполне допустимо" и "ну, это уже безобразие", и почему? :)
EM>> в этих условиях ты не сможешь обеспечить бесперебойное
EM>> взаимодействие линуксового процесса с контроллером на интервалах,
EM>> меньших единиц-десятков миллисекунд.
AV> И не надо - это забота софта, работающего внутри лошадьтроллера.
Hу запихай в лошадьтроллер софт, реализующий в реальном времени гитарные эффекты, чтоб можно было играть на гитаре, рулить эффектами, петь, и все это записывать в цифру. Потом скажи, сколько времени оно делалось, и почем стоит купить. :) А для винды такого софта полно, и много бесплатного. Приходится повозиться с настройкой винды, чтобы убрать наиболее жестокие тормоза, но это один раз.
EM>> обработать разумное (максимум - сотни-тысячи в секунду) количество
EM>> событий максимально близко к моментам их возникновения.
AV> Это аппаратная задача и решать ее нужно аппаратными же средствами.
А когда быстродействие центральных процессоров достигнет, например, триллиона операций в секунду - это тоже будет "аппаратная задача для отдельного контроллера"? :) Или тогда в отдельном контроллере уже будет крутиться линукс, а критичный ко времени софт - в еще более отдельном? :)
Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)
--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: Fox Tracks, Servoz, France (2:5000/14)
|
