Частота тактовой частоты ЦП и таким образом QueryPerformanceCounter неправильно?

По-видимому, существует известная проблема с QPC на некоторых чипсетах, таким образом, можно хотеть удостовериться, что у Вас нет их чипсетом. Дополнительно некоторый двухъядерный AMDS может также вызвать проблему. См. второе сообщение sebbbi, где он заявляет:

QueryPerformanceCounter () и QueryPerformanceFrequency () предлагают немного лучшее разрешение, но имеют другие вопросы. Например, в Windows XP, весь AMD Athlon X2 двухъядерные центральные процессоры возвращают ПК любого из ядер "случайным образом" (ПК иногда переходит немного назад), если Вы особенно не устанавливаете AMD двухъядерный пакет драйвера для устранения проблемы. Мы не заметили никакого другого двойного + базовые центральные процессоры, имеющие подобные проблемы (p4 двойной, p4 ht, core2 двойной, core2 четверка, четверка явления).

Из этого ответа.

Необходимо всегда ожидать, что базовая частота изменится на любом ЦП, который поддерживает технологию, такую как SpeedStep или Cool'n'Quiet. Стенное время не затронуто, оно использует RTC. Необходимо, вероятно, прекратить использовать счетчики производительности, если Вы не можете терпеть ценность нескольких миллисекунд (5-50) случайных фазовых подстроек и готовы выполнить некоторую математику для выполнения упомянутой фазовой подстройки непрерывно или периодически перенормализация значений счетчика производительности на основе частоты счетчика производительности, о которой сообщают, и на RTC время с низкой разрешающей способностью (можно сделать это по запросу, или асинхронно от таймера с высоким разрешением, в зависимости от окончательных потребностей приложения.)

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

Используйте свойство IsHighResolution, чтобы видеть, основан ли таймер на счетчике производительности с высоким разрешением.

Примечание: На многопроцессорном компьютере это не имеет значения, на каком процессоре поток работает. Однако из-за ошибок в BIOS или Уровне аппаратной абстракции (HAL), можно получить различные результаты синхронизации на различных процессорах. Для определения привязки процессора к потоку используйте ProcessThread.. метод::.ProcessorAffinity.

Просто выстрел в темноте.

На моем домашнем ПК я раньше имел "AI NOS", или что-то как этот включило в BIOS. Я подозреваю, что это завинтило API QueryPerformanceCounter/QueryPerformanceFrequency, потому что, хотя системные часы работали при нормальном темпе и нормальных приложениях, работал отлично, все полноэкранные 3D игры выполнили приблизительно 10-15% слишком быстро, порождение, например, смежные строки диалогового окна в игре для смещения друг на друге.

Я боюсь, что Вы не можете сказать, что "У меня не должно быть этой проблемы", когда Вы используете QueryPerformance* - в то время как документация указывает, что значение, возвращенное QueryPerformanceFrequency, является постоянным, практическое экспериментирование показывает, что это действительно не.

Однако Вы также не хотите называть QPF каждым разом, когда Вы называете QPC также. На практике мы нашли, что периодически (в нашем случае однажды секунда) называющий QPF для получения новое значение сохранил таймеры синхронизируемыми достаточно хорошо для надежного профилирования.

Как был указан также, необходимо сохранить все QPC, обращается к единственному процессору для последовательных результатов. В то время как это не могло бы иметь значения в профильных целях (потому что можно просто использовать ProcessorAffinity для блокировки потока на единственный ЦП), Вы не хотите делать это для синхронизации, которая работает как часть надлежащего многопоточного приложения (потому что затем Вы рискуете блокировать усердный поток к ЦП, который занят).

Особенно произвольно не блокируйте к ЦП 0, потому что можно гарантировать, что некоторое другое плохо кодированное приложение сделало это также, и затем оба приложения будут бороться за процессорное время на ЦП 0, в то время как ЦП 1 (или 2 или 3) простаивает. Случайным образом выберите из набора доступных центральных процессоров, и у Вас есть, по крайней мере, шанс борьбы, что Вы не заблокированы к перегруженному ЦП.