Получение меток времени с высоким разрешением

Windows предоставляет API-интерфейсы, которые можно использовать для получения меток времени высокого разрешения или измерения интервалов времени. Основным API для машинного кода является QueryPerformanceCounter (QPC). Для драйверов устройств API режима ядра — KeQueryPerformanceCounter. Для управляемого кода класс System.Diagnostics.Stopwatch использует QPC в качестве точной базы времени.

QPC не зависит от какого-либо внешнего временного эталона и не синхронизируется с ним. Чтобы получить метки времени, которые можно синхронизировать с внешним временем, например, временем UTC для высокоточных измерений, используйте GetSystemTimePreciseAsFileTime.

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

QPC обычно является лучшим методом для использования для событий метки времени и измерения небольших интервалов времени, которые происходят в той же системе или виртуальной машине. Рассмотрите возможность использования GetSystemTimePreciseAsFileTime, если вам нужно проставить метку времени событий на нескольких компьютерах, при условии, что каждый из них участвует в схеме синхронизации времени, например, с использованием протокола NTP. QPC помогает избежать трудностей, с которыми можно столкнуться с другими подходами к измерению времени, например, считывание счетчика меток времени процессора (TSC).

• Поддержка QPC в версиях Windows
• Руководство по получению меток времени
  • Виртуализация
  • Прямое использование TSC
  • Примеры получения меток времени
• Общие вопросы и ответы о QPC и TSC
• Часто задаваемые вопросы о программировании с помощью QPC и TSC
• Низкоуровневые характеристики аппаратных часов
  • Абсолютные часы и часы разницы
  • Разрешение, точность, точность и стабильность
• Сведения о таймере оборудования

Поддержка QPC в версиях Windows

QPC появился в Windows 2000 и Windows XP и развивался, чтобы воспользоваться преимуществами улучшения аппаратной платформы и процессоров. Здесь описаны характеристики QPC в разных версиях Windows, которые помогут вам поддерживать программное обеспечение, работающее в этих версиях Windows.

Windows XP и Windows 2000

QPC доступен в Windows XP и Windows 2000 и хорошо работает в большинстве систем. Однако BIOS некоторых аппаратных систем не указывает правильно аппаратные характеристики ЦП (TSC, не являющийся инвариантным), а некоторые многоядерные или многопроцессорные системы использовали процессоры с TSC, которые не могли быть синхронизированы между ядрами. Системы с недостатками встроенного ПО, выполняющие эти версии Windows, могут не обеспечивать одинаковое чтение QPC на разных ядрах, если они использовали TSC в качестве основы для QPC.

Windows Vista и Windows Server 2008

Все компьютеры, которые поставлялись с Windows Vista и Windows Server 2008, использовали счетчик платформы (таймер событий высокой точности (HPET)) или таймер управления питанием ACPI (PM timer) в качестве основы для QPC. Такие таймеры платформы имеют более высокую задержку доступа, чем TSC, и совместно используются между несколькими процессорами. Это ограничивает масштабируемость QPC , если она вызывается одновременно из нескольких процессоров.

Windows 7 и Windows Server 2008 R2

Большинство компьютеров Windows 7 и Windows Server 2008 R2 имеют процессоры с константной частотой TSCs и используют эти счетчики в качестве основы для QPC. TSCs — это высокоточные счетчики, встроенные в каждый процессор, которые обеспечивают доступ с очень низкой задержкой и нагрузкой (порядка десятков или сотен тактов процессора, в зависимости от типа процессора). Windows 7 и Windows Server 2008 R2 используют TSC в качестве основы QPC в однодоменных системах с одним тактовым генератором, где операционная система (или гипервизор) может тесно синхронизировать отдельные счетчики TSC на всех процессорах во время инициализации системы. В таких системах затраты на чтение счетчика производительности значительно ниже по сравнению с системами, используюющими счетчик платформы. Кроме того, нет дополнительных накладных расходов на одновременные вызовы, и запросы в пользовательском режиме часто обходят системные вызовы, что еще больше снижает накладные расходы. В системах, где TSC не подходит для хранения времени, Windows автоматически выбирает счетчик платформы (таймер HPET или таймер ACPI PM) в качестве основы для QPC.

Windows 8, Windows 8.1, Windows Server 2012 и Windows Server 2012 R2

Windows 8, Windows 8.1, Windows Server 2012 и Windows Server 2012 R2 используют TSCs в качестве основы для счетчика производительности. Алгоритм синхронизации TSC был значительно улучшен для улучшения размещения больших систем с множеством процессоров. Кроме того, добавлена поддержка нового API точного времени дня, что позволяет получать точные метки времени настенных часов из операционной системы. Дополнительные сведения см. в разделе GetSystemTimePreciseAsFileTime. На устройствах Windows RT и Windows 11 и Windows 10 с процессорами Arm счетчик производительности основан на счетчике собственной платформы или системном счетчике, предоставленном универсальным таймером Arm, если платформа настолько оснащена.

Руководство по получению меток времени

Windows имеет и будет продолжать инвестировать в обеспечение надежного и эффективного счетчика производительности. Если вам нужны метки времени с разрешением 1 микросекунды или лучше, и вам не нужны метки времени для синхронизации со ссылкой на внешнее время, выберите QueryPerformanceCounter, KeQueryPerformanceCounter или KeQueryInterruptTimePrecise. Если вам нужны синхронизированные в формате UTC метки времени с разрешением 1 микросекунда или лучше, выберите GetSystemTimePreciseAsFileTime или KeQuerySystemTimePrecise.

На относительно небольшом числе платформ, которые не могут использовать регистр TSC в качестве основы для QPC, например, по причинам, описанным в информации о таймере оборудования, получение меток времени с высоким разрешением может быть значительно дороже, чем получение меток времени с более низким разрешением. Если разрешение от 10 до 16 миллисекунда достаточно, можно использовать GetTickCount64, QueryInterruptTime, QueryUnbiasedInterruptTime, KeQueryInterruptTime или KeQueryUnbiasedInterruptTime , чтобы получить метки времени, которые не синхронизированы со внешней ссылкой на время. Для меток времени, синхронизированных в формате UTC, используйте GetSystemTimeAsFileTime или KeQuerySystemTime. Если требуется более высокое разрешение, можно использовать QueryInterruptTimePrecise, QueryUnbiasedInterruptTimePrecise или KeQueryInterruptTimePrecise для получения меток времени.

Как правило, результаты счетчика производительности согласованы во всех процессорах в многоядерных и многопроцессорных системах, даже если измеряется в разных потоках или процессах. Ниже приведены некоторые исключения для этого правила:

• Операционные системы До Windows Vista, работающие на определенных процессорах, могут нарушить эту согласованность из-за одной из следующих причин:

  • Аппаратные процессоры имеют неинвариантную TSC, а BIOS неправильно указывает это состояние.
  • Алгоритм синхронизации TSC, который использовался, не подходит для систем с большим количеством процессоров.

• При сравнении результатов счетчика производительности, полученных из различных потоков, следует учитывать значения, которые отличаются на ± 1 тик, что приводит к неоднозначному упорядочению. Если метки времени взяты из одного потока, эта ± 1 неопределенность не применяется. В этом контексте термин "тик" означает период времени, равный 1 ÷ (частота счетчика производительности, полученного из QueryPerformanceFrequency).

При использовании счетчика производительности в крупных серверных системах с несколькими часовыми доменами, которые не синхронизированы аппаратно, Windows определяет, что TSC не может использоваться для измерения времени и выбирает счетчик платформы в качестве основы для QPC. Хотя этот сценарий по-прежнему обеспечивает надежные метки времени, задержка доступа и масштабируемость оказываются неблагоприятно затронутыми. Таким образом, как указано ранее в руководстве по использованию, используйте только API, обеспечивающие 1 микросекунд или более эффективное разрешение, если это необходимо. TSC используется в качестве основы для QPC в многодоменных системах с несколькими часами, которые включают аппаратную синхронизацию всех тактовых доменов процессора, так как это эффективно позволяет им функционировать как единая система тактового домена.

Частота счетчика производительности фиксирована при загрузке системы и согласована во всех процессорах, поэтому необходимо запрашивать частоту из QueryPerformanceFrequency в качестве инициализации приложения, а затем кэшировать результат.

Виртуализация

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

Прямое использование TSC

Настоятельно не рекомендуется использовать инструкцию процессора RDTSC или RDTSCP для того чтобы напрямую запрашивать TSC, так как вы не получите надежные результаты на некоторых версиях Windows, при живой миграции виртуальных машин и на аппаратных системах без инвариантных или плотно синхронизированных TSCs. Вместо этого мы рекомендуем использовать QPC для использования абстракции, согласованности и переносимости, которую она предлагает.

Примеры получения меток времени

В различных примерах кода в этих разделах показано, как получить метки времени.

Использование QPC в нативном коде

В этом примере показано, как использовать QPC в машинном коде C и C++.

LARGE_INTEGER StartingTime, EndingTime, ElapsedMicroseconds;
LARGE_INTEGER Frequency;

QueryPerformanceFrequency(&Frequency); 
QueryPerformanceCounter(&StartingTime);

// Activity to be timed

QueryPerformanceCounter(&EndingTime);
ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;


//
// We now have the elapsed number of ticks, along with the
// number of ticks-per-second. We use these values
// to convert to the number of elapsed microseconds.
// To guard against loss-of-precision, we convert
// to microseconds *before* dividing by ticks-per-second.
//

ElapsedMicroseconds.QuadPart *= 1000000;
ElapsedMicroseconds.QuadPart /= Frequency.QuadPart;

Получение меток времени высокой точности из управляемого кода

В этом примере показано, как использовать класс Managed Code System.Diagnostics.Stopwatch .

using System.Diagnostics;

long StartingTime = Stopwatch.GetTimestamp();

// Activity to be timed

long EndingTime  = Stopwatch.GetTimestamp();
long ElapsedTime = EndingTime - StartingTime;

double ElapsedSeconds = ElapsedTime * (1.0 / Stopwatch.Frequency);

Класс System.Diagnostics.Stopwatch также предоставляет несколько удобных методов для выполнения измерений интервала времени.

Использование QPC из режима ядра

Ядро Windows предоставляет доступ к счетчику производительности в режиме ядра через KeQueryPerformanceCounter , из которого можно получить счетчик производительности и частоту производительности. KeQueryPerformanceCounter доступен только в режиме ядра и предоставляется для записи драйверов устройств и других компонентов режима ядра.

В этом примере показано, как использовать KeQueryPerformanceCounter в режиме ядра C и C++.

LARGE_INTEGER StartingTime, EndingTime, ElapsedMicroseconds;
LARGE_INTEGER Frequency;

StartingTime = KeQueryPerformanceCounter(&Frequency);

// Activity to be timed

EndingTime = KeQueryPerformanceCounter(NULL);
ElapsedMicroseconds.QuadPart = EndingTime.QuadPart - StartingTime.QuadPart;
ElapsedMicroseconds.QuadPart *= 1000000;
ElapsedMicroseconds.QuadPart /= Frequency.QuadPart;

Общие вопросы и ответы о QPC и TSC

Ниже приведены ответы на часто задаваемые вопросы о QPC и TSCs в целом.

Совпадает ли функция QueryPerformanceCounter() с функцией Win32 GetTickCount() или GetTickCount64() ?

Нет. GetTickCount и GetTickCount64 не связаны с QPC. GetTickCount и GetTickCount64 возвращают количество миллисекунд с момента запуска системы.

Следует ли использовать QPC или вызывать инструкции RDTSC/RDTSCP напрямую?

Чтобы избежать ошибок и проблем с переносимостью, мы настоятельно советуем использовать QPC вместо регистра TSC или процессорных инструкций RDTSC или RDTSCP.

Что такое отношение QPC к эпохе внешнего времени? Можно ли синхронизировать его с внешней эпохой, например UTC?

QPC основан на счетчике оборудования, который не может быть синхронизирован с внешней ссылкой на время, например UTC. Для точных меток времени, которые можно синхронизировать с внешней справочной точкой UTC, используйте GetSystemTimePreciseAsFileTime.

Влияют ли летнее время, високосные секунды, часовые пояса или изменения системного времени, внесенные администратором, на работу QPC?

Нет. QPC полностью не зависит от системного времени и времени UTC.

Влияет ли точность QPC на изменения частоты процессора, вызванные технологией управления питанием или Turbo Boost?

Нет. Если процессор имеет инвариантный TSC, QPC не влияет на эти изменения. Если процессор не имеет инвариантного TSC, QPC вернется к аппаратному таймеру платформы, на который не влияет изменение частоты процессора или технология Turbo Boost.

Надежно ли QPC работает в многопроцессорных системах, многоядерных системах и системах с гиперпотоками?

Да.

Как определить и проверить, работает ли QPC на моем компьютере?

Вам не нужно выполнять такие проверки.

Какие процессоры имеют невариантные TSCs? Как проверить, есть ли у моей системы невариантный TSC?

Вам не нужно выполнять эту проверку самостоятельно. Операционные системы Windows выполняют несколько проверок при инициализации системы, чтобы определить, подходит ли TSC в качестве основы для QPC. Однако в справочных целях можно определить, имеет ли процессор инвариантный TSC с помощью одного из следующих вариантов:

• служебная программа Coreinfo.exe из Windows Sysinternals
• проверка значений, возвращаемых инструкцией CPUID, относящейся к характеристикам TSC
• Документация производителя процессора

Ниже показаны сведения TSC-INVARIANT, предоставляемые служебной программой Windows Sysinternals Coreinfo.exe (www.sysinternals.com). Звездочка означает "True" (истина).

> Coreinfo.exe 

Coreinfo v3.2 - Dump information on system CPU and memory topology
Copyright (C) 2008-2012 Mark Russinovich
Sysinternals - www.sysinternals.com

 <unrelated text removed>

RDTSCP          * Supports RDTSCP instruction
TSC             * Supports RDTSC instruction
TSC-DEADLINE    - Local APIC supports one-shot deadline timer
TSC-INVARIANT   * TSC runs at constant rate

Работает ли QPC надежно на аппаратных платформах Windows RT?

Да.

Как часто происходит обновление состояния QPC?

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

Каковы вычислительные затраты на вызов QPC?

Стоимость вычислений QPC определяется главным образом базовой аппаратной платформой. Если регистр TSC используется в качестве основы для QPC, вычислительные затраты определяются главным образом тем, сколько времени требуется процессору для обработки инструкции RDTSC . Диапазон составляет от десятков циклов ЦП до нескольких сотен циклов ЦП в зависимости от используемого процессора. Если не удается использовать TSC, система выберет другую основу аппаратного времени. Так как эти базы времени расположены на материнской плате (например, на южном мосту PCI или PCH), вычислительные затраты на вызов выше, чем при использовании TSC (Time Stamp Counter), и часто находятся в пределах от 0,8 до 1,0 микросекунды в зависимости от скорости процессора и других факторов оборудования. Основную часть этой стоимости составляет время, необходимое для доступа к аппаратному устройству на материнской плате.

Требуется ли для QPC переход в ядро (системный вызов)?

Переход ядра не требуется, если система может использовать регистр TSC в качестве основы для QPC. Если система должна использовать другую базу времени, например таймер HPET или PM, требуется системный вызов.

Является ли счетчик производительности монотонным (не уменьшающимся)?

Да. QPC не идет назад.

Можно ли использовать счетчик производительности для упорядочивания событий во времени?

Да. Однако при сравнении результатов счетчика производительности, полученных из разных потоков, значения, отличающиеся на ± 1 тик, имеют неопределенный порядок, как если бы они имели идентичные метки времени.

Насколько точно счетчик производительности?

Ответ зависит от различных факторов. Дополнительные сведения см. в разделе "Низкоуровневые аппаратные характеристики часов".

Часто задаваемые вопросы о программировании с помощью QPC и TSC

Ниже приведены ответы на часто задаваемые вопросы о программировании с помощью QPC и TSCs.

Необходимо преобразовать выходные данные QPC в миллисекунды. Как избежать потери точности при преобразовании в типы double или float?

При выполнении вычислений по целым числам счетчиков производительности следует учитывать несколько моментов:

• Целочисленное деление потеряет остаток. Это может привести к потере точности в некоторых случаях.
• Преобразование между 64-разрядными целыми числами и плавающей запятой (double) может привести к потере точности, так как мантисса с плавающей запятой не может представлять все возможные целочисленные значения.
• Умножение 64-разрядных целых чисел может привести к переполнению целых чисел.

В соответствии с общим принципом, откладывайте выполнение этих вычислений и преобразований настолько долго, насколько это возможно, чтобы избежать накапливания ошибок.

Как преобразовать QPC в 100 наносекондных галок, чтобы добавить его в FILETIME?

Время файла — это 64-разрядное значение, представляющее число 100-наносекундных интервалов, прошедших с 12:00 1 января 1601 года по всемирному координированному времени (UTC). Время файла используется вызовами API Win32, возвращающими время суток, например GetSystemTimeAsFileTime и GetSystemTimePreciseAsFileTime. Напротив, QueryPerformanceCounter возвращает значения, представляющие время в единицах 1/(частота счетчика производительности, полученного из QueryPerformanceFrequency). Преобразование между этими двумя требует расчета отношения интервала QPC и 100-наносекундных интервалов. Будьте осторожны, чтобы избежать потери точности, так как значения могут быть небольшими (0,0000001 / 0,000000340).

Почему метка времени, возвращаемая из QPC, целое число со знаком?

Вычисления, связанные с метками времени QPC , могут включать вычитание. Используя подписанное значение, можно обрабатывать вычисления, которые могут привести к отрицательным значениям.

Как получить метки времени высокого разрешения из управляемого кода?

Вызовите метод Stopwatch.GetTimeStamp из класса System.Diagnostics.Stopwatch . Пример использования Stopwatch.GetTimeStamp см. в разделе "Получение меток времени высокого разрешения" из управляемого кода.

В каких случаях queryPerformanceFrequency возвращает значение FALSE или QueryPerformanceCounter возвращает ноль?

Это не происходит в любой системе под управлением Windows XP или более поздней версии, если вы передаете допустимые параметры функциям.

Нужно ли задать привязку потока к одному ядру для использования QPC?

Нет. Дополнительные сведения см. в руководстве по получению меток времени. Этот сценарий не является ни обязательным, ни желательным. Выполнение этого сценария может негативно повлиять на производительность приложения, ограничивая обработку до одного ядра или создавая узкое место на одном ядре, если несколько потоков устанавливают свое соответствие одному ядру при вызове QueryPerformanceCounter.

Низкоуровневые характеристики аппаратных часов

Характеристики низкоуровневых аппаратных часов показаны в этих разделах.

Абсолютные часы и часы разницы

Абсолютные часы обеспечивают точное время суток. Обычно они основаны на универсальном времени (UTC) и, следовательно, их точность зависит от того, насколько хорошо они синхронизированы со ссылкой на внешнее время. Дифференцированные часы измеряют интервалы времени и, как правило, не основаны на внешней временной эпохе. QPC — разностные часы, не синхронизированные с внешней эпохой времени или эталоном. При использовании QPC для измерения интервала времени обычно вы получаете лучшую точность, чем при использовании меток времени, производных от абсолютных часов. Это связано с тем, что процесс синхронизации времени абсолютного часов может привести к сменам фазы и частоты, которые повышают неопределенность краткосрочных измерений интервала времени.

Разрешение, точность, аккуратность и стабильность

QPC использует аппаратный счетчик в качестве основы. Аппаратные таймеры состоят из трех частей: генератор галок, счетчик, который подсчитывает галочки, и средства получения значения счетчика. Характеристики этих трех компонентов определяют разрешение, точность, точность и стабильность QPC.

Если аппаратный генератор выдает такты с постоянной скоростью, интервалы времени можно измерять, просто подсчитывая эти такты. Частота генерации тиков называется частотой и выражается в Герцах (Гц). Обратная величина частоты называется периодом или интервалом тика и выражается в соответствующей единице времени Международной системы единиц (SI), например, секунда, миллисекунда, микросекунда или наносекунда.

Точность таймера равна периоду. Разрешающая способность позволяет различать любые две метки времени и устанавливает нижнюю границу на наименьшие интервалы времени, которые можно измерять. Иногда это называется разрешением галок.

Цифровое измерение времени вносит неопределенность измерений ± 1 тика, так как цифровой счетчик работает в дискретных шагах, в то время как время непрерывно продвигается. Эта неопределенность называется ошибкой квантизации. Для типичных измерений интервала времени этот эффект часто может быть проигнорирован, так как квантизация ошибки гораздо меньше интервала времени, измеряемого.

Однако если измеряемый период мал и приближается к разрешению таймера, необходимо учесть эту ошибку квантования. Размер введенной ошибки — один период часов.

На следующих двух схемах иллюстрируется влияние неопределенности в ± 1 тик путем использования таймера с разрешением 1 единицы времени.

QueryPerformanceFrequency возвращает частоту QPC, а период и разрешение равны взаимному значению. Частота счетчика производительности, возвращаемая QueryPerformanceFrequency , определяется во время инициализации системы и не изменяется во время выполнения системы.

QueryPerformanceCounter считывает счетчик производительности и возвращает общее количество тиков, которые произошли с момента запуска операционной системы Windows, включая время, когда компьютер находился в состоянии сна, например в режиме ожидания, гибернации или подключенного ожидания.

В этих примерах показано, как вычислить интервал галочки и разрешение, а также как преобразовать число галок в значение времени.

Пример 1

QueryPerformanceFrequency возвращает значение 3 125 000 на определенном компьютере. Каков тактный интервал и разрешение измерений QPC на этом компьютере? Интервал галочки или период является обратным значением 3125 000, что составляет 0,00000320 (320 наносеконд). Таким образом, каждый тик представляет прохождение 320 наносекунд. Интервалы времени меньше 320 наносекунд нельзя измерять на этом компьютере.

Интервал такта = 1/(частота таймера)

Тактный интервал = 1/3,125,000 = 320 ns

Пример 2

На том же компьютере, что и в предыдущем примере, разница значений, возвращаемых из двух последовательных вызовов QPC , составляет 5. Сколько времени прошло между двумя звонками? 5 тиков, умноженных на 320 наносекунд, дает 1,6 микросекунда.

ВремяПрошло = Тики * Интервал тиков

ElapsedTime = 5 * 320 ns = 1,6 мкс

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

Точность = MAX [ Разрешение, Время доступа]

Например, рассмотрим гипотетический аппаратный таймер с разрешением 100 nanosecond и временем доступа 800 nanosecond. Это может быть так, если таймер платформы использовался вместо регистра TSC в качестве основы QPC. Таким образом, точность составит 800 наносекунд, не 100 наносекунд, как показано в этом вычислении.

Точность = MAX [800 ns,100 ns] = 800 ns

Эти два рисунка изображают этот эффект.

Если время доступа больше разрешающей способности, не пытайтесь повысить точность, предпринимая догадки. Другими словами, это ошибка, предполагающая, что метка времени принимается точно в середине, или в начале или конце вызова.

В отличие от этого, рассмотрим следующий пример, в котором время доступа QPC составляет всего 20 наносекунд, а разрешение аппаратных часов равно 100 наносекундам. Это может быть так, если регистр TSC использовался в качестве основы для QPC. Здесь точность ограничена разрешением часов.

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

Эта таблица содержит сведения о приблизительном разрешении, времени доступа и точности различных часов. Обратите внимание, что некоторые значения зависят от различных процессоров, аппаратных платформ и скоростей процессора.

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

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

Точность таймера относится к степени соответствия истинному или стандартному значению. Это зависит в первую очередь от способности кристаллического осциллятора обеспечивать такты на указанной частоте. Если частота колебаний слишком высока, часы будут "выполняться быстро", и измеренные интервалы будут отображаться дольше, чем они на самом деле; и если частота слишком низка, часы будут "выполняться медленно", и измеренные интервалы будут отображаться короче, чем они действительно.

Для типичных измерений интервала времени в течение короткой длительности (например, измерений времени отклика, измерений задержки сети и т. д.), точность аппаратного осилятеля обычно достаточна. Однако для некоторых измерений точность частоты колебания становится важной, особенно для длительных интервалов времени или при сравнении измерений, принятых на разных компьютерах. Оставшаяся часть этого раздела изучает последствия точности осциллятора.

Частота колебаний кристаллов устанавливается во время производственного процесса и указывается производителем с точки зрения указанной частоты плюс или минус производственной погрешности, выраженной в "частях на миллион" (ppm), называемой максимальной смещением частоты. Кристалл с указанной частотой 1000 000 Гц и максимальное смещение частоты ± 10 ppm будет в пределах спецификации, если его фактическая частота была от 999 990 Гц до 1000 010 Гц.

Заменив части фразы на миллион микросекундами в секунду, мы можем применить эту ошибку смещения частоты к измерениям интервала времени. Осциллятор со смещением +10 ppm будет иметь ошибку в 10 микросекунд в секунду. Соответственно, при измерении 1-секундного интервала он будет идти быстрее и измерять 1-секундный интервал как 0,999990 секунд.

Удобный ориентир заключается в том, что ошибка частоты 100 ppm вызывает погрешность на 8,64 секунды через 24 часа. Эта таблица представляет неопределенность измерения из-за накапливаемой ошибки в течение более длительных интервалов времени.

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

Кварцевые осцилляторы, которые используются в персональных компьютерах и серверах, обычно производятся с допустимым отклонением частоты ± 30 до 50 частей на миллион, и редко кристаллы могут иметь отклонение до 500 ppm. Хотя кристаллы с гораздо более жесткими ограничениями смещения частоты доступны, они более дороги и поэтому не используются в большинстве компьютеров.

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

Как показано в следующих примерах, ошибка смещения частоты аппаратных часов влияет на достижимую точность, а разрешение часов может быть менее важным.

Пример 1

Предположим, что вы выполняете измерения интервала времени с помощью осциллятора 1 МГц, который имеет разрешение 1 микросекунда, а также максимальную ошибку смещения частоты ±50 ppm. Теперь предположим, что смещение составляет ровно +50 ppm. Это означает, что фактическая частота будет составлять 1000 050 Гц. Если бы мы измерили интервал времени в 24 часа, наше измерение было бы на 4,3 секунды короче (23:59:55,7 измерено по сравнению с фактическим значением 24:00:00,0).

Секунды в день = 86400

Ошибка смещения частоты = 50 ppm = 0,00005

86 400 секунд * 0,00005 = 4,3 секунды

Пример 2

Предположим, что часы TSC процессора управляются кристаллическим осциллятором и имеют указанную частоту 3 ГГц. Это означает, что разрешение будет равно 1/3 000 000 000 или около 333 пикосеконд. Предположим, что кристалл, используемый для управления тактовыми часами процессора, имеет допуск частоты ±50 ppm, и фактически составляет +50 ppm. Несмотря на впечатляющее разрешение, измерение интервала времени в 24 часа все равно будет на 4,3 секунды короче. (23:59:55.7000000000 измерено по сравнению с 24:00:00.0000000000 фактическое).

Секунды в день = 86400

Ошибка смещения частоты = 50 ppm = 0,00005

86 400 секунд * 0,00005 = 4,3 секунды

Это показывает, что часы TSC с высоким разрешением не обязательно обеспечивают более точные измерения, чем более низкие часы разрешения.

Пример 3

Рассмотрите возможность использования двух разных компьютеров для измерения одного и того же 24-часового интервала времени. На обоих компьютерах имеется осциллятор с максимальной частотой смещения ± 50 ppm. Насколько может различаться измерение одного и того же интервала времени на этих двух системах? Как и в предыдущих примерах, ± 50 ppm дает максимальную ошибку ± 4,3 секунды после 24 часов. Если одна система спешит на 4,3 секунды, а другая отстаёт на 4,3 секунды, максимальная погрешность после 24 часов может достичь 8,6 секунды.

Секунды в день = 86400

Ошибка смещения частоты = ±50 ppm = ±0,00005

±(86 400 секунд * 0,00005) = ±4,3 секунды

Максимальное смещение между двумя системами = 8,6 секунды

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

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

Сведения о таймере оборудования

Регистрация TSC (x86 и x64)

Все современные процессоры Intel и AMD содержат регистр TSC, который является 64-разрядным регистром, который увеличивается на высоком уровне, как правило, равным часам процессора. Значение этого счетчика можно считывать с помощью машинных инструкций RDTSC или RDTSCP, обеспечивая очень низкое время доступа и вычислительные затраты в пределах десятков или сотен машинных циклов, что зависит от процессора.

Хотя регистр TSC кажется идеальным механизмом метки времени, ниже приведены обстоятельства, в которых она не может надежно функционировать в целях хранения времени:

• Не все процессоры имеют доступные регистры TSC, поэтому использование регистрации TSC в программном обеспечении напрямую создает проблему переносимости. (Windows выберет альтернативный источник времени для QPC в этом случае, что позволяет избежать проблемы переносимости.)
• Некоторые процессоры могут изменять частоту часов TSC или остановить обновление регистра TSC, что делает TSC непригодным для синхронизации по времени на этих процессорах. Как говорят, эти процессоры имеют невариантные регистры TSC. (Windows автоматически обнаруживает это и выбирает альтернативный источник времени для QPC.
• Даже если узел виртуализации имеет работоспособный TSC, динамическая миграция работающих виртуальных машин, если целевой узел виртуализации не имеет и не использует аппаратное масштабирование TSC, может привести к изменению частоты TSC, видимой гостям. Ожидается, что если этот тип динамической миграции возможен для гостя, гипервизор очищает бит функции инвариантной TSC в CPUID.
• В системах с несколькими процессорами или несколькими ядрами некоторые процессоры и системы не могут синхронизировать часы на каждом ядре с одинаковым значением. (Windows автоматически обнаруживает это и выбирает альтернативный источник времени для QPC.
• В некоторых крупных многопроцессорных системах может не удастся синхронизировать часы процессора до одного значения, даже если процессор имеет инвариантный TSC. (Windows автоматически обнаруживает это и выбирает альтернативный источник времени для QPC.
• Некоторые процессоры будут выполнять инструкции неупорядоченно. Это может привести к неправильному количеству циклов, когда RDTSC используется для последовательностей инструкций по времени, так как инструкция RDTSC может выполняться в другое время, чем указано в программе. Инструкция RDTSCP была введена на некоторых процессорах в ответ на эту проблему.

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

Во время инициализации системы Windows проверяет, подходит ли TSC для синхронизации времени и выполняет необходимую калибровку частоты и синхронизацию ядер процессоров.

Часы PM (x86 и x64)

Таймер ACPI, также известный как часы PM, был добавлен в системную архитектуру, чтобы обеспечить надежные метки времени независимо от скорости процессоров. Так как это была единственная цель этого таймера, она предоставляет метку времени в одном цикле часов, но она не предоставляет никаких других функций.

Таймер HPET (x86 и x64)

Таймер событий высокой точности (HPET) был разработан корпорацией Intel и Майкрософт для удовлетворения требований к времени мультимедиа и других приложений с учетом времени. В отличие от TSC, который является ресурсом на процессор, HPET является общим ресурсом на уровне платформы, хотя система может иметь несколько HPE. Поддержка HPET была в Windows с Windows Vista, а сертификация аппаратного логотипа Windows 7 и Windows 8 требует поддержки HPET на аппаратной платформе.

Универсальный счетчик системы таймера (Arm)

Платформы на основе ARM не имеют часов TSC, HPET или PM, как на платформах, основанных на Intel или AMD. Вместо этого процессоры Arm предоставляют универсальный таймер (иногда называемый универсальным таймером интервала или GIT), который содержит регистр системного счетчика (например, CNTVCT_EL0). Универсальный счетчик системы таймера — это источник времени с фиксированной частотой на уровне всей платформы. Он начинается с нуля при запуске и увеличивается с высокой скоростью. В Armv8.6 или более поздней версии это определяется как 1 ГГц, но необходимо определить, считывая регистр частоты часов, заданный ранним загрузочным ПО. Дополнительные сведения см. в главе "Универсальный таймер в состоянии AArch64" руководства "Справочник по архитектуре Arm для архитектуры A-profile" (DDI 0487).

Счетчик циклов (Arm)

Платформы на базе ARM предоставляют регистр счетчика циклов производительности, такой как PMCCNTR_EL0. Этот счетчик подсчитывает циклы часов процессора. Он не является инвариантным, и его единицы могут не быть сопоставлены с режимом реального времени. Не рекомендуется использовать этот регистр для получения меток времени.