Интервал временного интервала планировщика не зависит напрямую от разрешения таймера. Для большинства процессов на клиентских SKU это 20 мсек; для процесса, которому принадлежит окно переднего плана, это 60 мсек. Эти значения обычно равны 120 мсек в SKU сервера.
Эти значения одинаковы независимо от того, что вы делаете с NtSetTimerResolution. Независимо от разрешения таймера, соответствующее количество тактовых прерываний отсчитывается до того, как будет обнаружен интервал в 20 мс, и планировщик уменьшает «квантовый» счетчик текущего потока и т. Д.
Таким образом, если вам удастся улучшить разрешение таймера до 100 мкс, это не повлияет на планирование потоков. Это, однако, создаст дополнительные издержки, что с 5-кратным предыдущим числом обращений к подпрограмме, которая проверяет, истек ли срок действия таймеров.
Там нет реестра или других настроек, чтобы изменить это.
Существует взлом реестра, который можно использовать для преодоления «растяжения временного интервала», которое происходит в клиентских SKU, или для того, чтобы заставить серверную систему вести себя как клиент, или наоборот, в отношении длины временного интервала. И иногда (из-за небольшого изменения Thread-> Quantum, которое выполняется, когда поток выходит из ожидания), временной интервал может быть немного короче, чем «должен» быть. Но нет никакого способа установить временной интервал менее 20 мсек или что-либо, кроме кратного 20 мсек, и не так много разных кратных значений доступно.
Обратите внимание, что интервал таймслей-планировщика не влияет на приоритет. Когда ожидание потока разрешено, если приоритет потока выше, чем приоритет текущего потока на идеальном процессоре нового потока, последний поток прерывается немедленно . Он не может дойти до конца своего временного интервала до того, как его опередят. Временные фрагменты важны только тогда, когда несколько потоков конкурируют с одинаковым приоритетом.
Источник: Большая часть этого находится в Windows Internals от Solomon, Russinovich, et al .