Sejauh yang saya tahu, akurasi sinkronisasi NTP sangat tergantung pada jaringan. Saya telah melihat beberapa angka dari 50 mikrodetik hingga "di bawah satu detik" melalui internet. Nah, ini perbedaan yang sangat besar.
Saya percaya, ketepatan ketergantungan adalah pertanyaan yang bagus untuk dipelajari, tetapi sejauh ini saya gagal menemukan materi, yang dengan jelas menyatakan bahwa, katakanlah, beberapa konfigurasi tertentu memberikan akurasi tertentu.
Dikatakan di http://www.ntp.org/ntpfaq/NTP-s-algo.htm :
Perbedaan waktu antara 128ms antara server dan klien diperlukan untuk menjaga sinkronisasi NTP. Keakuratan tipikal di Internet berkisar dari sekitar 5 ms hingga 100 ms, mungkin berbeda dengan penundaan jaringan. Sebuah survei baru-baru ini [2] menunjukkan bahwa 90% dari server NTP mengalami keterlambatan jaringan di bawah 100 ms, dan sekitar 99% disinkronkan dalam satu detik ke rekan sinkronisasi.
Dengan sinkronisasi PPS, akurasi 50μs dan stabilitas di bawah 0,1 PPM dapat dicapai pada PC Pentium (menjalankan Linux misalnya).
Itu sesuatu, tapi mungkin ada beberapa analisis yang lebih menyeluruh tentang topik ini?
Jawaban:
Tidak ada yang dapat menjamin seberapa baik NTP akan bekerja di jaringan Anda, karena tidak ada yang tahu seberapa baik koneksi jaringan Anda ke internet, dan ke server jam di atasnya. Namun, menurut halaman algoritma disiplin jam di ntp.org
Perhatikan bahwa latensi besar-tetapi-stabil antara LAN Anda dan server jam internet tidak memiliki dampak buruk pada keakuratan seperti latensi yang sangat bervariasi.
Anda tidak mengatakan di mana Anda mendapatkan taksiran di atas ('50 mikrodetik ke ... "di bawah satu detik" '), jadi saya tidak dapat mengomentarinya, tetapi dalam pengalaman saya 50us tidak mungkin kecuali Anda memiliki lampiran yang terpasang langsung sumber jam, dan 1s tidak mungkin kecuali Anda memiliki seutas tali basah yang menghubungkan Anda ke internet dan Anda menggunakan server hulu di Antartika.
Sunting : teks yang sekarang Anda kutip dalam pertanyaan Anda memberikan petunjuk ke kertas yang, pada tahun 1999, memang menetapkan bahwa 99% server ntp disinkronkan dalam waktu satu detik. Untungnya, ada pekerjaan yang lebih baru; dalam makalah ini beberapa penulis dari Universitas Federal Parana, Brasil, mengulangi percobaan pada tahun 2005, dan menemukan (jika saya memahami Gambar mereka dengan benar) bahwa utara 99% - lebih seperti 99,5% - server sekarang memiliki offset kurang dari 100 ms, dan 90% memiliki offset kurang dari 10 ms. Ini sangat cocok dengan pengalaman saya (lihat di atas).
Sunting 2 : satu kerutan terakhir: semua studi ini tidak menyelidiki seberapa akurat jam lokal, tetapi seberapa jauh berbeda dari jam referensi hulu. Ini jelas bukan hal yang sama. Tapi yang pertama tidak bisa diketahui; untuk mengetahui betapa salahnya jam Anda, Anda harus tahu persis jam berapa itu, dan jika Anda tahu itu, mengapa Anda salah mengatur jam Anda? Perlu diketahui bahwa apa yang diukur oleh studi-studi ini bukanlah perbedaan antara jam lokal dan waktu absolut, tetapi antara jam lokal dan jam referensi.
sumber
Masalah apa yang Anda sedang coba pecahkan?
Solusi yang saya temui untuk lingkungan yang membutuhkan lebih presisi daripada NTP adalah Precision Time Protocol (PTP) . Saya sudah memilikinya dalam aplikasi komputasi ilmiah dan komputasi keuangan. Ada pengorbanan , meskipun.
Juga lihat: sinkronisasi waktu ptp pada centos6 / rhel
sumber
Beberapa hal lain yang layak disebutkan:
sumber
Tertarik pada bagian saya: Saya seorang agen Meinberg :-)
Ya NTP dapat mencapai presisi ujung ke ujung hingga kira-kira. 50 us (itu microseconds) dari jitter, jika Anda menyinkronkan "klien" linux pada bare metal yang menjalankan Chrony atau ntpd, ke server NTP berbasis Linux yang didisiplinkan oleh GPS, jam atom lokal atau sumber semacam itu.
Pada mesin yang memiliki GPS lokal (dengan interkoneksi PPS), Anda mungkin akan melihat 0-2 mikrodetik offset, antara instance ntpd yang berjalan di OS, dan input driver pengisian ulang PPS-nya.
Sisa 50 kita "ujung ke ujung melalui LAN" adalah hasil dari beberapa tahap buffering, latensi IRQ variabel, lalu lintas lainnya yang mengganggu LAN dan pada bus komputer yang terlibat dan yang lainnya. 50 us berarti LAN dengan lalu lintas yang sangat sedikit. Bahkan hanya sebuah sakelar dapat menambahkan beberapa mikrodetik jitter - dan sakelar kelas atas dengan fitur kompleks menambah lebih banyak latensi dan jitter. Dengan kata lain, bisa sangat sulit untuk mencapai 50 mikrodetik dalam kondisi dunia nyata Anda pada beberapa LAN praktis.
Demikian pula, cca <2us dari PPS mengimbangi hasil dari hanya ketidakpastian latensi IRQ dan jitter latensi bus umum pada perangkat keras PC berperilaku baik.
Perhatikan bahwa NTP dan implementasinya ntpd dan Chrony tentu saja mengukur waktu pulang-pergi transaksi NTP dan kurangi (tambah, sebenarnya) setengah dari perjalanan pulang-pergi itu, sebagai ukuran untuk menyaring latensi transportasi sistematis (satu arah). Mereka juga melakukan penolakan outlier, konsensus kuorum, pemilihan syspeer dan setiap demon NTP menyaring respons yang didapatnya ke kueri hulu. Jadi seperti yang dikatakan orang lain, milidetik yang Anda lihat di Ping dan Traceroute tidak secara langsung mengimbangi jam lokal Anda. Yang penting adalah variabilitas round-trip transaksi, yaitu lalu lintas lain di jalur ke server NTP hulu Anda. Ntpq -p adalah teman Anda.
Penerima GPS dasar untuk penggunaan waktu, dengan TCXO, dapat memiliki 100-200 ns sisa jitter + mengembara pada output PPS-nya. Cukup bagus untuk NTP, selama GPS tetap terkunci. (Performa peninggalan tidak terlalu baik dengan TCXO.) GPS timing yang berkualitas dengan OCXO dapat berada dalam jarak 100 ns, mungkin lebih seperti 10-30 ns dari residual error (diimbangi dari UTC global).
Perhatikan bahwa satelit yang sebenarnya terbang di atas kepala dan menyinari Anda melalui atmosfer mungkin merupakan permainan yang sedikit lebih sulit bagi penerima, daripada melakukan pembandingan di laboratorium dengan generator GPS.
PTP adalah palu. Anda memerlukan dukungan HW di grandmaster, dan di dalam slave, dan di sakelar apa pun - tetapi jika Anda mendapatkan semua itu, offset residual hingga dua digit nanoseconds rendah dimungkinkan. Saya pribadi melihat ini di ptp4l berjalan dengan i210 NIC yang memiliki dukungan HW (timestamping dengan resolusi nanosecond).
Chip i210 sangat menakjubkan. Ini memiliki 4 pin tujuan umum yang dapat digunakan untuk input atau output sinyal PPS. Referensi papan addon NIC Intel dengan i210 (dan versi OEM dari beberapa vendor besar) dilengkapi dengan pin header yang memberi Anda akses ke setidaknya 2 pin GPIO (SDP yang disebut oleh Intel). Selain menerapkan port grandmaster PTP, input PPS dapat dimanfaatkan untuk cap waktu yang tepat dalam penangkapan paket. Anda membutuhkan sumber PPS dan perangkat lunak khusus untuk menjalankan servo loop, menyesuaikan PHC i210 ke ext.PPS. Pada rig pengujian saya, ini menghasilkan satu digit ns (per 1 s iterasi) dari residual offset. Ini adalah presisi yang Anda dapatkan di cap waktu penangkapan Anda, jika Anda menjalankan tcpdump atau wireshark baru-baru ini pada kernel Linux modern (semua perangkat lunak memerlukan dukungan untuk resolusi tingkat nanosecond). Lebih baik lagi: Saya bekerja keras dan membangun synth PLL sederhana untuk menghasilkan 25 MHz untuk jam NIC, dikunci ke referensi 10MHz hulu yang tepat. Setelah itu, sisa offset dalam loop servo rig tangkapan paket saya turun ke 0 bersih (bukti bahwa referensi 10 MHz saya adalah fase-sinkron dengan PPS dari kotak GPS yang sama).
Perhatikan bahwa grandmaster PTP dapat ditentukan untuk memberikan cap waktu dengan granularity aktual per 8 ns (dalam tipe data dengan resolusi 1 ns). Ini masuk akal - gigabit Ethernet cenderung menggunakan jam 125 MHz, digunakan sebagai jam byte di bagian dalam MAC, jam ini mungkin juga digunakan di GMII, dan itu juga jam simbol dalam logam 1000Base-TX (empat pasang secara paralel, 2 bit per simbol per pasangan). Jadi, kecuali jika Anda menggunakan 1000Base-FX (serat optik) dengan SERDES dan implementasi ekstremis unit timestamping HW di PHY yang bekerja pada bit SERDES individual, 8 ns itulah yang bisa Anda harapkan secara realistis pada gigabit Ethernet. Beberapa lembar data chip (dengan dukungan PTP) bahkan mengklaim bahwa jalur data MII tidak bebas dari buffering dan beberapa jitter dapat berasal dari sana.
Paket-paket PTP sebenarnya mengandung cap waktu yang disimpan dalam tipe data yang memungkinkan untuk resolusi sub-nanosecond yang dalam. Tetapi "bidang fraksi sub-nanodetik" saat ini biasanya tidak digunakan. AFAIR hanya proyek Kelinci Putih (terkait dengan CERN, pusat penelitian Swiss) yang telah menerapkan presisi sub-ns sejauh ini.
PTP juga tersedia dalam perangkat lunak murni, tanpa akselerasi HW. Dalam hal itu, untuk GM berbasis SW dan klien berbasis SW, berharap untuk mendapatkan jitter residual yang sama seperti dengan NTP - yaitu sekitar 50 kita pada LAN berdedikasi tetapi tidak menyadari PTP. Saya ingat mendapatkan presisi sub-mikrodetik dari grandmaster HW pada interkoneksi langsung (tanpa sakelar di antara) dan klien hanya-SW (pada PTP PC NIC yang tidak sadar). Dibandingkan dengan NTP, servo PTP menyatu jauh lebih cepat.
Saat melakukan beberapa "pekerjaan rumah", baru-baru ini terpikir oleh saya bahwa mengangkut PPS atau sinyal pewaktuan "diskrit" serupa melalui rute serat optik luas mungkin rentan terhadap waktu propagasi yang bergantung pada suhu "berkeliaran". Dan meskipun saya tidak punya cara untuk menguji ini secara eksperimental, beberapa sumber dalam kata kata jalinan angka antara 40 dan 76 picoseconds per km dan Kelvin. Perhatikan bahwa meskipun "pengembara termal" semacam ini tidak mungkin untuk mengurangi "dalam pita" dalam transmisi PPS simpleks, PTP akan mengimbangi ini secara inheren, berdasarkan pada pengukuran keterlambatan jalur standar (yang tergantung pada transmisi dupleks penuh).
Begitu banyak untuk ikhtisar tentang bagaimana "precision" terlihat, pada teknologi / antarmuka waktu yang berbeda. Tingkat presisi apa yang cukup baik untuk Anda, itu tergantung pada aplikasi Anda, pada kebutuhan Anda yang sebenarnya.
sumber