Bagaimana saya bisa mengukur dan mencegah jam melayang?

15

Pada beberapa platform produksi kami telah mengamati gejala yang tampaknya menunjukkan bahwa waktu siang hari secara berkala melompat maju atau mundur. Lompatan biasanya sekitar 1 detik, biasanya dibatalkan (lompat ke depan lalu mundur segera setelah itu) dan terjadi sekitar 50 kali per hari. Penyimpangan ini paling terlihat selama waktu penggunaan aplikasi puncak, dan selama periode operasi I / O disk tinggi seperti cadangan harian. Drift ini memengaruhi aplikasi sensitif real-time lunak kami.

Sistemnya adalah server Oracle Netra X4250 dan Netra X4270 yang menjalankan SLES 11SP2 dengan kernel default 3.0.58-0.6.6.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Kami telah menonaktifkan NTP , tetapi itu tidak berpengaruh pada drift. Apakah ada alat yang mengukur waktu jam siang hari melayang? Bagaimana kita bisa menghindari ini?

Ini adalah platform produksi, dan kami tidak dapat membuat ulang masalah di lab kami, jadi kemampuan saya untuk bereksperimen terbatas. Jika dibiarkan sendiri, saya akan menulis alat untuk mengukur drift, dan mungkin bereksperimen dengan sumber daya jam HPET .

linux sles clock

— brett
sumber

5

Menonaktifkan NTP membuat jam jauh lebih tidak stabil ... satu-satunya alasan saya dapat melihat NTP untuk tidak menjaga jam tetap sejalan adalah bahwa jamnya rusak, dan NTP menolak untuk memperbaruinya (lihat ntpdate(8)atau ntpd(8)).

— vonbrand

1

NTPD melacak dan memperbaiki drift jam, tetapi apa yang Anda miliki tidak drift. Drift secara konsisten dalam arah yang sama dengan jumlah yang kira-kira sama dari waktu ke waktu. Jika secara acak melompat maju dan mundur, tidak ada cara untuk memprediksi itu, dan menampungnya.

— Patrick

1

Apa yang dikatakan @Patrick benar, masalah yang Anda gambarkan adalah lompatan waktu ke depan dan ke belakang, beberapa kali per hari. NTP berfungsi dengan baik pada drift tetapi tidak banyak membantu Anda dengan ini. Sesuatu mungkin mengatur ulang tanggal sistem Anda ke beberapa sumber waktu eksternal yang mungkin hanya memiliki resolusi 1 detik. Jika server Anda x86 * perangkat keras RTC mungkin menjadi sumber dan beberapa cron pekerjaan pelakunya. Sejauh mengukur jam mengimbangi jawaban ntpdate Bratchley adalah pendekatan yang masuk akal asalkan menggunakan stratum 1 referensi jam yang baik: jalankan satu menit sekali dan gnuplot hasilnya untuk gambar.

— duanev

1

Berlari melintasi evaluasi NTP ini memulai pada server baru ( drdobbs.com/embedded-systems/… ). Butuh NTP jam untuk mempelajari kristal baru. Untuk kristal yang benar-benar buruk, NTP harus 'menginjak' jam dengan jumlah yang signifikan beberapa kali saat pelatihan (lihat Gambar 4 dan 5 dalam artikel itu). Nilai akhir dalam ntp.drift dari 118ppm adalah 10 detik per hari atau 208ms setiap 30 menit. Meskipun ini bukan apa yang dilihat OP, NTP pada awalnya dapat menyebabkan lompatan yang terlihat pada waktunya.

— duanev

8

Apakah ada alat yang mengukur waktu jam siang hari melayang?

Satu-satunya alat yang saya ketahui adalah alat NTP yang cukup. Anda tidak harus benar-benar mengkonfigurasi ntpd untuk menyinkronkan dengan sumber clock yang diberikan, Anda cukup menggunakan -dopsi ntpdateuntuk mengambil offset yang dihitung.

Contoh:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d adalah opsi debug yang berfungsi NTP tanpa benar-benar menyentuh jam sistem.

Adakah saran untuk menghindari hal ini?

Saya tidak terlalu terkejut bahwa Anda tidak dapat mereproduksi ini di lingkungan dev / test karena mungkin hanya karena jam perangkat keras. Jika Anda memiliki dukungan perangkat keras dengan seseorang, saya akan mencoba untuk memperbaiki mesin Anda. Salah satu kemungkinan adalah menukar salah satu mesin dev untuk mesin produksi ini, memperbaiki sistem PROD sebelumnya dan memperkenalkannya kembali sebagai mesin dev untuk menggantikan yang ada di PROD sekarang.

Singkatnya, mengganti sumber jam perangkat keras adalah tentang semua yang dapat Anda lakukan. Jika Anda tidak atau tidak dapat melakukan swap, saya sarankan Anda pergi ke rute yang sulit. Anda dapat menguji apakah perubahan sumber jam mengacaukan layanan sistem dan kemudian menyebarkannya ke dalam produksi sebagai hujan es.

— Bratchley
sumber

Dengan "mengukur jam drift", maksud saya bukan drift dari sumber waktu referensi, seperti NTP memberi Anda. Maksud saya alat yang dapat mendeteksi "lompatan" pada waktu siang hari dalam rentang waktu terus menerus. Misalnya, ambil sampel waktu harian setiap 50 ms, dan laporkan jika perbedaan dari pengambilan sampel terakhir terlalu jauh dari 50 ms. Alat semacam itu akan menunjukkan jika jam siang melayang dari jam perangkat keras yang mendasarinya dengan alasan apa pun.

— brett

1

Bukankah kehadiran intervensi seperti itu mungkin menyebabkan penurunan kinerja lebih banyak daripada yang Anda harapkan untuk diselesaikan? Namun, dalam semua kemungkinan, ini adalah masalah perangkat keras, jadi Anda perlu memperbaiki perangkat keras atau menggunakan sumber jam tanpa masalah ini. tscBerbasis di CPU sehingga masuk akal bahwa aktivitas CPU yang lebih tinggi akan memicu masalah dengan jam hardware. Jika hpet cukup cepat untuk Anda, maka Anda mungkin hanya perlu mencobanya, dilayani, atau melakukan pertukaran. Itulah satu-satunya opsi yang bisa saya lihat untuk Anda.

— Bratchley

3

Salah satu solusinya adalah menggunakan HPET

Lihat juga Timer Acara Presisi Tinggi

Untuk mengaturnya sebagai penggunaan parameter boot

clocksource=hpet

Pada perangkat keras yang lebih lama TSCsering tidak stabil dan dinonaktifkan oleh kernel.

Dengan munculnya CPU multi-core / hyper-threaded, sistem dengan banyak CPU, dan sistem operasi hibernasi, TSC tidak dapat diandalkan untuk memberikan hasil yang akurat ...

Wikipedia: Penghitung Stempel Waktu

Pada sistem produksi yang menunjukkan gejala jam jitter, saya mengalihkan sumber daya jam ke hpet. Ini tidak berpengaruh pada gejala jam jitter yang diamati.

— brett

HPET adalah pengatur waktu perangkat keras eksternal dan tidak dapat jitter. Jadi solusi ini sepertinya jalan yang salah. Ada banyak masalah pengaturan waktu dengan perangkat keras lama, terutama saat menggunakan virtualisasi. Apakah Anda memeriksa ini dengan perangkat lunak yang berbeda juga?

1

Saya menulis alat yang lebih terperinci untuk menghubungkan pengukuran jam dengan gejala latensi yang ditunjukkan oleh aplikasi kita. Alat ini tampaknya mengesampingkan apa yang sebelumnya saya duga sebagai jitter di waktu Linux siang hari.

Singkat cerita, hipotesis awal saya tidak valid. Tetapi saya belajar banyak tentang jam Linux dari jawaban dan tautan, jadi terima kasih kepada semua yang menjawab!

— brett
sumber

3

(...) hipotesis awal saya tidak valid. Bisakah Anda memberi tahu kami apa penyebab sebenarnya?

— Piotr Dobrogost

0

Bukankah jam seharusnya monoton kecuali seseorang mengubahnya? Melompat mundur seharusnya tidak mungkin. Pasti ada sesuatu yang mengatur jam - tugas cron atau daemon lain (misalnya panggilan kehwclock --adjust ). Saya ingat bahwa ntp sendiri memperbarui statistik untuk penyimpangan dan mengkompensasi untuk itu secara rutin dan jika Anda gagal menjalankan ntp untuk waktu yang lama dan mendapatkan offset besar, itu mengacaukan waktu selama berhari-hari setelahnya jika Anda tidak mengatur ulang /etc/adjtime. Anda mungkin memiliki pengaturan seperti itu - sesuatu yang menyesuaikan waktu melayang secara berkala (dan menyebabkan lompatan).

ntp sebenarnya dimaksudkan untuk mengatasi masalah ini.

— orion
sumber

Itulah yang saya pikirkan juga. Pembacaan saya terhadap sumber jam perangkat keras menunjukkan bahwa penghitung harus meningkat secara monoton. Jika itu benar, paling buruk kita harus mengamati tingkat centang yang tidak menentu, tetapi tidak pernah melompat kembali. Pada sistem multiprosesor, saya mengerti bahwa tsc perlu disinkronkan di antara prosesor - mungkin ini yang menyebabkan melompat mundur?

— brett