Seberapa jauh “terlalu jauh” untuk ntpd? Bisakah itu tiba di sana dengan lompatan tiba-tiba ke beban berat? Bisakah ini ditimpa?

Dalam banyak primer pada ntpd, seperti ini , selalu ada peringatan bahwa ntpd akan berhenti mengatur ulang jam "[jika] jam Anda terlalu jauh."

Seberapa jauh "terlalu jauh"?

Juga, jika server mengambil lompatan tiba-tiba ke beban berat, misalnya dari total idleness menjadi 100% CPU, akankah peningkatan suhu menyebabkan jam cenderung "terlalu jauh"?

Bisakah ntpd dikonfigurasikan untuk menyetel ulang jam bahkan jika waktunya "terlalu jauh" atau setidaknya membuat "terlalu jauh" sedikit lebih jauh?

Pertama, perbedaan maksimum default adalah 1000-an seperti yang disebutkan orang lain. Seperti yang dinyatakan @kyle, Anda dapat menggunakan -gbendera untuk mengabaikan SATU kali ini hanya untuk mengatur jam Anda pada awalnya.

Setelah itu Anda benar-benar tidak akan melihat jam Anda terbawa 1000-an antara pembaruan bahkan di bawah beban tinggi, dan jika Anda melakukannya, Anda benar-benar perlu mengganti jam. Pengaturan dalam konfigurasi yang Anda butuhkan adalah minpolldan maxpoll. Ini akan memungkinkan Anda untuk mengatur durasi interval ke kekuatan 2 (misalnya 10 berarti 2 ¹⁰ = 1024 dtk).

Harap dicatat bahwa sistem Anda kemungkinan tidak akan melayang secara substansial bahkan di bawah beban tinggi, dan pengaturan default harus tetap di periksa. Anda tidak ingin membombardir server NTP dengan pembaruan setiap detik karena Anda menghabiskan sumber daya yang akan membuat Anda diblokir dan kemungkinan besar panggilan ke ISP NOC Anda. Jika Anda benar-benar membutuhkan waktu yang sangat akurat gunakan GPS atau atur server NTP Anda sendiri.

NTPD dapat menyesuaikan jam Anda secara bertahap lambat, jika jam mati. Gagasan di balik itu adalah bahwa langkah-langkah lambat tidak akan menyebabkan masalah dengan pengatur waktu perangkat lunak, kesenjangan aneh dalam file log dll.

Tingkat perubahan tegangan maksimum yang dimungkinkan dibatasi hingga 500 bagian per juta (PPM) oleh kernel Unix. Akibatnya, jam dapat mengambil 2000 untuk setiap detik jam berada di luar rentang yang dapat diterima.

Menurut halaman buku panduan, ntpd tidak akan berfungsi jika jam Anda lebih dari 1000 detik.

Karena memperlambat jam untuk menyesuaikannya dengan 1000 detik akan memakan waktu setidaknya 3 minggu dan selama waktu itu semua tanggal / cap waktu masih mati, itu sepertinya tidak masuk akal.

The ntpdateperintah memiliki -b beralih ke hanya menyesuaikan waktu tanpa slewing. Ini berguna dalam kasus di mana jam sistem lokal menyimpang terlalu banyak dari waktu "benar".

Ini ditentukan dalam man ntpd, dan Anda menimpanya Anda mungkin tertarik pada -gopsi (Perhatikan "yang 1000 s secara default":

-g Biasanya, ntpdkeluar dengan pesan ke log sistem jika offset melebihi ambang panik, yang merupakan 1000 s secara default. Opsi ini memungkinkan waktu diatur ke nilai apa pun tanpa batasan; Namun, ini bisa terjadi hanya sekali. Jika ambang melebihi setelah itu, ntpdakan keluar dengan pesan ke log sistem. Opsi ini dapat digunakan dengan opsi -qdan -x. Lihat tinkerperintah untuk opsi lain.

Anda dapat menyesuaikan ini di ntpd.conf. Jika Anda ingin menonaktifkannya, Anda dapat mengatur tinker panic 0. Lihat dokumentasi Opsi Macam - Macam untuk mempelajari lebih lanjut.