chrony vs systemd-timesyncd - Apa perbedaan dan kasus penggunaan sebagai klien NTP?

Entah bagaimana tetapi tidak cukup membangun pada pertanyaan lama "ntpd vs systemd-timesyncd - Bagaimana cara mencapai sinkronisasi NTP yang andal?" , Saya ingin bertanya tentang perbedaan antara chrony dan systemd-timesyncd dalam hal klien NTP .

Saya tahu bahwa systemd-timesyncd adalah implementasi klien ntp yang kurang lebih minimal sedangkan chrony adalah solusi daemon NTP yang lengkap yang kebetulan menyertakan klien NTP.

Catatan rilis Bionic Beaver ubuntu menyatakan sebagai berikut:

Untuk sinkronisasi waktu sederhana, sistem dasar sudah dilengkapi dengan systemd-timesyncd. Chrony hanya diperlukan untuk bertindak sebagai server waktu atau jika Anda ingin sinkronisasi yang diiklankan lebih akurat dan efisien.

Saya suka ide menggunakan alat minimal yang sudah diinstal sebelumnya untuk melakukan pekerjaan dan saya cukup yakin systemd-timesyncd akan melakukan pekerjaan untuk kasus penggunaan saya, masih saya ingin tahu:

• Apa perbedaan dunia nyata antara keduanya dalam hal akurasi?
• Apa perbedaan dalam efisiensi?
• Apa itu kebutuhan sinkronisasi waktu "tidak sederhana" alias kasus penggunaan untuk kroni sebagai klien NTP?

The pengumuman systemd-timesyncd di file NEWS systemd melakukan pekerjaan yang baik menjelaskan perbedaan dari alat ini dibandingkan dengan Chrony dan alat-alat seperti itu. (penekanan milikku):

Sebuah baru "systemd-timesyncd" daemon telah ditambahkan untuk sinkronisasi jam sistem di seluruh jaringan. Ini mengimplementasikan klien SNTP . Berbeda dengan implementasi NTP seperti chrony atau server referensi NTP ini hanya mengimplementasikan sisi klien, dan tidak repot dengan kompleksitas NTP penuh, hanya berfokus pada permintaan waktu dari satu server jauh dan menyinkronkan jam lokal untuk itu . Kecuali Anda bermaksud untuk melayani NTP ke klien jaringan atau ingin terhubung ke jam perangkat keras lokal, klien NTP sederhana ini akan lebih dari cukup untuk sebagian besar instalasi. [...]

Pengaturan ini adalah kasus penggunaan umum untuk sebagian besar host di armada server. Mereka biasanya akan disinkronkan dari server NTP lokal, yang dengan sendirinya disinkronkan dari berbagai sumber, mungkin termasuk perangkat keras. systemd-timesyncd mencoba untuk memberikan solusi yang mudah digunakan untuk kasus penggunaan umum.

Mencoba menjawab pertanyaan spesifik Anda:

Apa perbedaan dunia nyata antara keduanya dalam hal akurasi?

Saya percaya Anda bisa mendapatkan akurasi yang lebih tinggi dengan mendapatkan data sinkronisasi dari berbagai sumber, yang secara khusus bukan kasus penggunaan yang didukung untuk systemd-timesyncd. Tetapi ketika Anda menggunakannya untuk mendapatkan data sinkronisasi dari server NTP pusat yang terhubung ke jaringan internal andal Anda, menggunakan beberapa sumber tidak terlalu relevan dan Anda mendapatkan akurasi yang baik dari satu sumber.

Jika Anda menyinkronkan server Anda dari server tepercaya di jaringan lokal dan di pusat data yang sama , perbedaan akurasi antara NTP dan SNTP akan hampir tidak ada. NTP dapat memperhitungkan RTT dan melakukan penghitungan waktu, tetapi itu tidak menguntungkan ketika RTT Anda sangat kecil, yang merupakan kasus jaringan lokal cepat dan mesin di dekatnya. Anda juga tidak memerlukan banyak sumber jika dapat mempercayai sumber yang Anda gunakan.

Apa perbedaan dalam efisiensi?

Mendapatkan sinkronisasi dari satu sumber jauh lebih sederhana daripada mendapatkannya dari berbagai sumber, karena Anda tidak harus membuat keputusan tentang sumber mana yang lebih baik daripada yang lain dan mungkin menggabungkan informasi dari berbagai sumber. Algoritma lebih sederhana dan akan membutuhkan lebih sedikit beban CPU untuk kasing sederhana.

Apa itu kebutuhan sinkronisasi waktu "tidak sederhana" alias kasus penggunaan untuk kroni sebagai klien NTP?

Itu dibahas dalam kutipan di atas, tetapi bagaimanapun juga ini adalah kasus penggunaan untuk Chrony yang tidak dicakup oleh systemd-timesyncd:

• menjalankan server NTP (sehingga host lain dapat menggunakan host ini sebagai sumber untuk sinkronisasi);
• mendapatkan informasi sinkronisasi NTP dari berbagai sumber (yang penting bagi penghuni yang mendapatkan informasi itu dari server publik di Internet); dan
• mendapatkan informasi sinkronisasi dari jam lokal, yang biasanya melibatkan perangkat keras khusus seperti perangkat GPS yang dapat memperoleh informasi waktu yang akurat dari satelit.

Kasus penggunaan ini membutuhkan Chrony atau ntpd atau serupa.

Saat jawaban yang lain menyatakan dengan benar, chronymengimplementasikan NTP dan systemd-timesyncdSNTP.

Dari sudut pandang klien layanan waktu:

SNTP adalah protokol yang jauh lebih sederhana untuk diimplementasikan;
NTP memungkinkan untuk peningkatan bertahap / koreksi tepat waktu. Satu keuntungan utama NTP adalah bahwa ia juga memperhitungkan RTT dari jawaban untuk mendapatkan waktu yang lebih tepat.

Dari https://www.meinbergglobal.com/english/faq/faq_37.htm

Sementara server NTP berfitur lengkap atau klien mencapai tingkat akurasi yang sangat tinggi dan menghindari langkah waktu mendadak sebanyak mungkin dengan menggunakan metode matematika dan statistik yang berbeda dan penyesuaian kecepatan clock yang halus, SNTP hanya dapat direkomendasikan untuk aplikasi sederhana, di mana persyaratan untuk akurasi dan reliabilitas tidak terlalu menuntut. Dengan mengabaikan nilai drift dan menggunakan cara-cara yang disederhanakan dari metode penyesuaian jam sistem (sering kali loncatan waktu sederhana), SNTP hanya mencapai sinkronisasi waktu berkualitas rendah bila dibandingkan dengan implementasi NTP penuh.

SNTP mengadopsi pendekatan yang jauh lebih sederhana. Banyak kompleksitas dari algoritma NTP dihilangkan. Alih-alih mengurangi waktu, banyak klien SNTP mengambil waktu. Ini bagus untuk banyak aplikasi di mana cap waktu yang sederhana diperlukan. Selain itu, SNTP tidak memiliki kemampuan untuk memantau dan memfilter beberapa server NTP. Seringkali pendekatan round-robin sederhana digunakan, di mana jika satu server gagal, yang berikutnya dalam daftar digunakan

Dari https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP jauh lebih akurat dan tepat daripada SNTP, dan ini membuatnya menjadi pemenang de facto di sebagian besar aplikasi perusahaan. Di sisi lain, kesederhanaan SNTP membuatnya lebih sesuai untuk hal-hal seperti kamera IP, DVR dan beberapa switch jaringan. Jenis perangkat keras ini tidak memiliki sumber daya pemrosesan untuk menangani protokol yang lebih kompleks, tetapi karena perangkat yang terhubung menjadi semakin kuat, itu dapat berubah.

Satu kelemahan utama dari SNTP adalah Anda tidak dapat membuatnya lebih akurat dengan mengambil waktu dari berbagai sumber seperti Network Time Protocol lakukan secara default.

Satu poin utama lainnya yang saya bisa lihat implementasi SNTP memberikan lebih banyak masalah daripada NTP adalah dalam virtualisasi, ketika Anda memiliki daemon hypervisor dan NTP yang mencoba mengubah waktu VM. Khususnya dengan mereka yang tidak setuju tepat waktu dengan beberapa kesalahan konfigurasi menyebabkan keduanya aktif, ini dapat menyebabkan masalah besar. (Sementara administrator sistem yang kompeten hanya akan tetap aktif satu metode untuk sinkronisasi dengan waktu, itu bisa terjadi mereka berdua aktif oleh kesalahan konfigurasi).

PS systemd-timesyncdtidak boleh menjadi alternatif yang disarankan saat tidak digunakan systemd.

chronybukan bentuk garpu ntpdtetapi diimplementasikan dari awal. Ini mengimplementasikan mode klien dan server protokol NTPv4 penuh ( RFC5905 ). Pada pengguna kelas perusahaan, kami melihat tren beralih dari tradisional ntpdke chronyseperti Red Hat (RHEL 7 dan seterusnya) dan SuSE (dari SLES 15).

systemd-timesyncdhanya menerapkan mode klien protokol SNTP ( RFC4330 ) . Karenanya kasus penggunaan yang rumit tidak dicakup oleh . Sebagai contoh, SNTP tidak dapat membuatnya lebih akurat dengan mengambil waktu dari berbagai sumber seperti NTP tidak secara default. Akibatnya tidak dapat memberikan waktu presisi setinggi .systemd-timesyncdsystemd-timesyncdchrony