[algent 0]

Имхо, из ядра всё должно быть не сложно. В современных архитектурах в локальном APIC есть встроенный 32-битный таймер. Разрешающая способность там вроде очень высокая, лень смотреть ДШ. Ну только ISR не имеет права длиться дольше 20мкс, иначе бсод. Ну DPC и так далее... Мне кажется, для тонкого и аккуратного использования, всё реально. 

 

[gridinp 10]

В 09.08.2024 в 09:03, dxp сказал:

Бенчмарки можно где-нить увидеть?

https://lemariva.com/blog/2019/09/raspberry-pi-4b-preempt-rt-kernel-419y-performance-test

ну и у меня на rpi cm3+ с preempt_rt реакция в программе на прерывание укладывается в 100 мксек по осцилографу

Edited August 12, 2024 by gridinp

[sasamy 11]

On 8/12/2024 at 11:08 AM, gridinp said:

ну и у меня на rpi cm3+ с preempt_rt реакция в программе на прерывание укладывается в 100 мксек по осцилографу

есть специальные тестовые фермы с разными процессорами с полным описанием конфигурации как аппаратной так и програмной

https://www.osadl.org/Continuous-latency-monitoring.qa-farm-monitoring.0.html

[tegumay 5]

Существуют программные надстройки для винды и не только

которые обеспечивают реалтайм,

к сожалению видел лет 10 назад и не могу указать пруфы =\

[x893 76]

Для начала откройте своё понимание слова риалтайм, а потом уже можно и советов ожидать.

[tegumay 5]

если гарантированные 125 мкс реакции для вас не реалтайм, я молчу. это был семинар, где все разжевывалось под Win7. Там была реализация 2-in-1 одновременно работала подсистема ОСРВ и паралельно с ней на процессоре крутилась винда. Немного удивляет подход автора (управление потоком в реалтайме), но интересно почитать.

[Sh@dow 1]

Здраствуйте.

Сам сталкивался с проблемами когда винда не обеспечивала нужнные временные интервалы. 

В связи с этим хочи поделиться радикальной идеей о которой давно думал.

Пишем драйвер который все задачи выполняет а перед этим запрещаем переключения на другой контекст.

После завершения задачи восстанавляваем рабочее состояние системы.

Я понимаю что драйвера периферии с которой работаем это отдельные процессы и поэтому наш драфвер должен быть

монолитным. Тоесть сожержать в себе и код лля работы с периферией для воздействия с внешним миром.

Где бы почитать про такой радикальный подход?

[A.V.Avtomat 45]

36 минут назад, Sh@dow сказал:

Где бы почитать про такой радикальный подход?

MS-DOS или режим MS-DOS вполне обеспечат такой подход.

Современные компьютеры и Windows - нет.

А в чём идея-то? Windows 10 не даст так просто отключить все свои службы, процессы, программы и драйверы.

Это Вам не правила расстановки запятых игнорировать, над ней работали очень много умных дядек.

 

[khach 56]

Сечас многоядерность процессора  стала нормой. Существует ли возможность средствами API  винды захватить монопольно для своей задачи одно ядро? Понятно, что шину и  память захватить не получится, но все равно будет намного быстрее чем у  обычного планировщика.

[Sh@dow 1]

18 minutes ago, khach said:

Сечас многоядерность процессора  стала нормой. Существует ли возможность средствами API  винды захватить монопольно для своей задачи одно ядро? Понятно, что шину и  память захватить не получится, но все равно будет намного быстрее чем у  обычного планировщика.

SetThreadAffinityMask 

https://learn.microsoft.com/en-us/windows/win32/procthread/multiple-processors

Эта установка иногда дает серьезный прирост производительности.

Я кстате заметил что винда иногда перебрасывает потоки с одного ядра на другое.

Ходят легенды, чтоб ядра равномерно прогревались....

Edited November 1, 2024 by Sh@dow

[khach 56]

9 минут назад, Sh@dow сказал:

SetThreadAffinityMask 

Спасибо, когда знаешь как называется ключевой параметр, то и искать информацию  легче. Ну мелкомягкие и запихнули аж и IOT ...

https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/soft-real-time/soft-real-time-application

[dxp 112]

8 часов назад, Sh@dow сказал:

Я кстате заметил что винда иногда перебрасывает потоки с одного ядра на другое.

Ходят легенды, чтоб ядра равномерно прогревались....

Это обычное дело на современных многоядерниках -- SMP (Synchronous Multiprocessing), на всех, где есть аппаратная когерентность кешей L1. Это повышает производительность: например, одно ядро выполнляло поток (процесс), по логике программы нужно было остановить выполнение (ожидание события, слип и т.п.), далее это ядро переключилось на другой поток (процесс), в какой-то момент возникает событие, которое ждал тот прерванный поток (процесс), но выполнявшее его ядро в данный момент занято, и прерывать его будет неэффективно, а вместо этого пробуждающийся поток (процесс) подхватывает другое ядро -- за счёт когерентности кэшей оно сможет продолжить работу почти так же эффективно, как и то, которое выполняло поток первым.

[Sh@dow 1]

[QUOTE = A.V.Avtomat]

MS-DOS или режим MS-DOS вполне обеспечат такой подход.

Современные компьютеры и Windows - нет.

А в чём идея-то? Windows 10 не даст так просто отключить все свои службы, процессы, программы и драйверы.

[/QUOTE]

Так идея в том чтоб изменить алгоритм планировщика на некоторый период времени а потом вернуть все аккуратно 

обратно. Не вижу проблемы в принципе. Главное препятствие это то что алгоритм не только не задокументирован 

но и отсутствует публичный доступ к API планировщика.

Это уверен можно сделать в Linux правда надо серьезно погрузиться в код ядра.

По идее дальше всех в этом должны продвинуться высокочастотные торгаши на биржах.Это как раз то что им очень нужно. Попадались когда то публикации на эту тему но понятно что никто просто так не опубликует решение.

Автор поднял интересную тему но поскольку не указал чем собирается управлять то и ответа нет.

Хотя правильный ответ такой.Поскольку реалтайм это не про время а про гарантии а поскольку гарантий нет никаких то и windows для этого дела не пригоден.

 

[QUOTE = dxp]

Это обычное дело

[/QUOTE]

 

Спасибо.Это разумный подход со стороны разработчика.

Понятно почему microsoft не рекомендует вручную привязывать потоки. Чтоб не тормозить работу

других приложений.

Edited November 2, 2024 by Sh@dow

[tegumay 5]

как недавно я прочувствовал на себе.
если винда запускает виртуальную машину WinXP на энергоэфф. ядре она виснет,

если на обычном все нормально. Есть софт который XPx32 only T_T
 

[quаrk 35]

В 09.08.2024 в 09:43, novikovfb сказал:

Чем не подходит такой вариант: реалтайм сделать на подключенном внешнем микроконтроллере?

На самом деле, это единственно возможный вариант - внешний МК, имеющий со всеми управляемыми внешними устройствами прямые каналы связи, независимые от ПК. А между МК и ПК может быть, практически, любой канал связи, даже не обеспечивающий реал-тайм.

В этом случае, основная программа, обеспечивающая управление в реал-тайм режиме "крутится" на МК. А все задачи, не требующие реал-тайма, "сбрасываются" в ПК. Система получается, как бы, "вывернутой на изнанку", поскольку главным устройством (центральным процессором) в ней является МК, а ПК становится лишь подключенным к нему периферийным устройством, выполняющим запросы МК. Может ли в роли такого "внешнего МК" выступать отдельное ядро процессора ПК - это вопрос к специалистам. Кроме возможности монопольного захвата ядра отдельной задачей, нужно еще иметь отдельный внешний канал передачи информации (хотя бы один), независимый от всего остального железа и установленной ОС.

Собственно, такая связка (главный МК + подчиненный ПК) может являться относительно дешевой заменой полноценного компьютера, работающего в реал-тайм режиме, с реал-тайм ОС на борту. В этом случае, с помощью ПК эмулируется вся внешняя периферия такого компьютера, для которой не требуется реал-тайм. Однако, чтобы правильно запрограммировать такую систему, мозги программиста тоже придется "вывернуть наизнанку". В частности, например может периодически возникать желание "порулить" напрямую из ПК каким-либо периферийным реал-тайм устройством, что, данном случае, делать категорически нельзя.

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