Почему GetTickCount и timeGetTime имеют разное разрешение?

Question

По умолчанию GetTickCount и timeGetTime имеют такое же разрешение - 15.625мс, но после того, как я вызываю timeBeginPeriod (1), GetTickCount все равно обновляет каждые 15.625 мс, а timeGetTime обновляет каждые 1 мс, почему это?

В Bug in waitable timers?, автор отметил, что:

Мне интересно, что: Почему GetTickCount и timeGetTime из того же RTC, но есть два вида разрешения?

спасибо!

Answer 1

Я думаю, что ОП путается между таймерами, прерываниями и таймерами.

Квантовый интервал - это период таймера. Это связано с системой в 18,2 тика/сек. Это никогда не меняется по какой-либо причине и не основано на системных тактовых импульсах CPU (очевидно!).

Вы можете запросить систему на две разные вещи: дату и время (GetTime) или количество времени, в которое система работала (GetTickCount/GetTickCount64).

Если вас интересует время работы системы, используйте GetTickCount. Из моего ограниченного понимания GetInterruptTime возвращает только время, затрачиваемое на прерывания в реальном времени (в отличие от времени, затраченного на запуск приложений или бездействия).

Я не уверен, что сообщить новому программисту прекратить спрашивать «почему?». поможет им. Да, ОП не видел или не читал комментарии на упомянутой странице; но просьба здесь не должна быть привилегией, предоставляемой только искателям, которые исчерпали все другие возможности (возможно, включая «Видящие камни С»). Мы ВСЕ учимся здесь. Перестаньте говорить людям, что их вопрос бессмыслен, не говоря им почему. И нет причин не спрашивать. Таймеры могут ввести в заблуждение!

Answer 2

Фактически указанная вами таблица неверна для QueryPerformanceCounter. QPC (для краткости) реализована в трех возможных источниках синхронизации: 1: HPET, таймер ACPI 2: PM, 3: RDTSC. решение основано на эвристике в зависимости от условий, параметров загрузки ядра, ошибок в BIOS и ошибок в коде ACPI, предоставляемом чипсетом. Все эти ошибки обнаруживаются на каждой аппаратной основе в лабораториях Microsoft. Программисты Linux и BSD должны сами по себе найти жесткий диск и, как правило, должны переписывать код ACPI для устранения ошибок. Сообщество linux стало ненавидеть RDTSC, а также ACPI по разным причинам. Но в любом случае ...

TimeReadTime отличается от GetTickCount, потому что для стабильности в соответствии с тем, как указано в документации GetTickCount, его поведение не может быть изменено. Тем не менее, в некоторых случаях для улучшения качества таймера в окне необходимо было улучшить разрешение тика. (таймер работает с сообщениями, отправляя в приложение GetMessage или PeekMessage, а затем вступает в хороший обратный вызов для обработки таймера). Это необходимо для мультимедиа, например, для аудио/аудио синхронизации.

Очевидно, что игра или программирование в реальном времени требуют лучшей точности даже когда-то и не могут использовать таймеры. Вместо этого они используют ожидание, или они спят только в одном случае: VSync через вызов OpenGL или DirectX uppon backbuffer/frontbuffer swapping. Видеодрайвер просветит ожидающий поток вверх по сигналу VSync с самого экрана. Это сон, основанный на событии, как таймер, но не основанный на прерывании таймера.

Следует отметить, что современные ядра имеют динамическое тикание (безъядерное ядро, из окон 8 или linux 2.6.18). Наилучшая частота прерывания тика не может быть увеличена до 1 мс, чтобы избежать засорения, но верхнего предела нет. если ни одно приложение не запускается и не отправляет событие синхронизации, тогда машина может спать неограниченное время, позволяя ЦП перейти в самое глубокое состояние сна (состояние расширенной скорости C7 с расширенной скоростью). После чего следующее пробуждение, в большинстве случаев, происходит из-за прерывания устройства, в основном USB. (перемещение мыши или другие вещи)