Memperoleh stempel waktu resolusi tinggi

Windows menyediakan API yang dapat Anda gunakan untuk memperoleh stempel waktu resolusi tinggi, atau mengukur interval waktu. API utama untuk kode asli adalah QueryPerformanceCounter (QPC). Untuk driver perangkat, API mode kernel adalah KeQueryPerformanceCounter. Untuk kode terkelola, kelas System.Diagnostics.Stopwatch menggunakan QPC sebagai dasar waktu yang tepat.

QPC tidak bergantung pada, dan tidak disinkronkan ke, referensi waktu eksternal apa pun. Untuk mengambil stempel waktu yang dapat disinkronkan ke referensi waktu eksternal, seperti, Waktu Universal Terkoordinasi (UTC) untuk digunakan dalam pengukuran waktu sehari resolusi tinggi, gunakan GetSystemTimePreciseAsFileTime.

Stempel waktu dan pengukuran interval waktu adalah bagian integral dari pengukuran performa komputer dan jaringan. Operasi pengukuran performa ini mencakup komputasi waktu respons, throughput, dan latensi, serta eksekusi kode pembuatan profil. Masing-masing operasi ini melibatkan pengukuran aktivitas yang terjadi selama interval waktu yang ditentukan oleh peristiwa awal dan akhir yang dapat independen dari referensi waktu sehari eksternal.

QPC biasanya merupakan metode terbaik untuk digunakan untuk peristiwa stempel waktu dan mengukur interval waktu kecil yang terjadi pada sistem atau komputer virtual yang sama. Pertimbangkan untuk menggunakan GetSystemTimePreciseAsFileTime saat Anda ingin memberi stempel waktu di beberapa komputer, asalkan setiap komputer berpartisipasi dalam skema sinkronisasi waktu seperti Network Time Protocol (NTP). QPC membantu Anda menghindari kesulitan yang dapat ditemui dengan pendekatan pengukuran waktu lainnya, seperti membaca penghitung stempel waktu prosesor (TSC) secara langsung.

• Dukungan QPC dalam versi Windows
• Panduan untuk memperoleh stempel waktu
  • Virtualization
  • Penggunaan TSC langsung
  • Contoh untuk memperoleh stempel waktu
• Tanya Jawab Umum tentang QPC dan TSC
• Tanya Jawab Umum tentang pemrograman dengan QPC dan TSC
• Karakteristik jam perangkat keras tingkat rendah
  • Jam Absolut dan Jam Perbedaan
  • Resolusi, Presisi, Akurasi, dan Stabilitas
• Info timer perangkat keras

Dukungan QPC dalam versi Windows

QPC diperkenalkan di Windows 2000 dan Windows XP dan telah berkembang untuk memanfaatkan peningkatan dalam platform dan prosesor perangkat keras. Di sini kami menjelaskan karakteristik QPC pada versi Windows yang berbeda untuk membantu Anda mempertahankan perangkat lunak yang berjalan pada versi Windows tersebut.

Windows XP dan Windows 2000

QPC tersedia di Windows XP dan Windows 2000 dan berfungsi dengan baik pada sebagian besar sistem. Namun, BIOS beberapa sistem perangkat keras tidak menunjukkan karakteristik CPU perangkat keras dengan benar (TSC non-invarian), dan beberapa sistem multi-inti atau multi-prosesor yang menggunakan prosesor dengan TSC yang tidak dapat disinkronkan di seluruh inti. Sistem dengan firmware cacat yang menjalankan versi Windows ini mungkin tidak menyediakan pembacaan QPC yang sama pada inti yang berbeda jika menggunakan TSC sebagai dasar untuk QPC.

Windows Vista dan Windows Server 2008

Semua komputer yang dikirim dengan Windows Vista dan Windows Server 2008 menggunakan penghitung platform (High Precision Event Timer (HPET)) atau Timer Manajemen Daya ACPI (timer PM) sebagai dasar untuk QPC. Timer platform tersebut memiliki latensi akses yang lebih tinggi daripada TSC dan dibagikan antara beberapa prosesor. Ini membatasi skalabilitas QPC jika disebut secara bersamaan dari beberapa prosesor.

Windows 7 dan Windows Server 2008 R2

Sebagian besar komputer Windows 7 dan Windows Server 2008 R2 memiliki prosesor dengan TSC tingkat konstan dan menggunakan penghitung ini sebagai dasar untuk QPC. TSC adalah penghitung perangkat keras per prosesor resolusi tinggi yang dapat diakses dengan latensi dan overhead yang sangat rendah (dalam urutan 10 atau 100 detik siklus mesin, tergantung pada jenis prosesor). Windows 7 dan Windows Server 2008 R2 menggunakan TSC sebagai dasar QPC pada sistem domain jam tunggal di mana sistem operasi (atau hypervisor) dapat menyinkronkan TSC individu dengan ketat di semua prosesor selama inisialisasi sistem. Pada sistem tersebut, biaya membaca penghitung kinerja jauh lebih rendah dibandingkan dengan sistem yang menggunakan penghitung platform. Selain itu, tidak ada overhead tambahan untuk panggilan bersamaan dan kueri mode pengguna sering melewati panggilan sistem, yang semakin mengurangi overhead. Pada sistem di mana TSC tidak cocok untuk timekeeping, Windows secara otomatis memilih penghitung platform (baik timer HPET atau timer ACPI PM) sebagai dasar untuk QPC.

Windows 8, Windows 8.1, Windows Server 2012, dan Windows Server 2012 R2

Windows 8, Windows 8.1, Windows Server 2012, dan Windows Server 2012 R2 menggunakan TSC sebagai dasar untuk penghitung kinerja. Algoritma sinkronisasi TSC secara signifikan ditingkatkan untuk mengakomodasi sistem besar dengan lebih baik dengan banyak prosesor. Selain itu, dukungan untuk API time-of-day yang tepat baru ditambahkan, yang memungkinkan memperoleh stempel waktu jam dinding yang tepat dari sistem operasi. Untuk informasi selengkapnya, lihat GetSystemTimePreciseAsFileTime. Pada perangkat Windows RT dan Windows 11 dan Windows 10 yang menggunakan prosesor Arm, penghitung kinerja didasarkan pada penghitung platform kepemilikan atau penghitung sistem yang disediakan oleh Arm Generic Timer jika platform sangat dilengkapi.

Panduan untuk memperoleh stempel waktu

Windows telah dan akan terus berinvestasi dalam menyediakan penghitung kinerja yang andal dan efisien. Saat Anda membutuhkan stempel waktu dengan resolusi 1 mikrodetik atau lebih baik dan Anda tidak memerlukan stempel waktu untuk disinkronkan ke referensi waktu eksternal, pilih QueryPerformanceCounter, KeQueryPerformanceCounter, atau KeQueryInterruptTimePrecise. Saat Anda memerlukan stempel waktu yang disinkronkan UTC dengan resolusi 1 mikrosekon atau lebih baik, pilih GetSystemTimePreciseAsFileTime atau KeQuerySystemTimePrecise.

Pada sejumlah kecil platform yang tidak dapat menggunakan register TSC sebagai basis QPC , misalnya, karena alasan yang dijelaskan dalam Info timer perangkat keras, memperoleh stempel waktu resolusi tinggi dapat secara signifikan lebih mahal daripada memperoleh stempel waktu dengan resolusi yang lebih rendah. Jika resolusi 10 hingga 16 milidetik sudah cukup, Anda dapat menggunakan GetTickCount64, QueryInterruptTime, QueryUnbiasedInterruptTime, KeQueryInterruptTime, atau KeQueryUnbiasedInterruptTime untuk mendapatkan stempel waktu yang tidak disinkronkan ke referensi waktu eksternal. Untuk stempel waktu yang disinkronkan UTC, gunakan GetSystemTimeAsFileTime atau KeQuerySystemTime. Jika resolusi yang lebih tinggi diperlukan, Anda dapat menggunakan QueryInterruptTimePrecise, QueryUnbiasedInterruptTimePrecise, atau KeQueryInterruptTimePrecise untuk mendapatkan stempel waktu sebagai gantinya.

Secara umum, hasil penghitung kinerja konsisten di semua prosesor dalam sistem multi-inti dan multi-prosesor, bahkan ketika diukur pada utas atau proses yang berbeda. Berikut adalah beberapa pengecualian untuk aturan ini:

• Sistem operasi Vista Pra-Windows yang berjalan pada prosesor tertentu mungkin melanggar konsistensi ini karena salah satu alasan berikut:

  • Prosesor perangkat keras memiliki TSC yang tidak invarian dan BIOS tidak menunjukkan kondisi ini dengan benar.
  • Algoritma sinkronisasi TSC yang digunakan tidak cocok untuk sistem dengan prosesor dalam jumlah besar.

• Saat Anda membandingkan hasil penghitung kinerja yang diperoleh dari utas yang berbeda, pertimbangkan nilai yang berbeda dengan ± 1 tick untuk memiliki urutan ambigu. Jika stempel waktu diambil dari utas yang sama, ± 1 ketidakpastian centang ini tidak berlaku. Dalam konteks ini, tanda centang istilah mengacu pada periode waktu yang sama dengan 1 ÷ (frekuensi penghitung kinerja yang diperoleh dari QueryPerformanceFrequency).

Saat Anda menggunakan penghitung kinerja pada sistem server besar dengan domain beberapa jam yang tidak disinkronkan dalam perangkat keras, Windows menentukan bahwa TSC tidak dapat digunakan untuk tujuan waktu dan memilih penghitung platform sebagai dasar untuk QPC. Meskipun skenario ini masih menghasilkan stempel waktu yang dapat diandalkan, latensi akses dan skalabilitas terpengaruh secara merugikan. Oleh karena itu, seperti yang dinyatakan sebelumnya dalam panduan penggunaan sebelumnya, hanya gunakan API yang memberikan 1 mikrosekon atau resolusi yang lebih baik ketika resolusi tersebut diperlukan. TSC digunakan sebagai dasar untuk QPC pada sistem domain multi-jam yang mencakup sinkronisasi perangkat keras dari semua domain jam prosesor, karena ini secara efektif membuatnya berfungsi sebagai sistem domain jam tunggal.

Frekuensi penghitung kinerja diperbaiki pada boot sistem dan konsisten di semua prosesor sehingga Anda hanya perlu mengkueri frekuensi dari QueryPerformanceFrequency saat aplikasi menginisialisasi, lalu menyimpan hasilnya dalam cache.

Virtualization

Penghitung kinerja diharapkan berfungsi dengan andal pada semua komputer virtual tamu yang berjalan pada hypervisor yang diimplementasikan dengan benar. Namun, hypervisor yang mematuhi antarmuka hypervisor versi 1.0 dan memunculkan pencerahan waktu referensi dapat menawarkan overhead yang jauh lebih rendah. Untuk informasi selengkapnya tentang antarmuka dan pencerahan hypervisor, lihat Spesifikasi Hypervisor.

Penggunaan TSC langsung

Kami sangat mencegah penggunaan instruksi prosesor RDTSC atau RDTSCP untuk langsung mengkueri TSC karena Anda tidak akan mendapatkan hasil yang andal pada beberapa versi Windows, di seluruh migrasi langsung komputer virtual, dan pada sistem perangkat keras tanpa TSC yang invarian atau disinkronkan dengan ketat. Sebagai gantinya, kami mendorong Anda untuk menggunakan QPC untuk memanfaatkan abstraksi, konsistensi, dan portabilitas yang ditawarkannya.

Contoh untuk memperoleh stempel waktu

Berbagai contoh kode di bagian ini menunjukkan cara memperoleh stempel waktu.

Menggunakan QPC dalam kode asli

Contoh ini menunjukkan cara menggunakan QPC dalam kode asli C dan 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;

Memperoleh stempel waktu resolusi tinggi dari kode terkelola

Contoh ini menunjukkan cara menggunakan kelas System.Diagnostics.Stopwatch kode terkelola.

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

Kelas System.Diagnostics.Stopwatch juga menyediakan beberapa metode yang nyaman untuk melakukan pengukuran interval waktu.

Menggunakan QPC dari mode kernel

Kernel Windows menyediakan akses mode kernel ke penghitung kinerja melalui KeQueryPerformanceCounter tempat penghitung kinerja dan frekuensi performa dapat diperoleh. KeQueryPerformanceCounter hanya tersedia dari mode kernel dan disediakan untuk penulis driver perangkat dan komponen mode kernel lainnya.

Contoh ini menunjukkan cara menggunakan KeQueryPerformanceCounter dalam mode kernel C dan 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;

Tanya Jawab Umum tentang QPC dan TSC

Berikut adalah jawaban atas pertanyaan yang sering diajukan tentang QPC dan TSC secara umum.

Apakah QueryPerformanceCounter() sama dengan fungsi Win32 GetTickCount() atau GetTickCount64() ?

Nomor. GetTickCount dan GetTickCount64 tidak terkait dengan QPC. GetTickCount dan GetTickCount64 mengembalikan jumlah milidetik sejak sistem dimulai.

Haruskah saya menggunakan QPC atau memanggil instruksi RDTSC/RDTSCP secara langsung?

Untuk menghindari kesalahan dan masalah portabilitas, kami sangat mendorong Anda untuk menggunakan QPC alih-alih menggunakan register TSC atau instruksi prosesor RDTSC atau RDTSCP .

Apa hubungan QPC dengan epoch waktu eksternal? Dapatkah disinkronkan ke epoch eksternal seperti UTC?

QPC didasarkan pada penghitung perangkat keras yang tidak dapat disinkronkan ke referensi waktu eksternal, seperti UTC. Untuk stempel waktu tepat hari yang dapat disinkronkan ke referensi UTC eksternal, gunakan GetSystemTimePreciseAsFileTime.

Apakah QPC dipengaruhi oleh waktu musim panas, detik lompatan, zona waktu, atau perubahan waktu sistem yang dibuat oleh administrator?

Nomor. QPC sepenuhnya independen dari waktu sistem dan UTC.

Apakah akurasi QPC terpengaruh oleh perubahan frekuensi prosesor yang disebabkan oleh manajemen daya atau teknologi Turbo Boost?

Nomor. Jika prosesor memiliki TSC invarian, QPC tidak terpengaruh oleh perubahan semacam ini. Jika prosesor tidak memiliki TSC invarian, QPC akan kembali ke timer perangkat keras platform yang tidak akan terpengaruh oleh perubahan frekuensi prosesor atau teknologi Turbo Boost.

Apakah QPC dengan andal bekerja pada sistem multi-prosesor, sistem multi-inti, dan sistem dengan hyper-threading?

Ya.

Bagaimana cara menentukan dan memvalidasi bahwa QPC berfungsi di komputer saya?

Anda tidak perlu melakukan pemeriksaan tersebut.

Prosesor mana yang memiliki TSC yang tidak invarian? Bagaimana cara memeriksa apakah sistem saya memiliki TSC non-invarian?

Anda tidak perlu melakukan pemeriksaan ini sendiri. Sistem operasi Windows melakukan beberapa pemeriksaan pada inisialisasi sistem untuk menentukan apakah TSC cocok sebagai dasar untuk QPC. Namun, untuk tujuan referensi, Anda dapat menentukan apakah prosesor Anda memiliki TSC yang invarian dengan menggunakan salah satu dari berikut:

• utilitas Coreinfo.exe dari Windows Sysinternals
• memeriksa nilai yang dikembalikan oleh instruksi CPUID yang berkaitan dengan karakteristik TSC
• dokumentasi produsen prosesor

Berikut ini menunjukkan info TSC-INVARIANT yang disediakan oleh utilitas Coreinfo.exe Windows Sysinternals (www.sysinternals.com). Tanda bintang berarti "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

Apakah QPC berfungsi dengan andal pada platform perangkat keras Windows RT?

Ya.

Seberapa sering QPC bergulir?

Tidak kurang dari 100 tahun dari boot sistem terbaru, dan berpotensi lebih lama berdasarkan timer perangkat keras yang mendasar yang digunakan. Untuk sebagian besar aplikasi, rollover tidak menjadi perhatian.

Berapa biaya komputasi panggilan QPC?

Biaya panggilan komputasi QPC ditentukan terutama oleh platform perangkat keras yang mendasar. Jika register TSC digunakan sebagai dasar untuk QPC, biaya komputasi ditentukan terutama oleh berapa lama prosesor mengambil untuk memproses instruksi RDTSC . Waktu ini berkisar dari 10-an siklus CPU hingga beberapa ratus siklus CPU tergantung pada prosesor yang digunakan. Jika TSC tidak dapat digunakan, sistem akan memilih basis waktu perangkat keras yang berbeda. Karena basis waktu ini terletak di motherboard (misalnya, pada PCI South Bridge atau PCH), biaya komputasi per panggilan lebih tinggi dari TSC, dan sering berada di sekitar 0,8 - 1,0 mikrodetik tergantung pada kecepatan prosesor dan faktor perangkat keras lainnya. Biaya ini didominasi oleh waktu yang diperlukan untuk mengakses perangkat keras pada motherboard.

Apakah QPC memerlukan transisi kernel (panggilan sistem)?

Transisi kernel tidak diperlukan jika sistem dapat menggunakan register TSC sebagai dasar untuk QPC. Jika sistem harus menggunakan basis waktu yang berbeda, seperti timer HPET atau PM, panggilan sistem diperlukan.

Apakah penghitung kinerja monotonik (tidak menurun)?

Ya. QPC tidak mundur.

Dapatkah penghitung kinerja digunakan untuk memesan peristiwa pada waktunya?

Ya. Namun, ketika membandingkan hasil penghitung kinerja yang diperoleh dari utas yang berbeda, nilai yang berbeda dengan ± 1 tick memiliki urutan ambigu seolah-olah mereka memiliki stempel waktu yang identik.

Seberapa akurat penghitung kinerja?

Jawabannya tergantung pada berbagai faktor. Untuk informasi selengkapnya, lihat Karakteristik jam perangkat keras tingkat rendah.

Tanya Jawab Umum tentang pemrograman dengan QPC dan TSC

Berikut adalah jawaban atas pertanyaan yang sering diajukan tentang pemrograman dengan QPC dan TSC.

Saya perlu mengonversi output QPC menjadi milidetik. Bagaimana cara menghindari hilangnya presisi dengan mengonversi ke ganda atau mengambang?

Ada beberapa hal yang perlu diingat saat melakukan perhitungan pada penghitung kinerja bilangan bulat:

• Pembagian bilangan bulat akan kehilangan sisanya. Ini dapat menyebabkan hilangnya presisi dalam beberapa kasus.
• Konversi antara bilangan bulat 64 bit dan floating point (ganda) dapat menyebabkan hilangnya presisi karena mantissa floating point tidak dapat mewakili semua nilai integral yang mungkin.
• Perkalian bilangan bulat 64 bit dapat mengakibatkan luapan bilangan bulat.

Sebagai prinsip umum, tunda komputasi dan konversi ini selama mungkin untuk menghindari majemuk kesalahan yang diperkenalkan.

Bagaimana cara mengonversi QPC menjadi 100 tanda nanodetik sehingga saya dapat menambahkannya ke FILETIME?

Waktu file adalah nilai 64-bit yang menunjukkan jumlah interval 100 nanodetik yang telah berlalu sejak 12:00 A.M. 1 Januari 1601 Waktu Universal Terkoordinasi (UTC). Waktu file digunakan oleh panggilan API Win32 yang mengembalikan time-of-day, seperti GetSystemTimeAsFileTime dan GetSystemTimePreciseAsFileTime. Sebaliknya, QueryPerformanceCounter mengembalikan nilai yang mewakili waktu dalam satuan 1/(frekuensi penghitung kinerja yang diperoleh dari QueryPerformanceFrequency). Konversi antara keduanya memerlukan pengkalkulasian rasio interval QPC dan interval 100-nanodetik. Berhati-hatilah untuk menghindari kehilangan presisi karena nilainya mungkin kecil (0,0000001 / 0.000000340).

Mengapa stempel waktu yang dikembalikan dari QPC bilangan bulat yang ditandatangani?

Perhitungan yang melibatkan stempel waktu QPC mungkin melibatkan pengurangan. Dengan menggunakan nilai yang ditandatangani, Anda dapat menangani perhitungan yang mungkin menghasilkan nilai negatif.

Bagaimana cara mendapatkan stempel waktu resolusi tinggi dari kode terkelola?

Panggil metode Stopwatch.GetTimeStamp dari kelas System.Diagnostics.Stopwatch . Untuk contoh tentang cara menggunakan Stopwatch.GetTimeStamp, lihat Memperoleh stempel waktu resolusi tinggi dari kode terkelola.

Dalam keadaan apa QueryPerformanceFrequency mengembalikan FALSE, atau QueryPerformanceCounter mengembalikan nol?

Ini tidak akan terjadi pada sistem apa pun yang menjalankan Windows XP atau yang lebih baru.

Apakah saya perlu mengatur afinitas utas ke satu inti untuk menggunakan QPC?

Nomor. Untuk informasi selengkapnya, lihat Panduan untuk memperoleh stempel waktu. Skenario ini tidak diperlukan atau diinginkan. Melakukan skenario ini mungkin berdampak buruk pada performa aplikasi Anda dengan membatasi pemrosesan ke satu inti atau dengan membuat hambatan pada satu inti jika beberapa utas mengatur afinitasnya ke inti yang sama saat memanggil QueryPerformanceCounter.

Karakteristik jam perangkat keras tingkat rendah

Bagian ini menunjukkan karakteristik jam perangkat keras tingkat rendah.

Jam Absolut dan Jam Perbedaan

Jam absolut memberikan pembacaan waktu hari yang akurat. Mereka biasanya didasarkan pada Waktu Universal Terkoordinasi (UTC) dan akibatnya akurasinya tergantung sebagian pada seberapa baik mereka disinkronkan ke referensi waktu eksternal. Jam perbedaan mengukur interval waktu dan biasanya tidak didasarkan pada periode waktu eksternal. QPC adalah jam perbedaan dan tidak disinkronkan ke periode waktu eksternal atau referensi. Ketika Anda menggunakan QPC untuk pengukuran interval waktu, Anda biasanya mendapatkan akurasi yang lebih baik daripada yang akan Anda dapatkan dengan menggunakan stempel waktu yang berasal dari jam absolut. Ini karena proses sinkronisasi waktu jam absolut dapat memperkenalkan fase dan pergeseran frekuensi yang meningkatkan ketidakpastian pengukuran interval waktu jangka pendek.

Resolusi, Presisi, Akurasi, dan Stabilitas

QPC menggunakan penghitung perangkat keras sebagai dasarnya. Timer perangkat keras terdiri dari tiga bagian: generator tick, penghitung yang menghitung kutu, dan sarana untuk mengambil nilai penghitung. Karakteristik ketiga komponen ini menentukan resolusi, presisi, akurasi, dan stabilitas QPC.

Jika generator perangkat keras memberikan tanda centang pada tingkat konstanta, interval waktu dapat diukur hanya dengan menghitung kutu ini. Tingkat di mana kutu dihasilkan disebut frekuensi dan dinyatakan dalam Hertz (Hz). Timbal balik frekuensi disebut interval periode atau tick dan dinyatakan dalam unit waktu Sistem Unit Internasional (SI) yang sesuai (misalnya, kedua, milidetik, mikrodetik, atau nanodetik).

Resolusi timer sama dengan periode. Resolusi menentukan kemampuan untuk membedakan antara dua stempel waktu dan menempatkan batas yang lebih rendah pada interval waktu terkecil yang dapat diukur. Ini kadang-kadang disebut resolusi centang.

Pengukuran waktu digital memperkenalkan ketidakpastian pengukuran ± 1 tick karena penghitung digital maju dalam langkah-langkah diskrit, sementara waktu terus maju. Ketidakpastian ini disebut kesalahan kuantisasi. Untuk pengukuran interval waktu umum, efek ini sering diabaikan karena kesalahan kuantisasi jauh lebih kecil daripada interval waktu yang diukur.

Namun, jika periode yang diukur kecil dan mendekati resolusi timer, Anda harus mempertimbangkan kesalahan kuantisasi ini. Ukuran kesalahan yang diperkenalkan adalah dari satu periode jam.

Dua diagram berikut menggambarkan dampak ketidakpastian centang ± 1 dengan menggunakan timer dengan resolusi 1 unit waktu.

QueryPerformanceFrequency mengembalikan frekuensi QPC, dan periode dan resolusi sama dengan timbal balik nilai ini. Frekuensi penghitung kinerja yang dikembalikan QueryPerformanceFrequency ditentukan selama inisialisasi sistem dan tidak berubah saat sistem sedang berjalan.

Catatan

Seringkali QueryPerformanceFrequency tidak mengembalikan frekuensi aktual generator tick perangkat keras. Misalnya, di beberapa versi Windows yang lebih lama, QueryPerformanceFrequency mengembalikan frekuensi TSC yang dibagi dengan 1024; dan saat berjalan di bawah hypervisor yang mengimplementasikan antarmuka hypervisor versi 1.0 (atau selalu di beberapa versi Windows yang lebih baru), frekuensi penghitung kinerja ditetapkan ke 10 MHz. Akibatnya, jangan berasumsi bahwa QueryPerformanceFrequency akan mengembalikan nilai yang berasal dari frekuensi perangkat keras.

 

QueryPerformanceCounter membaca penghitung kinerja dan mengembalikan jumlah total kutu yang telah terjadi sejak sistem operasi Windows dimulai, termasuk waktu ketika komputer dalam keadaan tidur seperti siaga, hibernasi, atau siaga yang terhubung.

Contoh-contoh ini menunjukkan cara menghitung interval dan resolusi centang dan cara mengonversi jumlah centang menjadi nilai waktu.

Contoh 1

QueryPerformanceFrequency mengembalikan nilai 3.125.000 pada komputer tertentu. Apa interval centang dan resolusi pengukuran QPC pada komputer ini? Interval tick, atau periode, adalah timbal balik 3.125.000, yaitu 0,000000320 (320 nanodetik). Oleh karena itu, setiap kutu mewakili lewatnya 320 nanodetik. Interval waktu yang lebih kecil dari 320 nanodetik tidak dapat diukur pada komputer ini.

Interval Centang = 1/(Frekuensi Performa)

Interval Centang = 1/3.125.000 = 320 ns

Contoh 2

Pada komputer yang sama dengan contoh sebelumnya, perbedaan nilai yang dikembalikan dari dua panggilan berturut-turut ke QPC adalah 5. Berapa banyak waktu yang berlalu di antara dua panggilan? 5 kutu dikalikan dengan 320 nanodetik menghasilkan 1,6 mikrodetik.

ElapsedTime = Ticks * Tick Interval

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

Dibutuhkan waktu untuk mengakses (membaca) penghitung centang dari perangkat lunak, dan waktu akses ini dapat mengurangi presisi pengukuran waktu. Ini karena waktu interval minimum (interval waktu terkecil yang dapat diukur) adalah lebih besar dari resolusi dan waktu akses.

Presisi = MAX [ Resolution, AccessTime]

Misalnya, pertimbangkan timer perangkat keras hipotetis dengan resolusi 100 nanodetik dan waktu akses 800 nanodetik. Ini mungkin terjadi jika timer platform digunakan alih-alih register TSC sebagai dasar QPC. Dengan demikian, presisinya adalah 800 nanodetik bukan 100 nanodetik seperti yang ditunjukkan dalam perhitungan ini.

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

Kedua angka ini menggambarkan efek ini.

Jika waktu akses lebih besar dari resolusi, jangan mencoba meningkatkan presisi dengan menebak. Dengan kata lain, ini adalah kesalahan untuk mengasumsikan bahwa stempel waktu diambil tepat di tengah, atau di awal atau akhir panggilan.

Sebaliknya, pertimbangkan contoh berikut di mana waktu akses QPC hanya 20 nanodetik dan resolusi jam perangkat keras adalah 100 nanodetik. Ini mungkin terjadi jika register TSC digunakan sebagai dasar untuk QPC. Di sini presisi dibatasi oleh resolusi jam.

Dalam praktiknya, Anda dapat menemukan sumber waktu di mana waktu yang diperlukan untuk membaca penghitung lebih besar atau lebih kecil dari resolusi. Dalam kedua kasus, presisi akan menjadi yang lebih besar dari keduanya.

Tabel ini menyediakan info tentang perkiraan resolusi, waktu akses, dan presisi berbagai jam. Perhatikan bahwa beberapa nilai akan bervariasi dengan prosesor, platform perangkat keras, dan kecepatan prosesor yang berbeda.

Sumber Jam	Frekuensi Jam Nominal	Resolusi Jam	Waktu Akses (Umum)	Presisi
PC RTC	64 Hz	15,625 milidetik	T/A	T/A
Penghitung kinerja kueri menggunakan TSC dengan jam prosesor 3 GHz	3 MHz	333 nanodetik	30 nanodetik	333 nanodetik
Instruksi mesin RDTSC pada sistem dengan waktu siklus 3 GHz	3 GHz	333 picoseconds	30 nanodetik	30 nanodetik

 

Karena QPC menggunakan penghitung perangkat keras, ketika Anda memahami beberapa karakteristik dasar penghitung perangkat keras, Anda mendapatkan pemahaman tentang kemampuan dan batasan QPC.

Generator tick perangkat keras yang paling umum digunakan adalah osilator kristal. Kristal adalah sepotong kecil kuarsa atau bahan keramik lainnya yang menunjukkan karakteristik piezoelektrik yang memberikan referensi frekuensi murah dengan stabilitas dan akurasi yang sangat baik. Frekuensi ini digunakan untuk menghasilkan tanda centang yang dihitung oleh jam.

Akurasi timer mengacu pada tingkat kesuaian dengan nilai benar atau standar. Ini terutama tergantung pada kemampuan osilator kristal untuk memberikan kutu pada frekuensi yang ditentukan. Jika frekuensi osilasi terlalu tinggi, jam akan 'berjalan cepat', dan interval terukur akan muncul lebih lama dari yang sebenarnya; dan jika frekuensi terlalu rendah, jam akan 'berjalan lambat', dan interval terukur akan tampak lebih pendek dari yang sebenarnya.

Untuk pengukuran interval waktu umum untuk durasi singkat (misalnya, pengukuran waktu respons, pengukuran latensi jaringan, dan sebagainya), akurasi osilator perangkat keras biasanya cukup. Namun, untuk beberapa pengukuran, akurasi frekuensi osilator menjadi penting, terutama untuk interval waktu yang lama atau ketika Anda ingin membandingkan pengukuran yang diambil pada komputer yang berbeda. Sisa bagian ini mengeksplorasi efek akurasi osilator.

Frekuensi osilasi kristal diatur selama proses manufaktur dan ditentukan oleh produsen dalam hal frekuensi tertentu ditambah atau dikurangi toleransi manufaktur yang dinyatakan dalam 'suku cadang per juta' (ppm), yang disebut offset frekuensi maksimum. Kristal dengan frekuensi tertentu 1.000.000 Hz dan offset frekuensi maksimum ± 10 ppm akan berada dalam batas spesifikasi jika frekuensi aktualnya antara 999.990 Hz dan 1.000.010 Hz.

Dengan mengganti bagian frasa per juta dengan mikrodetik per detik, kita dapat menerapkan kesalahan offset frekuensi ini ke pengukuran interval waktu. Osilator dengan offset + 10 ppm akan memiliki kesalahan 10 mikrodetik per detik. Dengan demikian, ketika mengukur interval 1 detik, interval akan berjalan cepat dan mengukur interval 1 detik sebagai 0,999990 detik.

Referensi yang nyaman adalah bahwa kesalahan frekuensi 100 ppm menyebabkan kesalahan 8,64 detik setelah 24 jam. Tabel ini menyajikan ketidakpastian pengukuran karena akumulasi kesalahan untuk interval waktu yang lebih lama.

Durasi interval waktu	Ketidakpastian pengukuran karena akumulasi kesalahan dengan toleransi frekuensi +/- 10 PPM
1 mikrosetik	± 10 picoseconds (10-12)
1 milidetik	± 10 nanodetik (10-9)
1 detik	± 10 mikrosetik
1 jam	± 60 mikrosetik
1 hari	± 0,86 detik
1 minggu	± 6,08 detik

 

Tabel sebelumnya menunjukkan bahwa untuk interval waktu kecil, kesalahan offset frekuensi sering diabaikan. Namun untuk interval waktu yang lama, bahkan offset frekuensi kecil dapat mengakibatkan ketidakpastian pengukuran yang substansial.

Osilator kristal yang digunakan dalam komputer dan server pribadi biasanya diproduksi dengan toleransi frekuensi ± 30 hingga 50 bagian per juta, dan jarang, kristal dapat mati sebanyak 500 ppm. Meskipun kristal dengan toleransi offset frekuensi yang jauh lebih ketat tersedia, kristal lebih mahal dan dengan demikian tidak digunakan di sebagian besar komputer.

Untuk mengurangi efek samping dari kesalahan offset frekuensi ini, versi Windows terbaru, terutama Windows 8, gunakan beberapa timer perangkat keras untuk mendeteksi offset frekuensi dan mengimbanginya sejauh mungkin. Proses kalibrasi ini dilakukan ketika Windows dimulai.

Seperti yang ditunjukkan contoh berikut, kesalahan offset frekuensi jam perangkat keras memengaruhi akurasi yang dapat dicapai, dan resolusi jam bisa kurang penting.

Contoh 1

Misalkan Anda melakukan pengukuran interval waktu dengan menggunakan osilator 1 MHz, yang memiliki resolusi 1 mikrosecond, dan kesalahan offset frekuensi maksimum ±50 ppm. Sekarang, mari kita misalkan offset tepat +50 ppm. Ini berarti bahwa frekuensi aktual adalah 1.000.050 Hz. Jika kami mengukur interval waktu 24 jam, pengukuran kami akan menjadi 4,3 detik terlalu singkat (23:59:55.7000000 diukur versus 24:00:00.000000 aktual).

Detik dalam sehari = 86400

Kesalahan offset frekuensi = 50 ppm = 0,00005

86.400 detik * 0,00005 = 4,3 detik

Contoh 2

Misalkan jam TSC prosesor dikendalikan oleh osilator kristal dan telah menentukan frekuensi 3 GHz. Ini berarti bahwa resolusinya adalah 1/3.000.000.000 atau sekitar 333 picosecond. Asumsikan kristal yang digunakan untuk mengontrol jam prosesor memiliki toleransi frekuensi ±50 ppm dan sebenarnya +50 ppm. Terlepas dari resolusi yang mengesankan, pengukuran interval waktu 24 jam masih akan menjadi 4,3 detik terlalu pendek. (23:59:55.70000000000 diukur versus 24:00:00.00000000000 aktual).

Detik dalam sehari = 86400

Kesalahan offset frekuensi = 50 ppm = 0,00005

86.400 detik * 0,00005 = 4,3 detik

Ini menunjukkan bahwa jam TSC resolusi tinggi tidak selalu memberikan pengukuran yang lebih akurat daripada jam resolusi yang lebih rendah.

Contoh 3

Pertimbangkan untuk menggunakan dua komputer berbeda untuk mengukur interval waktu 24 jam yang sama. Kedua komputer memiliki osilator dengan offset frekuensi maksimum ± 50 ppm. Seberapa jauh pengukuran interval waktu yang sama pada kedua sistem ini? Seperti contoh sebelumnya, ± 50 ppm menghasilkan kesalahan maksimum ± 4,3 detik setelah 24 jam. Jika satu sistem berjalan cepat 4,3 detik, dan 4,3 detik lainnya lambat, kesalahan maksimum setelah 24 jam bisa 8,6 detik.

Detik dalam sehari = 86400

Kesalahan offset frekuensi = ±50 ppm = ±0.00005

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

Offset maksimum antara dua sistem = 8,6 detik

Singkatnya, kesalahan offset frekuensi menjadi semakin penting saat mengukur interval waktu lama dan saat membandingkan pengukuran antara sistem yang berbeda.

Stabilitas timer menjelaskan apakah frekuensi centang berubah dari waktu ke waktu, misalnya sebagai hasil dari perubahan suhu. Kristal kuarsa yang digunakan sebagai generator tick pada komputer akan menunjukkan perubahan kecil dalam frekuensi sebagai fungsi suhu. Kesalahan yang disebabkan oleh penyimpangan termal biasanya kecil dibandingkan dengan kesalahan offset frekuensi untuk rentang suhu umum. Namun, perancang perangkat lunak untuk peralatan portabel atau peralatan yang tunduk pada fluktuasi suhu besar mungkin perlu mempertimbangkan efek ini.

Info timer perangkat keras

Daftar TSC (x86 dan x64)

Semua prosesor Intel dan AMD modern berisi register TSC yang merupakan register 64-bit yang meningkat pada tingkat tinggi, biasanya sama dengan jam prosesor. Nilai penghitung ini dapat dibaca melalui instruksi mesin RDTSC atau RDTSCP , memberikan waktu akses yang sangat rendah dan biaya komputasi dalam urutan puluhan atau ratusan siklus mesin, tergantung pada prosesor.

Meskipun register TSC tampaknya seperti mekanisme stempel waktu yang ideal, berikut adalah keadaan di mana ia tidak dapat berfungsi dengan andal untuk tujuan timekeeping:

• Tidak semua prosesor memiliki register TSC yang dapat digunakan, jadi menggunakan register TSC dalam perangkat lunak secara langsung menciptakan masalah portabilitas. (Windows akan memilih sumber waktu alternatif untuk QPC dalam hal ini, yang menghindari masalah portabilitas.)
• Beberapa prosesor dapat memvariasikan frekuensi jam TSC atau menghentikan kemajuan register TSC, yang membuat TSC tidak cocok untuk tujuan waktu pada prosesor ini. Prosesor ini dikatakan memiliki register TSC non-invarian. (Windows akan secara otomatis mendeteksi ini, dan memilih sumber waktu alternatif untuk QPC).
• Bahkan jika host virtualisasi memiliki TSC yang dapat digunakan, migrasi langsung menjalankan komputer virtual ketika host virtualisasi target tidak memiliki atau menggunakan penskalaan TSC yang dibantu perangkat keras dapat mengakibatkan perubahan frekuensi TSC yang terlihat oleh tamu. (Diharapkan bahwa jika jenis migrasi langsung ini dimungkinkan untuk tamu, hypervisor menghapus bit fitur TSC invariant di CPUID.)
• Pada sistem multi-prosesor atau multi-inti, beberapa prosesor dan sistem tidak dapat menyinkronkan jam pada setiap inti ke nilai yang sama. (Windows akan secara otomatis mendeteksi ini, dan memilih sumber waktu alternatif untuk QPC).
• Pada beberapa sistem multi-prosesor besar, Anda mungkin tidak dapat menyinkronkan jam prosesor ke nilai yang sama meskipun prosesor memiliki TSC yang invarian. (Windows akan secara otomatis mendeteksi ini, dan memilih sumber waktu alternatif untuk QPC).
• Beberapa prosesor akan menjalankan instruksi di luar urutan. Ini dapat mengakibatkan jumlah siklus yang salah ketika RDTSC digunakan untuk mengurutkan instruksi waktu karena instruksi RDTSC mungkin dijalankan pada waktu yang berbeda dari yang ditentukan dalam program Anda. Instruksi RDTSCP telah diperkenalkan pada beberapa prosesor sebagai respons terhadap masalah ini.

Seperti timer lainnya, TSC didasarkan pada osilator kristal yang frekuensi tepatnya tidak diketahui sebelumnya dan yang memiliki kesalahan offset frekuensi. Dengan demikian sebelum dapat digunakan, itu harus dikalibrasi menggunakan referensi waktu lain.

Selama inisialisasi sistem, Windows memeriksa apakah TSC cocok untuk tujuan waktu dan melakukan kalibrasi frekuensi dan sinkronisasi inti yang diperlukan.

Jam PM (x86 dan x64)

Timer ACPI, juga dikenal sebagai jam PM, ditambahkan ke arsitektur sistem untuk memberikan stempel waktu yang andal secara independen dari kecepatan prosesor. Karena ini adalah tujuan tunggal dari timer ini, ia menyediakan stempel waktu dalam satu siklus jam, tetapi tidak menyediakan fungsionalitas lainnya.

Timer HPET (x86 dan x64)

High Precision Event Timer (HPET) dikembangkan bersama oleh Intel dan Microsoft untuk memenuhi persyaratan waktu multimedia dan aplikasi sensitif waktu lainnya. Tidak seperti TSC, yang merupakan sumber daya per prosesor, HPET adalah sumber daya bersama di seluruh platform, meskipun sistem mungkin memiliki beberapa HPETs. Dukungan HPET telah ada di Windows sejak Windows Vista, dan sertifikasi Logo Windows 7 dan Windows 8 Hardware memerlukan dukungan HPET di platform perangkat keras.

Penghitung Sistem Timer Generik (Arm)

Platform berbasis arm tidak memiliki jam TSC, HPET, atau PM seperti yang ada di platform berbasis Intel atau AMD. Sebagai gantinya, prosesor Arm menyediakan Timer Generik (kadang-kadang disebut Timer Interval Generik, atau GIT) yang berisi register Penghitung Sistem (misalnya, CNTVCT_EL0). Penghitung Sistem Timer Generik adalah sumber waktu di seluruh platform frekuensi tetap. Ini dimulai pada nol saat start-up dan meningkat pada tingkat tinggi. Di Armv8.6 atau yang lebih tinggi, ini didefinisikan sebagai tepat 1 GHz, tetapi harus ditentukan dengan membaca register frekuensi jam yang ditetapkan oleh firmware boot awal. Untuk detail selengkapnya, lihat bab "Timer Generik dalam status AArch64" dalam "Panduan Referensi Arsitektur Arm untuk arsitektur profil A" (DDI 0487).

Penghitung Siklus (Arm)

Platform berbasis arm menyediakan register Penghitung Siklus Monitor Performa (misalnya, PMCCNTR_EL0). Penghitung ini menghitung siklus jam prosesor. Ini tidak invarian dan unitnya mungkin tidak berkorelasi dengan real time. Tidak disarankan untuk menggunakan register ini untuk mendapatkan tanda waktu.