Компания
260,32
рейтинг
18 июля 2013 в 13:48

Разработка → Почему не стоит разгонять таймер Windows или мегаватты, потраченные впустую перевод


Период таймера Windows по умолчанию составляет 15.6 мс – он тикает 64 раза в секунду. Когда программа увеличивает частоту таймера, растет потребление энергии, что сказывается на расходе батареи. При этом также расходуется вычислительная мощность компьютера, и даже больше, чем я думал – то есть компьютер начинает работать медленнее! Вот почему в течение многих лет Microsoft настоятельно не рекомендует разработчикам поднимать частоту таймера.
Почему же тогда почти каждый раз, когда я вижу разгон таймера, он вызван программой от Microsoft?

Узнать текущую частоту таймера Windows довольно просто с помощью утилиты clockres от sysinternals.

ClockRes v2.0 – View the system clock resolution
Copyright 2009 Mark Russinovich
SysInternals – www.sysinternals.com

Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms


Для увеличения времени работы компьютера от батарей текущий период таймера (который может быть изменен функцией timeBeginPeriod) должен быть равен 15.6 мс; но, как вы видите выше, какая-то программа изменила его на 1 мс, что эквивалентно дополнительным 936 тикам в секунду.

Поиск виновного – WPF


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

powercfg -energy duration 5

и в текущем каталоге появится файл energy-report.html, в котором мы, в частности, прочитаем:

The stack of modules responsible for the lowest platform timer setting in this process.
Requested Period 10000
Requesting Process ID 3932
Requesting Process Path
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe
Calling Module Stack
C:\Windows\SysWOW64\ntdll.dll
C:\Windows\SysWOW64\winmm.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\wpfgfx_v0400.dll
C:\Windows\SysWOW64\kernel32.dll
C:\Windows\SysWOW64\ntdll.dll


Итак, Visual Studio 11, посредством использования WPF, запросила интервал в 1 мс, что и указано в отчете посредством несколько сбивающей с толку единицы измерения, равной 100 нс. Это известная проблема, связанная с WPF; все версии Visual Studio ведут себя так время от времени и, по-видимому, любое приложение, использующее WPF, может стать источником проблемы. Увеличение частоты может иметь смысл, когда программа пытается поддерживать постоянный фрейм рейт вывода, однако это не оправдывает WPF, поскольку она сохраняет высокую частоту таймера даже в том случае, когда никакой анимации не происходит.

Поиск виновного – SQL сервер


Другой процесс, часто виновный в увеличении частоты на моем компьютере – sqlservr.exe. Думаю, что он был установлен Visual Studio, но не уверен в этом, как не уверен, используется он или нет. В любом случае, SQL сервер не должен повышать частоту таймера; если таким образом предполагается повысить производительность приложения, то это больше похоже на костыль. И, как в случае с WPF, увеличение частоты нужно только тогда, когда сервер занят обработкой данных, а не постоянно.

Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 2384
Requesting Process Path \Device\HarddiskVolume1\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\sqlservr.exe


Поиск виновного – quartz.dll


У меня нет соответствующей записи из отчета powercfg, но C:\Windows\System32\quartz.dll является еще одним источником проблем с частотой таймера. Я даже толком не знаю, что такое этот Quarts (ну а мы-то знаем, что это не что иное, как Microsoft DirectShow – прим. пер.), но замечал, что иногда он расходует энергию зря.

Поиск виновного – Chrome


Обычно виновными становятся продукты Microsoft, однако к ним в компанию я добавляю еще Google Chrome. Когда я запускаю Chrome он постоянно увеличивает частоту таймера 1000 Гц, даже в том случае, когда компьютер работает от батареи, а я просматриваю простую HTML страницу. Привожу скриншот, фиксирующий преступление Chrome.

Поиск виновного – svchost.exe


Иногда svchost.exe увеличивает частоту таймера до 100 Гц. Это, конечно, не так страшно, как 1000 Гц, но все-таки раздражает. Особенно печально то, что я не могу определить, какой именно сервис это делает.

Общая трагедия – побеждает максимальная частота


Таймер Windows является глобальным ресурсом, он тикает с одинаковой частотой для всей системы целиком. Получается, что если какая-то программа увеличивает частоту таймера, то это сказывается на поведении всей системы.
Когда процесс вызывает функцию timeBeginPeriod, этот запрос частоты остается в силе до тех пор, пока не будет принудительно отменен с помощью timeEndPeriod или до конца работы приложения. Большинство программ (включая и мои тестовые, приведенные ниже) никогда не вызывают timeEndPeriod, полагаясь на системные средства очистки Windows. Это работает и вполне разумно для приложений, которым необходима повышенная частота таймера на всем протяжении исполнения. В противном случае хорошей идеей будет использование timeEndPeriod. По рекомендации Microsoft к приложениям второго вида относятся проигрыватели видео в режиме паузы и свернутые в трей игры. Сюда же можно включить веб-браузеры, которые в текущий момент не требуют высокой частоты таймера или при работе от батареи.

Так ли это важно?


Моим основным компьютером является ноутбук. Каждый день я использую его в автобусе и предпочитаю тратить батарею на что-то полезное, нежели чем на ненужные обращения к процессору 1000 раз в секунду.
Microsoft считает, что это важно. Они говорят: «нашей позицией остается последовательное улучшение энергоэффективности Windows ПК» и все-таки, даже 4 года спустя, сами, похоже, не исполняют свои собственные указания и не обращают внимания на свои же предупреждения: «некоторые приложения уменьшают период таймера до 1 мс, что приводит к сокращению времени работы мобильной системы на 25%».
Удобным способом измерения потребленной энергии является утилита Intel Power Gadget. На поддерживаемых процессорах Intel она покажет мощность, потребляемую упаковкой процессора в реальном времени с точностью до 0,01 Вт. На моем ноутбуке на платформе Sandy Bridge утилита показывает прирост в 0,3 Вт при повышении частоты таймера, что составляет почти 10% от стандартного потребления упаковкой процессора; применительно ко всей системе процент, конечно, будет меньше.
Увеличение на 0,3 Вт может выглядеть не таким большим, но есть пара моментов, заставляющих воспринимать его серьезно. Во-первых, если ваша программа работает, скажем, на 33 миллионах компьютеров (для Chrome это, наверное, даже заниженная оценка), увеличение частоты таймера приведет к потере примерно 10 МегаВатт энергии. Во-вторых, важность проблемы со временем будет только возрастать. Новые процессора с улучшенным объединенным таймером будут затрачивать на учащенные вызовы еще больше вычислительных мощностей.

Быстрые таймеры ухудшают производительность


Исполнение прерываний отнимает некоторую часть ресурсов компьютера, поэтому увеличение их количества в единицу времени должно несколько замедлить скорость его работы. Я проверил эту теорию, написав тестовую программу, крутящую циклы активности и докладывающую каждую секунду скорость своего исполнения. Во время работы программы я изменил частоту таймера, чтобы посмотреть его влияние на производительность.
Влияние было, причем существенное.
Я проделал быстрые тесты на двух компьютерах, так что точные цифры не стоит воспринимать слишком серьезно. Кроме того, они наверняка сильно зависят от аппаратной платформы, нагрузки и т.д. Однако результаты явно показали влияние ускорения таймера на производительность, оно составляет 2,5-5% — это больше, чем я предполагал. Степень замедления достаточно велика, чтобы заподозрить традиционный подход – повышение частоты таймера для увеличения производительности приложения – в контр-продуктивности.
Увеличение частоты таймера Windows не приводит ни к чему хорошему. При этом зря расходуется энергия и замедляется компьютер. Практика применения его во всех без разбора программах, висящих часами без активности, должна быть прекращена.
Вот результаты работы моей тестовой программы в графическом формате



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

Исходный код


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

#include “stdafx.h”

#include <stdio.h>
#include <Windows.h>

LARGE_INTEGER g_frequency;
const double kDelayTime = 1.0;

double GetTime()
{
    LARGE_INTEGER counter;
    QueryPerformanceCounter(&counter);
    return counter.QuadPart / double(g_frequency.QuadPart);
}

int g_array[1024];
int offset;
int g_sum;

void SpinABit()
{
    for (int i = 0; i < ARRAYSIZE(g_array); ++i)
    {
        g_sum += g_array[i + offset];
    }
}

void Stall()
{
    double start = GetTime();
    int iterations = 0;
    for (;;)
    {
        ++iterations;
        SpinABit();
        double elapsed = GetTime() – start;
        if (elapsed >= kDelayTime)
        {
            printf(“%1.5e iterations/s\n”, iterations / elapsed);
            return;
        }
    }
}

int main(int argc, char* argv[])
{
    QueryPerformanceFrequency(&g_frequency);
    for (;;)
        Stall();
    return 0;
}


А вот программа, повышающая частоту таймера на 20 сек.

#include <stdio.h>
#include <Windows.h>

#pragma comment(lib, “winmm.lib”)

int main(int argc, char* argv[])
{
    timeBeginPeriod(1);
    printf(“Frequency raised.\n”);
    Sleep(20000);
    printf(“Frequency lowered.\n”);
    // timeEndPeriod call is omitted because process
    // cleanup will do that.
    return 0;
}


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

И потом исправьте код своих программ. Все, как один.
Автор: @saul Bruce Dawson
Intel
рейтинг 260,32

Комментарии (70)

  • +7
    А можно вкрадце объяснить что такое этот таймер и зачем он вообще нужен?
    • +4
      По DOS'у помню, дефолтный тик 18.2 раз в секунду. en.wikipedia.org/wiki/Intel_8253
    • +16
      Тоже начав читать статью возник вопрос про какой вообще таймер идет речь, что он делает и т.п.
    • +4
      Если я правильно понял, то это тот самый таймер, по которому происходит смена контекста процессора. То бишь, такая реализация вытесняемой многозадачности.
    • +1
      Речь идет о так называемом Multimedia Timer — софтовом таймере, который позволяет приложениям создавать очереди задач с высоким разрешением. Используется в основном мультимедийными и серверными приложениями.
      • +1
        Другими словами, если я делаю из компьютера DSP, таймер необходимо разгонять — по-другому я и не смогу добиться минимальной задержки.
        • 0
          А вот не факт — надо проверять. Теперь мы знаем, как.
          • +4
            Каким образом я в принципе смогу достичь задержки звука 2 мс? Чтоб такой задержки достичь, необходимо как минимум не реже раза в 2 мс переключаться на приложение, которое обрабатывает поступающий звук, чтоб оно могло собственно обработать свои очередные 128 сэмплов и выдать результат обратно на звуковуху.

            Очевидно, что чтобы приложение могло вызываться не реже раза в 2 мс, таймер должен стоять меньше, чем на 2 мс. А не на 15.6.

            Короче, я против этого безаппеляционного высказывания «маленький период — это плохо». Это совершенно неверно. Всему своё место, вполне может попасться задача, в которой нужно именно такое значение этого таймера.

            Надо просто понимать при разработке, где и когда. Для звука, как вы видите, это жизненно важно. Для игрушке в реальном времени, когда 5 мс уже влияют — тоже важно. Для потоковой обработки видео — нет: между кадрами там 40 мс, между полями — 20 мс (в стандарте PAL 25 кадров или 50 полей в секунду).
            • +8
              Если вы общаетесь со звуковой картой, умеющей генерировать прерывания, и обрабатываете очередную порцию данных по прерыванию, то частота таймера вам не важна — Windows может переключать потоки после любого прерывания, не только таймера. Конечно, если программа осуществляет задержки вызовом Sleep, то от повышения частоты никуда не деться.
              • 0
                Ещё, это немного не «в тему», но при работе со звуковыми приложениями, где ощущается задержак (например, если хочется записать партию с миди-клавиатуры) — можно увеличить частоту дискретизации — количество семплов задержки останется таким же, а длина — уменьшится.
                • 0
                  А также увеличится вычислительная нагрузка и используемая дисковая и оперативная память. Без любых других выгод.

                  Если уж на то пошло, лучше буфер уменьшить.
              • 0
                Не так. Во-первый мы не с ОС реального времени работам и время обработки прерываний никто не гарантирует. Во-вторых звуковые карты уже давно прямом доступом буфера воспроизводят, а не по прерываниям (прерывания редкие будут).
                В третьих, звук как правило нужно с чем-то синхронизировать — с сетью, с графикой. Где взять опорное время?
                • +1
                  Если я правильно понял, что вы об источнике частоты дискретизации, то опорное время в таких случаях всегда берётся с самой звуковухи. Откуда она получает — это её дело — либо на ней самой кристалл стоит, либо там есть вход World Clock и где-то стоит внешний генератор.

                  Если имеются ввиду «когда начать играть звук» а не «когда вывести очередной сэмпл» — в игре это игровые события (например, таймер, если речь о действиях бота).
                  • –1
                    Не всегда wordClock, и не всегда на звуковухе)
                    Есть просто Internal Sync и External Sync.
        • +2
          Сталкивался с задачей точного задания временных задержек и изучал проблему с изменением гранулярности шедулера и timeBeginPeriod — единственный способ заставить sleep(1) спать одну миллисекунду без оверхеда для процессора. Немного исследований на эту тему: www.geisswerks.com/ryan/FAQS/timing.html
      • +2
        Некорректно выразился. Используется этот таймер всеми приложениями. Как замечено выше, это реализация виндовой многозадачности. А вот тягу к изменению испытывают как раз мультимедийные и серверные приложения.
        • +4
          Да не только виндовой. Так по-моему все preemptive multitasking системы устроены.

          В линуксе указанный таймер может принимать четыре значения: 100, 250, 300 и 1000 Hz. Т.е. 10, 4, 3.333, 1 мс. Причём на десктопах обычно используют последний вариант, а энергопотребление снижают другим способом: система хитра, и таймер умеет пропускать тики (эта фича так и называется: dynamic ticks).
          • 0
            dynamic ticks есть и в Windows 8 — я даже специально отключал их в своей системе, так как из-за них валился BSOD :)
            • 0
              ну раз оно так работает, считай и нету
            • 0
              У многих людей нет такой проблемы.
    • +4
      Речь идет о системном таймере.
      Это маленькая железка, которая с определенной периодичностью генерирует прерывание.
      Соответственно, начинает отрабатывать обработчик прерывания, который, например решает будет ли текущая программа продолжать исполнение или будет вытеснена чем-то еще.
      Но, если процессор находится в неглубоком сне (что он и делает, например, когда вы читаете этот коммент), прерывание его разбудит по сути в холостую. Будет потрачена бесценная энергия. Ну и, соответственно, лучше чтобы это происходило в данном случае реже.
      • 0
        Ну я на него ссылку и давал выше. Только вот вопрос у меня — как в современном железе этот таймер аппаратно выглядит? Всё та же микруха или нечто покруче?
        • 0
          как вариант — local APIC внутри процессора, у каждого ядра свой

          как именно в винде сделано — не знаю
          • 0
            но суть та же осталась?
            • +1
              да, неважно же, что является источником прерывания — таймер, клавиатура или сетевуха, проц-то всё равно будится
        • 0
          Зависит от конкретной платформы. Обычно, это старая добрая 8254, правда вряд ли в отдельном корпусе.
  • +1
    а у меня этим балуются chrome, qip и Aimp.
  • 0
    "+5 копеек": \Device\HarddiskVolume2\Program Files (x86)\Mozilla Firefox\firefox.exe
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Насколько я понимаю, изменить поведение системы нельзя — иначе все бы решалось гораздо проще. Я тоже столкнулся с тем, что clockres показывает не все причины ускорения таймера, в своем случае я нашел ее методом перебора.
  • +1
    Не просто так этот таймер придумали.

    Увеличение частоты уменьшает производительность за счёт бОльшего числа прерываний таймера за тот же период времени (как-то круто в винде, видимо, обработчик этого прерывания чересчур тяжёлый) и увеличивает энергопотребление, но взамен он увеличивает субъективную отзывчивость системы.
    • 0
      Шедулер задачам по нему кванты времени раздает, сам обработчик не виноват — меняется логика работы.
      • +1
        Не, ну мало ли, чего там нужно сделать обработчику. Я в основном хотел сказать, что повышение потребления — это не просто так, это оборотная сторона повышения отзывчивости.
        • 0
          Вот я сильно сомневаюсь, что повышение отзывчивости в данном случае имеет место быть. Вдумайтесь, что такое 1 мс, и зачем такие интервалы тому же браузеру, или игрушке. Звук, да, требует учащенного таймера, но опять же 1 мс это перебор для программной обработки, а аппаратная обработка чего угодно и без ускорения этого таймера произойдёт вовремя.
          • 0
            Имеет место. Если речь о ритмичных событиях, то человек ощущает отклонение ритма даже на долю миллисекунды, а если речь о неритмичных событиях, то вполне реально время реакции 5 мс.

            Для звука считается удобным работать, если задержка в мониторах не больше 2 мс. (За это время звук в воздухе проходит 0.6 метра — примерно такое же расстояние при игре от натурального инструмента до ушей музыканта.) Больше 10 мс уже играть неудобно, именно такого порядка задержки звука между музыкантами в симфоническом оркестре и требуется дирижёр для синхронизации.

            В общем, 15.6 мс — это очень много по сравнению с комфортным для человека.
          • +1
            На практике — имеет место быть :) Основная проблема, что шедулер завязан на этот таймер тоже. Я чуть ниже в комментарии приводил пример ( habrahabr.ru/company/intel/blog/186998/#comment_6508774 ), когда на одноядерных системах, или когда на многоядерных все ядра загружены — отзывчивость заметно повышается при маленьких timeBeginPeriod
            • 0
              Благодарю :)
  • 0
    Да, аналогично, хром. А вот какие-то методы борьбы с этим есть со стороны пользователя? И нужна ли она, эта борьба (судя по выводам статьи — нужна)?
    • 0
      Ну, теоретически возможно сделать сплайсинг функции timeBeginPeriod…
      • 0
        Переведите пожалуйста на не-программистский )
        • +1
          Подменить поведение метода timeBeginPeriod в системных библиотеках, чтобы он не разгонял таймер, к примеру, а печатал смайлики на принтере.
  • 0
    Значит это куча вкладок Chrome'а виновата в скорости разрядки моего старого ноутбука :-)
    А решения никакого, стало быть, нет?
  • +9
    Помню, люди, которые держали игровые сервера Counter-Strike на Windows, запускали специально Windows Media Player на сервере, чтобы увеличить tickrate и уменьшить «лагучесть» в игре (-:
    • +4
      Они и сейчас так делают.
  • +3
    Пример с 33 миллионами компьютеров с Chrome и 10 МегаВатт энергии впечатляет. Учитывая прозрачную систему обновления Chrome, можно успешно спекулировать на рынке продаж электроэнергии, просто включая или выключая разгон таймера в очередной версии. И ведь никто не догадается.
    • 0
      C миру по нитке, ага :-)
  • +3
    Так процессоры ж стали многоядерными
    1. Нельзя ли на одном ядре переключаться для медийных, а на другом помедленнее для остальных?
    2. И как с этим в Linux, Mac OS, Andoid, iOS?
    • +1
      android === linux в данном случае (именно так, в андроиде именно линукс и занимается таймером)

      никаких проблем, dynamic ticks (выше ссылка в комментариях)
    • +1
      В грядущей версии макоси будет «timer coalescence», который позволит пропускать тики, как в примерах из мира линукса и вин8 в комментариях выше.
  • 0
    И был ещё бага в Windows из-за которого частое переключение между режимами таймера в Java приложении приводило к изменению в нормальном ходе системных часов.
  • 0
    Вот ведь подстава, а нельзя ли просто запретить пользовательским приложениям монопольно лезть и менять этот несчастный таймер? Или хотя бы приаттачить к каждому процессу по dllке, которая бы перехватывала этот вызов и дальше уже разрешала, запрещала приложению менять это значение таймера?
  • 0
    Я далек от программирования под Windows, но у меня есть вопрос общего характера: я написал код, который при запуске выяснил период работы системного таймера и в дальнейшем программа исходит из данного значения. Потом кто-то меняет период работы таймера. Что будет с моей программой?
    • +3
      программа будет работать неправильно
    • +2
      Зависит от того, что Вы называете словом «исходит».
      Например, короткий sleep или timed wait в цикле будет отрабатывать в N раз чаще или реже. Если тело (или условие) цикла имеет побочные эффекты, эти побочные эффекты тоже будут отрабатывать в N раз чаще или реже. Например, если Вы делаете пошаговую анимацию с фиксированным шагом, ее скорость изменится. Если Вы используете интерполяцию по времени, скорость анимации в среднем (amortized) не изменится, но она станет более или менее плавной. Наконец, если логика Вашей программы полагается на определенную частоту таймера, скорее всего, в ней есть и другие проблемы (hardcoded constants, смешение спецификации с реализацией, смешение бизнес-логики со вводом-выводом и еще что-нибудь столь же пионерское).

      Для внеклассного чтения: staff.um.edu.mt/jskl1/turbo.html#Error
  • +2
    Касательно вопроса таймеров — я так и не осилил синхронизацию времени в Windows с локальным Linux NTP сервером с точностью более ~10мс… Вероятно таймер виноват.

    habrahabr.ru/qa/31893/
  • 0
    > «что составляет почти 10% от стандартного потребления упаковкой процессора»

    Что еще за упаковки процессора?
    • +2
      Упаковкой процессора (CPU Package) называют физический конструктив процессора, т.е. его воплощение в кремнии и прочих материалах. В данном случае слово «упаковка», наверное, можно опустить, но я оставил так, как в оригинале.
      • 0
        Процессорного блока, как вариант.
  • –2
    MIcrosoft и Google специально замедляют работу своих продуктов, чтобы в следующей версии они работали быстрее предыдущих)))
  • –3
    Бред какой-то.
    Во-первых, Windows (как и Linux) в общем случае не ОС реального времени и никто вам никакой периодичности не обещает. Включая планировщик задач.
    Поэтому как только стоит задача привязки к каким-либо физическим процессам, то нужны мульти-медиа таймеры.
    Звуковой карте — чтобы синхронизировать звук с картинкой.
    Играм и видео-плеерам — чтобы синхронизировать звуковую дорожку и картинку.
    Играм — чтобы картинка не дёргалась.
    VS? Скорее всего они как-то профайлинг или синхронизацию на фоне делают (та же .NET, например). Потому и хотят разрешение 1 мС.
    Хрому может быть нужен, чтобы использовать ускорение видео, как и играм.
    Во-вторых, вы про какой из таймеров?
    "Период таймера Windows по умолчанию составляет 15.6 мс" ?!!!
    Вы утверждаете, что планировщик переключает и балансирует задачи 64 раза в секунду? Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?! Посмотрите, сколько в системе потоков.
    Планировщик замечательно увеличивает частоту до 1мс.
    Про линукс — весьма аналогично.
    • +2
      Вы утверждаете, что планировщик переключает и балансирует задачи 64 раза в секунду? Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?!
      Ну, во-первых, это не я утверждаю, а Брюс Досон, программист из Valve. А во-вторых, это действительно так. Вот отчет powercfg с моей машины:

      Установленное по умолчанию разрешение аппаратного таймера, равное 15,6 мс(15 625 000 нс), следует использовать во всех случаях простоя системы. При увеличении разрешения таймера возможно снижение эффективности технологий управления электропитанием процессора. Разрешение таймера может увеличиваться при воспроизведении файлов мультимедиа или анимации.
      Текущее разрешение таймера (х100 нс) 156000


      Могу привести нотариально заверенный скриншот :)
      • 0
        "следует использовать во всех случаях простоя системы"
        Жёсткие 15.6 мС как мне помнится ещё 98 было. В XP уже был какой-то динамический таймер — как только появлялась нагрузка на систему интервал времени уменьшался.
    • +1
      Именно так, шедулер дергается раз в 15.6 мс по дефолту.
      Т.е. Вы утверждаете, что если в системе более 64 активных потоков, то цикл планирования будет секунда?!
      Да, но тут многое зависит еще и от приоритета, и от действительной активности. Если поток отработал, и у него осталось свободное время от кванта — то оно будет отдано другому. В действительности же очень мало потоков одновременно нагружают процессор, ожидающие потоки сразу же отдают свое время и проблем с этим не возникает.

      Кстати вы помните как бывало на одноядерных машинах, когда какой-нибудь зависший процесс валит CPU на 100%? Приходилось со скрипом кое-как открывать диспетчер задач, и прибивать процесс. Если бы вы поигрались с мультимедиа таймером, вы бы заметили, что при timeBeginPeriod(1) открыть диспетчер задач гораздо проще, чем при дефолтных 15.6мс

      Вот тут кстати неплохое мини исследование того как работает шедулер: dtf.ru/articles/read.php?id=39888
      • 0
        Это было в бородатые годы. С тех пор я помню заявление MS (ещё об XP) о том, что у них динамический интервал таймера и теперь ничего не виснет. И оно правда уже так не виснет.
  • +1
    Может от этого зависит прикол на некоторых компах, когда ставишь систему и все работает отлично только звук в любых программах играет очень быстро! И никакие драйверы не помогают, только внешняя звуковая
  • 0
    Можно ли изменить этот период в Opera(2ms), Winamp(2ms) и Sametime(1ms)?
    • 0
      А флэш и прочая мультипликация как играться будет в опере?
      А звук как синхронизировать винампу?
      • 0
        У меня foobar2000 что-то без проблем синхронизирует при 15.625.
  • –1
    ктонибудь пожалуйста напишите программу которая запускаясь устанавливает таймер в 0.5мс.
    дело в том что в бф4 лучше стреляется с минимальным временем таймера.

    я нашел две программы TimerTool.exe и TimerResolution.exe но они после запуска требуют введения нужного числа. А после закрытия возвращают 1мс взад.

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

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

Самое читаемое Разработка