[EDIT] Penulisan ulang utama dengan referensi karena saya baru saja menuliskan jawaban lama dari memori.
Jawaban singkat:tidak. Tidak mungkin mendapatkan akurasi mendekati milidetik dari sistem operasi run-of-the-mill pada platform x86/x64 saat ini.
PENAFIAN Ini adalah jawaban orang awam karena saya adalah sysadmin biasa dengan tampilan komputer sysadmin biasa. Tingkat pengetahuan profesional tentang ketepatan waktu kemungkinan besar ditemukan di antara beberapa pengembang kernel dan arsitek perangkat keras.
Jawaban panjang:
Kita harus mulai dari suatu tempat. Saya akan melakukannya dari atas ke bawah, dimulai dengan aplikasi bergerak ke bawah menuju osilator.
Masalah pertama adalah tidak memiliki ketepatan waktu di satu komputer, tetapi mengatur agar lingkungan secara keseluruhan menyetujui ketepatan waktu apa pun yang Anda miliki. Apa ketepatan waktu? Ternyata ada beberapa cara untuk menjaga waktu di komputer saat ini. Yang paling sering kita lihat adalah waktu sistem (seperti yang ditampilkan di salah satu sudut layar). Mari kita mulai dengan berpura-pura bahwa hal-hal yang sederhana dan rumit hanya beberapa paragraf.
Kami ingin waktu sistem benar dan kami ingin seragam di semua komputer kami. Kami memerlukan cara untuk mengomunikasikannya dari sumber tepercaya pada tingkat yang sangat terperinci untuk memenuhi persyaratan kami, apa pun itu.
Mari kita buat persyaratan kita menjadi tingkat toleransi 1 md, yaitu, waktu kita mungkin menyimpang 1 md dalam lingkungan kita atau kita kehilangan tujuan kritis. Mari menjadi konkret dan lihat apa yang dapat dilakukan Microsoft untuk kita.
Tidak termasuk yang sudah usang seperti NT, Windows asli menjalankan ketepatan waktunya berdasarkan ntp yang disederhanakan (komputer yang bergabung dengan domain dimulai dengan XP/2003) atau sntp yang disederhanakan (komputer yang tidak bergabung dengan domain yang dimulai dengan Win2k) - terima kasih kepada @Ryan untuk memilih detail ini . Microsoft menetapkan dua tujuan saat melakukan penerapan ketepatan waktu, yang keduanya tidak mencakup tingkat akurasi yang kami inginkan:
"Kami tidak menjamin dan kami tidak mendukung keakuratan layanan W32Time antara node pada jaringan. Layanan W32Time bukanlah solusi NTP berfitur lengkap yang memenuhi kebutuhan aplikasi sensitif waktu. Layanan W32Time terutama dirancang untuk melakukan hal berikut:
- Buat protokol autentikasi Kerberos versi 5 berfungsi.
- Berikan waktu sinkronisasi yang longgar untuk komputer klien.
Layanan W32Time tidak dapat mempertahankan waktu sinkronisasi dengan andal ke kisaran satu hingga dua detik. Toleransi tersebut berada di luar spesifikasi desain layanan W32Time."
OKE. Dengan asumsi kami menjalankan tumpukan layanan Anda di lebih dari satu komputer dan memiliki tingkat toleransi ketepatan waktu mendekati 1 ms untuk korelasi peristiwa, itu cukup mengecewakan. Jika tumpukan layanan menyertakan dua komputer, kami sebenarnya tidak dapat menggunakan ketepatan waktu asli Windows sama sekali. Namun sementara kita membahasnya, mari garis bawahi satu atau dua poin penting tentang ketepatan waktu asli Windows, dan sertakan beberapa dokumentasi menyeluruh:
Jika Anda memiliki AD amati bahwa waktu dalam domain tertentu akan disinkronkan dari peran Emulator PDC, DC mana pun yang memilikinya. Oleh karena itu, membawa waktu yang tepat ke dalam domain harus melalui Pengontrol Domain yang menjalankan peran PDC Emulator. Jika di hutan multidomain ini diterjemahkan ke Emulator PDC dari domain akar hutan. Dari sana waktu tersebar terutama ke PDC Emulator subdomain dan ke setiap anggota domain dengan cara menyebar (dengan beberapa peringatan). Proses ini didokumentasikan di sini. Informasi lebih mendalam lagi di sini
OKE. Apa yang bisa kita lakukan?
Untuk memulainya, kita memerlukan satu atau cara lain yang lebih tepat untuk menyinkronkan waktu di seluruh lingkungan. Dengan asumsi kita tidak dapat menjalankan Linux ntpd atau ntpd untuk Windows, Anda dapat melihat klien shareware bernama Tardis, tetapi kemungkinan masih banyak lagi yang dapat dicoba.
Kami menjalankan Tardis di server Win2k3 yang berjalan sebagai PDC Emulator yang memiliki jam CMOS dengan kemiringan yang sangat besar, karena alasan historis yang tidak dapat dijelaskan kami tidak punya pilihan selain menyinkronkan seluruh jaringan darinya. Sekarang telah diganti menjadi sangat menyenangkan dengan Linux ntpd khusus yang membawa waktu dari jam atom di luar, tetapi Tardis menyelamatkan kita dengan mengagumkan saat itu juga. Namun saya tidak tahu apakah ini dapat membantu Anda mencapai presisi yang lebih tinggi daripada Windows native.
Tapi mari kita asumsikan mulai saat ini, bahwa kita (kita) telah menemukan cara menerapkan sinkronisasi waktu jaringan pengganti yang sempurna. Melalui kecerdikannya yang melekat, ia memiliki kapasitas untuk tingkat toleransi di bawah satu milidetik. Kami telah menerapkannya untuk menegakkan bagaimana AD kami mengharapkan waktu untuk menyebar melalui jaringan.
Apakah ini berarti bahwa kami dapat memperoleh diagnostik yang akurat dari sistem operasi dan layanan mikro dengan perincian yang mendekati satu milidetik?
Mari kita lihat bagaimana sistem operasi pada arsitektur x86/x64 menjadwalkan waktu prosesor.
Mereka menggunakan interupsi, yang merupakan binatang multifaset yang kaya akan substansi arkeologi. Namun, sistem operasi tidak sendirian dalam keinginannya untuk melakukan interupsi. Perangkat keras juga ingin menginterupsi, dan ia memiliki sarana untuk melakukannya! (Halo keyboard) Dan sistem operasi ikut bermain.
Di sinilah menjadi rumit dan saya akan menyelesaikannya dengan menyederhanakan. Pertanyaan? Saya merunduk, menutupi, dan mengarahkan Anda ke risalah yang sangat bagus tentang masalah ini. (Jika Anda mencari milidetik pada platform Windows, Anda benar-benar harus membacanya..) Versi terbaru untuk Win8.1/Win2012r2 dilaporkan sedang dikerjakan tetapi belum ada tanggal rilis yang muncul.
Oke, interupsi. Setiap kali sesuatu harus terjadi di OS, interupsi memicu tindakan yang mengikutinya. Tindakannya adalah sekumpulan instruksi yang diambil dari kernel, yang dapat dieksekusi dengan banyak cara berbeda. Intinya adalah bahwa meskipun interupsi terjadi pada waktu yang dapat ditentukan dengan lebih atau kurang akurat tergantung pada arsitektur perangkat keras dan penanganan interupsi kernel, waktu yang tepat di mana bagian eksekusi selanjutnya terjadi umumnya tidak bisa. Serangkaian instruksi tertentu dapat dieksekusi lebih awal setelah interupsi atau terlambat, dapat dieksekusi dalam urutan yang dapat diprediksi atau tidak, mungkin menjadi korban perangkat keras yang bermasalah atau driver yang ditulis dengan buruk yang memengaruhi latensi yang bahkan sulit dikenali. Sebagian besar waktu seseorang tidak tahu. Stempel waktu tingkat milidetik yang ditampilkan di file log berikutnya - sangat tepat, tetapi apakah akurat untuk kapan peristiwa itu terjadi?
Mari kita berhenti sebentar dengan interupsi ketepatan waktu. Interupsi hadir dengan tingkat prioritas, tingkat terendah adalah tempat aplikasi pengguna (seperti layanan standar) mendapatkan waktu prosesornya. Level (lebih tinggi) lainnya dicadangkan untuk perangkat keras dan untuk pekerjaan kernel. Jika interupsi pada tingkat di atas yang terendah tiba, sistem akan berpura-pura bahwa interupsi dengan prioritas lebih rendah juga dalam antrean tidak ada (sampai interupsi prio yang lebih tinggi telah ditangani). Aplikasi dan layanan biasa yang berjalan dengan cara ini akan menjadi yang terakhir dalam antrean waktu prosesor. Sebaliknya, prioritas tertinggi diberikan pada interupsi jam. Pembaruan waktu hampir selalu dilakukan dalam suatu sistem. Ini adalah penyederhanaan yang hampir seperti kriminal tentang cara kerjanya, tetapi ini memenuhi tujuan dari jawaban ini.
Waktu pembaruan sebenarnya terdiri dari dua tugas:
-
Memperbarui waktu sistem / AKA jam dinding / AKA apa yang saya katakan ketika seseorang bertanya kepada saya jam berapa sekarang / AKA hal ntp sedikit bolak-balik relatif terhadap sistem terdekat.
-
Memperbarui jumlah centang, digunakan misalnya saat mengukur durasi dalam eksekusi kode.
Tapi apakah itu wall time atau tick count, dari mana sistem mendapatkan waktu? Itu sangat tergantung pada arsitektur perangkat keras. Di suatu tempat di perangkat keras, satu atau beberapa osilator berdetak, dan detak itu dibawa melalui salah satu dari beberapa jalur yang memungkinkan ke antarmuka untuk kontak dengan kernel karena dengan presisi dan akurasi yang lebih besar atau lebih kecil memperbarui waktu dinding dan jumlah centangnya.
Ada beberapa model desain untuk penempatan osilator dalam sistem multicore, pembeda utama tampaknya adalah penempatan sinkron vs asinkron. Ini bersama dengan tantangan masing-masing untuk ketepatan waktu dijelaskan di sini misalnya.
Singkatnya, ketepatan waktu sinkron memiliki satu jam referensi per multicore, yang membuat sinyalnya didistribusikan ke semua core. Ketepatan waktu asinkron memiliki satu osilator per inti. Perlu dicatat bahwa prosesor multicore Intel terbaru (Haswell) menggunakan beberapa bentuk desain sinkron menggunakan bus serial yang disebut "QuickPath Interconnect" dengan "Forwarded Clocking", ref. lembaran data. Pencatatan Jam Kerja yang Diteruskan dijelaskan sedemikian rupa sehingga orang awam (saya) dapat dengan cepat memahaminya di sini.
Oke, jadi dengan semua nerderisme itu (yang berfungsi untuk menunjukkan bahwa ketepatan waktu adalah tugas praktis yang rumit dengan banyak sejarah hidup tentangnya), mari kita lihat lebih dekat penanganan interupsi.
Sistem operasi menangani interupsi menggunakan salah satu dari dua strategi berbeda:ticking atau tickless. Sistem Anda menggunakan satu atau yang lain, tetapi apa arti istilah tersebut?
Kernel berdetak mengirim interupsi pada interval tetap. OS tidak dapat mengukur waktu pada resolusi yang lebih halus daripada interval tick. Bahkan kemudian, pemrosesan aktual yang terlibat dalam melakukan satu atau beberapa tindakan mungkin mengandung penundaan yang lebih besar daripada interval centang. Pertimbangkan misalnya sistem terdistribusi (seperti layanan mikro) di mana penundaan yang melekat pada panggilan antar-layanan dapat memakan banyak waktu. Namun setiap set instruksi akan dikaitkan dengan satu atau beberapa interupsi yang diukur oleh OS pada resolusi yang tidak lebih baik dari waktu detak kernel. Waktu centang memiliki nilai dasar tetapi setidaknya di Windows dapat dikurangi sesuai permintaan oleh aplikasi individual. Ini adalah tindakan yang terkait tidak hanya dengan manfaat tetapi juga dengan biaya, dan membawa cukup banyak cetakan halus dengannya.
Disebut kernel tickless (yang memiliki nama yang sangat tidak deskriptif) adalah penemuan yang relatif baru. Kernel tickless mengatur waktu tick pada interval variabel (durasi selama mungkin di masa mendatang). Alasannya adalah agar OS secara dinamis memungkinkan inti prosesor masuk ke berbagai tingkat tidur selama mungkin, dengan tujuan sederhana untuk menghemat daya. "Berbagai level" termasuk memproses instruksi dengan kecepatan penuh, memproses dengan kecepatan yang dikurangi (yaitu kecepatan prosesor yang lebih lambat) atau tidak memproses sama sekali. Inti yang berbeda diizinkan untuk beroperasi pada kecepatan yang berbeda dan kernel tickless mencoba untuk membiarkan prosesor seaktif mungkin, bahkan dalam kasus termasuk mengantri instruksi untuk mematikannya dalam kumpulan interupsi. Singkatnya, inti yang berbeda dalam sistem multiprosesor dibiarkan melayang dalam waktu relatif satu sama lain. Ini tentu saja merusak waktu yang baik, dan sejauh ini merupakan masalah yang belum terpecahkan dengan arsitektur prosesor hemat daya yang lebih baru dan kernel tanpa tick yang memungkinkan mereka melakukan penghematan daya yang efisien. Bandingkan ini dengan kernel yang berdetak (interval tick statis) yang terus membangunkan semua inti prosesor, terlepas dari mereka menerima pekerjaan aktual atau tidak, dan di mana ketepatan waktu membawa tingkat ketidakakuratan tetapi pada tingkat yang relatif dapat diandalkan dibandingkan dengan kernel tanpa tick.
Waktu tick Windows standar - yaitu resolusi sistem - adalah 15,6 md hingga Windows 8/2012 di mana perilaku defaultnya adalah tickless (tetapi dapat dikembalikan ke kernel ticking). Waktu tick default Linux saya percaya tergantung pada kompilasi kernel, tetapi ceruk ini jauh di luar pengalaman saya (dan yang ini juga) jadi Anda mungkin ingin memeriksa ulang jika Anda bergantung padanya. Kernel Linux saya percaya dikompilasi tickless dari 2.6.21 dan dapat dikompilasi dengan berbagai flag yang mengoptimalkan perilaku tickless (dan saya hanya mengingat beberapa varian no_hz).
Begitu banyak untuk sistem logam telanjang. Dalam sistem virtual, ini menjadi lebih buruk, karena pertentangan VM dan hypervisor dengan cara yang berbeda membuat ketepatan waktu menjadi sangat sulit. Ini ikhtisar untuk VMware dan ini satu untuk RHEL KVM. Hal yang sama berlaku untuk sistem terdistribusi. Sistem cloud bahkan lebih sulit karena kami bahkan tidak bisa melihat hypervisor dan perangkat keras yang sebenarnya.
Sebagai kesimpulan, mendapatkan waktu yang akurat dari suatu sistem adalah masalah berlapis-lapis. Sekarang dari bawah ke atas dari sudut pandang tingkat tinggi, kita harus menyelesaikan:Sinkronisasi waktu internal antara perangkat keras dan kernel, pemrosesan interupsi dan penundaan eksekusi instruksi yang kita inginkan waktunya, jika dalam lingkungan virtual ketidakakuratan karena enkapsulasi lapisan OS kedua, sinkronisasi waktu antara sistem terdistribusi.
Oleh karena itu, pada titik ini dalam sejarah komputasi, kami tidak akan mendapatkan akurasi tingkat milidetik dari arsitektur x86/x64, setidaknya tidak menggunakan sistem operasi run-of-the-mill.
Tapi seberapa dekat kita bisa mendapatkan? Saya tidak tahu dan itu harus sangat bervariasi antara sistem yang berbeda. Mengatasi ketidakakuratan dalam sistem spesifiknya sendiri adalah tugas yang menakutkan. Orang hanya perlu melihat bagaimana Intel menyarankan pembandingan kode harus dilakukan untuk melihat bahwa sistem biasa, seperti yang kebetulan saya kelola, sangat tidak terkendali dalam perspektif ini.
Saya bahkan tidak berpikir untuk mencapai "Semua pengoptimalan daya, teknologi Intel Hyper-Threading, fungsi penskalaan frekuensi, dan mode turbo dimatikan" dalam sistem kritis, apalagi mengotak-atik pembungkus kode dalam C dan menjalankan tes jangka panjang untuk mendapatkan jawaban selanjutnya. Saya hanya berusaha menjaga mereka tetap hidup dan belajar sebanyak mungkin tentang mereka tanpa terlalu banyak mengganggu mereka. Terima kasih stempel waktu, saya tahu saya tidak dapat mempercayai Anda sepenuhnya tetapi saya tahu Anda tidak terlalu lama. Ketika akurasi milidetik yang sebenarnya menjadi penting, satu ukuran saja tidak cukup, tetapi diperlukan lebih banyak pengukuran untuk memverifikasi polanya. Apa lagi yang bisa kami lakukan?
Terakhir, menarik untuk melihat bagaimana orang-orang OS waktu nyata berpikir latensi interupsi. Ada juga alternatif sinkronisasi waktu yang sangat menarik dalam pengerjaannya, di mana cukup banyak statistik, metodologi, dan kertas putih yang menarik dipublikasikan. Tambahkan arsitektur perangkat keras dan pengembangan kernel di masa depan ke dalamnya dan dalam beberapa tahun hal akurasi ketepatan waktu ini mungkin tidak lagi menjadi masalah. Seseorang mungkin berharap.