🏈 🧝🏽 👆 Detail Implementasi Protokol Sinkronisasi Waktu PTPv2 ✍🏽 🛬 🍽️

Pendahuluan

Konsep membangun "Digital Substation" di industri tenaga listrik membutuhkan sinkronisasi dengan akurasi 1 μs. Transaksi keuangan juga membutuhkan akurasi mikrodetik. Dalam aplikasi ini, akurasi waktu NTP tidak lagi memadai.

Protokol sinkronisasi PTPv2, dijelaskan oleh standar IEEE 1588v2, memungkinkan akurasi sinkronisasi beberapa puluh nanodetik. PTPv2 memungkinkan Anda mengirim paket sinkronisasi melalui jaringan L2 dan L3.

Area utama di mana PTPv2 digunakan adalah:

teknik tenaga;
peralatan kontrol dan pengukuran;
kompleks industri militer;
Telekomunikasi
sektor keuangan.

Posting ini melihat bagaimana protokol sinkronisasi PTPv2 bekerja.

Kami memiliki lebih banyak pengalaman industri dan kami sering menemukan protokol ini dalam aplikasi energi. Karenanya, kami akan melakukan tinjauan dengan memperhatikan energi .

Mengapa itu perlu?

Saat ini, STO 34.01-21-004-2019 dari PJSC Rosseti dan STO 56947007-29.240.10.302-2020 dari PJSC FGC UES berisi persyaratan untuk mengatur bus proses dengan sinkronisasi waktu melalui PTPv2.

Hal ini disebabkan oleh fakta bahwa terminal proteksi relay dan alat pengukur terhubung ke bus proses, yang mentransmisikan nilai arus dan tegangan sesaat melalui bus proses menggunakan apa yang disebut aliran SV (aliran multicast).

Terminal perlindungan relai menggunakan nilai-nilai ini untuk menerapkan perlindungan koneksi. Jika keakuratan pengukuran dari waktu ke waktu kecil, maka beberapa perlindungan mungkin berhasil salah.

Misalnya, perlindungan selektivitas absolut dapat menjadi korban sinkronisasi waktu "lemah". Seringkali logika pertahanan semacam itu didasarkan pada perbandingan dua nilai. Jika nilai-nilai berbeda dengan nilai yang cukup besar, perlindungan dipicu. Jika nilai-nilai ini diukur dengan akurasi 1 ms, maka Anda bisa mendapatkan perbedaan besar di mana nilai-nilai itu sebenarnya normal, jika Anda mengukurnya dengan akurasi 1 μs.

Versi PTP

Protokol PTP pada awalnya dijelaskan pada tahun 2002 dalam standar IEEE 1588-2002 dan disebut "Standar untuk Protokol Sinkronisasi Jam Presisi untuk Pengukuran Jaringan dan Sistem Kontrol". Pada tahun 2008, standar IEEE 1588-2008 yang diperbarui, yang menggambarkan PTP Versi 2. dirilis dalam versi protokol ini, akurasi dan stabilitas ditingkatkan, tetapi kompatibilitas ke belakang dengan versi protokol yang pertama tidak dipertahankan. Juga, pada tahun 2019, versi standar IEEE 1588-2019 dirilis yang menggambarkan PTP v2.1. Versi ini menambahkan perbaikan kecil ke PTPv2 dan kompatibel dengan PTPv2.

Dengan kata lain, kami memiliki gambar berikut dengan versi:

	PTPv1 (IEEE 1588-2002)	PTPv2 (IEEE 1588-2008)	PTPv2.1 (IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)	-	Tidak kompatibel	Tidak kompatibel
PTPv2 (IEEE 1588-2008)		—
PTPv2.1 (IEEE 1588-2019)			—

Tapi, seperti biasa, ada nuansa.

Ketidakcocokan antara PTPv1 dan PTPv2 menunjukkan bahwa perangkat dengan dukungan PTPv1 tidak akan dapat menyinkronkan dari jam yang tepat berjalan di PTPv2. Mereka menggunakan berbagai format pesan untuk sinkronisasi.

Tetapi Anda masih bisa menggabungkan perangkat dengan PTPv1 dan perangkat dengan PTPv2 di jaringan yang sama. Untuk melakukan ini, beberapa produsen mengizinkan Anda untuk memilih versi protokol pada port jam perbatasan. Artinya, batas jam dapat disinkronkan melalui PTPv2 dan pada saat yang sama menyinkronkan jam lain yang terhubung ke keduanya oleh PTPv1 dan PTPv2.

Perangkat PTP. Apa dan bagaimana perbedaannya?

Standar IEEE 1588v2 menjelaskan beberapa jenis perangkat. Semuanya diberikan dalam tabel.

Perangkat berkomunikasi satu sama lain melalui LAN menggunakan PTP.

Perangkat PTP disebut jam. Semua jam tangan mengambil waktu yang tepat dari jam tangan grandmaster.

Ada 5 jenis jam tangan:

Jam grandmaster	Sumber utama waktu yang akurat. Seringkali dilengkapi dengan antarmuka untuk menghubungkan GPS.
Jam Biasa	Perangkat port tunggal yang dapat berupa master (master clock) atau slave (master clock)
Jam kerja unggulan (master)	Mereka adalah sumber waktu yang tepat saat jam lain disinkronkan.
Slave Clock (Slave)	Perangkat akhir yang disinkronkan dari master clock
Jam Batas	Perangkat dengan banyak port, yang bisa berupa master atau slave. Artinya, arloji ini dapat menyinkronkan dari master clock yang lebih tinggi dan menyinkronkan slave clock yang lebih rendah.
End-to-end Transparent Clock ( , End-to-End)	, , . PTP . PTP-. .
Peer-to-Peer Transparent Clock ( , Peer-to-Peer)	Perangkat dengan banyak port yang bukan master clock atau slave. Ini mentransmisikan data PTP antara dua jam. Saat mengirimkan data, jam transparan mengoreksi semua pesan PTP Sinkronisasi dan Follow_Up (lebih lanjut tentang mereka dijelaskan di bawah). Koreksi dicapai dengan menambahkan bidang penyesuaian paket delay yang ditransmisikan pada perangkat transmisi dan penundaan pada saluran data.
Simpul Manajemen	Perangkat yang mengkonfigurasi dan mendiagnosis jam tangan lain

Master dan slave jam disinkronkan menggunakan perangko waktu dalam pesan PTP. Ada dua jenis pesan dalam protokol PTP:

Pesan Acara adalah pesan yang disinkronkan yang melibatkan pembuatan cap waktu pada saat pesan dikirim dan pada saat diterima.
General Messages – ,

Event Messages	General Messages
Sync Delay_Req Pdelay_Req Pdelay_Resp	Announce Follow_Up Delay_Resp Pdelay_Resp_Follow_Up Management Signaling

Selanjutnya, kami akan mempertimbangkan semua jenis pesan secara lebih rinci.

Masalah utama sinkronisasi

Ketika mengirimkan paket sinkronisasi melalui jaringan lokal, ia tertunda di sakelar dan di saluran transmisi data. Setiap saklar akan memberikan penundaan sekitar 10 μs, yang tidak dapat diterima untuk PTPv2. Bagaimanapun, kita perlu mendapatkan akurasi 1 μs pada perangkat akhir. (Ini adalah

soal energi. Aplikasi lain mungkin memerlukan lebih akurat.) IEEE 1588v2 menjelaskan beberapa algoritma operasi yang memungkinkan Anda untuk merekam waktu tunda dan menyesuaikannya.

Algoritma operasional
Selama operasi normal, protokol beroperasi dalam dua fase.

Fase 1 - Pembentukan hierarki "Jam Memimpin - Jam Slave".
Fase 2 - sinkronisasi jam menggunakan mekanisme End-to-End atau Peer-to-Peer.

Fase 1 - Menyiapkan hierarki Master Slave

Setiap port jam biasa atau batas memiliki sejumlah negara tertentu (jam slave dan jam master). Standar menggambarkan algoritma transisi antara negara-negara ini. Dalam pemrograman, algoritma semacam itu disebut mesin negara atau mesin negara (lebih lanjut tentang Wiki).

Mesin negara ini menggunakan Algoritma Clock Master Terbaik (BMCA) untuk mengatur master ketika dua jam terhubung.

Algoritma ini memungkinkan arloji untuk memikul kewajiban arloji grandmaster ketika arloji grandmaster superior kehilangan sinyal GPS, terputus dari jaringan, dll

Transisi negara sesuai dengan BMCA secara singkat ditunjukkan pada diagram berikut:

Informasi tentang jam di ujung "kawat" dikirim dalam pesan khusus (Umumkan pesan). Ketika informasi ini diterima, algoritma mesin negara memproses dan membandingkan jam mana yang lebih baik. Port pada jam tangan terbaik menjadi arloji terkemuka.

Hirarki sederhana disajikan pada diagram di bawah ini. Jalur 1, 2, 3, 4, 5 dapat berisi jam transparan (jam Transparan), tetapi mereka tidak berpartisipasi dalam pembentukan hierarki "Jam terkemuka - Jam budak".

Fase 2 - Sinkronisasi jam normal dan batas

Segera setelah hierarki "Jam buka - Jam buka" ditetapkan, fase sinkronisasi jam reguler dan batas dimulai.

Untuk sinkronisasi, jam master mengirim pesan berisi cap waktu ke jam pendukung.

Jam kerja utama dapat:

satu tahap;
dua tahap.

Jam satu tahap untuk sinkronisasi mengirim satu pesan Sync.

Jam dua tahap menggunakan dua pesan untuk sinkronisasi - Sinkronisasi dan Follow_Up.

Dua mekanisme dapat digunakan untuk fase sinkronisasi:

Menunda mekanisme respons permintaan.
Mekanisme pengukuran keterlambatan rekan.

Untuk mulai dengan, kami akan mempertimbangkan mekanisme ini dalam kasus paling sederhana - ketika jam tangan transparan tidak digunakan.

Menunda mekanisme respons permintaan

Mekanisme ini memiliki dua langkah:

Pengukuran keterlambatan pengiriman pesan antara master clock dan slave. Hal ini dilakukan dengan menggunakan mekanisme respons permintaan penundaan.
Mengoreksi pergeseran waktu yang tepat.

Delay Measurement

t1 - Menyinkronkan waktu pengiriman pesan dengan jam terkemuka; t2 - Menyinkronkan waktu penerimaan pesan dengan jam slave; t3 - Menunda waktu pengiriman permintaan (Delay_Req) oleh jam kerja paksa; t4 - Delay_Req waktu penerimaan oleh jam terkemuka.

Ketika jam slave mengetahui waktu t1, t2, t3 dan t4, mereka dapat menghitung rata-rata waktu pengiriman pesan sinkronisasi (tmpd). Dihitung sebagai berikut:

Saat mengirimkan pesan Sync dan Follow_Up, waktu tunda dari master ke slave dihitung - t-ms.

Saat mengirimkan pesan Delay_Req dan Delay_Resp, waktu tunda dari slave ke master, t-sm, dihitung.

Jika beberapa asimetri terjadi di antara kedua nilai ini, kesalahan muncul dalam koreksi keberangkatan waktu yang tepat. Kesalahan ini disebabkan oleh fakta bahwa penundaan yang dihitung adalah rata-rata dari penundaan t-ms dan t-sm. Jika penundaan tidak sama satu sama lain, maka kami akan menyesuaikan waktu secara tidak akurat.

Mengoreksi offset waktu yang tepat

Setelah penundaan antara jam utama dan jam pendukung diketahui, jam pendukung melakukan koreksi waktu.

Jam slave menggunakan pesan Sync dan pesan Follow_Up opsional untuk menghitung offset waktu yang tepat saat mentransmisikan paket dari master clock ke slave. Pergeseran dihitung menggunakan rumus berikut:

Mekanisme pengukuran keterlambatan rekan Mekanisme

ini juga menggunakan dua langkah untuk menyinkronkan:

. peer delay mechanism.
.

Pengukuran

Penundaan Sebaya Sebaya Delay antara perangkat berkemampuan sebaya diukur dengan menggunakan pesan-pesan berikut:

Ketika port 1 mengetahui waktu t1, t2, t3 dan t4, ia dapat menghitung rata-rata penundaan (tmld ) Itu dihitung menggunakan rumus berikut:

Kemudian, port menggunakan nilai ini untuk menghitung bidang penyesuaian untuk setiap pesan Sync atau pesan Follow_Up opsional yang melewati perangkat ini.

Total keterlambatan akan sama dengan jumlah keterlambatan saat mentransmisikan melalui perangkat ini, penundaan rata-rata saat mentransmisikan melalui saluran data dan penundaan yang sudah terkandung dalam pesan ini, termasuk pada perangkat yang lebih tinggi.

Pesan Pdelay_Req, Pdelay_Resp dan opsional Pdelay_Resp_Follow_Up memungkinkan Anda untuk mendapatkan penundaan dari master ke slave dan dari slave ke master (melingkar).

Asimetri apa pun di antara kedua nilai ini akan menghasilkan kesalahan koreksi offset waktu yang akurat.

Mengoreksi offset waktu yang tepat

Jam slave menggunakan pesan Sync dan pesan Follow_Up opsional untuk menghitung offset waktu yang tepat ketika mentransmisikan paket dari jam terkemuka ke budak. Pergeseran dihitung berdasarkan rumus berikut:

Keuntungan penyesuaian peer-to-peer - waktu tunda setiap pesan Sync atau Follow_Up dihitung saat ditransmisikan di jaringan. Oleh karena itu, perubahan jalur transmisi tidak akan memengaruhi akurasi penyesuaian.

Saat menggunakan mekanisme ini, sinkronisasi waktu tidak memerlukan perhitungan waktu tunda pada jalur yang ditempuh oleh paket sinkronisasi, seperti yang dilakukan dengan pertukaran dasar. Itu Pesan Delay_Req dan Delay_Resp tidak terkirim. Dalam metode ini, penundaan antara jam master dan pengikut hanya dijumlahkan di bidang penyesuaian setiap pesan Sync atau Follow_Up.

Keuntungan lain adalah bahwa jam mengemudi diturunkan dari kebutuhan untuk memproses pesan Delay_Req.

Mode operasi jam tangan transparan

Oleh karena itu, contoh-contoh sederhana diperiksa. Sekarang anggap bahwa sakelar muncul di jalur sinkronisasi.

Jika Anda menggunakan sakelar tanpa dukungan PTPv2, maka paket sinkronisasi akan ditunda sekitar 10 μs pada sakelar.

Switch dengan dukungan PTPv2 dalam terminologi IEEE 1588v2 disebut jam Transparan. Jam transparan tidak disinkronkan dari jam terkemuka dan tidak berpartisipasi dalam hierarki "Jam terkemuka - Jam Slave", tetapi saat mengirimkan pesan sinkronisasi, mereka ingat berapa banyak pesan yang tertunda oleh mereka. Ini memungkinkan Anda untuk menyesuaikan waktu tunda.

Jam tangan transparan dapat berfungsi dalam dua mode:

Ujung ke ujung.
Rekan sebaya.

End-to-End (E2E)

Arloji E2E transparan mentransmisikan pesan Sync dan menyertai pesan Follow_Up ke semua port. Bahkan yang diblokir oleh protokol apa pun (misalnya, RSTP).

Switch mengingat cap waktu ketika paket Sync (Follow_Up) diterima pada port dan ketika itu dikirim dari port. Berdasarkan dua cap waktu ini, waktu pemrosesan sakelar untuk pesan dihitung. Dalam standar, waktu ini disebut waktu tinggal.

Waktu pemrosesan ditambahkan ke bidang koreksiField pesan Sync (jam satu tahap) atau Follow_Up (jam dua tahap).

Arloji transparan E2E mengukur waktu pemrosesan untuk pesan Sync dan Delay_Req yang melewati sakelar. Tetapi penting untuk memahami bahwa waktu tunda antara jam utama dan jam slave dihitung menggunakan mekanisme respons-respons tunda. Jika jam master berubah atau jalur dari jam master ke slave berubah, penundaan diukur lagi. Ini meningkatkan waktu transisi jika terjadi perubahan jaringan.

Jam P2P transparan, selain mengukur waktu pemrosesan pesan oleh saklar, mengukur keterlambatan pada saluran data ke tetangga terdekat menggunakan mekanisme pengukuran keterlambatan simpul tetangga.

Penundaan diukur pada setiap saluran di kedua arah, termasuk saluran yang diblokir oleh protokol (misalnya, RSTP). Ini memungkinkan Anda untuk segera menghitung penundaan baru di jalur sinkronisasi jika jam grandmaster atau topologi jaringan telah berubah.

Waktu pemrosesan sakelar dan waktu tunda diakumulasikan saat mengirimkan pesan Sync atau Follow_Up.

Jenis Dukungan untuk PTPv2 Switches

Switches dapat mendukung PTPv2:

secara terprogram;
perangkat keras.

Dalam implementasi perangkat lunak protokol PTPv2, sakelar meminta cap waktu dari firmware. Masalahnya adalah bahwa firmware bekerja secara siklis, dan Anda harus menunggu sampai selesai siklus saat ini, mengambil permintaan ke pemrosesan, dan setelah siklus berikutnya ia mengeluarkan timestamp. Semua ini juga akan memakan waktu, dan kami akan mendapat penundaan, meskipun tidak sepenting tanpa dukungan perangkat lunak PTPv2.

Hanya dukungan perangkat keras untuk PTPv2 yang memungkinkan Anda untuk mempertahankan akurasi yang diperlukan. Dalam hal ini, penerbitan cap waktu dilakukan oleh ASIC khusus, yang dipasang pada port.

Format Pesan

Semua pesan PTP terdiri dari bidang-bidang berikut:

Header - 34 byte.
Tubuh - ukurannya tergantung pada jenis pesan.
Suffix - opsional.

Header

Field Header adalah sama untuk semua pesan PTP. Ukurannya 34 byte.

Format bidang Header:

messageType adalah jenis pesan yang dikirim, misalnya, Sinkronisasi, Delay_Req, PDelay_Req, dll.

messageLength - berisi ukuran penuh dari pesan PTP, termasuk header, body, dan suffix (tetapi tidak termasuk fill bytes).

domainNumber - Menentukan domain PTP mana dari pesan tersebut.

Domain adalah beberapa jam yang berbeda, dirangkai menjadi satu grup logis dan disinkronkan dari satu jam terkemuka, tetapi tidak harus disinkronkan dengan jam milik domain lain.

bendera - bidang ini berisi berbagai bendera untuk mengidentifikasi status pesan.

koreksiField- Berisi waktu tunda dalam nanodetik. Waktu tunda mencakup penundaan transmisi melalui jam transparan, serta penundaan transmisi melalui saluran saat menggunakan mode Peer-to-Peer.

sourcePortIdentity - bidang ini berisi informasi tentang asal port pesan ini.

sequenceID - berisi nomor identifikasi untuk masing-masing pesan.

controlField - bidang artifact =) Masih dari versi pertama standar dan berisi informasi tentang jenis pesan ini. Pada dasarnya sama dengan messageType, tetapi dengan lebih sedikit opsi.

logMessageInterval - bidang ini ditentukan oleh jenis pesan.

Tubuh

Seperti dibahas di atas, ada beberapa jenis pesan. Jenis-jenis ini dijelaskan di bawah ini:

Mengumumkan pesan Mengumumkan
pesan digunakan untuk "memberi tahu" jam tangan lain dalam domain yang sama tentang pengaturannya. Pesan ini memungkinkan Anda untuk mengatur hierarki "Leading Clock - Slave Clock".

Sync
Sebuah pesan pesan sinkronisasi (sync) dikirim oleh jam master dan berisi saat jam master pada saat pesan Sync diciptakan. Jika jam depan adalah dua tahap, maka cap waktu dalam pesan Sync akan diatur ke 0, dan cap waktu saat ini akan dikirim dalam pesan Follow_Up berpasangan. Pesan Sync digunakan untuk kedua mekanisme pengukuran keterlambatan.

Pesan ditransmisikan menggunakan Multicast. Anda secara opsional dapat menggunakan Unicast.

Pesan Delay_Req Format pesan Delay_Req identik dengan pesan Sync. Jam budak mengirim Delay_Req. Ini berisi waktu Delay_Req dikirim oleh jam slave. Pesan ini hanya digunakan untuk mekanisme respons permintaan penundaan.

Pesan ditransmisikan menggunakan Multicast. Anda secara opsional dapat menggunakan Unicast.

Pesan Follow_Up Pesan Follow_Up

secara opsional dikirim oleh jam master dan berisi waktu master mengirim pesan Sync . Pesan Follow_Up hanya dikirim oleh jam mengemudi dua tahap.

Pesan Follow_Up digunakan untuk kedua mekanisme pengukuran keterlambatan.

Pesan ditransmisikan menggunakan Multicast. Anda secara opsional dapat menggunakan Unicast.

Pesan Delay_Resp

Pesan Delay_Resp dikirim oleh master clock. Ini berisi waktu Delay_Req diterima oleh jam master. Pesan ini hanya digunakan untuk mekanisme respons permintaan penundaan.

Pesan ditransmisikan menggunakan Multicast. Anda secara opsional dapat menggunakan Unicast. Pesan

Pdelay_Req

Pesan Pdelay_Req dikirim oleh perangkat yang meminta penundaan. Ini berisi waktu pesan dikirim dari port perangkat ini. Pdelay_Req hanya digunakan untuk mekanisme pengukuran keterlambatan simpul tetangga.

Pesan Pdelay_Resp Pesan Pdelay_Resp

dikirim oleh perangkat yang menerima permintaan penundaan. Berisi waktu pesan Pdelay_Req diterima oleh perangkat ini. Pesan Pdelay_Resp hanya digunakan untuk mekanisme pengukuran keterlambatan simpul tetangga.

Pesan Pdelay_Resp_Follow_Up Pesan Pdelay_Resp_Follow_Up

secara opsional dikirim oleh perangkat yang menerima permintaan penundaan. Berisi waktu pesan Pdelay_Req diterima oleh perangkat ini. Pesan Pdelay_Resp_Follow_Up hanya dikirim oleh master clock dua tahap.

Pesan ini juga dapat digunakan untuk runtime, bukan timestamp. Waktu eksekusi adalah waktu sejak Pdelay-Req diterima hingga Pdelay_Resp dikirim.

Pdelay_Resp_Follow_Up hanya digunakan untuk mekanisme pengukuran keterlambatan simpul tetangga.

Pesan Kontrol (Pesan Manajemen) Pesan

kontrol PTP diperlukan untuk mentransfer informasi antara satu jam atau lebih dan node kontrol.

Transfer ke LV

Pesan PTP dapat dikirim pada dua tingkat:

Jaringan - sebagai bagian dari data IP.
Tautan - sebagai bagian dari bingkai Ethernet.

Mengirim pesan PTP melalui UDP melalui IP melalui Ethernet

PTP melalui UDP melalui Ethernet

Profil

PTP memiliki banyak parameter "fleksibel" yang perlu dikonfigurasi. Contohnya:

Opsi BMCA.
Mekanisme pengukuran keterlambatan.
Interval dan nilai awal dari semua parameter yang dapat dikonfigurasi, dll.

Dan terlepas dari kenyataan bahwa sebelumnya kami mengatakan bahwa perangkat PTPv2 kompatibel satu sama lain, dalam cara yang baik tidak. Perangkat harus memiliki pengaturan yang sama untuk berinteraksi.

Oleh karena itu, ada yang disebut profil PTPv2. Profil adalah grup pengaturan yang dikonfigurasikan dan batasan protokol tertentu sehingga Anda dapat menerapkan sinkronisasi waktu untuk aplikasi tertentu.

Standar IEEE 1588v2 sendiri hanya menjelaskan satu profil - "Profil Default". Semua profil lain dibuat dan dijelaskan oleh berbagai organisasi dan asosiasi.

Misalnya, Profil Daya atau Profil Daya PTPv2 dibuat oleh Komite Relai Sistem Daya dan Komite Substation dari IEEE Power dan Energy Society. Profil itu sendiri disebut IEEE C37.238-2011.

Profil tersebut menjelaskan bahwa PTP dapat ditransmisikan:

Hanya melalui jaringan L2 (mis. Ethernet, HSR, PRP, bukan IP).
Pesan hanya dikirimkan oleh milis Multicast.
Mekanisme pengukuran keterlambatan rekan digunakan sebagai mekanisme pengukuran keterlambatan.

Domain default adalah 0, domain yang disarankan adalah 93.

Filosofi menciptakan C37.238-2011 adalah keinginan untuk mengurangi jumlah fitur opsional dan hanya menyisakan fungsi yang diperlukan untuk interaksi yang dapat diandalkan antara perangkat dan meningkatkan stabilitas sistem.

Juga, frekuensi pengiriman pesan ditentukan:

Faktanya, hanya satu parameter yang tersedia untuk pemilihan - jenis jam terkemuka (satu tahap atau dua tahap).

Akurasi tidak boleh lebih dari 1 μs. Dengan kata lain, maksimum 15 jam transparan atau tiga jam batas dapat dimuat dalam satu jalur sinkronisasi.

Detail Implementasi Protokol Sinkronisasi Waktu PTPv2

More articles: