1

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

Я на платформе WS2016 x64, и я могу установить разрешение таймера только до 500us (0.5ms), вызывая NtSetTimerResolution() в библиотеке ntdll.dll . Я думаю, что это значение привязано к временному интервалу sheduler.

Тем не менее, я хочу увеличить его до 100US. Измерение может включать вызов NtDelayExecution() обернутый в QueryPerformanceCounter() много раз внутри цикла, а затем анализ статистики, такой как джиттер, стандартное отклонение и т.д.

Как это сделать? Есть ли в реестре / файл настройки, где я могу установить Arbiraty Windows Sheduler Timeslice?


PS. Некоторые люди могут спросить: « Зачем вам это нужно?"или заявить " Не делай этого, это неправильно!». Я предвижу подобные мысли и отвечу заранее.

  • Это всего лишь программный эксперимент. Это просто для проверки возможности и физических результатов этого.
  • Я знаю, что это может привести к потенциальным проблемам, таким как дополнительное время процессора, потраченное только на переключение контекста, нестабильность системы, безответственность, потеря данных и любые другие проблемы, которые это может вызвать. Я принимаю любые негативные последствия, если буду делать это заранее и брать на себя всю ответственность. Даже если бы дым и блестки вышли бы из моей машины :)
  • В соответствии с поиском или поиском здесь - конечно, я сделал это и не смог найти полезную информацию, потому что эта тема довольно узкая, касающаяся работы планировщиков ОС. И делать практически бессмысленно на любой windows-машине. Я знаю, что не могу превратить его в реальное время. Этот поиск по сайту "sheduler timeslice" не дает результата.

1 ответ1

0

Интервал временного интервала планировщика не зависит напрямую от разрешения таймера. Для большинства процессов на клиентских SKU это 20 мсек; для процесса, которому принадлежит окно переднего плана, это 60 мсек. Эти значения обычно равны 120 мсек в SKU сервера.

Эти значения одинаковы независимо от того, что вы делаете с NtSetTimerResolution. Независимо от разрешения таймера, соответствующее количество тактовых прерываний отсчитывается до того, как будет обнаружен интервал в 20 мс, и планировщик уменьшает "квантовый" счетчик текущего потока и т.д.

Таким образом, если вам удастся улучшить разрешение таймера до 100 мкс, это не повлияет на планирование потоков. Это, однако, создаст дополнительные издержки, что с 5-кратным предыдущим числом обращений к подпрограмме, которая проверяет, истек ли срок действия таймеров.

Там нет реестра или других настроек, чтобы изменить это.

Существует взлом реестра, который можно использовать для преодоления "растяжения временного интервала", которое происходит в клиентских SKU, или для того, чтобы заставить серверную систему вести себя как клиент, или наоборот, в отношении длины временного интервала. И иногда (из-за небольшого изменения Thread-> Quantum, которое выполняется, когда поток выходит из ожидания), временной интервал может быть немного короче, чем "должен" быть. Но нет никакого способа установить временной интервал менее 20 мсек или что-либо, кроме кратного 20 мсек, и не так много разных кратных значений доступно.

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

Источник: Большая часть этого находится в Windows Internals от Solomon, Russinovich, et al.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .