Wawancara Umum: Bagaimana cara memilih antara NTP, PTP, dan monotonic clock?

Prompt dan cakupan

Beberapa server harus mencatat waktu kejadian yang dapat dibandingkan sementara beberapa layanan juga mengukur batas waktu (deadline) dan latensi. Jelaskan masalah apa yang diselesaikan oleh NTP, PTP, dan monotonic clock lokal-proses, lalu usulkan penerapan, perilaku saat kehilangan sinkronisasi, serta verifikasinya. Asumsikan keterlambatan jaringan yang bervariasi, restart node, dan bahwa sinkronisasi waktu tidak dapat diperlakukan sebagai konsistensi kausal (causal consistency).

Apa yang diuji oleh pewawancara

Poin penilaian utama adalah memisahkan antara waktu wall-clock yang dapat dibandingkan, waktu lokal yang telah berlalu (elapsed time), dan kausalitas kejadian. Jawaban yang kuat akan menanyakan batas toleransi presisi (precision budget) dan batasan jaringan terlebih dahulu, kemudian menempatkan NTP pada sinkronisasi umum atau jaringan luas, PTP pada LAN terkendali dengan hardware timestamping, dan monotonic clock pada pengukuran timeout. Jawaban tersebut tidak mengklaim bahwa PTP secara otomatis lebih akurat di mana saja.

Klarifikasi sebelum menjawab

1. Berapa offset maksimum yang dapat ditoleransi? Timestamp audit milidetik sering kali cocok dengan NTP; kontrol mikrodetik adalah kondisi di mana PTP dan hardware timestamping layak dievaluasi.
2. Apakah jaringan terkendali, apakah switch mendukung IEEE 1588, dan apakah boundary clock atau transparent clock tersedia? Tanpa hal-hal tersebut, asumsi PTP mungkin tidak berlaku.
3. Apakah waktu digunakan untuk pengurutan, deadline, tanda tangan digital, atau bukti kepatuhan? Deadline menggunakan waktu monotonik; pengurutan lintas node tetap memerlukan nomor urut, versi, atau logical clock.
4. Apa yang terjadi ketika sumber waktu upstream hilang: hentikan penulisan (write), turunkan performa (degrade), atau lanjutkan? Jawabannya menentukan holdover, ambang batas peringatan, dan pelabelan data.

Desain dan penurunan yang direkomendasikan

Bangun hierarki: sebagian kecil GPS, jam atom, atau sumber upstream tepercaya mengalirkan waktu ke server NTP regional, dan host biasa mendisiplinkan wall clock mereka menggunakan NTP. Pertukaran NTP harus memperhitungkan round-trip delay dan asimetri jalur, jadi pantau offset, frequency error, round-trip delay, stratum, dan usia sinkronisasi terakhir daripada hanya memantau status berjalannya layanan.

PTP menyebarkan grandmaster clock melalui switch dan dapat menggunakan hardware timestamping untuk mengurangi kesalahan penjadwalan OS dan antrean NIC. Dalam LAN terkendali dengan boundary clock atau transparent clock serta endpoint berkemampuan perangkat keras, PTP dapat memenuhi batasan kesalahan yang lebih ketat daripada NTP. Di seluruh internet publik atau jalur cloud yang berubah-ubah, verifikasi dukungan perangkat dan jaringan yang sebenarnya sebelum menjanjikan tingkat presisi tersebut.

wall_now = CLOCK_REALTIME      # calendar, logs, cross-node timestamps
elapsed = CLOCK_MONOTONIC      # deadlines, retries, latency measurement
deadline = monotonic_start + timeout

Monotonic clock tidak bergerak mundur saat NTP mendisiplinkan wall time, sehingga tepat digunakan untuk kalkulasi waktu yang telah berlalu. Linux mendokumentasikan semantik yang berbeda untuk CLOCK_REALTIME dan CLOCK_MONOTONIC. Bahkan wall clock yang tersinkronisasi dengan baik pun tidak aman untuk timeout 30 detik karena koreksi waktu dapat melakukan penyesuaian seketika (step) atau penyesuaian bertahap (slew).

Alternatif dan kompromi (trade-off)

NTP mudah diterapkan, bekerja melintasi jaringan ter-routing, dan memiliki perangkat operasional yang matang; tingkat kesalahannya bergantung pada jalur dan proses timestamping host. PTP dapat memberikan offset dan jitter yang lebih rendah dalam domain terkendali; PTP bergantung pada NIC, switch, driver, dan sumber clock, sehingga failure domain dan konfigurasinya lebih besar. Untuk pengurutan kejadian, logical clock atau urutan database sering kali lebih langsung daripada mengejar waktu fisik yang lebih ketat. Untuk durasi satu host, waktu monotonik adalah alat yang tepat untuk kedua kasus tersebut.

Mode kegagalan, batasan, dan contoh kontra

• Memperlakukan status “NTP tersinkronisasi” sebagai bukti bahwa timestamp bisnis akurat sambil mengabaikan perubahan offset, stratum, dan sumber.
• Menggunakan CLOCK_REALTIME untuk deadline; perubahan manual atau koreksi jam dapat membuat batas waktu (timeout) terjadi terlalu cepat atau terlambat.
• Menjanjikan presisi mikrodetik PTP pada host cloud tanpa hardware timestamping; kapabilitas jaringan adalah prasyarat mutlak.
• Menyimpulkan kausalitas lintas node dari timestamp wall clock. Latensi jaringan dapat menghasilkan waktu yang sama persis (tie) atau pengamatan yang terbalik; gunakan data urutan, versi, atau logical clock.
• Tetap menerbitkan tanda tangan digital atau catatan audit yang tampaknya presisi setelah kehilangan sinkronisasi; catat sumber waktu, usia sinkronisasi, dan ketidakpastian, lalu beri label atau tolak operasi berisiko tinggi yang melampaui ambang batas.

Daftar periksa pengujian dan verifikasi

Verifikasi tiga lapisan: uji semantik realtime dan monotonic pada setiap node; kumpulkan offset NTP/PTP, jitter, frequency error, dan usia sinkronisasi; lalu lakukan injeksi latensi, packet loss, perubahan sumber upstream, dan restart. Nyatakan kriteria penerimaan sebagai “di bawah jaringan dan perangkat keras yang ditentukan, 99,9% jendela waktu tetap berada di bawah offset X”, serta uji holdover dan pemulihan secara terpisah. Perbandingan tunggal date bukanlah bentuk validasi yang memadai.

Pertanyaan lanjutan

Bagaimana seharusnya urutan kejadian lintas node diatur?

Gunakan waktu fisik untuk tampilan antarmuka dan kolom audit, tetapi serahkan penetapan kausalitas pada versi monotonik, nomor urut pesan, urutan commit database, atau logical clock. Jika timeline yang dihadapi pengguna diperlukan, tampilkan interval ketidakpastian dan terapkan tie-breaker yang stabil di dalam interval yang saling tumpang tindih.

Bisakah PTP sepenuhnya menggantikan NTP?

Tidak ada pengganti yang berlaku secara universal. PTP cocok untuk domain terkendali dengan batasan presisi yang eksplisit; NTP masih mencakup jaringan manajemen, tautan area luas (wide-area links), dan host tanpa perangkat keras PTP. Desain umum menggunakan PTP untuk domain kritis dan menyediakan NTP dari layanan di dalam domain tersebut ke host lain.

Haruskah sebuah layanan berhenti ketika sumber waktunya hilang?

Tingkatkan penilaian berdasarkan risiko bisnis. Cache atau metrik biasa dapat terus berjalan dalam batas holdover tertentu; tanda tangan digital, sertifikat, atau pencocokan transaksi keuangan harus menolak atau meneruskan eskalasi saat ketidakpastian melampaui ambang batas. Setiap penurunan fungsionalitas (downgrade) memerlukan peringatan, label data, dan catatan kalibrasi setelah pemulihan.