Abrufen von Zeitstempeln mit hoher Auflösung

Windows bietet APIs, mit denen Sie zeitstempel mit hoher Auflösung erhalten oder Zeitintervalle messen können. Die primäre API für nativen Code ist QueryPerformanceCounter (QPC). Für Gerätetreiber ist die Kernelmodus-API KeQueryPerformanceCounter. Für verwalteten Code verwendet die System.Diagnostics.Stopwatch-Klasse QPC als genaue Zeitbasis.

QPC ist unabhängig von externen Zeitverweisen und wird nicht mit ihnen synchronisiert. Verwenden Sie GetSystemTimePreciseAsFileTime,um Zeitstempel abzurufen, die mit einem externen Zeitverweis synchronisiert werden können, z. B. koordinierte Weltzeit (UTC) für die Verwendung in messungen mit hoher Auflösung zur Tageszeit.

Zeitstempel und Zeitintervallmessungen sind ein wesentlicher Bestandteil von Computer- und Netzwerkleistungsmessungen. Zu diesen Leistungsmessungsvorgängen gehören die Berechnung von Antwortzeit, Durchsatz und Latenz sowie die Codeausführung für die Profilerstellung. Jeder dieser Vorgänge umfasst eine Messung der Aktivitäten, die während eines Zeitintervalls auftreten, das durch ein Start- und ein Endereignis definiert wird, das unabhängig von externen Tageszeitverweisen sein kann.

QPC ist in der Regel die beste Methode, um Zeitstempelereignisse zu verwenden und kleine Zeitintervalle zu messen, die auf demselben System oder virtuellen Computer auftreten. Erwägen Sie die Verwendung von GetSystemTimePreciseAsFileTime, wenn Sie Ereignisse auf mehreren Computern zeitstempeln möchten, vorausgesetzt, dass jeder Computer an einem Zeitsynchronisierungsschema wie Network Time Protocol (NTP) beteiligt ist. QPC hilft Ihnen, Schwierigkeiten zu vermeiden, die bei anderen Zeitmessungsansätzen auftreten können, z. B. das direkte Lesen des Zeitstempelzählers (Time Stamp Counter, TSC) des Prozessors.

QPC-Unterstützung in Windows Versionen

QPC wurde in Windows 2000 und Windows XP eingeführt und hat sich weiterentwickelt, um die Verbesserungen der Hardwareplattform und der Prozessoren zu nutzen. Hier werden die Merkmale von QPC in verschiedenen Windows beschrieben, um Sie bei der Wartung von Software zu unterstützen, die auf diesen Windows wird.

Windows XP und Windows 2000

QPC ist auf Windows XP und Windows 2000 verfügbar und funktioniert auf den meisten Systemen gut. Das BIOS einiger Hardwaresysteme gibt jedoch die Hardware-CPU-Merkmale (ein nicht invariantes TSC) nicht richtig an, und einige Systeme mit mehreren Kernen oder mehreren Prozessoren verwendeten Prozessoren mit TSCs, die nicht kernübergreifend synchronisiert werden konnten. Systeme mit fehlerhafter Firmware, auf denen diese Versionen von Windows ausgeführt werden, bieten möglicherweise nicht denselben QPC-Lesefehler auf verschiedenen Kernen, wenn sie TSC als Grundlage für QPC verwenden.

Windows Vista und Windows Server 2008

Alle Computer, die mit Windows Vista und Windows Server 2008 ausgeliefert wurden, verwendeten einen Plattformzähler (High Precision Event Timer (HPET)) oder den ACPI Power Management Timer (PM-Timer) als Grundlage für QPC. Solche Plattformzeiter haben eine höhere Zugriffslatenz als der TSC und werden von mehreren Prozessoren gemeinsam genutzt. Dies schränkt die Skalierbarkeit von QPC ein, wenn es von mehreren Prozessoren gleichzeitig aufgerufen wird.

Windows 7 und Windows Server 2008 R2

Die meisten Windows 7- und Windows Server 2008 R2-Computer verfügen über Prozessoren mit konstanten TSCs und verwenden diese Leistungsindikatoren als Grundlage für QPC. TSCs sind hardwareleistungsbasierte Leistungsindikatoren mit hoher Auflösung pro Prozessor, auf die mit sehr geringer Latenz und geringem Mehraufwand zugegriffen werden kann (je nach Prozessortyp in der Reihenfolge von 10 oder 100Ern von Computerzyklen). Windows 7 und Windows Server 2008 R2 verwenden TSCs als Grundlage für QPC auf Domänensystemen mit nur einer Uhr, bei denen das Betriebssystem (oder der Hypervisor) die einzelnen TSCs während der Systemin initialisierung über alle Prozessoren hinweg eng synchronisieren kann. In solchen Systemen sind die Kosten für das Lesen des Leistungsindikators im Vergleich zu Systemen, die einen Plattformzähler verwenden, deutlich niedriger. Darüber hinaus gibt es keinen zusätzlichen Mehraufwand für gleichzeitige Aufrufe, und Benutzermodusabfragen umgehen häufig Systemaufrufe, wodurch der Mehraufwand weiter reduziert wird. Auf Systemen, in denen der TSC nicht für die Zeitmessung geeignet ist, wählt Windows automatisch einen Plattformzähler (entweder den HPET-Timer oder den ACPI PM-Timer) als Grundlage für QPC aus.

Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2

Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 verwenden TSCs als Grundlage für den Leistungsindikator. Der TSC-Synchronisierungsalgorithmus wurde erheblich verbessert, um große Systeme mit vielen Prozessoren besser aufnehmen zu können. Darüber hinaus wurde Unterstützung für die neue API zur genauen Tageszeit hinzugefügt, die das Abrufen präziser Zeitstempel für die Wanduhr vom Betriebssystem ermöglicht. Weitere Informationen finden Sie unter GetSystemTimePreciseAsFileTime. Auf Windows RT PC-Plattformen basiert der Leistungsindikator entweder auf einem proprietären Plattformzähler oder auf dem Systemzähler, der vom generischen Windows RT-PC-Timer bereitgestellt wird, wenn die Plattform so ausgestattet ist.

Leitfaden zum Abrufen von Zeitstempeln

Windows hat und investiert weiterhin in die Bereitstellung eines zuverlässigen und effizienten Leistungsindikators. Wenn Sie Zeitstempel mit einer Auflösung von 1 Mikrosekunde oder besser benötigen und die Zeitstempel nicht mit einem externen Zeitverweis synchronisiert werden müssen, wählen Sie QueryPerformanceCounter, KeQueryPerformanceCounteroder KeQueryInterruptTimePrecise aus. Wenn Sie UTC-synchronisierte Zeitstempel mit einer Auflösung von 1 Mikrosekunde oder besser benötigen, wählen Sie GetSystemTimePreciseAsFileTime oder KeQuerySystemTimePrecise aus.

Auf einer relativ kleinen Anzahl von Plattformen, die das TSC-Register nicht als QPC-Basis verwenden können, z. B. aus Gründen, die unter Hardware-Timerinformationenerläutert werden, kann das Abrufen von Zeitstempeln mit hoher Auflösung erheblich teurer sein als das Abrufen von Zeitstempeln mit geringerer Auflösung. Wenn eine Auflösung von 10 bis 16 Millisekunden ausreicht, können Sie GetTickCount64, QueryInterruptTime, QueryUnbiasedInterruptTime, KeQueryInterruptTimeoder KeQueryUnbiasedInterruptTime verwenden, um Zeitstempel zu erhalten, die nicht mit einem externen Zeitverweis synchronisiert werden. Verwenden Sie für UTC-synchronisierte Zeitstempel GetSystemTimeAsFileTime oder KeQuerySystemTime. Wenn eine höhere Auflösung erforderlich ist, können Sie stattdessen QueryInterruptTimePrecise, QueryUnbiasedInterruptTimePreciseoder KeQueryInterruptTimePrecise verwenden, um Zeitstempel zu erhalten.

Im Allgemeinen sind die Leistungsindikatorergebnisse für alle Prozessoren in Systemen mit mehreren Kernen und mehreren Prozessoren konsistent, auch wenn sie in verschiedenen Threads oder Prozessen gemessen werden. Hier sind einige Ausnahmen von dieser Regel:

  • Vor Windows Vista-Betriebssystemen, die auf bestimmten Prozessoren ausgeführt werden, kann diese Konsistenz aus einem der folgenden Gründe verletzen:

    • Die Hardwareprozessoren verfügen über ein nicht invariantes TSC, und das BIOS gibt diese Bedingung nicht ordnungsgemäß an.
    • Der verwendete TSC-Synchronisierungsalgorithmus eignete sich nicht für Systeme mit einer großen Anzahl von Prozessoren.
  • Wenn Sie Leistungsindikatorergebnisse vergleichen, die von verschiedenen Threads erfasst werden, sollten Sie Werte berücksichtigen, die sich um einen ± 1 Teilstrich unterscheiden, um eine mehrdeutige Reihenfolge zu erhalten. Wenn die Zeitstempel aus demselben Thread genommen werden, gilt ± 1 Tick-Unsicherheit nicht. In diesem Kontext bezieht sich der Begriff Tick auf einen Zeitraum, der gleich 1 ÷ ist (die Häufigkeit des Leistungsindikators, der von QueryPerformanceFrequency ermittelt wird).

Wenn Sie den Leistungsindikator auf großen Serversystemen mit Domänen mit mehreren Takten verwenden, die nicht in der Hardware synchronisiert sind, bestimmt Windows, dass der TSC nicht zu Zeitsteuerungszwecken verwendet werden kann, und wählt einen Plattformzähler als Grundlage für QPC aus. Obwohl dieses Szenario weiterhin zuverlässige Zeitstempel liefert, sind die Zugriffslatenz und Skalierbarkeit beeinträchtigt. Verwenden Sie daher, wie bereits im vorherigen Nutzungsleitfaden erwähnt, nur die APIs, die eine Auflösung von 1 Mikrosekunden oder eine bessere Auflösung bereitstellen, wenn eine solche Auflösung erforderlich ist. Das TSC wird als Grundlage für QPC auf Domänensystemen mit mehreren Uhren verwendet, die die Hardwaresynchronisierung aller Prozessoruhrdomänen umfassen, da sie dadurch effektiv als einzelnes Uhrdomänensystem funktionieren.

Die Häufigkeit des Leistungsindikators wird beim Systemstart festgelegt und ist für alle Prozessoren konsistent, sodass Sie nur die Häufigkeit von QueryPerformanceFrequency abfragen müssen, während die Anwendung initialisiert wird, und dann das Ergebnis zwischenspeichern müssen.

Virtualisierung

Es wird erwartet, dass der Leistungsindikator zuverlässig auf allen virtuellen Gastcomputern funktioniert, die auf ordnungsgemäß implementierten Hypervisoren ausgeführt werden. Hypervisoren, die der Schnittstelle der Hypervisorversion 1.0 entsprechen und die Referenzzeitreferenz zur Verfügung stellen, können jedoch einen erheblich geringeren Mehraufwand bieten. Weitere Informationen zu Hypervisorschnittstellen und -benutzeroberflächen finden Sie unter Hypervisorspezifikationen.

Direkte TSC-Nutzung

Wir raten dringend davon ab, die RDTSC- oder RDTSCP-Prozessoranweisung zum direkten Abfragen des TSC zu verwenden, da Sie bei einigen Versionen von Windows, bei Livemigrationen virtueller Computer und auf Hardwaresystemen ohne invariante oder eng synchronisierte TSCs keine zuverlässigen Ergebnisse erhalten. Stattdessen empfehlen wir Ihnen, QPC zu verwenden, um die Abstraktion, Konsistenz und Portabilität zu nutzen, die es bietet.

Beispiele für das Abrufen von Zeitstempeln

Die verschiedenen Codebeispiele in diesen Abschnitten zeigen, wie Zeitstempel erhalten werden.

Verwenden von QPC in nativem Code

In diesem Beispiel wird gezeigt, wie QPC in nativem C- und C++-Code verwendet wird.

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;

Abrufen von Zeitstempeln mit hoher Auflösung aus verwaltetem Code

In diesem Beispiel wird die Verwendung der System.Diagnostics.Stopwatch-Klasse mit verwaltetem Code veranschaulicht.

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);

Die System.Diagnostics.Stopwatch-Klasse bietet auch mehrere praktische Methoden zum Durchführen von Zeitintervallmessungen.

Verwenden von QPC aus dem Kernelmodus

Der Windows-Kernel ermöglicht den Kernelmoduszugriff auf den Leistungsindikator über KeQueryPerformanceCounter, von dem sowohl der Leistungsindikator als auch die Leistungshäufigkeit ermittelt werden können. KeQueryPerformanceCounter ist nur im Kernelmodus verfügbar und wird für Writer von Gerätetreibern und anderen Kernelmoduskomponenten bereitgestellt.

In diesem Beispiel wird die Verwendung von KeQueryPerformanceCounter im C- und C++-Kernelmodus veranschaulicht.

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;

Allgemeine häufig gestellte Fragen zu QPC und TSC

Hier finden Sie Antworten auf häufig gestellte Fragen zu QPC und TSCs im Allgemeinen.

Ist QueryPerformanceCounter() mit der Win32-Funktion GetTickCount() oder GetTickCount64() identisch?

Nein. GetTickCount und GetTickCount64 stehen nicht im Zusammenhang mit QPC. GetTickCount und GetTickCount64 geben die Anzahl von Millisekunden seit dem Start des Systems zurück.

Sollte ich QPC verwenden oder die RDTSC/RDTSCP-Anweisungen direkt aufrufen?

Um Richtigkeits- und Portabilitätsprobleme zu vermeiden, wird dringend empfohlen, QPC anstelle des TSC-Registers oder der RDTSC- oder RDTSCP-Prozessoranweisungen zu verwenden.

Was ist die Beziehung von QPC zu einer externen Zeitepoche? Kann es mit einer externen Epoche wie UTC synchronisiert werden?

QPC basiert auf einem Hardwarezähler, der nicht mit einem externen Zeitverweis wie UTC synchronisiert werden kann. Verwenden Sie GetSystemTimePreciseAsFileTime,um genaue Zeitstempel für die Tageszeit zu erhalten, die mit einer externen UTC-Referenz synchronisiert werden können.

Ist QPC von Sommerzeit, Schaltsekunden, Zeitzonen oder Systemzeitänderungen betroffen, die vom Administrator vorgenommen wurden?

Nein. QPC ist vollständig unabhängig von systemzeit und UTC.

Wird die QPC-Genauigkeit durch Prozessorfrequenzänderungen beeinflusst, die durch die Energieverwaltung oder Turbo Boost-Technologie verursacht werden?

Nein. Wenn der Prozessor über einen invarianten TSC verfügt, ist der QPC von diesen Änderungen nicht betroffen. Wenn der Prozessor nicht über ein invariantes TSC verfügt, wird QPC auf einen Plattformhardware-Timer zurückverwendet, der nicht von Änderungen der Prozessorfrequenz oder Turbo Boost-Technologie betroffen ist.

Funktioniert QPC zuverlässig auf Systemen mit mehreren Prozessoren, Systemen mit mehreren Kernen und Systemen mit Hyperthreading?

Ja

Gewusst wie und überprüfen Sie, ob QPC auf meinem Computer funktioniert?

Sie müssen solche Überprüfungen nicht durchführen.

Welche Prozessoren verfügen über nicht invariante TSCs? Wie kann ich überprüfen, ob mein System über ein nicht invariantes TSC verfügt?

Sie müssen diese Überprüfung nicht selbst durchführen. Windows Betriebssystemen führen mehrere Überprüfungen bei der Systemin initialisierung durch, um zu ermitteln, ob der TSC als Grundlage für QPC geeignet ist. Zu Referenzzwecken können Sie jedoch ermitteln, ob Ihr Prozessor über einen invarianten TSC verfügt, indem Sie einen der folgenden Schritte verwenden:

  • Das Coreinfo.exe-Hilfsprogramm Windows Sysinternals
  • Überprüfen der von der CPUID-Anweisung zurückgegebenen Werte für die TSC-Merkmale
  • Dokumentation des Prozessorherstellers

Das folgende Beispiel zeigt die TSC-INVARIANT-Informationen, die vom hilfsprogramm Windows Sysinternals Coreinfo.exe bereitgestellt werden (www.sysinternals.com). Ein Sternchen bedeutet "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

Funktioniert QPC zuverlässig auf Windows RT PC-Hardwareplattformen?

Ja

Wie oft führt QPC ein Rollover durch?

Nicht weniger als 100 Jahre nach dem letzten Systemstart und möglicherweise länger basierend auf dem verwendeten zugrunde liegenden Hardware-Timer. Für die meisten Anwendungen ist der Rollover kein Problem.

Was sind die Berechnungskosten für den Aufruf von QPC?

Die Berechnungskosten für Aufrufe von QPC werden in erster Linie von der zugrunde liegenden Hardwareplattform bestimmt. Wenn das TSC-Register als Grundlage für QPC verwendet wird, werden die Berechnungskosten in erster Linie durch die Verarbeitung einer RDTSC-Anweisung durch den Prozessor bestimmt. Diese Zeit reicht von 10s von CPU-Zyklen bis zu mehreren hundert CPU-Zyklen, abhängig vom verwendeten Prozessor. Wenn das TSC nicht verwendet werden kann, wählt das System eine andere Hardwarezeitbasis aus. Da sich diese Zeitbasen auf der Hauptplatine befinden (z. B. auf der PCI-Süd-Brücke oder PCH), sind die Berechnungskosten pro Aufruf höher als der TSC und liegen abhängig von der Prozessorgeschwindigkeit und anderen Hardwarefaktoren häufig in der Nähe von 0,8 bis 1,0 Mikrosekunden. Diese Kosten werden durch die Zeit, die für den Zugriff auf das Hardwaregerät auf der Hauptplatine erforderlich ist, 1st.

Erfordert QPC einen Kernelübergang (Systemaufruf)?

Ein Kernelübergang ist nicht erforderlich, wenn das System das TSC-Register als Grundlage für QPC verwenden kann. Wenn das System eine andere Zeitbasis verwenden muss, z. B. den HPET- oder PM-Timer, ist ein Systemaufruf erforderlich.

Ist der Leistungsindikator monoton (nicht abnehmend)?

Ja

Kann der Leistungsindikator verwendet werden, um Ereignisse in der Zeit zu bestellen?

Ja. Beim Vergleich von Leistungsindikatorergebnissen, die von verschiedenen Threads erfasst werden, haben Werte, die sich um ± 1 Tick unterscheiden, jedoch eine mehrdeutige Reihenfolge, als hätten sie einen identischen Zeitstempel.

Wie genau ist der Leistungsindikator?

Die Antwort hängt von einer Vielzahl von Faktoren ab. Weitere Informationen finden Sie unter Low-level hardware clock characteristics (Hardwareuhrmerkmale auf niedriger Ebene).

Häufig gestellte Fragen zur Programmierung mit QPC und TSC

Hier finden Sie Antworten auf häufig gestellte Fragen zur Programmierung mit QPC und TSCs.

Ich muss die QPC-Ausgabe in Millisekunden konvertieren. Wie kann ich Genauigkeitsverlust bei der Konvertierung in double oder float vermeiden?

Beim Ausführen von Berechnungen für ganzzahlige Leistungsindikatoren sind mehrere Dinge zu beachten:

  • Die Division ganzer Zahlen verliert den Rest. Dies kann in einigen Fällen zu Genauigkeitsverlusten führen.
  • Die Konvertierung zwischen 64-Bit-Ganzzahlen und Gleitkommazahlen (double) kann zu Genauigkeitsverlusten führen, da die Gleitkomma-Mantisse nicht alle möglichen ganzzahligen Werte darstellen kann.
  • Die Multiplikation von 64-Bit-Ganzzahlen kann zu einem Ganzzahlüberlauf führen.

Im Allgemeinen sollten diese Berechnungen und Konvertierungen so lange wie möglich verzögert werden, um eine Verbundbildung der eingeführten Fehler zu vermeiden.

Wie kann ich QPC in 100 Nanosekunden-Ticks konvertieren, damit ich es einer FILETIME hinzufügen kann?

Eine Dateizeit ist ein 64-Bit-Wert, der die Anzahl von 100-Nanosekunden-Intervallen darstellt, die seit 12:00 Uhr verstrichen sind. 1. Januar 1601 koordinierte Weltzeit (UTC). Dateizeiten werden von Win32-API-Aufrufen verwendet, die die Tageszeit zurückgeben, z. B. GetSystemTimeAsFileTime und GetSystemTimePreciseAsFileTime. Im Gegensatz dazu gibt QueryPerformanceCounter Werte zurück, die die Zeit in Einheiten von 1/darstellen (die Häufigkeit des Leistungsindikators, der von QueryPerformanceFrequency ermittelt wurde). Für die Konvertierung zwischen den beiden Ist-Intervallen muss das Verhältnis des QPC-Intervalls und der Intervalle von 100 Nanosekunden berechnet werden. Achten Sie darauf, genauigkeitsverlust zu vermeiden, da die Werte klein sein können (0,0000001 / 0,000000340).

Warum ist der Zeitstempel, der von QPC zurückgegeben wird, eine ganze Zahl mit Vorzeichen?

Berechnungen, die QPC-Zeitstempel umfassen, können subtrahiert werden. Mithilfe eines Werts mit Vorsigniert können Sie Berechnungen verarbeiten, die möglicherweise negative Werte ergeben.

Wie erhalte ich Zeitstempel mit hoher Auflösung aus verwaltetem Code?

Rufen Sie die Stopwatch.GetTimeStamp-Methode aus der System.Diagnostics.Stopwatch-Klasse auf. Ein Beispiel für die Verwendung von Stopwatch.GetTimeStamp finden Sie unter Abrufen von Zeitstempeln mit hoher Auflösung aus verwaltetem Code.

Unter welchen Umständen gibt QueryPerformanceFrequency FALSE oder QueryPerformanceCounter 0 (null) zurück?

Dies tritt nicht auf einem System auf, auf dem Windows XP oder höher ausgeführt wird.

Muss ich die Threadaffinität auf einen einzelnen Kern festlegen, um QPC verwenden zu können?

Nein. Weitere Informationen finden Sie unter Leitfaden zum Abrufen von Zeitstempeln. Dieses Szenario ist weder erforderlich noch wünschenswert. Das Ausführen dieses Szenarios kann sich negativ auf die Leistung Ihrer Anwendung auswirken, indem die Verarbeitung auf einen Kern eingeschränkt oder ein Engpass für einen einzelnen Kern verursacht wird, wenn mehrere Threads ihre Affinität beim Aufrufen von QueryPerformanceCounterauf denselben Kern festlegen.

Hardwareuhrmerkmale auf niedriger Ebene

In diesen Abschnitten werden Hardwareuhrmerkmale auf niedriger Ebene gezeigt.

Absolute Uhren und Differenzuhren

Absolute Uhren bieten genaue Tageszeitwerte. Sie basieren in der Regel auf koordinierte Weltzeit (UTC) und daher hängt ihre Genauigkeit teilweise davon ab, wie gut sie mit einem externen Zeitverweis synchronisiert werden. Differenzuhren messen Zeitintervalle und basieren in der Regel nicht auf einer externen Zeitepoche. QPC ist eine Differenzuhr und wird nicht mit einer externen Zeitepoche oder einem externen Verweis synchronisiert. Wenn Sie QPC für Zeitintervallmessungen verwenden, erhalten Sie in der Regel eine bessere Genauigkeit als bei Verwendung von Zeitstempeln, die von einer absoluten Uhr abgeleitet sind. Dies liegt daran, dass der Prozess der Synchronisierung der Zeit einer absoluten Uhr Phasen- und Häufigkeitsverschiebungen zur Verunsicherung kurzfristiger Zeitintervallmessungen führen kann.

Auflösung, Genauigkeit, Genauigkeit und Stabilität

QPC verwendet einen Hardwarezähler als Grundlage. Hardwarezeitgeber bestehen aus drei Teilen: einem Tick-Generator, einem Zähler, der die Ticks zählt, und einem Mittel zum Abrufen des Indikatorwerts. Die Merkmale dieser drei Komponenten bestimmen die Auflösung, Genauigkeit, Genauigkeit und Stabilität von QPC.

Wenn ein Hardwaregenerator Takte mit konstanter Rate zur Verfügung stellt, können Zeitintervalle durch einfaches Zählen dieser Ticks gemessen werden. Die Rate, mit der die Ticks generiert werden, wird als Häufigkeit bezeichnet und in Hertz (Hz) ausgedrückt. Die Reziprok der Häufigkeit wird als Zeitraum oder Taktintervall bezeichnet und in einer entsprechenden SI-Zeiteinheit (z. B. Sekunde, Millisekunde, Mikrosekunde oder Nanosekunde) ausgedrückt.

Zeitintervall

Die Auflösung des Timers entspricht dem Punkt. Die Auflösung bestimmt die Fähigkeit, zwischen zwei beliebigen Zeitstempeln zu unterscheiden, und legt eine untere Grenze für die kleinsten Zeitintervalle fest, die gemessen werden können. Dies wird manchmal als Tickauflösung bezeichnet.

Die digitale Zeitmessung führt zu einer verunsicherten Messung ± 1 Tick, da der digitale Zähler in diskreten Schritten schreitet, während die Zeit kontinuierlich schreitet. Diese Unsicherheit wird als Quantisierungsfehler bezeichnet. Bei typischen Zeitintervallmessungen kann dieser Effekt häufig ignoriert werden, da der Quantisierungsfehler viel kleiner als das gemessene Zeitintervall ist.

Digitale Zeitmessung

Wenn der gemessene Zeitraum jedoch klein ist und sich der Auflösung des Timers nähert, müssen Sie diesen Quantisierungsfehler berücksichtigen. Die Größe des eingeführten Fehlers ist die Eines-Uhr-Zeitraums.

Die folgenden beiden Diagramme veranschaulichen die Auswirkungen der ± 1 Tick-Unschärfe, indem ein Timer mit einer Auflösung von einer Zeiteinheit verwendet wird.

Tickunsicherheit

QueryPerformanceFrequency gibt die Häufigkeit von QPCzurück, und Zeitraum und Auflösung sind gleich dem Reziprok dieses Werts. Die Häufigkeit des Leistungsindikators, die QueryPerformanceFrequency zurückgibt, wird während der Systeminitialisierung bestimmt und ändert sich nicht, während das System ausgeführt wird.

Hinweis

Es können Fälle vorhanden sein, in denen QueryPerformanceFrequency nicht die tatsächliche Häufigkeit des Hardware-Tickgenerators zurückgibt. In vielen Fällen gibt QueryPerformanceFrequency beispielsweise die TSC-Häufigkeit dividiert durch 1024 zurück. und bei Hyper-V beträgt die Leistungsindikatorfrequenz immer 10 MHz, wenn der virtuelle Gastcomputer unter einem Hypervisor ausgeführt wird, der die Hypervisor-Schnittstelle der Version 1.0implementiert. Gehen Sie daher nicht davon aus, dass QueryPerformanceFrequency die genaue TSC-Häufigkeit zurückgibt.

QueryPerformanceCounter liest den Leistungsindikator und gibt die Gesamtzahl der Ticks zurück, die seit dem Starten des Windows Betriebssystems aufgetreten sind, einschließlich der Zeit, zu der sich der Computer im Standbymodus, Ruhezustand oder verbundenen Standbymodus befand.

Diese Beispiele zeigen, wie das Taktintervall und die Auflösung berechnet und die Taktanzahl in einen Zeitwert konvertiert wird.

Beispiel 1

QueryPerformanceFrequency gibt den Wert 3.125.000 auf einem bestimmten Computer zurück. Wie lautet das Taktintervall und die Auflösung von QPC-Messungen auf diesem Computer? Das Taktintervall bzw. der Zeitraum ist der Kehrwert von 3.125.000, was 0,0000000320 (320 Nanosekunden) entspricht. Daher stellt jeder Teilstrich die Übergabe von 320 Nanosekunden dar. Zeitintervalle, die kleiner als 320 Nanosekunden sind, können auf diesem Computer nicht gemessen werden.

Taktintervall = 1/(Leistungshäufigkeit)

Taktintervall = 1/3.125.000 = 320 ns

Beispiel 2

Auf demselben Computer wie im vorherigen Beispiel beträgt der Unterschied zwischen den Werten, die von zwei aufeinander folgenden Aufrufen von QPC zurückgegeben werden, 5. Wie viel Zeit ist zwischen den beiden Aufrufen verstrichen? 5 Ticks multipliziert mit 320 Nanosekunden ergeben 1,6 Mikrosekunden.

ElapsedTime = Ticks * Tick Interval

ElapsedTime = 5 * 320 ns = 1,6 μs

Es dauert eine Weile, bis auf den Tickzähler von der Software zugegriffen (gelesen) wird, und diese Zugriffszeit kann die Genauigkeit der Zeitmessung verringern. Dies liegt daran, dass die Mindestintervallzeit (das kleinste Zeitintervall, das gemessen werden kann) größer als die Auflösung und die Zugriffszeit ist.

Genauigkeit = [ MAX-Auflösung, AccessTime]

Betrachten Sie beispielsweise einen hypothetischen Hardwaretimer mit einer Auflösung von 100 Nanosekunden und einer Zugriffszeit von 800 Nanosekunden. Dies kann der Fall sein, wenn der Plattformtimer anstelle des TSC-Registers als Grundlage für QPCverwendet wurde. Daher wäre die Genauigkeit 800 Nanosekunden und nicht 100 Nanosekunden, wie in dieser Berechnung gezeigt.

Genauigkeit = MAX [ 800 ns,100 ns ] = 800 ns

Diese beiden Abbildungen zeigen diesen Effekt.

qpc-Zugriffszeit

Wenn die Zugriffszeit größer als die Auflösung ist, versuchen Sie nicht, die Genauigkeit durch Erraten zu verbessern. Anders ausgedrückt: Es ist ein Fehler, davon auszugehen, dass der Zeitstempel genau in der Mitte, am Anfang oder am Ende des Aufrufs liegt.

Betrachten Sie im Gegensatz dazu das folgende Beispiel, in dem die QPC-Zugriffszeit nur 20 Nanosekunden beträgt und die Hardwareuhrauflösung 100 Nanosekunden beträgt. Dies kann der Fall sein, wenn das TSC-Register als Grundlage für QPC verwendet wurde. Hier wird die Genauigkeit durch die Uhrauflösung beschränkt.

qpc precision

In der Praxis finden Sie Zeitquellen, für die die zum Lesen des Zählers erforderliche Zeit größer oder kleiner als die Auflösung ist. In beiden Fällen ist die Genauigkeit die größere der beiden.

Diese Tabelle enthält Informationen zur ungefähren Auflösung, Zugriffszeit und Genauigkeit einer Vielzahl von Uhren. Beachten Sie, dass einige der Werte mit unterschiedlichen Prozessoren, Hardwareplattformen und Prozessorgeschwindigkeiten variieren.

Uhrquelle Nominelle Taktfrequenz Uhrauflösung Zugriffszeit (typisch) Precision
PC RTC 64 Hz 15,625 Millisekunden
Abfrageleistungsindikator mit TSC mit einer Prozessoruhr mit 3 GHz 3 MHz 333 Nanosekunden 30 Nanosekunden 333 Nanosekunden
RDTSC-Computeranweisung auf einem System mit einer Zykluszeit von 3 GHz 3 GHz 333 Pikosekunden 30 Nanosekunden 30 Nanosekunden

Da QPC einen Hardwarezähler verwendet, können Sie sich mit den Funktionen und Einschränkungen von QPC auskennen, wenn Sie einige grundlegende Merkmale von Hardwareindikatoren verstehen.

Der am häufigsten verwendete Hardware-Tick-Generator ist ein Gitteroszillator. Das Leuchtmittel ist ein kleines Stück Desins oder anderes Materialien, das zierliche Merkmale aufweist, die einen kostengünstigen Frequenzverweis mit hervorragender Stabilität und Genauigkeit bieten. Diese Häufigkeit wird verwendet, um die Ticks zu generieren, die von der Uhr gezählt werden.

Die Genauigkeit eines Timers bezieht sich auf den Grad der Konformität mit einem true- oder standard-Wert. Dies hängt in erster Linie von der Fähigkeit des Oszillators ab, Ticks mit der angegebenen Häufigkeit bereitzustellen. Wenn die Frequenz der Oszillation zu hoch ist, wird die Uhr "schnell ausgeführt", und gemessene Intervalle erscheinen länger als sie tatsächlich sind. und wenn die Häufigkeit zu niedrig ist, wird die Uhr langsam ausgeführt, und gemessene Intervalle erscheinen kürzer als sie tatsächlich sind.

Bei typischen Zeitintervallmessungen für kurze Zeiträume (z. B. Messungen der Antwortzeit, Messungen der Netzwerklatenz usw.) ist die Genauigkeit des Hardwareoszillators in der Regel ausreichend. Bei einigen Messungen ist die Genauigkeit der Oszillationsfrequenz jedoch wichtig, insbesondere bei langen Zeitintervallen oder beim Vergleichen von Messungen, die auf verschiedenen Computern durchgeführt wurden. Im weiteren Verlauf dieses Abschnitts werden die Auswirkungen der Oszillationsgenauigkeit untersucht.

Die Frequenz der Oszillation der Steine wird während des Herstellungsprozesses festgelegt und vom Hersteller in Form einer angegebenen Frequenz plus oder minus einer Fertigungstoleranz angegeben, die in "Parts per Million" (ppm) ausgedrückt wird. Dies wird als Offset mit maximaler Frequenz bezeichnet. EinHz mit einer angegebenen Frequenz von 1.000.000 Hz und einem maximalen Frequenzoffset von ± 10 ppm würde innerhalb der Spezifikationsgrenzen liegen, wenn seine tatsächliche Frequenz zwischen 999.990 Hz und 1.000.010 Hz liegt.

Indem wir die Ausdrucksteile pro Million durch Mikrosekunden pro Sekunde ersetzen, können wir diesen Frequenzoffsetfehler auf Zeitintervallmessungen anwenden. Ein Oszillator mit einem Offset von + 10 ppm würde einen Fehler von 10 Mikrosekunden pro Sekunde aufweisen. Entsprechend würde beim Messen eines Intervalls von einer Sekunde schnell ausgeführt und ein Intervall von 1 Sekunde mit 0,999990 Sekunden gemessen.

Ein praktischer Verweis ist, dass ein Häufigkeitsfehler von 100 ppm nach 24 Stunden einen Fehler von 8,64 Sekunden verursacht. Diese Tabelle zeigt die Maßunsicherheit aufgrund des akkumulierten Fehlers für längere Zeitintervalle.

Dauer des Zeitintervalls Maßunsicherheit aufgrund eines akkumulierten Fehlers mit +/- 10 PPM Häufigkeitstoleranz
1 Mikrosekunde ± 10 Picosekunden (10-12)
Eine Millisekunde ± 10 Nanosekunden (10–9)
1 Sekunde ± 10 Mikrosekunden
1 Stunde ± 60 Mikrosekunden
1 Tag ± 0,86 Sekunden
1 Woche ± 6,08 Sekunden

Die obige Tabelle zeigt, dass der Häufigkeitsoffsetfehler bei kleinen Zeitintervallen häufig ignoriert werden kann. Bei langen Zeitintervallen kann jedoch auch ein kleiner Frequenzoffset zu einer erheblichen Maßunsicherheit führen.

Die in Personalcomputern und Servern verwendeten Synthetoszatoren werden in der Regel mit einer Frequenztoleranz von ± 30 bis 50 Teilen pro Million hergestellt, und selten können Steine um bis zu 500 ppm ausgeschaltet werden. Obwohl Steine mit wesentlich strengeren Frequenzoffsettoleranzen verfügbar sind, sind sie teurer und werden daher auf den meisten Computern nicht verwendet.

Um die negativen Auswirkungen dieses Häufigkeitsoffsetfehlers zu reduzieren, verwenden aktuelle Versionen von Windows, insbesondere Windows 8, mehrere Hardwaretimer, um den Häufigkeitsoffset zu erkennen und so weit wie möglich zu kompensieren. Dieser Kalibrierungsprozess wird ausgeführt, wenn Windows gestartet wird.

Wie die folgenden Beispiele zeigen, beeinflusst der Frequenzoffsetfehler einer Hardwareuhr die erreichbare Genauigkeit, und die Auflösung der Uhr kann weniger wichtig sein.

Frequenzoffsetfehler beeinflusst erreichbare Genauigkeit

Beispiel 1

Angenommen, Sie führen Zeitintervallmessungen mithilfe eines 1-MHz-Oszillators mit einer Auflösung von 1 Mikrosekunde und einem Maximalen Frequenzoffsetfehler von ±50 ppm durch. Nehmen wir nun an, dass der Offset genau +50 ppm beträgt. Dies bedeutet, dass die tatsächliche Frequenz 1.000.050 Hz beträgt. Wenn wir ein Zeitintervall von 24 Stunden gemessen haben, wäre unsere Messung 4,3 Sekunden zu kurz (23:59:55.700000 gemessen im Vergleich zu 24:00:00.000000 tatsächlich).

Sekunden pro Tag = 86400

Frequenzoffsetfehler = 50 ppm = 0,000005

86.400 Sekunden * 0,00005 = 4,3 Sekunden

Beispiel 2

Angenommen, die Prozessor-TSC-Uhr wird von einem Oszillators gesteuert und hat eine angegebene Frequenz von 3 GHz. Dies bedeutet, dass die Auflösung 1/3.000.000.000 oder etwa 333 Pikosekunden beträgt. Angenommen, der Zur Steuerung der Prozessoruhr verwendete Steine weist eine Frequenztoleranz von ±50 ppm auf und ist tatsächlich +50 ppm. Trotz der beeindruckenden Auflösung ist eine Zeitintervallmessung von 24 Stunden immer noch 4,3 Sekunden zu kurz. (23:59:55.70000000000 gemessen im Vergleich zu 24:00:00.00000000000 tatsächlich).

Sekunden pro Tag = 86400

Frequenzoffsetfehler = 50 ppm = 0,000005

86.400 Sekunden * 0,00005 = 4,3 Sekunden

Dies zeigt, dass eine TSC-Uhr mit hoher Auflösung nicht unbedingt genauere Messungen als eine Uhr mit niedrigerer Auflösung bietet.

Beispiel 3

Erwägen Sie die Verwendung von zwei verschiedenen Computern, um das gleiche 24-Stunden-Zeitintervall zu messen. Beide Computer verfügen über einen Oszillatoren mit einem maximalen Frequenzoffset von ± 50 ppm. Wie weit auseinander kann die Messung des gleichen Zeitintervalls für diese beiden Systeme liegen? Wie in den vorherigen Beispielen ergibt ± 50 ppm einen maximalen Fehler von ± 4,3 Sekunden nach 24 Stunden. Wenn ein System 4,3 Sekunden schnell und das andere 4,3 Sekunden langsam ausgeführt wird, kann der maximale Fehler nach 24 Stunden 8,6 Sekunden betragen.

Sekunden pro Tag = 86400

Häufigkeitsoffsetfehler = ±50 ppm = ±0,00005

±(86.400 Sekunden * 0,00005) = ±4,3 Sekunden

Maximaler Offset zwischen den beiden Systemen = 8,6 Sekunden

Zusammenfassend wird der Häufigkeitsoffsetfehler immer wichtiger, wenn lange Zeitintervalle gemessen und Messungen zwischen verschiedenen Systemen verglichen werden.

Die Stabilität eines Timers beschreibt, ob sich die Taktfrequenz im Laufe der Zeit ändert, z. B. als Ergebnis von Temperaturänderungen. Die als Taktgeneratoren auf Computern verwendeten Steine weisen in Abhängigkeit von der Temperatur kleine Änderungen in der Häufigkeit auf. Der durch die wärmerische Abweichung verursachte Fehler ist im Vergleich zum Frequenzoffsetfehler für allgemeine Temperaturbereiche in der Regel klein. Entwickler von Software für tragbare Geräte oder Geräte, die großen Temperaturschwankungen ausgesetzt sind, müssen diese Auswirkung jedoch möglicherweise berücksichtigen.

Hardwaretimerinformationen

TSC-Register

Einige Intel- und AMD-Prozessoren enthalten ein TSC-Register, bei dem es sich um ein 64-Bit-Register handelt, das sich mit einer hohen Rate erhöht, in der Regel gleich der Prozessoruhr. Der Wert dieses Leistungsindikators kann durch die RDTSC- oder RDTSCP-Computeranweisungen gelesen werden, wodurch je nach Prozessor sehr niedrige Zugriffszeit und Rechenkosten in der Reihenfolge von Dutzenden oder Hunderten von Computerzyklen zur Verfügung stehen.

Das TSC-Register scheint zwar wie ein idealer Zeitstempelmechanismus zu sein, aber hier sind Umstände, in denen es aus Zeitgründen nicht zuverlässig funktionieren kann:

  • Nicht alle Prozessoren verfügen über TSC-Register. Daher führt die direkte Verwendung des TSC-Registers in der Software zu einem Portabilitätsproblem. (Windows wählt in diesem Fall eine alternative Zeitquelle für QPC aus, um das Portabilitätsproblem zu vermeiden.)
  • Einige Prozessoren können die Häufigkeit der TSC-Uhr variieren oder die Weiterentwicklung des TSC-Registers beenden, wodurch das TSC für Zeitsteuerungszwecke auf diesen Prozessoren ungeeignet wird. Diese Prozessoren verfügen über nicht invariante TSC-Register. (Windows erkennt dies automatisch und wählt eine alternative Zeitquelle für QPCaus.
  • Auf Systemen mit mehreren Prozessoren oder mehreren Kernen können einige Prozessoren und Systeme die Uhren auf jedem Kern nicht mit demselben Wert synchronisieren. (Windows erkennt dies automatisch und wählt eine alternative Zeitquelle für QPCaus.
  • Bei einigen großen Systemen mit mehreren Prozessoren sind Sie möglicherweise nicht in der Lage, die Prozessoruhren mit demselben Wert zu synchronisieren, selbst wenn der Prozessor über einen invarianten TSC verfügt. (Windows erkennt dies automatisch und wählt eine alternative Zeitquelle für QPCaus.
  • Einige Prozessoren führen Anweisungen in nicht ordnungsgemäßer Reihenfolge aus. Dies kann zu einer falschen Zyklusanzahl führen, wenn RDTSC verwendet wird, um Anweisungssequenzen zu timen, da die RDTSC-Anweisung zu einem anderen Zeitpunkt als im Programm angegeben ausgeführt werden kann. Die RDTSCP-Anweisung wurde auf einigen Prozessoren als Reaktion auf dieses Problem eingeführt.

Wie andere Timer basiert der TSC auf einem Gitteroszillators, dessen genaue Häufigkeit im Voraus nicht bekannt ist und einen Frequenzoffsetfehler aufweist. Daher muss sie mit einem anderen Zeitsteuerungsverweis kalibriert werden, bevor sie verwendet werden kann.

Während der Systeminitialisierung überprüft Windows, ob das TSC für Zeitsteuerungszwecke geeignet ist, und führt die erforderliche Häufigkeitskalibrierung und Kernsynchronisierung durch.

PM-Uhr

Der ACPI-Timer, auch bekannt als PM-Uhr, wurde der Systemarchitektur hinzugefügt, um zuverlässige Zeitstempel unabhängig von der Prozessorgeschwindigkeit bereitzustellen. Da dies das einzige Ziel dieses Timers war, stellt er einen Zeitstempel in einem einzelnen Taktzyklus bereit, bietet aber keine andere Funktionalität.

HPET Timer

Der High Precision Event Timer (HPET) wurde gemeinsam von Intel und Microsoft entwickelt, um die Zeitanforderungen von Multimediaanwendungen und anderen zeitkritischen Anwendungen zu erfüllen. Die HPET-Unterstützung ist seit Windows Vista in Windows, und Windows 7- und Windows 8-Hardwarelogo-Zertifizierung erfordert HPET-Unterstützung auf der Hardwareplattform.