Sinkronisasi jam dengan NTP saat online, dan dengan RTC saat offline?

Apakah ada mekanisme yang ada yang menyinkronkan sistem linux dengan NTP saat online, dan dengan RTC yang diprediksi melayang saat offline?

Kami mengoperasikan "kolektor" jarak jauh: sistem Linux tertanam yang mengumpulkan dan stempel waktu data sensor. Kami membutuhkan kesalahan jam mereka untuk tetap cukup kecil, katakanlah di bawah 5 detik. Biasanya kami menggunakan NTP untuk menyinkronkan jam mereka, dan itu berfungsi dengan baik - selama sistem online.

Masalahnya adalah beberapa kolektor memiliki uplink yang sangat buruk yang dapat turun selama berjam-jam, berhari-hari atau bahkan berminggu-minggu. Itu tidak menghentikan pengumpulan data lokal, tetapi tanpa NTP, jam sistem Linux melayang dengan buruk dan sangat tidak terduga.

OTOH, RTC perangkat keras melayang juga, tetapi pada tingkat yang konstan. Tingkat drift RTC bervariasi dari satu papan ke papan, tetapi konstan per papan dan dapat diukur.

Saya kira yang kita butuhkan adalah mekanisme yang melakukan hal berikut:

• Ukur tingkat drift RTC dari papan sebelum penempatannya
• Sesuaikan waktu sistem yang sedang berlangsung / secara teratur melalui NTP bila memungkinkan
• Sesuaikan waktu sistem secara teratur dari RTC ketika NTP tidak dapat dihindari. Mempertimbangkan laju penyimpangan RTC yang diketahui.
• Opsional: Ukur dan catat laju drift RTC yang sedang berlangsung saat online (1)

Dengan 'mekanisme' yang saya maksudkan adalah beberapa perangkat lunak dan / atau konfigurasi terpelihara dengan baik yang didokumentasikan yang dapat menangani dua status "online" vs. "offline", memastikan bahwa jam sistem disinkronkan dengan sumber waktu yang benar (ntp vs. rtc), mendeteksi perubahan status, dan memperbaiki drift RTC. Tidak masalah apakah itu diterapkan sebagai konfigurasi / plugin ntpd khusus, sebagai daemon terpisah, sebagai tugas cron, atau yang lain.

Saya telah melihat Chrony , tetapi menurut dokumentasinya ia mencoba untuk memprediksi penyimpangan jam sistem , yang dalam kasus kami melayang jauh lebih tak terduga daripada RTC. Chrony tampaknya menggunakan RTC hanya untuk menjaga waktu di reboot.

(1) Catatan ntpd mengaktifkan '11-menit mode 'kernel (perbarui rtc dari jam sistem setiap 11 menit). Sepertinya tidak ada cara dengan kernel saat ini dan ntpd untuk mencegah mode 11 menit. Oleh karena itu, setiap informasi rtc drift hilang saat ntpd berjalan (thx @billthor).

Pembaruan / pengeditan:

• Kami sedang mempertimbangkan untuk menambahkan jam radio eksternal untuk sinyal MSF atau DCF77 (kami berbasis di Eropa) melalui USB atau Serial. Tapi kami lebih memilih perangkat keras tetap ramping.
• Kolektor kami berada di dalam ruangan, sering di ruang bawah tanah. Jadi menambahkan jam GPS tidak akan membantu.
• Kami menggunakan Debian 7. Itu berarti hwclock dari util-linux-2.20.1, ntpdate-4.2.6p5, ntpd dari ntp-4.2.6.p5, chrony-1.24 (berpotensi 1.30).
• Perhatikan bahwa masalah kita bukanlah bahwa kita tidak tahu bagaimana menggunakan ntpdate(8), hwclock(8), date(1), dll Silakan lihat bagian ditambahkan dalam huruf miring tentang apa yang saya maksud dengan 'mekanisme'.
• Menambahkan catatan kaki tentang '11-menit mode '
• Berikut ini diskusi yang sangat menarik tentang penyinkronan offline dan penyimpangan RTC

Situasi Anda tidak biasa, dan saya akan terkejut jika ada yang datang dengan ntpdkonfigurasi berbasis standar untuk melakukan apa yang Anda inginkan. Yang mengatakan, saya suka terkejut, dan itu cukup sering terjadi di sekitar bagian ini.

Tetapi sampai seseorang datang dengan ide yang lebih baik, sudahkah Anda mempertimbangkan crontabentri seperti ini?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

Yaitu, setiap lima menit mencoba untuk menyinkronkan jam melalui ntpdate, dan jika (dan hanya jika) yang gagal, sesuaikan jam perangkat keras untuk penyimpangan sesuai dengan /etc/adjtimefile (yang formatnya dirinci man hwclock, dan yang baris pertamanya telah Anda isi dengan tepat menggunakan pengetahuan Anda. dari tingkat RTC tertentu), lalu atur jam sistem dari RTC.

Perhatikan bahwa jika Anda mencari solusi seperti ini, dan Anda sedang mengerahkan sejumlah besar sistem ini, dianggap sopan untuk bekerja dengan kumpulan, dan berkontribusi server kembali sesuai dengan penggunaan Anda. Anda dapat menemukan informasi lebih lanjut di http://www.pool.ntp.org/en/vendors.html .

NTP sudah memiliki mekanisme untuk mengetahui apakah itu online atau offline, dan itu akan beralih ke sumber prioritas yang lebih rendah seperti yang diperlukan. Sangat mudah untuk memeriksa nilai jangkauan untuk memicu sumber alternatif, tapi saya akan tetap menggunakan NTP. Seperti yang dibahas di bawah ini, pemantauan dan koreksi untuk penyimpangan RTC kemungkinan akan sulit.

Pada masa pra-Internet saya menggunakan program yang akan menelepon ke sumber data dan menyinkronkan jam. Mungkin masih ada layanan yang menyediakan sumber waktu melalui modem. Ini akan membutuhkan akses ke saluran telepon.

Ada masalah yang diketahui dengan jam lokal, yang tidak berlaku untuk RTC. Beberapa masalah didokumentasikan dalam daftar Masalah OS yang Dikenal NTP . Ini mungkin menjelaskan pergeseran jam Anda. Mengatasinya dapat menyelesaikan masalah Anda. Dengan tidak adanya kutu yang terlewat, saya telah menemukan sumber waktu (sistem) lokal mungkin sangat stabil.

Anda mungkin dapat menggunakan driver Jam bisu (33) dengan program yang menulis waktu RTC yang sesuai untuk perangkat / dev / dumbclockX.

Ada sejumlah driver lain berdasarkan jam Radio. Beberapa di antaranya menggunakan layanan gelombang pendek seperti WWV dan CHU, yang dapat bekerja di lingkungan di mana sinyal GPS tidak tersedia. Untuk Eropa daftar ini akan mencakup BBC, TDF, RBU, dan RMW.

Pavel Krejci telah menulis driver RTC juga, tetapi tampaknya tidak dimasukkan ke dalam driver resmi. Ini dapat bekerja dengan sinkronisasi jenis PPS.

Seharusnya dimungkinkan untuk mengukur penyimpangan RTC sebelum penyebaran. Namun, Anda perlu memastikan bahwa RTC tidak diperbarui secara otomatis. Ketika jam sistem diperbarui dengan fungsi adjtimex, RTC dapat diperbarui setiap 11 menit.

NTP akan memperbarui jam ketika terhubung. Biasanya NTP akan menolak untuk melakukan penyesuaian besar pada jam sistem. Ada opsi untuk menyesuaikan seberapa jauh jam dapat disesuaikan.

Saya telah menyarankan opsi untuk menggunakan RTC di atas. Jam radio mungkin lebih cocok daripada jam GPS.

Mengukur arus tanpa adanya sumber waktu yang dapat diandalkan untuk membandingkannya kemungkinan merupakan upaya yang sia-sia. Jika waktu lokal tidak stabil, Anda tidak dapat menggunakannya untuk memantau RTC dan sebaliknya. Mengukur drift ketika NTP terhubung tidak akan berfungsi jika kernel memperbarui RTC setiap 11 menit. RTC yang saya gunakan memiliki resolusi satu detik, sehingga mereka harus melayang secara signifikan agar dapat diukur dengan andal.