Kernel Linux mendeteksi frekuensi prosesor yang salah

Setelah boot dingin dari server Debian 6.0.8 (HP ProLiant), ntpdbermain malapetaka dengan waktu sistem: offset dan jitter sehubungan dengan server waktu referensi biasa dan dapat diandalkan tumbuh tanpa batas. (Perhatikan bahwa server identik kembar tidak memiliki masalah sama sekali.) Setelah banyak upaya gagal untuk memperbaiki masalah di ntpdsisi saya memutuskan untuk mencoba reboot, dan semuanya berjalan OK.

Untuk menyelidiki masalah saya menemukan perbedaan ini, yang dapat menjelaskan masalah jam saya:

root@n1:~# zgrep Detected /var/log/dmesg*
/var/log/dmesg:[    0.004000] Detected 2400.110 MHz processor.
/var/log/dmesg.0:[    0.004000] Detected 2383.579 MHz processor.
/var/log/dmesg.1.gz:[    0.004000] Detected 2400.036 MHz processor.
/var/log/dmesg.2.gz:[    0.004000] Detected 2400.298 MHz processor.
/var/log/dmesg.3.gz:[    0.004000] Detected 2400.165 MHz processor.
/var/log/dmesg.4.gz:[    0.004000] Detected 2400.410 MHz processor.

Perhatikan bahwa pada boot terakhir kedua (yang bermasalah), freq CPU yang terdeteksi adalah outlier yang jelas. Tanpa outlier, kesalahan dan standar deviasi dari frekuensi yang terdeteksi sehubungan dengan yang nominal adalah +0,15 MHz ± 0,25 MHz. Untuk boot bermasalah saya memiliki kesalahan -16,4 Mhz, yaitu sekitar 100 kali lebih besar dari yang diharapkan.

Pertanyaan saya:

1. Bisakah kesalahan jenis ini membuat ntpdisiplin waktu tidak stabil / tidak dapat digunakan? Apakah ini alasan untuk masalah jam saya?

2. Apakah perilaku seperti ini merupakan gejala dari perangkat keras yang jelek? Haruskah server masuk ke pemeliharaan hw?

Memperbarui

Beberapa data bermanfaat:

• kernel 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource adalah tsc
• kesalahan untuk lpj(tentu saja) konsisten dengan kesalahan pada freq CPU

Beberapa garis konteks untuk hal di atas grep

[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.004000] Detected 2400.110 MHz processor.
[    0.000008] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.22 BogoMIPS (lpj=9600440)

Saya meyakinkan diri sendiri bahwa masalahnya adalah frekuensi salah cap waktu penghitung cap (TSC).

Rupanya kernel sedang mengkalibrasi TSC terhadap programmable interval timer (PIT). Biasanya frekuensi CPU yang diidentifikasi adalah 2400,204 ± 0,134 MHz, yang sesuai dengan akurasi sekitar 56 ppm. Setelah boot bermasalah, freq CPU diperkirakan 2383.579 MHz, yang sesuai dengan kesalahan sekitar 6900 ppm, yang ntpdtidak dapat mengompensasi. Bahkan selama 10h30m pertama berfungsi, jam sistem memperoleh sekitar 4m30s, yaitu sekitar 7000 ppm.

Karena kesalahan dalam frekuensi TSC sesuai dengan penyimpangan dalam jam sistem saya akan menyimpulkan bahwa perilaku jam abnormal disebabkan oleh kalibrasi TSC yang salah.

Namun saya tidak pernah melihat masalah sebesar ini: Saya masih bertanya-tanya tentang kemungkinan penyebab (hw, sw?) Kalibrasi yang salah ini.

Jenis perilaku ini tidak lazim. Pemeriksaan yang baik adalah memantau nilai-nilai ntp.driftfile untuk melihat apakah perubahan signifikan terjadi ketika perilaku itu muncul. Jika terus berubah secara signifikan, NTP sedang mencoba untuk memiringkan masalah. Jika itu masalahnya, itu adalah pertanda bahwa kernel salah mengidentifikasi frekuensi clock sebenarnya pada saat startup, atau jam itu sendiri lambat untuk bagian boot yang salah. Sayangnya, acara yang satu ini bukan merupakan sinyal masalah hardware yang jelas.

Jika itu terjadi lagi, tonton file ntp.drift itu.