[jcxz 224]

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

Какова максимальная возможная реалтаймовость не-GUI потока win-приложения на уровне пользователя (без разработки драйвера уровня ядра)?

Допустим: Имеем отдельный поток (для работы с железом). Без GUI-вызовов из него. И без блокировок потока при доступе к разделяемым ресурсам (предположим - вся межпоточная синхронизация выполняется неблокирующими методами: Interlocked...()-функциями, межпоточными асинхронными сообщениями, сигналами и т.п.). Поток работает только со своими данными и своими же (выделенными только ему) ресурсами.

Так вот - как обеспечить максимально возможную реалтаймовость этого потока? Т.е. - чтобы все события в нём происходили максимально точно по заданными времянкам. Если скажем нужно, чтобы поток получал управление каждые 20 мсек, с минимальным отклонением от этого интервала вне зависимости от прочих событий в системе? Какими средствами этого достичь? На обычном ПК, без каких-то аппаратных добавлений к нему и без доп.драйверов на уровне ядра. На виндах от XP до последних.

 

Рабочему потоку (о котором и идёт речь) выставлен высокий приоритет = THREAD_PRIORITY_TIME_CRITICAL. Временные интервалы пробую создавать двумя методами:

1. Мультимедиа-таймером: timeBeginPeriod(1)/timeEndPeriod(1). Разрешение (запрошенное и выданное) = 1ms. Из callback-функции ММ-таймера пинаю рабочий поток посылкой ему сигналов (SetEvent()).

2. Созданием отдельного высокоприоритетного потока (также THREAD_PRIORITY_TIME_CRITICAL). Который занимается только тем, что ложится спать на 20 ms, просыпаясь посылает сигнал (SetEvent()) рабочему потоку и снова ложится спать. Больше ничего не делает.

Но оба этих метода работают не очень хорошо.  Потестил программу в течение некоторого времени параллельно с обычной работой на двух разных ПК (ничего особенного - обычный набор программ: браузеры, компиляторы и т.п.) с разными win (Win7, Win11). Сделал сбор статистики периодичности вызовов функций пинания рабочего потока. Получаю такую картину:

С префикса "mmTimer" - статистика по вызовам мультимедиа-таймера. "Thread" - по вызовам из спец.потока. Статистика накоплена за время работы - немногим более часа.

3 столбца = минимальное/среднее/максимальное время между вызовами.

Как видно - разброс получился довольно значительный. Хоть ПК, на котором это работало - современный AMD Ryzen (6 ядер / 12 потоков) и не загружен особо. Почему так?  

Причём (как видно) - "Thread"-метод довольно хорошо держит нижнюю границу (отклонение менее 1 ms). Но зато - плохо держит верхнюю границу. Иногда возникают какие-то задержки аж на почти 70ms сверх положенного! Да и в среднем - отклонение больше, чем у ММ-таймера.

А мультимедиа-таймер лучше держит средний интервал, но очень плохо - нижний интервал (а это самый критичный для меня параметр). Причём - это в данном запуске теста нижний интервал упал всего до ~8.2 ms. В другом запуске на другом ПК он падал ещё ниже.

 

Так вот: Может кто подсказать ещё другие способы получения событий потоку (пинания потока) в Win с более высокой точностью/стабильностью? Пинания с обычного уровня пользовательского приложения. Кроме двух вышеприведённых испытываемых.

 

PS: Все данные измерений времени получены от службы аппаратного таймера - QueryPerformanceFrequency()/QueryPerformanceCounter(). Поэтому думаю - достоверны.

[_pv 64]

Как-то очень давно в 7 или даже XP, опрашивал параллельным ещё портом какой-то микрометр с ~2кГц последовательным интерфейсом, через тупой опрос inp(), драйверами параллельного порта от avreal.

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

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

я бы вот сюда ещё бы посмотрел: https://learn.microsoft.com/en-us/windows/win32/procthread/multimedia-class-scheduler-service

 

[pyroman 2]

Как пишут в интернетах - точность системного таймера не влияет на работу планировщика задач Windows. Поэтому это нереально, имхо.

[dxp 56]

5 копеек. На толстых ОС типа венды или линуха добиться реалтаймовости в смысле гарантии времени реакции на события в общем случае, имхо, малореально. Там масса внешних факторов, которые влияют на это, а планировщик не позволяет их купировать. Поэтому, наверное, самым действенным способом как-то улучшить реалтаймовость -- это минимизировать влияние этих факторов. 

Основные меры: уменьшить количество процессов до минимума, использовать как можно более древние версии -- вплоть до XP (если, конечно, это возможно). Ну, и проц наоборот -- поновее. Если ещё руками как-то распределить процессы по ядрам, указав для реалтаймового отдельное, чтобы только он там выполнялся (и кэш не портили другие процессы), но насколько это реализуемо, не ведаю.

[tonyk_av 39]

17 hours ago, jcxz said:

Какова максимальная возможная реалтаймовость

Тут как с беременностью: нельзя быть чуть-чуть беременной. Рилтайм он или есть, или его нет. Нужно реальное время- используйте ОСРВ, например, QNX.

 

[makc 213]

2 часа назад, dxp сказал:

5 копеек. На толстых ОС типа венды или линуха добиться реалтаймовости в смысле гарантии времени реакции на события в общем случае, имхо, малореально.

Мои 5 копеек. Вы https://archive.kernel.org/oldwiki/rt.wiki.kernel.org/ или https://wiki.linuxfoundation.org/realtime/start читали? Под виндой, согласен, печаль. Но в линуксе с патчами есть варианты.

[dxp 56]

1 час назад, makc сказал:

Но в линуксе с патчами есть варианты.

Бенчмарки можно где-нить увидеть? То, что патчи что-то улучшают, не сомневаюсь. Вопрос на сколько и за счёт чего. Как правило подобные патчи -- это костыли. Есть и более радикальный подход: https://xenomai.org, но это, имхо, уже не вполне линукс. 🙂

[makc 213]

2 минуты назад, dxp сказал:

Бенчмарки можно где-нить увидеть? То, что патчи что-то улучшают, не сомневаюсь. Вопрос на сколько и за счёт чего. Как правило подобные патчи -- это костыли. Есть и более радикальный подход: https://xenomai.org, но это, имхо, уже не вполне линукс. 🙂

LMGFY - https://habr.com/ru/articles/562636/

[_pv 64]

1 hour ago, makc said:

Под виндой, согласен, печаль. Но в линуксе с патчами есть варианты.

в виндах тоже есть варианты типа TwinCAT, но не бесплатно и не "без доп.драйверов на уровне ядра"

[makc 213]

5 минут назад, _pv сказал:

в виндах тоже есть варианты типа TwinCAT, но не бесплатно и не "без доп.драйверов на уровне ядра"

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

[dxp 56]

34 минуты назад, makc сказал:

LMGFY - https://habr.com/ru/articles/562636/

Цитата

Хотя среднее значение временного интервала особо не изменилось (510.8 мкс), но вот максимальное отклонение достигает 4524.4 мкс. Даже единичные случаи такой ошибки могут привести к плачевным результатам скажем в медицине или в оборонной промышленности. Такая система для наших задач уже не пригодна.

Вот том-то и дело. В среднем оно, вроде, гуд, потянет, но в каждом отдельном случае нет никакой гарантии, что не наступит задница. 

Кроме того, там в описании сказано, что во время теста активно копировались файлы, это не самая большая нагрузка. Интереснее было, если бы там видео лилось или трафик по сети на высокой скорости пёр. Подозреваю, что результат мог оказаться и похуже.

 

[novikovfb 17]

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

[makc 213]

4 минуты назад, dxp сказал:

Вот том-то и дело. В среднем оно, вроде, гуд, потянет, но в каждом отдельном случае нет никакой гарантии, что не наступит задница. 

В общем случае ни одно решение не идеально, хочется жёсткого риалтайма - ставим конечный автомат на ПЛИС и вперёд. 😉 Но для определённых задач даже такой вариант на Linux вполне себе неплохо себя показывает.

5 минут назад, dxp сказал:

Кроме того, там в описании сказано, что во время теста активно копировались файлы, это не самая большая нагрузка. Интереснее было, если бы там видео лилось или трафик по сети на высокой скорости пёр. Подозреваю, что результат мог оказаться и похуже.

Мы опять говорим про условия: смотря какая сеть и смотря какой диск. Или вы считаете, что интенсивность обмена с SSD (в среднем) будет выше интенсивности работы с сетью? Особенно учитывая то, что нормальные сетевые адаптеры умеют делать interrupt throttling?

[dxp 56]

1 минуту назад, makc сказал:

Или вы считаете, что интенсивность обмена с SSD (в среднем) будет выше интенсивности работы с сетью? Особенно учитывая то, что нормальные сетевые адаптеры умеют делать interrupt throttling?

В случае с SSD там этим аппаратура занимается по большей части. Копировать файлы -- там никакого интеллекта не надо, бери больше, кидай дальше. А с сетевым трафиком уже не так просто -- там надо ведь принятое от сетёвки успевать пережёвывать, каждый пакетик -- skbuf создай, через netfilter пропусти и т.п., и это всё программно, там нагрузка на CPU возрастает кратно, особенно, если не "бытовой" трафик, а серверный (мне довелось немножко поработать с этим со стороны железа). Особенно вилы наступают, когда валится много мелких пакетов. 

В целом, тема понятна. Всё сводится к тому. подходит ли то или иное решение в конкретной ситуации или нет.

[makc 213]

11 минут назад, dxp сказал:

В случае с SSD там этим аппаратура занимается по большей части. Копировать файлы -- там никакого интеллекта не надо, бери больше, кидай дальше.

Т.е. прерываний там по вашему мнению там нет? Копирования блоков памяти из пространства ядра (буферов DMA) в пространство пользователя тоже нет? А всё это кушает ресурсы процессора довольно сильно. 

12 минут назад, dxp сказал:

А с сетевым трафиком уже не так просто -- там надо ведь принятое от сетёвки успевать пережёвывать, каждый пакетик -- skbuf создай, через netfilter пропусти и т.п., и это всё программно, там нагрузка на CPU возрастает кратно, особенно, если не "бытовой" трафик, а серверный (мне довелось немножко поработать с этим со стороны железа). Особенно вилы наступают, когда валится много мелких пакетов. 

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

13 минут назад, dxp сказал:

В целом, тема понятна. Всё сводится к тому. подходит ли то или иное решение в конкретной ситуации или нет.

Скорее речь о том, как правильно собрать и сконфигурировать систему (включая ОС), чтобы результат отвечал требованиями. "Всё есть яд и всё есть лекарство. Только доза делает лекарство ядом и яд лекарством" (с) Парацельс.