Uzyskiwanie sygnatur czasowych o wysokiej rozdzielczości

System Windows udostępnia interfejsy API, których można użyć do uzyskiwania sygnatur czasowych o wysokiej rozdzielczości lub mierzenia interwałów czasu. Podstawowym interfejsem API dla kodu natywnego jest QueryPerformanceCounter (QPC). W przypadku sterowników urządzeń interfejs API trybu jądra to KeQueryPerformanceCounter. W przypadku kodu zarządzanego klasa System.Diagnostics.Stopwatch używa funkcji QPC jako dokładnej podstawy czasu.

QPC jest niezależny i nie jest synchronizowany z żadnym zewnętrznym źródłem czasu. Aby pobrać znaczniki czasowe, które można zsynchronizować z zewnętrznym odniesieniem czasowym, takim jak Uniwersalny Czas Koordynowany (UTC) do użycia w pomiarach o wysokiej rozdzielczości czasu dnia, użyj polecenia GetSystemTimePreciseAsFileTime.

Sygnatury czasowe i pomiary interwałów czasowych są integralną częścią pomiarów wydajności komputera i sieci. Te operacje pomiaru wydajności obejmują obliczanie czasu odpowiedzi, przepływności i opóźnienia, a także profilowanie wykonywania kodu. Każda z tych operacji obejmuje pomiar działań, które występują w przedziale czasu zdefiniowanym przez początkowe i końcowe zdarzenie, które mogą być niezależne od jakiegokolwiek zewnętrznego odniesienia do pory dnia.

QPC jest zazwyczaj najlepszą metodą do oznaczania czasem zdarzeń i mierzenia małych odstępów czasu występujących na tym samym systemie lub maszynie wirtualnej. Rozważ użycie funkcji GetSystemTimePreciseAsFileTime, jeśli chcesz oznaczyć zdarzenia sygnaturą czasową na wielu maszynach, pod warunkiem, że każda maszyna uczestniczy w systemie synchronizacji czasu, takim jak protokół NTP (Network Time Protocol). QPC pomaga uniknąć trudności, które można napotkać z innymi metodami pomiaru czasu, takimi jak bezpośrednie odczytywanie licznika sygnatury czasowej procesora (TSC).

• Obsługa QPC w wersjach systemu Windows
• Wskazówki dotyczące uzyskiwania sygnatur czasowych
  • Wirtualizacja
  • Bezpośrednie użycie TSC
  • Przykłady uzyskiwania sygnatur czasowych
• Ogólne często zadawane pytania dotyczące QPC i TSC
• Często zadawane pytania dotyczące programowania za pomocą technologii QPC i TSC
• Charakterystyki zegara sprzętowego niskiego poziomu
  • Zegary bezwzględne i zegary różnicowe
  • Rozdzielczość, precyzja, dokładność i stabilność
• Informacje o czasomierzu sprzętu

Obsługa QPC w wersjach systemu Windows

QPC został wprowadzony w systemach Windows 2000 i Windows XP i ewoluował, aby korzystać z ulepszeń platformy sprzętowej i procesorów. W tym miejscu opisano cechy QPC w różnych wersjach systemu Windows, aby ułatwić konserwację oprogramowania działającego w tych wersjach systemu Windows.

Windows XP i Windows 2000

QPC jest dostępny w systemach Windows XP i Windows 2000 i działa dobrze w większości systemów. Jednak BIOS niektórych systemów nie wskazuje prawidłowo charakterystyki procesora (niedeterministyczny TSC), a niektóre systemy wielordzeniowe lub wieloprocesorowe używały procesorów z TSC, które nie mogły być zsynchronizowane między jądrami. Systemy z wadliwym oprogramowaniem układowym, które uruchamiają te wersje systemu Windows, mogą nie zapewniać tego samego odczytu QPC na różnych rdzeniach, jeśli używały TSC jako podstawy dla QPC.

Windows Vista i Windows Server 2008

Wszystkie komputery dostarczane z systemami Windows Vista i Windows Server 2008 używały licznika platformy (Czasomierz zdarzeń o wysokiej precyzji (HPET)) lub czasomierza zarządzania energią ACPI (czasomierz PM) jako podstawy dla QPC. Takie czasomierze platformy mają większe opóźnienie dostępu niż TSC i są współdzielone między wieloma procesorami. Ogranicza to skalowalność QPC , jeśli jest wywoływana współbieżnie z wielu procesorów.

Windows 7 i Windows Server 2008 R2

Większość komputerów z systemami Windows 7 i Windows Server 2008 R2 ma procesory ze stałą szybkością TSC i używają tych liczników jako podstawy dla QPC. Rejestry stanu procesora (TSC) to liczniki sprzętowe o wysokiej rozdzielczości dla każdego procesora, do których można uzyskać dostęp z bardzo małym opóźnieniem i obciążeniem systemowym (w granicach 10 lub 100 cykli maszynowych, w zależności od typu procesora). Systemy Windows 7 i Windows Server 2008 R2 używają TSC jako podstawy QPC w systemach z pojedynczą domeną zegarową, gdzie system operacyjny (lub hipernadzorca) jest w stanie ściśle zsynchronizować poszczególne TSC we wszystkich procesorach w trakcie inicjalizacji systemu. W takich systemach koszt odczytywania licznika wydajności jest znacznie niższy w porównaniu z systemami korzystającymi z licznika platformy. Ponadto nie ma dodatkowych obciążeń związanych z współbieżnymi wywołaniami i zapytaniami trybu użytkownika często pomijają wywołania systemowe, co dodatkowo zmniejsza obciążenie. W systemach, w których TSC nie jest odpowiedni do przechowywania czasu, system Windows automatycznie wybiera licznik platformy (czasomierz HPET lub czasomierz ACPI PM) jako podstawę dla QPC.

Windows 8, Windows 8.1, Windows Server 2012 i Windows Server 2012 R2

Windows 8, Windows 8.1, Windows Server 2012 i Windows Server 2012 R2 używają TSC jako podstawy licznika wydajności. Algorytm synchronizacji TSC został znacznie ulepszony, aby lepiej pomieścić duże systemy z wieloma procesorami. Ponadto dodano obsługę nowego precyzyjnego interfejsu API czasu dobowego, co umożliwia uzyskanie dokładnych znaczników czasu zegara czasu rzeczywistego z systemu operacyjnego. Aby uzyskać więcej informacji, zobacz GetSystemTimePreciseAsFileTime. Na urządzeniach z systemami Windows RT, Windows 11 oraz Windows 10 z procesorami Arm licznik wydajności jest oparty na własnym liczniku platformy lub liczniku systemowym dostarczonym przez Arm Generic Timer, jeśli platforma jest wyposażona.

Wskazówki dotyczące uzyskiwania sygnatur czasowych

System Windows ma i będzie nadal inwestować w zapewnienie niezawodnego i wydajnego licznika wydajności. Jeśli potrzebujesz znaczników czasu z rozdzielczością 1 mikrosekundy lub lepszą i nie potrzebujesz synchronizować znaczników czasu z zewnętrznym źródłem czasu, wybierz QueryPerformanceCounter, KeQueryPerformanceCounter lub KeQueryInterruptTimePrecise. Jeśli potrzebujesz zsynchronizowanych sygnatur czasowych UTC z rozdzielczością 1 mikrosekund lub lepiej, wybierz pozycję GetSystemTimePreciseAsFileTime lub KeQuerySystemTimePrecise.

Na stosunkowo małej liczbie platform, które nie mogą używać rejestru TSC jako podstawy QPC, na przykład z powodów wyjaśnionych w Informacjach o czasomierzu sprzętowym, uzyskanie znaczników czasu o wysokiej rozdzielczości może być znacząco droższe niż uzyskanie znaczników czasu z niższą rozdzielczością. Jeśli precyzja od 10 do 16 milisekund jest wystarczająca, możesz użyć funkcji GetTickCount64, QueryInterruptTime, QueryUnbiasedInterruptTime, KeQueryInterruptTime lub KeQueryUnbiasedInterruptTime, aby uzyskać znaczniki czasu, które nie są synchronizowane z zewnętrznym odniesieniem czasowym. W przypadku sygnatur czasowych zsynchronizowanych z utc użyj polecenia GetSystemTimeAsFileTime lub KeQuerySystemTime. Jeśli potrzebna jest wyższa rozdzielczość, możesz użyć QueryInterruptTimePrecise, QueryUnbiasedInterruptTimePrecise lub KeQueryInterruptTimePrecise, aby uzyskać znaczniki czasu.

Ogólnie rzecz biorąc, wyniki licznika wydajności są spójne we wszystkich procesorach w systemach wielordzeniowych i wieloprocesorowych, nawet w przypadku pomiaru w różnych wątkach lub procesach. Oto kilka wyjątków od tej reguły:

• Systemy operacyjne sprzed Windows Vista, działające na niektórych procesorach, mogą naruszać spójność z jednego z następujących powodów:

  • Procesory sprzętowe mają niewariancyjny TSC, a system BIOS nie wskazuje tego warunku poprawnie.
  • Algorytm synchronizacji TSC, który był używany, nie był odpowiedni dla systemów z dużą liczbą procesorów.

• Podczas porównywania wyników liczników wydajności uzyskiwanych z różnych wątków należy wziąć pod uwagę, że wartości różniące się o ±1 tik mają niejednoznaczną kolejność. Jeśli sygnatury czasowe są pobierane z tego samego wątku, ta niepewność ± 1 tick nie ma zastosowania. W tym kontekście termin znacznik odnosi się do okresu równego 1 ÷ (częstotliwość licznika wydajności uzyskanego z funkcji QueryPerformanceFrequency).

W przypadku korzystania z licznika wydajności w dużych systemach serwerowych z domenami o wielu zegarach, które nie są synchronizowane w sprzęcie, system Windows określa, że TSC nie może być używany do celów chronometrażu i wybiera licznik platformy jako podstawę dla QPC. Mimo że ten scenariusz nadal zapewnia niezawodne sygnatury czasowe, opóźnienie dostępu i skalowalność są niekorzystnie dotknięte. W związku z tym, jak wspomniano wcześniej w poprzednich wskazówkach dotyczących użycia, należy używać tylko interfejsów API, które zapewniają 1 mikrosekundy lub lepszą rozdzielczość, gdy takie rozwiązanie jest konieczne. TSC jest używane jako podstawa dla QPC w wielodomenowych systemach zegarowych, które obejmują sprzętową synchronizację wszystkich domen zegarów procesora, co skutkuje działaniem jako system z jedną domeną zegara.

Częstotliwość licznika wydajności jest stała podczas rozruchu systemu i jest spójna we wszystkich procesorach, więc wystarczy wykonać zapytanie o częstotliwość z QueryPerformanceFrequency , gdy aplikacja inicjuje, a następnie buforować wynik.

Wirtualizacja

Oczekuje się, że licznik wydajności będzie działać niezawodnie na wszystkich maszynach wirtualnych uruchomionych na poprawnie zaimplementowanych hiperwizorach. Jednak hypervisory, które są zgodne z interfejsem w wersji 1.0 i udostępniają funkcję ujednolicenia czasu odniesienia, mogą oferować znacznie niższe obciążenie. Aby uzyskać więcej informacji na temat interfejsów i ulepszeń hypervisora, zobacz Specyfikacje Hypervisora.

Bezpośrednie użycie TSC

Zdecydowanie odradzamy korzystanie z instrukcji procesora RDTSC lub RDTSCP w celu bezpośredniego wykonywania zapytań dotyczących TSC, ponieważ nie uzyskasz niezawodnych wyników w niektórych wersjach systemu Windows, w ramach migracji na żywo maszyn wirtualnych i w systemach sprzętowych bez niezmiennych lub ściśle zsynchronizowanych TSC. Zamiast tego zachęcamy do korzystania z QPC w celu wykorzystania abstrakcji, spójności i przenośności, którą oferuje.

Przykłady uzyskiwania sygnatur czasowych

W różnych przykładach kodu w tych sekcjach pokazano, jak uzyskać sygnatury czasowe.

Korzystanie z QPC w kodzie natywnym

W tym przykładzie pokazano, jak używać QPC w kodzie natywnym C i 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;

Uzyskiwanie sygnatur czasowych o wysokiej rozdzielczości z kodu zarządzanego

W tym przykładzie pokazano, jak używać klasy System.Diagnostics.Stopwatch kodu zarządzanego.

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

Klasa System.Diagnostics.Stopwatch udostępnia również kilka wygodnych metod wykonywania pomiarów interwału czasu.

Używanie funkcji QPC z trybu jądra

Jądro systemu Windows zapewnia dostęp w trybie jądra do licznika wydajności za pośrednictwem keQueryPerformanceCounter , z którego można uzyskać zarówno licznik wydajności, jak i częstotliwość wydajności. KeQueryPerformanceCounter jest dostępny tylko w trybie jądra i jest udostępniany twórcom sterowników urządzeń oraz innych składników trybu jądra.

W tym przykładzie pokazano, jak używać metody KeQueryPerformanceCounter w trybie jądra C i 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;

Ogólne często zadawane pytania dotyczące QPC i TSC

Poniżej przedstawiono odpowiedzi na często zadawane pytania dotyczące QPC i TSCs w ogóle.

Czy funkcja QueryPerformanceCounter() jest taka sama jak funkcja Win32 GetTickCount() lub GetTickCount64()?

Nie. GetTickCount i GetTickCount64 nie są powiązane z QPC. Polecenia GetTickCount i GetTickCount64 zwracają liczbę milisekund od czasu uruchomienia systemu.

Czy należy używać QPC lub wywoływać instrukcje RDTSC/RDTSCP bezpośrednio?

Aby uniknąć problemów z niepoprawnością i przenośnością, zdecydowanie zachęcamy do korzystania z QPC zamiast używania rejestru TSC lub instrukcji procesora RDTSC lub RDTSCP .

Co to jest relacja QPC z epoką czasu zewnętrznego? Czy można ją zsynchronizować z epoką zewnętrzną, taką jak UTC?

QPC jest oparty na liczniku sprzętowym, którego nie można zsynchronizować z zewnętrznym odniesieniem czasowym, takim jak UTC. Aby uzyskać dokładną sygnaturę czasową dnia, które można zsynchronizować z zewnętrznym odwołaniem UTC, użyj polecenia GetSystemTimePreciseAsFileTime.

Czy czas QPC ma wpływ na czas letni, sekundy przestępne, strefy czasowe lub zmiany czasu systemowego wprowadzone przez administratora?

Nie. QPC jest całkowicie niezależny od czasu systemowego i czasu UTC.

Czy dokładność QPC ma wpływ na zmiany częstotliwości procesora spowodowane przez zarządzanie energią lub technologię Turbo Boost?

Nie. Jeśli procesor ma niezmienny TSC, QPC nie ma wpływu na tego rodzaju zmiany. Jeśli procesor nie ma niezmiennego TSC, technologia QPC powróci do czasomierza sprzętowego platformy, który nie będzie miał wpływu na zmiany częstotliwości procesora ani technologii Turbo Boost.

Czy technologia QPC niezawodnie działa w systemach wieloprocesorowych, systemach wielordzeniowych i systemach z hiperwątkiem?

Tak.

Jak określić i zweryfikować, czy funkcja QPC działa na mojej maszynie?

Nie trzeba wykonywać takich testów.

Które procesory mają niewariantowe TSC? Jak sprawdzić, czy mój system ma niewariantowy TSC?

Nie musisz wykonywać tego sprawdzania samodzielnie. Systemy operacyjne Windows przeprowadzają kilka kontroli podczas inicjowania systemu w celu określenia, czy TSC jest odpowiedni jako podstawa dla QPC. Jednak w celach referencyjnych można określić, czy procesor ma niezmienny TSC przy użyciu jednej z następujących opcji:

• narzędzie Coreinfo.exe z systemu Windows Sysinternals
• sprawdzanie wartości zwracanych przez instrukcję CPUID, odnoszącą się do właściwości TSC
• dokumentacja producenta procesora

Poniżej przedstawiono informacje o TSC-INVARIANT, które są udostępniane przez narzędzie Windows Sysinternals Coreinfo.exe (www.sysinternals.com). Gwiazdka oznacza "Prawda".

> 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

Czy QPC działa niezawodnie na platformach sprzętowych Windows RT?

Tak.

Jak często przewraca się QPC?

Nie mniej niż 100 lat od ostatniego rozruchu systemu i potencjalnie dłużej na podstawie używanego czasomierza sprzętowego. W przypadku większości aplikacji przejście nie jest problemem.

Jaki jest koszt obliczeniowy wywołania QPC?

Koszt wywołania obliczeniowego QPC jest określany głównie przez podstawową platformę sprzętową. Jeśli rejestr TSC jest używany jako podstawa QPC, koszt obliczeniowy jest określany przede wszystkim przez czas przetwarzania instrukcji RDTSC procesora. Ten czas waha się od 10 cykli CPU do kilkuset cykli CPU w zależności od używanego procesora. Jeśli nie można użyć TSC, system wybierze inną podstawę czasu sprzętu. Ponieważ te podstawy czasowe znajdują się na płycie głównej (na przykład na mostku PCI South Bridge lub PCH), koszt obliczeniowy na wywołanie jest wyższy niż w przypadku TSC i często wynosi w granicach 0,8 - 1,0 mikrosekund, w zależności od szybkości procesora i innych czynników sprzętowych. Ten koszt jest zdominowany przez czas wymagany do uzyskania dostępu do urządzenia sprzętowego na płycie głównej.

Czy QPC wymaga przejścia jądra (wywołanie systemowe)?

Przejście jądra nie jest wymagane, jeśli system może użyć rejestru TSC jako podstawy dla QPC. Jeśli system musi używać innej bazy czasowej, takiej jak czasomierz HPET lub PM, wymagane jest wywołanie systemowe.

Czy licznik wydajności jest monotoniczny (nie malejący)?

Tak. QPC nie cofa się.

Czy licznik wydajności może być używany do porządkowania zdarzeń w czasie?

Tak. Jednak w przypadku porównywania wyników licznika wydajności, które są uzyskiwane z różnych wątków, wartości różniące się ± 1 znacznikiem czasu mają niejednoznaczne kolejność, tak jakby miały identyczną sygnaturę czasową.

Jak dokładny jest licznik wydajności?

Odpowiedź zależy od różnych czynników. Aby uzyskać więcej informacji, zobacz Właściwości zegara sprzętowego niskiego poziomu.

Często zadawane pytania dotyczące programowania za pomocą technologii QPC i TSC

Poniżej przedstawiono odpowiedzi na często zadawane pytania dotyczące programowania za pomocą technologii QPC i TSCs.

Chcę przekonwertować wynik QPC na milisekundy. Jak uniknąć utraty dokładności przy konwersji na double lub float?

Podczas wykonywania obliczeń na licznikach wydajności całkowitej należy pamiętać o kilku kwestiach:

• Podział liczb całkowitych utraci resztę. Może to spowodować utratę dokładności w niektórych przypadkach.
• Konwersja między 64-bitowymi liczbami całkowitymi i zmiennoprzecinkowymi (podwójna) może spowodować utratę precyzji, ponieważ mantissa zmiennoprzecinkowa nie może reprezentować wszystkich możliwych wartości całkowitych.
• Mnożenie 64-bitowych liczb całkowitych może spowodować przepełnienie liczby całkowitej.

Ogólnie rzecz biorąc, opóźnij te obliczenia i konwersje tak długo, jak to możliwe, aby uniknąć wprowadzania błędów.

Jak mogę przekonwertować QPC na odcinki 100 nanosekund, abym mógł dodać je do FILETIME?

Czas pliku to wartość 64-bitowa, która reprezentuje liczbę interwałów 100-nanosekundowych, które upłynęły od 12:00 1 stycznia 1601 czasu uniwersalnego koordynowanego (UTC). Czasy plików są używane przez wywołania interfejsu API Win32, które zwracają godzinę dnia, takie jak GetSystemTimeAsFileTime i GetSystemTimePreciseAsFileTime. Natomiast QueryPerformanceCounter zwraca wartości reprezentujące czas w jednostkach 1/(częstotliwość licznika wydajności uzyskiwana z QueryPerformanceFrequency). Konwersja między nimi wymaga obliczenia współczynnika interwału QPC i interwałów 100 nanosekund. Należy zachować ostrożność, aby uniknąć utraty dokładności, ponieważ wartości mogą być małe (0,0000001 / 0,000000340).

Dlaczego sygnatura czasowa zwracana z QPC jest podpisaną liczbą całkowitą?

Obliczenia obejmujące sygnatury czasowe QPC mogą obejmować odejmowanie. Używając wartości podpisanej, można obsługiwać obliczenia, które mogą zwracać wartości ujemne.

Jak uzyskać sygnatury czasowe o wysokiej rozdzielczości z kodu zarządzanego?

Wywołaj metodę Stopwatch.GetTimeStamp z klasy System.Diagnostics.Stopwatch . Aby zapoznać się z przykładem użycia stopwatch.GetTimeStamp, zobacz Uzyskiwanie sygnatur czasowych o wysokiej rozdzielczości z kodu zarządzanego.

W jakich okolicznościach funkcja QueryPerformanceFrequency zwraca wartość FALSE lub QueryPerformanceCounter zwraca zero?

Nie będzie to występować w żadnym systemie z systemem Windows XP lub nowszym, pod warunkiem przekazania prawidłowych parametrów do funkcji.

Czy muszę ustawić przypisanie wątku do jednego rdzenia, aby używać QPC?

Nie. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące uzyskiwania sygnatur czasowych. Ten scenariusz nie jest ani konieczny, ani pożądany. Wykonanie tego scenariusza może niekorzystnie wpłynąć na wydajność aplikacji, ograniczając przetwarzanie do jednego rdzenia lub tworząc wąskie gardło na jednym rdzeniu, jeśli każdy z wielu wątków ustawia koligację na ten sam rdzeń podczas wywoływania funkcji QueryPerformanceCounter.

Charakterystyki zegara sprzętowego niskiego poziomu

W tych sekcjach przedstawiono charakterystykę zegara sprzętowego niskiego poziomu.

Zegary bezwzględne i zegary różnicowe

Zegary absolutne zapewniają dokładne odczyty czasu dnia. Zazwyczaj są one oparte na uniwersalnym czasie koordynowanym (UTC) i w związku z tym ich dokładność zależy częściowo od tego, jak dobrze są synchronizowane z odwołaniem czasu zewnętrznego. Zegary różnicowe mierzą interwały czasu i zwykle nie są oparte na zewnętrznej epoce. QPC to zegar różnicowy i nie jest synchronizowany z zewnętrzną epoką czasu ani referencją. W przypadku używania funkcji QPC do pomiarów interwału czasowego zwykle uzyskuje się lepszą dokładność niż przy użyciu sygnatur czasowych, które pochodzą z zegara bezwzględnego. Wynika to z faktu, że proces synchronizowania czasu zegara bezwzględnego może wprowadzać zmiany faz i częstotliwości, które zwiększają niepewność pomiarów krótkoterminowego interwału czasowego.

Rozdzielczość, precyzja, dokładność i stabilność

QPC używa licznika sprzętu jako podstawy. Czasomierze sprzętowe składają się z trzech części: generatora impulsów, licznika, który zlicza impulsy, oraz możliwości pobierania wartości licznika. Cechy tych trzech składników określają rozdzielczość, precyzję, dokładność i stabilność QPC.

Jeśli generator sprzętu zapewnia znaczniki w stałym tempie, interwały czasowe mogą być mierzone poprzez proste zliczanie tych znaczników. Szybkość generowania impulsów nazywana jest częstotliwością i wyrażana w hercach (Hz). Odwrotność częstotliwości jest nazywana okresem lub interwałem taktów i jest wyrażona w odpowiedniej jednostce czasu w międzynarodowym układzie jednostek SI (na przykład sekunda, milisekunda, mikrosekunda, lub nanosekunda).

Rozdzielczość czasomierza jest równa okresowi. Rozdzielczość określa możliwość rozróżnienia między dowolnymi dwoma sygnaturami czasowymi i umieszcza dolną granicę na najmniejszych przedziałach czasu, które można zmierzyć. Jest to czasami nazywane rozdzielczością tików.

Cyfrowy pomiar czasu wprowadza niepewność pomiarową na poziomie ±1 impuls, ponieważ licznik cyfrowy przesuwa się w dyskretnych krokach, podczas gdy czas biegnie nieustannie. Ta niepewność jest nazywana błędem kwantyzacji. W przypadku typowych pomiarów interwału czasowego ten efekt może być często ignorowany, ponieważ błąd kwantyzacji jest znacznie mniejszy niż mierzony przedział czasu.

Jeśli jednak mierzony okres jest mały i zbliża się do rozdzielczości timera, należy wziąć pod uwagę ten błąd kwantyzacji. Rozmiar wprowadzonego błędu to okres jednego zegara.

Na poniższych dwóch diagramach przedstawiono wpływ niepewności ± 1 ticka, ilustrowany przy użyciu czasomierza z rozdzielczością 1 jednostki czasu.

Funkcja QueryPerformanceFrequency zwraca częstotliwość QPC, a okres i rozdzielczość są równe odwrotności tej wartości. Częstotliwość licznika wydajności zwracana przez funkcję QueryPerformanceFrequency jest określana podczas inicjowania systemu i nie zmienia się podczas uruchamiania systemu.

QueryPerformanceCounter odczytuje licznik wydajności i zwraca łączną liczbę tików, które wystąpiły od czasu uruchomienia systemu operacyjnego Windows, w tym czas, kiedy maszyna znajdowała się w stanie uśpienia, takim jak tryb gotowości, hibernacja lub połączenie gotowości.

W tych przykładach pokazano, jak obliczyć interwał tyknięć i rozdzielczość oraz jak przekonwertować liczbę tyknięć na wartość czasu.

Przykład 1

Funkcja QueryPerformanceFrequency zwraca wartość 3 125 000 na określonej maszynie. Jaki jest interwał znaczników i rozdzielczość pomiarów QPC na tym komputerze? Interwał cyklu lub okres jest odwrotnością 3 125 000, co odpowiada 0,000000320 sekund (320 nanosekund). Dlatego każdy znacznik reprezentuje przemijanie 320 nanosekund. Interwały czasu mniejsze niż 320 nanosekund nie mogą być mierzone na tej maszynie.

Interwał taktu = 1/(Częstotliwość taktu)

Interwał znaczników = 1/3 125 000 = 320 ns

Przykład 2

Na tym samym komputerze co w poprzednim przykładzie różnica wartości zwracanych z dwóch kolejnych wywołań do QPC wynosi 5. Ile czasu upłynął między dwoma wywołaniami? 5 tików pomnożonych przez 320 nanosekund daje 1,6 mikrosekundy.

ElapsedTime = Znaczniki * Interwał znaczników

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

Uzyskanie dostępu do (odczytu) licznika tików z oprogramowania zajmuje trochę czasu, a ten czas dostępu może wpłynąć na dokładność pomiaru czasu. Wynika to z tego, że minimalny czas interwału (najmniejszy interwał, który można zmierzyć) jest większy od rozdzielczości i czasu dostępu.

Precyzja = MAX [rozdzielczość, czas dostępu]

Rozważmy na przykład hipotetyczny czasomierz sprzętowy z rozdzielczością 100 nanosekund i 800 nanosekundowym czasem dostępu. Może tak być, jeśli czasomierz platformy zostałby użyty zamiast rejestru TSC jako podstawę QPC. W związku z tym precyzja wyniesie 800 nanosekund nie 100 nanosekund, jak pokazano w tym obliczeniu.

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

Te dwie ilustracje przedstawiają ten efekt.

Jeśli czas dostępu jest większy niż rozdzielczość, nie próbuj poprawić dokładności, odgadując. Innymi słowy, błędem jest zakładać, że sygnatura czasowa jest pobierana dokładnie w środku, na początku lub na końcu rozmowy.

Natomiast rozważmy następujący przykład, w którym czas dostępu QPC wynosi tylko 20 nanosekund, a rozdzielczość zegara sprzętowego wynosi 100 nanosekund. Może tak być, jeśli rejestr TSC został użyty jako podstawa dla QPC. Tutaj precyzja jest ograniczona przez rozdzielczość zegara.

W praktyce można znaleźć źródła czasu, dla których czas wymagany do odczytania licznika jest większy lub mniejszy niż rozdzielczość. ** W każdym z przypadków precyzja będzie większa z tych dwóch.

Ta tabela zawiera informacje na temat przybliżonej rozdzielczości, czasu dostępu i dokładności różnych zegarów. Należy pamiętać, że niektóre wartości różnią się w zależności od różnych procesorów, platform sprzętowych i szybkości procesora.

Ponieważ technologia QPC używa licznika sprzętu, gdy rozumiesz niektóre podstawowe cechy liczników sprzętu, uzyskasz wiedzę na temat możliwości i ograniczeń QPC.

Najczęściej używanym generatorem sprzętowych impulsów zegarowych jest oscylator kwarcowy. Kryształ jest małym kawałkiem kwarcu lub innego materiału ceramicznego, który wykazuje właściwości piezoelektryczne, zapewniając tanie i stabilne odniesienie częstotliwości o doskonałej dokładności. Ta częstotliwość służy do generowania ticków zliczanych przez zegar.

Dokładność czasomierza odnosi się do stopnia zgodności z wartością true lub standardową. To przede wszystkim zależy od zdolności oscylatora kryształowego do zapewnienia taktów z określoną częstotliwością. Jeśli częstotliwość oscylacji jest zbyt wysoka, zegar będzie działać "szybko", a mierzone interwały będą wyglądać dłużej niż naprawdę są; a jeśli częstotliwość jest zbyt niska, zegar będzie działać wolno, a mierzone interwały będą wyglądać krótsze niż naprawdę.

W przypadku typowych pomiarów interwału czasowego przez krótki czas (na przykład pomiary czasu odpowiedzi, pomiary opóźnienia sieci itd.), dokładność oscylatora sprzętowego jest zwykle wystarczająca. Jednak w przypadku niektórych pomiarów dokładność częstotliwości oscylatora staje się ważna, szczególnie w przypadku długich interwałów czasowych lub porównywania pomiarów wykonanych na różnych maszynach. W pozostałej części tej sekcji przedstawiono skutki dokładności oscylatora.

Częstotliwość oscylacji kryształów jest ustawiana podczas procesu produkcyjnego i jest określana przez producenta pod względem określonej częstotliwości plus lub minus tolerancji produkcyjnej wyrażonej w "częściach na milion" (ppm), nazywanym przesunięciem maksymalnej częstotliwości. Kryształ z określoną częstotliwością 1000 000 Hz i maksymalnym przesunięciem częstotliwości ± 10 ppm byłoby w granicach specyfikacji, gdyby jej rzeczywista częstotliwość mieściła się w zakresie od 999 990 990 Hz do 1000 010 Hz.

Zastępując części na milion mikrosekundami na sekundę, możemy zastosować ten błąd przesunięcia częstotliwości do pomiarów odstępu czasu. Oscylator z przesunięciem + 10 ppm miałby błąd 10 mikrosekund na sekundę. W związku z tym podczas mierzenia 1-sekundowego interwału będzie działać szybko i zmierzyć 1-sekundowy interwał jako 0,999990 sekund.

Praktycznym punktem odniesienia jest to, że błąd częstotliwości 100 ppm powoduje błąd wynoszący 8,64 sekundy w ciągu 24 godzin. W tej tabeli przedstawiono niepewność pomiaru z powodu skumulowanego błędu przez dłuższe interwały czasowe.

W powyższej tabeli przedstawiono, że w przypadku małych interwałów czasu błąd przesunięcia częstotliwości może być często ignorowany. Jednak w przypadku długich interwałów czasu nawet niewielkie przesunięcie częstotliwości może spowodować znaczną niepewność pomiarów.

Oscylatory kwarcowe, które są używane w komputerach osobistych i serwerach, są zwykle produkowane z tolerancją częstotliwości ± 30 do 50 ppm, a w rzadkich przypadkach kryształy mogą odbiegać nawet do 500 ppm. Chociaż kryształy o znacznie ściślejszych tolerancjach przesunięcia częstotliwości są dostępne, są droższe i dlatego nie są używane w większości komputerów.

Aby zmniejszyć negatywne skutki tego błędu przesunięcia częstotliwości, najnowsze wersje systemu Windows, w szczególności Windows 8, używają wielu czasomierzy sprzętowych, aby wykryć przesunięcie częstotliwości i zrekompensować je w miarę możliwości. Ten proces kalibracji jest wykonywany po uruchomieniu systemu Windows.

Jak pokazano w poniższych przykładach, błąd przesunięcia częstotliwości zegara sprzętowego wpływa na osiągalną dokładność, a rozdzielczość zegara może być mniej ważna.

Przykład 1

Załóżmy, że wykonujesz pomiary interwału czasu przy użyciu oscylatora 1 MHz, który ma rozdzielczość 1 mikrosekund i maksymalny błąd przesunięcia częstotliwości ±50 ppm. Teraz załóżmy, że przesunięcie wynosi dokładnie +50 ppm. Oznacza to, że rzeczywista częstotliwość to 1000 050 Hz. Jeśli zmierzyliśmy przedział czasu wynoszący 24 godziny, nasz pomiar był o 4,3 sekundy zbyt krótki (zmierzono 23:59:55,700000 w porównaniu z rzeczywistymi 24:00:00,000000).

Sekundy w ciągu dnia = 86400

Błąd przesunięcia częstotliwości = 50 ppm = 0,00005

86 400 sekund * 0,00005 = 4,3 sekundy

Przykład 2

Załóżmy, że zegar TSC procesora jest kontrolowany przez oscylator kryształowy i ma określoną częstotliwość 3 GHz. Oznacza to, że rozdzielczość to 1/3 000 000 000 lub około 333 picoseconds. Załóżmy, że kryształ używany do sterowania zegarem procesora ma tolerancję częstotliwości ±50 ppm i jest rzeczywiście +50 ppm. Pomimo imponującej rozdzielczości pomiar interwału czasu wynoszący 24 godziny będzie nadal 4,3 sekundy za krótki. (23:59:55.7000000000 mierzone versus 24:00:00.0000000000 rzeczywiste).

Sekundy w ciągu dnia = 86400

Błąd przesunięcia częstotliwości = 50 ppm = 0,00005

86 400 sekund * 0,00005 = 4,3 sekundy

Pokazuje to, że zegar TSC o wysokiej rozdzielczości niekoniecznie zapewnia dokładniejsze pomiary niż zegar niższej rozdzielczości.

Przykład 3

Rozważ użycie dwóch różnych komputerów do mierzenia tego samego interwału czasu 24-godzinnego. Oba komputery mają oscylator z maksymalnym przesunięciem częstotliwości ± 50 ppm. Jak daleko od siebie może być pomiar tego samego przedziału czasu w tych dwóch systemach? Podobnie jak w poprzednich przykładach, ± 50 ppm daje maksymalny błąd ± 4,3 sekundy po 24 godzinach. Jeśli jeden system działa o 4,3 sekundy szybciej, a drugi o 4,3 sekundy wolniej, maksymalny błąd po 24 godzinach może wynosić 8,6 sekundy.

Sekundy w ciągu dnia = 86400

Błąd przesunięcia częstotliwości = ±50 ppm = ±0,00005

±(86 400 sekund * 0,00005) = ±4,3 sekundy

Maksymalne przesunięcie między dwoma systemami = 8,6 sekundy

Podsumowując, błąd przesunięcia częstotliwości staje się coraz ważniejszy podczas mierzenia długich interwałów czasu i porównywania pomiarów między różnymi systemami.

Stabilność czasomierza opisuje, czy częstotliwość znaczników zmienia się w czasie, na przykład w wyniku zmian temperatury. Kryształy kwarcowe używane jako generatory taktów w komputerach będą wykazywać niewielkie zmiany częstotliwości w zależności od temperatury. Błąd spowodowany dryfem cieplnym jest zwykle mały w porównaniu z błędem przesunięcia częstotliwości dla typowych zakresów temperatur. Jednak projektanci oprogramowania dla przenośnego sprzętu lub sprzętu podlegającego dużym wahaniom temperatury mogą wymagać rozważenia tego efektu.

Informacje o czasomierzu sprzętu

Rejestr TSC (x86 i x64)

Wszystkie nowoczesne procesory Intel i AMD zawierają rejestr TSC, który jest rejestrem 64-bitowym, który zwiększa się z dużą szybkością, zwykle równe zegarowi procesora. Wartość tego licznika można odczytać za pomocą instrukcji rdTSC lub RDTSCP , zapewniając bardzo niski czas dostępu i koszt obliczeniowy w kolejności dziesiątek lub setek cykli maszynowych, w zależności od procesora.

Chociaż rejestr TSC wydaje się idealnym mechanizmem sygnatury czasowej, oto okoliczności, w których nie może działać niezawodnie do celów odmierzania czasu:

• Nie wszystkie procesory mają użyteczne rejestry TSC, więc użycie rejestru TSC w oprogramowaniu bezpośrednio powoduje problem z przenośnością. (System Windows wybierze alternatywne źródło czasu dla QPC w tym przypadku, co pozwala uniknąć problemu z przenośnością).
• Niektóre procesory mogą zmieniać częstotliwość zegara TSC lub zatrzymywać postęp rejestru TSC, co sprawia, że TSC nie nadaje się do celów pomiaru czasu w tych procesorach. Mówi się, że procesory te mają niewariancyjne rejestry TSC. (System Windows automatycznie wykryje to i wybierze alternatywne źródło czasu dla QPC).
• Nawet jeśli host wirtualizacji ma użyteczne TSC, migracja na żywo uruchomionych maszyn wirtualnych, gdy docelowy host wirtualizacji nie ma lub nie korzysta ze sprzętowego skalowania TSC, może spowodować zmianę częstotliwości TSC, która jest widoczna dla gości. (Jeśli ten typ migracji na żywo jest możliwy dla gościa, to hiperwizor czyści niezmienny bit funkcji TSC w identyfikatorze CPUID.)
• W systemach wieloprocesorowych lub wielordzeniowych niektóre procesory i systemy nie mogą zsynchronizować zegarów na każdym rdzeniu z tą samą wartością. (System Windows automatycznie wykryje to i wybierze alternatywne źródło czasu dla QPC).
• W niektórych dużych systemach wieloprocesorowych może nie być w stanie zsynchronizować zegarów procesora z tą samą wartością, nawet jeśli procesor ma niezmienny TSC. (System Windows automatycznie wykryje to i wybierze alternatywne źródło czasu dla QPC).
• Niektóre procesory będą wykonywać instrukcje poza kolejnością. Może to spowodować nieprawidłowe liczby cykli, gdy RDTSC jest używany do mierzenia sekwencji instrukcji, ponieważ instrukcja RDTSC może być wykonana w innym czasie niż określony w programie. Instrukcja RDTSCP została wprowadzona na niektórych procesorach w odpowiedzi na ten problem.

Podobnie jak inne czasomierze, TSC opiera się na oscylatorze kryształowym, którego dokładna częstotliwość nie jest znana z wyprzedzeniem i ma błąd przesunięcia częstotliwości. W związku z tym, zanim będzie można go użyć, należy go skalibrować przy użyciu innego wzorca czasowego.

Podczas inicjowania systemu system Windows sprawdza, czy TSC jest odpowiedni do celów chronometrażu i wykonuje niezbędną kalibrację częstotliwości i synchronizację rdzeni.

Zegar PM (x86 i x64)

Czasomierz ACPI, znany również jako zegar PM, został dodany do architektury systemu w celu zapewnienia niezawodnych sygnatur czasowych niezależnie od szybkości procesorów. Ponieważ to był jedyny cel tego czasomierza, dostarcza on sygnaturę czasową w jednym cyklu zegarowym, ale nie oferuje żadnych innych funkcji.

Czasomierz HPET (x86 i x64)

Czasomierz zdarzeń o wysokiej precyzji (HPET) został opracowany wspólnie przez firmę Intel i firmę Microsoft, aby spełnić wymagania dotyczące chronometrażu multimediów i innych aplikacji wrażliwych na czas. W przeciwieństwie do TSC, który jest zasobem przypisanym do procesora, HPET jest współużytkowanym zasobem obejmującym całą platformę, choć system może mieć wiele HPET. Obsługa protokołu HPET jest w systemie Windows od systemu Windows Vista, a certyfikacja logo sprzętowego systemu Windows 7 i Windows 8 wymaga obsługi protokołu HPET na platformie sprzętowej.

Ogólny licznik systemu czasomierza (Arm)

Platformy oparte na ARM nie mają zegara TSC, HPET lub PM, tak jak na platformach Intel lub AMD. Zamiast tego procesory Arm zapewniają ogólny czasomierz (czasami nazywany ogólnym czasomierzem interwałowym, lub GIT), który zawiera rejestr licznika systemowego (na przykład CNTVCT_EL0). Ogólny licznik systemu czasomierza jest źródłem czasu o stałej częstotliwości dla całej platformy. Zaczyna się od zera po uruchomieniu i gwałtownie wzrasta. W Armv8.6 lub nowszym jest to zdefiniowane jako dokładnie 1 GHz, ale należy to określić przez odczyt rejestru częstotliwości zegara, który jest ustawiany przez wczesne oprogramowanie układowe podczas rozruchu. Aby uzyskać więcej informacji, zobacz rozdział "Ogólny czasomierz w stanie AArch64" w podręczniku "Arm Architecture Reference Manual for A-profile architecture" (DDI 0487).

Licznik cyklu (ramię)

Platformy oparte na Arm zapewniają rejestr licznika cykli monitora wydajności (na przykład PMCCNTR_EL0). Ten licznik zlicza cykle zegara procesora. Nie jest ona niezmienna, a jej jednostki mogą nie być skorelowane z czasem rzeczywistym. Nie zaleca się używania tego rejestru w celu uzyskania sygnatur czasowych.