Практическое руководство: soft real-time на обычной Windows

Когда на Windows делают обработку, для которой «опоздать нельзя» — периодическую, аудио, видео, измерения, управление оборудованием, — часто складывается впечатление, что «на Windows это тяжело». Впечатление верно наполовину: Windows не hard real-time ОС, но если довести проектирование, реализацию, измерения и эксплуатацию, систему можно вывести в вполне рабочее состояние soft real-time.

В статье речь про обычную Windows 10 / 11 — без специальных расширений RTOS, своих драйверов ядра и выделенных контроллеров. Это практический разговор о том, насколько далеко можно сжать задержку и джиттер user-mode приложением на обычном настольном или портативном ПК. У аудио, видео, периодического управления и сбора данных детали разные, но узкие места во многом общие, поэтому общая часть собрана в виде чек-листа.

Для кого статья и на каком языке примеры

Текст рассчитан на разработчиков, которые на Windows делают обработку, для которой «опоздать нельзя» (периодическое управление, аудио и видео, измерения, управление оборудованием). Предполагается разработка user-mode приложений; реализация драйверов режима ядра за рамками статьи.

Языки примеров кода разделены так.

Разбор причин в главах 1–3 и сам чек-лист главы 4 от языка не зависят. Если вы пишете только на C#, примеры на C++ достаточно читать как «какой API и в каком порядке вызывать».

Содержание

1. Сначала вывод (коротко)
   • 1.1. Таблица по диапазонам периода (с какого раздела начинать)
2. Что на обычной Windows называется «soft real-time»
   • 2.1. Что в статье значит «обычная Windows»
   • 2.2. Что получается и где начинается трудность
   • 2.3. Сначала коротко о терминах
3. Основные причины задержки и джиттера
   • 3.1. Планировщик и приоритеты
   • 3.2. DPC / ISR и драйверы
   • 3.3. Page fault и память
   • 3.4. Разрешение таймера и управление питанием
   • 3.5. Миграция между ядрами и нагрев
4. Практический чек-лист, как на обычной Windows уменьшить опоздания
   • 4.1. Периодический цикл и способ ожидания
   • 4.2. fast path / slow path и очередь фиксированной длины
   • 4.3. Приоритеты / MMCSS / background mode
   • 4.4. Память / GC / стоимость первого запуска
   • 4.5. Питание / EcoQoS / разрешение таймера
   • 4.6. Размещение по CPU / миграция между ядрами / нагрев
   • 4.7. Как отличить драйверы / DPC / ISR / внешние помехи
5. Измерение и оценка
   • 5.1. Что записывать
   • 5.2. Как читать p99 / p99.9 / max
   • 5.3. Чем смотреть
   • 5.4. Как тестировать
6. Как выбрать подход
7. Итог
8. Источники

Карта знаний этой статьи

Чтобы целиться в soft real-time на обычной Windows, не требуют hard real-time с гарантией нуля нарушений дедлайна, а проектируют так, чтобы задержка и jitter были малы и система не ломалась, даже если дедлайн сорван. Периодическое ожидание опирают на измерение через QueryPerformanceCounter и высокоточный waitable timer; разрешение таймера поднимают timeBeginPeriod только на нужное время. Если явно не снять понижение до EcoQoS и игнорирование разрешения таймера из-за Power Throttling, это вместе с DPC/ISR, ошибками страниц и thermal throttling становится ещё одной причиной роста jitter. В непрерывной обработке вроде звука и видео MMCSS предотвращает просрочку дедлайна приоритетным выделением ЦП; размещение по ЦП лучше сначала пробовать мягким назначением вроде CPU Sets, а не сразу жёсткой привязкой с высоким приоритетом; причину отделяют через WPR/WPA и LatencyMon.

flowchart LR
    accTitle: Карта знаний: soft real-time на обычной Windows
    accDescr: Схема связи waitable timer и MMCSS, которые поддерживают soft real-time; связи Power Throttling и EcoQoS; путей, по которым DPC/ISR и ошибки страниц порождают jitter; ступеней от CPU Sets к привязке ЦП; и связи WPR/WPA и LatencyMon как средств измерения.
    soft_realtime["мягкое реальное время (soft real-time)"]
    qpc["QPC (QueryPerformanceCounter)"]
    waitable_timer["waitable timer"]
    timebeginperiod["timeBeginPeriod (запрос разрешения таймера)"]
    power_throttling["Power Throttling (регулировка питания)"]
    ecoqos["EcoQoS"]
    jitter["джиттер (jitter)"]
    mmcss["MMCSS (Multimedia Class Scheduler Service)"]
    deadline_miss["пропуск дедлайна (deadline miss)"]
    thread_priority_class["приоритет потока / класс приоритета"]
    cpu_sets["CPU Sets"]
    cpu_affinity["CPU affinity (привязка к процессорам)"]
    thermal_throttling["тепловой троттлинг"]
    dpc_isr["DPC/ISR"]
    page_fault["ошибка страницы"]
    wpr_wpa["WPR/WPA (Windows Performance Recorder/Analyzer)"]
    latencymon["LatencyMon"]
    soft_realtime -.->|"использует"| qpc
    soft_realtime -.->|"использует"| waitable_timer
    soft_realtime -.->|"использует"| timebeginperiod
    power_throttling -.->|"несовместимо с"| timebeginperiod
    soft_realtime -.->|"использует"| power_throttling
    power_throttling -.->|"предотвращает"| ecoqos
    ecoqos -.->|"может вызвать"| jitter
    soft_realtime -.->|"использует"| mmcss
    mmcss -->|"снижает"| jitter
    mmcss -->|"снижает"| deadline_miss
    thread_priority_class -.->|"может вызвать"| jitter
    thread_priority_class -->|"не рекомендуется"| soft_realtime
    soft_realtime -.->|"использует"| cpu_sets
    cpu_sets -->|"должен предшествовать"| cpu_affinity
    thermal_throttling -.->|"может вызвать"| jitter
    dpc_isr -.->|"может вызвать"| jitter
    page_fault -.->|"может вызвать"| jitter
    dpc_isr -->|"проверяется"| wpr_wpa
    dpc_isr -->|"проверяется"| latencymon
    page_fault -->|"проверяется"| wpr_wpa

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 20, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

1. Сначала вывод (коротко)

• На обычной Windows цель — не гарантия hard real-time, а конфигурация soft real-time: «реже опаздывать и не ломаться, даже если опоздали».
• Сильнее всего работает короткий, фиксированной длины и неблокирующий hot path.
• Fast path (съём / управление) и slow path (сохранение / связь / UI) разделяют, а между ними ставят очередь фиксированной длины.
• Периодический цикл ведут не через Sleep(1), а по абсолютному сроку.
• Для непрерывных потоков вроде аудио и видео сначала смотрят MMCSS.
• Время измеряют QueryPerformanceCounter (QPC); в .NET — Stopwatch.
• Ждут событие устройства или высокоточный waitable timer.
• timeBeginPeriod включают только на время необходимости. Не проектируют так, будто он всегда включён.
• В реальной эксплуатации помогают питание от сети / режим питания / обращение с EcoQoS / уборка фоновой нагрузки.
• Оценивают не только среднее, а p99 (граница, где из 100 измерений начинает быть видно самое медленное) / p99.9 / max / число пропусков / DPC / ISR / page fault / глубину очереди.

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

flowchart TB
    accTitle: Устойчивость даёт проектирование, а не приоритет
    accDescr: Сильнее всего работает короткий, фиксированной длины и неблокирующий hot path, который срезает причины опоздания ещё на уровне проекта; приоритеты и питание важны, но одни они устойчивости не создают.
    hot["Hot path короткий и фиксированной длины"] --> less["Причин опоздания в проекте становится меньше"]
    less --> goal["Реже опаздывает и не ломается при опоздании"]
    prio["Настройка приоритетов и питания"] -.-> goal
    prio -.-> note["Важно, но одного этого мало"]

Рис. 1: Сильнее всего работает не настройка приоритетов, а то, что причины опоздания срезают ещё в проекте.

1.1. Таблица по диапазонам периода (с какого раздела начинать)

Статья длинная, поэтому сначала таблица, чтобы можно было читать только свою строку. Раньше этот материал стоял в конце (глава 6); его перенесли сюда.

Локализация причин и дисциплина измерений общие для любого диапазона (главы 3 и 5).

2. Что на обычной Windows называется «soft real-time»

2.1. Что в статье значит «обычная Windows»

Обычная Windows здесь примерно означает следующее.

• обычный настольный или портативный ПК с Windows 10 / 11
• без своего расширения RTOS
• без разработки своих драйверов режима ядра
• обычное user-mode приложение
• настройка штатными Windows API и параметрами

То есть это не разговор про «собрать отдельную машину целиком под управление реальным временем», а про то, насколько реалистично можно сжать поведение на обычном Windows-ПК.

flowchart LR
    A["Обычный ПК с Windows 10 / 11"] --> B["User-mode приложение"]
    B --> C["Цель — soft real-time"]
    C --> D["Снизить задержку"]
    C --> E["Уменьшить джиттер"]
    C --> F["Наблюдать missed deadline и не ломаться"]
    G["Нужна гарантия нуля нарушений срока"] -.-> H["RTOS / выделенный контроллер / FPGA / обработка на стороне устройства"]

Рис. 2: User-mode приложение на обычной Windows целится в soft real-time; гарантия нуля нарушений срока — область RTOS и соседних средств.

2.2. Что получается и где начинается трудность

Даже на обычной Windows для такой обработки вполне реалистично получить состояние «редко опаздывает».

• периодическая обработка с шагом от нескольких миллисекунд до нескольких десятков миллисекунд
• буферный режим аудио / видео
• съём с датчиков и контур управления
• периодическая обработка в духе программного ПЛК
• конвейер с низкой задержкой в отдельном от UI потоке

Но «можно» здесь не значит, что редкие всплески задержки удастся обнулить. Цель такая.

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

Наоборот, следующие требования одним user-mode на обычной Windows закрыть уже довольно тяжело.

• гарантировать ноль нарушений срока
• много часов стабильно держать интервалы ниже нескольких сотен микросекунд
• жить рядом с тяжёлым GUI, сетью и хранилищем
• делать это от батареи или с приоритетом энергосбережения
• не допускать даже всплесков от драйверов и устройств

В таких случаях безопаснее вынести только действительно жёсткий по времени участок на прошивку устройства, выделенный контроллер, FPGA или RTOS.

flowchart TB
    accTitle: Что даёт soft real-time и когда выносить наружу
    accDescr: На обычной Windows цель — низкая задержка в обычном режиме, меньший джиттер, устойчивость при редком пропуске срока и наблюдаемость этого пропуска; жёсткие требования вроде нуля нарушений срока выносят только из критичного по времени участка.
    aim["Состояние, к которому идёт soft real-time"] --> s1["Низкая задержка в обычном режиме"]
    aim --> s2["Меньший джиттер"]
    aim --> s3["При пропуске не ломается и это видно"]
    strict["Требование нуля нарушений срока"] -.-> out["Вынести на устройство или RTOS"]

Рис. 3: «Можно» — не ноль всплесков, а состояние «реже опаздывает, не ломается, пропускаемое видно».

2.3. Сначала коротко о терминах

Сначала зафиксируем смысл терминов, которые встречаются в статье.

3. Основные причины задержки и джиттера

Причины, по которым периодическая обработка на обычной Windows опаздывает, почти всегда сводятся к одной из ветвей этой схемы.

flowchart TD
    Late["Периодическая обработка опаздывает"] --> S["Планировщик / приоритеты"]
    Late --> D["DPC / ISR / драйверы"]
    Late --> M["Page fault / память"]
    Late --> T["Разрешение таймера / питание"]
    Late --> C["Миграция между ядрами / нагрев"]

Рис. 4: Причины опоздания периодической обработки сводятся к пяти ветвям: планировщик, DPC/ISR, память, таймер и питание, миграция ядер и нагрев.

3.1. Планировщик и приоритеты

Порядок выполнения потоков Windows задаёт приоритет. При равном приоритете потоки идут по кругу (round-robin); когда готов поток с более высоким приоритетом, поток с более низким отодвигают.

То есть даже если периодический поток написан аккуратно, раньше него вполне обычны:

• другие потоки
• другие процессы
• внутренняя обработка ОС
• продукты безопасности
• вспомогательная обработка устройств
• фоновая синхронизация

flowchart TB
    accTitle: Как приоритетное планирование отодвигает поток
    accDescr: Потоки с одинаковым приоритетом идут round-robin, а более высокий готовый приоритет отодвигает более низкий; поэтому перед периодическим потоком вполне обычны другие процессы и внутренняя обработка ОС.
    same["Одинаковый приоритет"] --> rr["По очереди, round-robin"]
    high["Готов более высокий приоритет"] --> push["Более низкий отодвигают"]
    push -.-> who["Другие процессы, внутренняя обработка ОС и т. п."]

Рис. 5: Даже аккуратно написанный периодический поток вполне может уступить работу с более высоким приоритетом.

3.2. DPC / ISR и драйверы

Этот момент довольно важен. Даже если приоритеты на стороне приложения приведены в порядок, пока длинные DPC (Deferred Procedure Call) или ISR (Interrupt Service Routine), user-mode поток выполняться не может.

Частыми источниками становятся такие устройства и драйверы:

• USB
• Wi-Fi / Bluetooth
• хранилище
• аудио
• GPU
• ACPI / питание

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

flowchart TB
    accTitle: Как DPC и ISR останавливают user-mode
    accDescr: Пока длинные ISR и DPC устройств вроде USB, Wi-Fi и GPU идут в ядре, user-mode поток не выполняется; поднять приоритет приложения недостаточно, чтобы это выиграть.
    dev["Устройства вроде USB, Wi-Fi, GPU"] --> kern["ISR и DPC идут в ядре"]
    kern --> block["Пока они идут, user-mode не выполняется"]
    block -.-> note["Повышение приоритета это не выигрывает"]

Рис. 6: Даже если код приложения не виноват, user-mode могут остановить драйвер или железо.

3.3. Page fault и память

Если в hot path случается page fault (нужной страницы нет в памяти, её приходится подгружать), задержка резко растёт.

Особенно стоит избегать таких паттернов:

• commit страницы при первом обращении
• отложенная загрузка
• page-in memory-mapped файлов
• динамические выделения сверх необходимого
• большие объекты или фрагментированная куча

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

flowchart TB
    accTitle: Задержка из-за page fault в hot path
    accDescr: Если страница, к которой обратились в hot path, не в памяти, её подгружают через page fault и задержка резко растёт; поэтому нужную память выделяют заранее и один раз касаются при запуске.
    touch["Hot path обращается к памяти"] --> q{"Страница уже в памяти?"}
    q -->|"да"| ok["Идём дальше"]
    q -->|"нет"| pf["Подгрузка через page fault"]
    pf --> spike["Задержка резко растёт"]
    pf -.-> fix["Выделить заранее и один раз коснуться при запуске"]

Рис. 7: Задержка скачет в зависимости от того, случился page fault или нет. Мера — предварительное выделение и прогрев при запуске.

3.4. Разрешение таймера и управление питанием

«Хочу раз в 1 мс, поэтому Sleep(1)» почти никогда не срабатывает. Точность ожидания в Windows зависит от разрешения таймера, планирования и состояния питания.

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

3.5. Миграция между ядрами и нагрев

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

При долгой работе нельзя игнорировать и нагрев. Когда включается thermal throttling, ранее стабильный период может разъехаться.

flowchart TB
    accTitle: Как миграция ядер и нагрев ломают период
    accDescr: Миграция потока между ядрами заставляет кеш прогреваться заново и при высокой нагрузке даёт колебания; при долгой работе нагрев включает thermal throttling и ранее стабильный период разъезжается.
    move["Поток мигрирует между ядрами"] --> cache["Кеш прогревается заново"]
    cache --> jitter["При высокой нагрузке это источник колебаний"]
    heat["При долгой работе копится тепло"] --> thr["Thermal throttling"]
    thr --> broke["Ранее стабильный период разъезжается"]

Рис. 8: Миграция ядер бьёт джиттером, нагрев — троттлингом; оба съедают устойчивость долгой работы.

4. Практический чек-лист, как на обычной Windows уменьшить опоздания

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

4.1. Периодический цикл и способ ожидания

Сначала типичный антипаттерн.

while (running)
{
    Sleep(1);
    Step();
}

Это не «период 1 мс», а цикл, который обычно ждёт не меньше примерно 1 мс, а сверху добавляет время Step(). Перерасход ожидания при этом накапливается как есть.

flowchart LR
    subgraph Bad["От относительного времени"]
        B1["Sleep(1)"] --> B2["Step()"]
        B2 --> B1
    end
    B2 --> B3["Ошибка ожидания и время выполнения понемногу копится"]

    subgraph Good["От абсолютного срока"]
        G1["next += period"] --> G2["WaitUntil(next - margin)"]
        G2 --> G3["При необходимости короткий spin"]
        G3 --> G4["FastStep()"]
        G4 --> G1
    end
    G4 --> G5["Дрейф копится хуже"]

Рис. 9: Цикл от Sleep(1) копит ошибку; цикл по абсолютному сроку дрейф копит хуже.

Чек-лист

• Периодический цикл не построен на Sleep(1)
• Период ведут по абсолютному сроку next += period
• Для ожидания предпочитают событие устройства или waitable timer
• Только финальную подстройку ограничивают очень коротким busy-spin
• timeBeginPeriod включают только на время необходимости и потом возвращают
• Поведение проверено и в свёрнутом / скрытом / невидимом состоянии

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

int64_t next = QpcNow() + periodTicks;

while (running)
{
    WaitUntil(next - wakeMarginTicks);

    while (QpcNow() < next)
    {
        CpuRelax(); // Короткий spin только в самом конце
    }

    int64_t started = QpcNow();
    FastStep();
    int64_t finished = QpcNow();

    RecordTiming(next, started, finished);

    next += periodTicks;

    while (finished > next)
    {
        ++missedDeadlines;
        next += periodTicks;
    }
}

4.2. fast path / slow path и очередь фиксированной длины

Основа архитектуры — в fast path оставлять только работу, чувствительную к сроку, остальное выносить в slow path.

flowchart LR
    Input["Устройство / события съёма"] --> Fast["fast path: съём, управление, минимум копирования"]
    Fast --> Queue["Очередь фиксированной длины"]
    Queue --> Slow["slow path: сохранение, отправка, UI, агрегация"]
    Fast --> Metrics["Запись lateness / miss / глубины очереди"]
    Metrics --> Slow

Рис. 10: В fast path оставляют только работу, чувствительную к сроку, и через очередь фиксированной длины выносят её в slow path.

В fast path оставляют примерно это.

• съём данных
• расчёт управляющих значений
• минимально необходимое копирование
• временная метка
• постановка в очередь
• запись miss / overrun

Всё остальное сбрасывают в slow path.

Чек-лист

• В hot path нет записи в файл, сетевой отправки, записи в БД
• В hot path нет тяжёлого логирования, Flush, синхронного RPC
• fast path и slow path явно разведены по потокам или ролям
• Очередь фиксированной длины
• Политика при переполнении очереди решена заранее
• Наблюдают число miss, число drop и глубину очереди
• Обновление UI и агрегация логов вынесены в более редкий цикл

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

flowchart TD
    Overflow["Очередь заполнена"] --> Policy{"Что бережём?"}
    Policy -->|Важно последнее значение| Latest["Выбросить старое, оставить последнее"]
    Policy -->|Важна каждая запись| All["Оповещение / остановка / управление вверх по потоку"]
    Policy -->|Для логов| Log["Выбросить старое, фиксировать только число drop"]

Рис. 11: Что беречь при заполненной очереди, решают заранее — в зависимости от назначения.

4.3. Приоритеты / MMCSS / background mode

Базовое правило приоритетов — не поднимать всё подряд. На обычной Windows лучше работает схема «поднять только важный поток, фоновую работу честно опустить». Background mode — механизм, который склоняет к низкому приоритету не только CPU, но и такие ресурсы, как I/O.

flowchart TD
    Work["Разделить работу"] --> Critical["Потоки, чувствительные к сроку"]
    Work --> Worker["Сохранение / отправка / сжатие / агрегация"]
    Work --> UI["UI"]
    Critical --> P1["При необходимости повышенный приоритет или MMCSS"]
    Worker --> P2["background mode / пониженный приоритет"]
    UI --> P3["Обычный приоритет"]
    P1 --> Warn["Не начинать сразу с REALTIME_PRIORITY_CLASS"]

Рис. 12: Как распределять приоритеты: поднимают только чувствительные к сроку потоки, фоновую работу честно опускают.

Чек-лист

• Не все потоки стоят на высоком приоритете
• Подняты только потоки, которым время действительно критично
• Фоновая работа — сохранение, отправка, сжатие, синхронизация — уведена в background mode
• Для непрерывной буферной обработки (аудио, видео, захват, воспроизведение) рассматривается MMCSS
• Мыслят сначала потоками, а не процессом целиком
• REALTIME_PRIORITY_CLASS не используют, пока необходимость не стала явной

MMCSS (Multimedia Class Scheduler Service) особенно полезен для обработки вроде аудио / видео, где нужно за фиксированное время заполнить буфер. Это лучше согласуется с устройством Windows, чем постоянно крутить поток с высоким приоритетом.

По коду это выглядит примерно так.

DWORD taskIndex = 0;
HANDLE avrt = AvSetMmThreadCharacteristicsW(L"Pro Audio", &taskIndex);
if (!avrt)
{
    throw std::runtime_error("AvSetMmThreadCharacteristicsW failed");
}

// Крутим цикл, чувствительный ко времени

if (!AvRevertMmThreadCharacteristics(avrt))
{
    throw std::runtime_error("AvRevertMmThreadCharacteristics failed");
}

flowchart TB
    accTitle: Регистрация потока в MMCSS и снятие
    accDescr: Перед чувствительным ко времени циклом поток регистрируют в MMCSS через AvSetMmThreadCharacteristicsW и после цикла возвращают через AvRevertMmThreadCharacteristics; MMCSS отдаёт CPU чувствительной ко времени обработке.
    reg["AvSetMmThreadCharacteristicsW"] --> loop["Крутим цикл, чувствительный ко времени"]
    loop --> rev["AvRevertMmThreadCharacteristics"]
    reg -.-> mm["MMCSS отдаёт CPU в приоритетном порядке"]

Рис. 13: MMCSS берут парой регистрация / снятие. Для непрерывной буферной обработки это ближе к устройству Windows, чем постоянно высокий приоритет.

4.4. Память / GC / стоимость первого запуска

Если в hot path на каждом шаге делать new / malloc / List<T>.Add / склейку строк / LINQ, рано или поздно наружу вылезут сборка мусора и переезд блоков. Сама GC не зло, но код с частыми выделениями проявляет это как джиттер.

flowchart LR
    Start["Запуск"] --> Alloc["Выделить нужные буферы"]
    Alloc --> Touch["Один раз коснуться, чтобы прогреть страницы"]
    Touch --> Warm["Закрыть JIT / загрузку DLL / первый I/O"]
    Warm --> Measure["Потом — боевые измерения / боевая работа"]

Рис. 14: При запуске выделяют буферы, прогревают страницы и закрывают стоимость первого запуска — и только потом идут в боевые измерения и работу.

Чек-лист

• В hot path нет выделения / освобождения памяти на каждом шаге
• Нужные буферы выделены заранее при запуске
• При запуске страницы один раз прогреты обращением
• Первый JIT, первая загрузка DLL, первый I/O не попадают в боевые измерения
• В цикле не растут огромные структуры или логи переменной длины
• Если VirtualLock всё же используется, то только на очень маленькой критической области

Проверки для .NET

• Время измеряют Stopwatch / Stopwatch.GetTimestamp()
• В hot path нет LINQ, склейки строк, ToString(), генерации огромных логов
• async/await не заносят в hot path
• Оценку до и после прогрева ведут раздельно

4.5. Питание / EcoQoS / разрешение таймера

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

flowchart TD
    Power["Питание на обычной Windows"] --> AC["Работать от сети"]
    Power --> Mode["Режим питания: ближе к максимальной производительности"]
    Power --> Plan["При необходимости — отдельный план питания для боя"]
    Power --> QoS["Чувствительные ко времени процессы держать вне EcoQoS"]
    Power --> Timer["Проверить, как обрабатывают запрос на разрешение таймера"]

Рис. 15: Что проверять вокруг питания: источник, режим, EcoQoS, обращение с запросом на разрешение таймера.

Чек-лист

• Боевую оценку сначала ведут при питании от сети
• [Параметры] > [Система] > [Питание и батарея] > [Режим питания] стоит ближе к максимальной производительности
• Во время работы не включены battery saver / режим с приоритетом экономии
• Проверены фирменные утилиты производителя — тихий / eco / battery-приоритетный режимы
• Чувствительные ко времени процессы ненароком не уведены в EcoQoS (QoS с уклоном в экономию)
• IGNORE_TIMER_RESOLUTION не включён у чувствительного ко времени процесса
• Проверено, не меняется ли действие запроса на разрешение таймера при сворачивании / скрытии окна
• Настройки питания для повседневной работы отделены от боевых / измерительных / демонстрационных

timeBeginPeriod полезен, если пользоваться им аккуратно, но это не панацея.

• вызывать непосредственно перед необходимостью
• по окончании возвращать через timeEndPeriod
• начиная с Windows 10 version 2004 поведение уже не настолько глобальное, как раньше
• в Windows 11 у процесса с окном, которое полностью скрыто / свёрнуто / не видно / не слышно, высокое разрешение может не гарантироваться
• повышение разрешения не поднимает точность QPC

Если подозреваете влияние питания или QoS, состояние power throttling проверяют через SetProcessInformation.

PROCESS_POWER_THROTTLING_STATE state{};
state.Version = PROCESS_POWER_THROTTLING_CURRENT_VERSION;
state.ControlMask =
    PROCESS_POWER_THROTTLING_EXECUTION_SPEED |
    PROCESS_POWER_THROTTLING_IGNORE_TIMER_RESOLUTION;
state.StateMask = 0; // HighQoS (ближе к производительности) + уважать запрос на разрешение таймера

if (!SetProcessInformation(
        GetCurrentProcess(),
        ProcessPowerThrottling,
        &state,
        sizeof(state)))
{
    throw std::runtime_error("SetProcessInformation failed");
}

ControlMask — «какими механизмами управляю сам», StateMask — «включить этот механизм или выключить». В примере выбраны оба механизма, и оба выключены. То есть это заявление: не уходить в EcoQoS (ближе к HighQoS) и не давать игнорировать запрос на разрешение таймера. Если поставить ControlMask в 0, оба снова отдаются ОС (поведение по умолчанию).

flowchart TB
    accTitle: Роль двух масок в настройке power throttling
    accDescr: ControlMask выбирает механизмы, которыми управляете сами, StateMask включает или выключает их; так можно заявить, что процесс не уходит в EcoQoS и что запрос на разрешение таймера нельзя игнорировать.
    cm["ControlMask выбирает, чем управлять"] --> sm["StateMask задаёт on и off"]
    sm --> r1["Заявление не уходить в EcoQoS"]
    sm --> r2["Не давать игнорировать запрос на разрешение таймера"]
    cm -.-> zero["ControlMask = 0 возвращает решение ОС"]

Рис. 16: Роль двух масок SetProcessInformation. Сначала выбирают, чем управлять, потом заявляют on / off.

Вызов из C#

То же самое из C# объявляют через P/Invoke так.

// C# / .NET 8
using System.Runtime.InteropServices;

internal static class PowerQos
{
    [StructLayout(LayoutKind.Sequential)]
    private struct PROCESS_POWER_THROTTLING_STATE
    {
        public uint Version;
        public uint ControlMask;
        public uint StateMask;
    }

    private const uint PROCESS_POWER_THROTTLING_CURRENT_VERSION = 1;
    private const uint PROCESS_POWER_THROTTLING_EXECUTION_SPEED = 0x1;
    private const uint PROCESS_POWER_THROTTLING_IGNORE_TIMER_RESOLUTION = 0x4;

    // ProcessPowerThrottling — 5-й элемент PROCESS_INFORMATION_CLASS (с нуля это 4)
    private const int ProcessPowerThrottling = 4;

    [DllImport("kernel32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    private static extern bool SetProcessInformation(
        IntPtr hProcess,
        int processInformationClass,
        ref PROCESS_POWER_THROTTLING_STATE processInformation,
        uint processInformationSize);

    [DllImport("kernel32.dll")]
    private static extern IntPtr GetCurrentProcess();

    /// <summary>Снимает и энергосберегающее обращение, и игнорирование запроса на разрешение таймера.</summary>
    public static void OptOutOfPowerThrottling()
    {
        var state = new PROCESS_POWER_THROTTLING_STATE
        {
            Version = PROCESS_POWER_THROTTLING_CURRENT_VERSION,
            ControlMask =
                PROCESS_POWER_THROTTLING_EXECUTION_SPEED |
                PROCESS_POWER_THROTTLING_IGNORE_TIMER_RESOLUTION,
            StateMask = 0,
        };

        if (!SetProcessInformation(
                GetCurrentProcess(),
                ProcessPowerThrottling,
                ref state,
                (uint)Marshal.SizeOf<PROCESS_POWER_THROTTLING_STATE>()))
        {
            throw new System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error());
        }
    }
}

Вызов: один раз PowerQos.OptOutOfPowerThrottling(); до старта чувствительного ко времени цикла. У handle процесса нужны права PROCESS_SET_INFORMATION; псевдо-handle своего процесса от GetCurrentProcess() этого достаточно.

4.6. Размещение по CPU / миграция между ядрами / нагрев

Размещение по CPU чаще лучше начинать не с резкой привязки к конкретным ядрам (hard affinity / CPU pinning), а с указания, близкого к soft affinity: «желательно работать преимущественно на этой группе ядер».

flowchart LR
    Measure["Сначала измерить"] --> Ideal["SetThreadIdealProcessor / CPU Sets"]
    Ideal --> Check{"Улучшение достаточное?"}
    Check -->|да| Keep["Остановиться на этом"]
    Check -->|нет| Hard["В последнюю очередь рассмотреть SetThreadAffinityMask"]
    Measure --> Therm["Параллельно смотреть температуру / частоту / долгую работу"]

Рис. 17: Размещение по CPU начинают с измерений, мягкого указания хватает — на нём останавливаются; привязка к конкретным ядрам — крайняя мера.

Чек-лист

• Размещение по CPU меняют только после измерения
• Нет резкой привязки к конкретным ядрам с самого начала
• Сначала пробуют SetThreadIdealProcessor или CPU Sets
• SetThreadAffinityMask рассматривают как крайнюю меру
• При долгой работе смотрят температуру, частоту, thermal throttling
• Проверены тихий режим и режим пониженного шума у портативных ПК

Порядок безопаснее такой.

1. сначала измерить
2. при необходимости — ideal processor / CPU Sets
3. если улучшение всё ещё нужно — привязка к конкретным ядрам

Привязка к конкретным ядрам выглядит сильной, но она сужает запасные пути ОС, поэтому при неосторожном использовании система, наоборот, становится менее гибкой.

4.7. Как отличить драйверы / DPC / ISR / внешние помехи

Когда «иногда взрывается только max» или «среднее хорошее, а p99.9 плохой», стоит подозревать и помехи за пределами кода приложения.

flowchart TD
    Spike["Появился всплеск late / miss / max"] --> Q1{"Своё время обработки тоже велико?"}
    Q1 -->|да| App["Укоротить hot path / урезать выделения / убрать I/O"]
    Q1 -->|нет| Q2{"Есть всплески DPC / ISR?"}
    Q2 -->|да| Driver["Проверить USB / Wi-Fi / Bluetooth / GPU / аудио / хранилище / ACPI / обновления драйверов"]
    Q2 -->|нет| Q3{"Есть page fault / GC / стоимость первого запуска?"}
    Q3 -->|да| Mem["Предварительное выделение / прогрев / снизить нагрузку на кучу"]
    Q3 -->|нет| Q4{"Есть влияние батареи / экономии / нагрева?"}
    Q4 -->|да| Pow["Питание от сети / настройки питания / охлаждение / длинные тесты"]
    Q4 -->|нет| ETW["Копать глубже через ETW / WPA / LatencyMon"]

Рис. 18: Порядок, в котором копают всплеск. Сначала своя обработка, затем DPC/ISR, память, питание и нагрев.

Чек-лист

• Проверены драйверы вокруг Wi-Fi / Bluetooth / USB / хранилища / GPU / аудио
• Сравнили с отключёнными ненужной облачной синхронизацией, индексированием, автообновлениями
• Проверили, разъезжается ли всё при сворачивании окна или выключении экрана
• Тенденции DPC / ISR смотрели через LatencyMon или ETW
• Раздельно смотрели, «моя обработка тяжёлая» или «меня останавливают снаружи»

5. Измерение и оценка

5.1. Что записывать

Как минимум стоит фиксировать следующее.

• запланированное время цикла
• фактическое время начала
• фактическое время окончания
• lateness (насколько позже запланированного начала фактически стартовали)
• время выполнения
• число missed deadline
• число подряд идущих missed deadline
• глубину очереди
• число drop
• загрузку CPU
• перекос по ядрам
• всплески DPC / ISR
• page fault
• колебания температуры / частоты

Одно среднее суть почти не показывает. В бою мешают как раз редкие крупные всплески задержки.

5.2. Как читать p99 / p99.9 / max

Показатели вроде p99 существуют, чтобы смотреть на медленный хвост. Если смотреть только среднее, редкие крупные задержки прячутся.

Например, пусть получился такой ряд (это пример, как читать показатели, а не замер на конкретном железе).

• среднее: 0,8 мс
• p99: 1,2 мс
• p99.9: 3,5 мс
• max: 28 мс

Это состояние «обычно быстро, но иногда бывает крупный всплеск». На обычной Windows настоящая проблема почти всегда вылезает в этом хвосте от p99 до max.

flowchart TB
    accTitle: Чем среднее отличается от показателей хвоста
    accDescr: Одно среднее прячет редкие крупные задержки; p99, p99.9 и max показывают медленный хвост, и на обычной Windows настоящая проблема как раз там.
    avg["Смотреть только среднее"] --> hide["Редкие крупные задержки прячутся"]
    tail["Смотреть p99, p99.9, max"] --> see["Виден медленный хвост"]
    see --> real["Настоящая проблема вылезает от p99 до max"]

Рис. 19: Хорошее среднее при скачущем max — это «обычно быстро, иногда скачет». Хвост ловят отдельными показателями.

В статье нет численных доказательств эффекта рекомендуемой конфигурации. Задержка и джиттер легко меняются от CPU, драйверов, резидентного ПО, питания и способа нагрузки, поэтому чужие цифры нельзя брать основанием для своей среды. Вместо этого ниже — минимальный порядок, как собрать такую же таблицу у себя.

Минимальный порядок, как получить p99 на своей машине

1. В hot path только записывают. Stopwatch.GetTimestamp() (в C++ — QueryPerformanceCounter) снимает lateness и время выполнения в заранее выделенный массив. Среднее и сортировку здесь считать нельзя
2. Останавливают измерение и только потом сводят. Сортируют и берут значение в позиции процентиля
3. Тот же порядок повторяют при смене условий. До и после прогрева, сеть / батарея, UI на переднем плане / свёрнут, с нагрузкой других процессов и без (5.4)
4. После каждого одиночного изменения снимают заново в тех же условиях и сравнивают

// C# / .NET 8. Сводку считают после остановки измерения
using System.Diagnostics;

// В hot path только пишем в массив (ноль выделений)
long[] latenessTicks = new long[100_000];
int count = 0;

// Пример внутри периодического цикла
// latenessTicks[count++] = Stopwatch.GetTimestamp() - scheduledTimestamp;

static double PercentileMs(long[] ticks, int count, double percentile)
{
    long[] sorted = ticks.AsSpan(0, count).ToArray();
    Array.Sort(sorted);

    int index = (int)Math.Ceiling(percentile / 100.0 * count) - 1;
    index = Math.Clamp(index, 0, count - 1);

    return sorted[index] * 1000.0 / Stopwatch.Frequency;
}

// Как пользоваться
// Console.WriteLine($"p50={PercentileMs(latenessTicks, count, 50):F3}ms");
// Console.WriteLine($"p99={PercentileMs(latenessTicks, count, 99):F3}ms");
// Console.WriteLine($"p99.9={PercentileMs(latenessTicks, count, 99.9):F3}ms");
// Console.WriteLine($"max={PercentileMs(latenessTicks, count, 100):F3}ms");

Stopwatch.Frequency — число отсчётов в секунду, поэтому после деления умножение на 1000 даёт миллисекунды. На малом числе выборок p99.9 бессмыслен. Если говорите про p99.9, соберите минимум 10 000 выборок (лучше 100 000).

5.3. Чем смотреть

Набор инструментов в целом известен.

• Измерение внутри приложения Сначала самим снять period / lateness / execution time / queue depth / drop
• ETW / WPR / WPA Копать CPU, context switch, DPC / ISR, page fault
• LatencyMon Наметить колебания от драйверов
• Мониторинг температуры / частоты Смотреть влияние нагрева

flowchart LR
    App["Измерение внутри приложения"] --> Dist["p50 / p95 / p99 / p99.9 / max"]
    App --> Miss["miss / drop / глубина очереди"]
    ETW["ETW / WPR / WPA"] --> Root["context switch / DPC / ISR / page fault"]
    Temp["Мониторинг температуры / частоты"] --> Root
    Dist --> Decide["Решить, что улучшать в первую очередь"]
    Miss --> Decide
    Root --> Decide

Рис. 20: Результаты измерения внутри приложения, ETW и мониторинга температуры сводят, чтобы решить, что улучшать в первую очередь.

Дойти до WPA несколько трудозатратно, но это весьма помогает отличить, виноваты DPC / ISR или просто своя обработка слишком тяжёлая.

Откуда брать и как пользоваться по минимуму

В WPA сначала смотрят среди графиков CPU время выполнения DPC / ISR и context switch. Там видно, какой драйвер держал CPU в те промежутки, когда ваш поток не мог работать; это сверяют с моментами задержки из 5.1.

Скриншотов экрана в статье нет. Внешний вид плавает от версии, поэтому пройдите шаги выше и смотрите на своей машине.

5.4. Как тестировать

Одного тихого стенда недостаточно. Как минимум эти условия стоит смотреть раздельно.

• сразу после запуска, до прогрева
• после прогрева
• долгая непрерывная работа
• UI на переднем плане
• UI свёрнут / состояние, близкое к скрытому
• питание от сети
• питание от батареи
• нагрузка на сеть или диск

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

flowchart TB
    accTitle: Зачем разводить условия теста
    accDescr: Оценка только на тихом стенде пропускает эксплуатационные проблемы, поэтому условия смотрят раздельно: до и после прогрева, долгая работа, UI на переднем плане и свёрнутый, питание от сети и от батареи, есть нагрузка или нет.
    bench["Оценка только на тихом стенде"] -.-> lose["Эксплуатационные проблемы пропускаются"]
    lose -.-> split["Оценивать по отдельным условиям"]
    split --> c1["Прогрев и долгая работа"]
    split --> c2["UI на переднем плане и свёрнутый"]
    split --> c3["Питание и нагрузка"]

Рис. 21: Обычная Windows тянется за тем, как ею пользуются. Оценку приближают к реальным условиям.

6. Как выбрать подход

Таблицу по диапазонам периода перенесли в 1.1, чтобы к ней можно было вернуться по ходу чтения. Здесь — два решения, которых одной таблицей не закрыть.

Когда решать, что «на обычной Windows уже не вытянуть»

Если нужно много часов под нагрузкой держать менее 1 мс, часто быстрее не продолжать крутить настройки, а вынести только жёсткий по времени участок. Кандидаты: прошивка устройства, выделенный контроллер, FPGA, RTOS. Решение опирают не на ощущение, а на цифры главы 5.

• hot path уже нельзя укоротить, а p99.9 и max всё равно выше требования
• виноваты внешние помехи (DPC / ISR, драйверы, другие процессы), и мерами на стороне приложения уже не достать (это подтверждают разбором из 4.7)
• требование уже не «если иногда сорвём — не ломаемся», а «нельзя сорвать ни разу»

Когда хочется держать всё в одном процессе

Если GUI, логи, связь и БД живут в одном цикле одного процесса, удобства хвоста ломают срок головы. Ожидание flush файла, переподключение БД, перерисовка UI легко растягиваются на десятки миллисекунд. Разделение fast path / slow path (4.2) можно расширить и до границ процессов. Если процессы разведены, голова продолжает крутить период, даже когда хвост завис.

flowchart TB
    accTitle: Совместное проживание против разведения по процессам
    accDescr: Если GUI, логи, связь и БД живут в одном цикле одного процесса, удобства хвоста ломают срок головы; если разделение fast path и slow path довести до процессов, голова продолжает крутить период, даже когда хвост завис.
    one["Всё в одном процессе и одном цикле"] --> broke["Удобства хвоста ломают срок головы"]
    broke -.-> ex["Ожидание flush, переподключение, перерисовка"]
    sep["Голову и хвост развести по процессам"] --> keep["Хвост завис — голова продолжает крутиться"]

Рис. 22: Если совместное проживание всё же нужно, разделение fast path / slow path можно довести до границ процессов.

7. Итог

Две предпосылки стоит зафиксировать.

• На обычной Windows цель — не гарантия hard real-time, а конфигурация soft real-time: меньшая задержка и джиттер и отсутствие поломки при нарушении срока
• Сильнее всего работает не настройка приоритетов, а наведение порядка в hot path

На стороне реализации работают такие вещи.

• разделить fast path и slow path
• очередь фиксированной длины и заранее решённая политика при переполнении
• измерять через QPC, ждать через событие / waitable timer
• в hot path избегать выделений, блокирующего I/O, тяжёлых блокировок

На стороне эксплуатации работают такие вещи.

• работать от сети
• держать отдельные настройки питания для боя
• убирать ненужную фоновую нагрузку
• оценивать по p99 / p99.9 / max и числу пропусков

Soft real-time на обычной Windows не определяется одними приоритетами: если раздельно довести проектирование, реализацию, питание, измерения и эксплуатацию, система может стать довольно устойчивой.

8. Источники

• Multimedia Class Scheduler Service
• AvSetMmThreadCharacteristicsW function
• SetThreadPriority function
• SetPriorityClass function
• timeBeginPeriod function
• CreateWaitableTimerExW function
• Acquiring high-resolution time stamps
• QueryPerformanceCounter function
• GetSystemTimePreciseAsFileTime function
• SetProcessInformation function
• VirtualLock function
• CPU Sets
• SetThreadIdealProcessor function
• SetThreadAffinityMask function
• Processor power management options
• Change the power mode for your Windows PC
• Power settings in Windows 11
• CPU Analysis (WPA / WPT)
• WPR Command-Line Options
• Download and install the Windows ADK
• Quality of Service (EcoQoS / HighQoS)
• PROCESS_POWER_THROTTLING_STATE structure
• LatencyMon - Resplendence Software

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Можно ли делать обработку реального времени на Windows?

Гарантировать hard real-time (ноль нарушений срока) нельзя. Но если довести проектирование, реализацию, измерения и эксплуатацию, систему можно вывести в вполне рабочее состояние soft real-time. Периодическая обработка с шагом от нескольких миллисекунд до нескольких десятков миллисекунд, буферный режим для аудио/видео, съём с датчиков и контур управления на обычной Windows 10/11 реалистичны. Если же нужна гарантия нуля нарушений срока или многочасовая устойчивость ниже нескольких сотен микросекунд, стоит смотреть в сторону RTOS, выделенного контроллера, FPGA или обработки на стороне устройства.

Почему в периодической обработке нельзя опираться на Sleep(1)?

Потому что Sleep(1) даёт не «период 1 мс», а «подождать примерно не меньше 1 мс и сверху добавить время обработки»; перерасход ожидания накапливается как есть. Цикл ведут по абсолютному сроку next += period, ждут событие устройства или высокоточный waitable timer, а короткий busy-spin оставляют только на финальную подстройку. timeBeginPeriod включают лишь на время необходимости и потом возвращают.

Что сильнее всего снижает задержку и джиттер?

Не повышение приоритета, а короткий, фиксированной длины и неблокирующий hot path. Fast path (съём / управление) и slow path (сохранение / связь / UI) разделяют и соединяют очередью фиксированной длины; в hot path не пишут в файл, не отправляют в сеть, не делают тяжёлое логирование и не выделяют память на каждом шаге. В эксплуатации помогают питание от сети, пересмотр режима питания, проверка EcoQoS и уборка лишней фоновой нагрузки.

По каким показателям оценивать устойчивость периодической обработки?

Не только по среднему, а по p99, p99.9, max и числу missed deadline. Например, среднее 0,8 мс при max 28 мс значит: обычно быстро, но иногда бывает крупный всплеск. На обычной Windows настоящая проблема как раз в этом хвосте от p99 до max. Параллельно фиксируют всплески DPC/ISR, page fault, глубину очереди, колебания температуры и частоты и оценивают по отдельным условиям: до и после прогрева, при долгой работе, в свёрнутом состоянии, от батареи и т. д.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.