{"id":77041,"date":"2020-04-07T13:42:46","date_gmt":"2020-04-07T11:42:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2"},"modified":"2020-04-07T13:42:46","modified_gmt":"2020-04-07T11:42:46","slug":"podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2","title":{"rendered":"Dettagli sull'implementazione del protocollo di sincronizzazione del tempo PTPv2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b>Introduzione<\/b><\/p>\n<p>Il concetto di costruzione della \u00abSottostazione Digitale\u00bb nell'energia elettrica richiede una sincronizzazione con una precisione di 1 \u00b5s. Anche per le transazioni finanziarie \u00e8 necessaria una precisione in microsecondi. In queste applicazioni, la precisione del tempo NTP non \u00e8 pi\u00f9 sufficiente.<\/p>\n<p>Il protocollo di sincronizzazione PTPv2, descritto nello standard IEEE 1588v2, consente di raggiungere una precisione di sincronizzazione nell'ordine di decine di nanosecondi. PTPv2 permette di inviare pacchetti di sincronizzazione attraverso reti L2 e L3.<\/p>\n<p>Le principali aree in cui viene applicato PTPv2 sono:<\/p>\n<ul>\n<li>energia;<\/li>\n<li>apparecchiature di controllo e misura;<\/li>\n<li>complesso della difesa e industriale;<\/li>\n<li>telecomunicazioni;<\/li>\n<li>settore finanziario.<\/li>\n<\/ul>\n<p>\nQuesto post esplora come funziona il protocollo di sincronizzazione PTPv2.<\/p>\n<p>Abbiamo pi\u00f9 esperienza nell'industria e ci troviamo spesso a confrontarci con questo protocollo nelle applicazioni energetiche. Di conseguenza, daremo una panoramica con un occhio di riguardo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.phoenixcontact.com\/online\/portal\/ru?1dmy&amp;urile=wcm%3apath%3a\/ruru\/web\/main\/products\/subcategory_pages\/Managed_switches_P-08-10-16-01\/aead25f7-3319-485d-8868-126c62b77cb1\">all'energia<\/a><\/noindex>.<\/p>\n<p><b>Perch\u00e9 \u00e8 necessario?<\/b><\/p>\n<p>Attualmente, nello standard 34.01-21-004-2019 di PAO \u00abRosseti\u00bb e nello standard 56947007-29.240.10.302-2020 di PAO \u00abFSK EES\u00bb sono presenti requisiti per l'organizzazione del bus di processo con garanzia di sincronizzazione temporale tramite PTPv2.<\/p>\n<p>Questo \u00e8 dovuto al fatto che al bus di processo si collegano terminali di protezione rel\u00e8 e dispositivi di misura, i quali attraverso il bus di processo, tramite i cosiddetti flussi SV (flussi multicast), trasmettono valori istantanei di corrente e tensione.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>I terminali di protezione rel\u00e8 utilizzano questi valori per implementare le protezioni delle connessioni. Se la precisione delle misurazioni temporali \u00e8 bassa, alcune protezioni possono attivarsi erroneamente.<\/p>\n<p>Ad esempio, una vittima di una \u00abdebole\u00bb sincronizzazione temporale possono essere le protezioni di assoluta selettivit\u00e0. Spesso la logica di tali protezioni si basa sul confronto di due grandezze. Se le grandezze divergono di un valore sufficientemente elevato, la protezione si attiva. Se queste grandezze vengono misurate con una precisione temporale di 1 ms, si possono ottenere grandi differenze dove i valori sono in realt\u00e0 nella norma, se misurati con una precisione di 1 \u00b5s.<\/p>\n<p><b>Versioni PTP<\/b><\/p>\n<p>Il protocollo PTP \u00e8 stato descritto per la prima volta nel 2002 nello standard IEEE 1588-2002 ed era denominato \"Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems\". Nel 2008 \u00e8 stato pubblicato lo standard aggiornato IEEE 1588-2008, che descrive la versione PTP 2. In questa versione del protocollo \u00e8 stata migliorata la precisione e la stabilit\u00e0, ma non \u00e8 stata mantenuta la retrocompatibilit\u00e0 con la prima versione del protocollo. Inoltre, nel 2019 \u00e8 stata rilasciata la versione dello standard IEEE 1588-2019, che descrive PTP v2.1. Questa versione aggiunge piccoli miglioramenti a PTPv2 ed \u00e8 retrocompatibile con PTPv2.<\/p>\n<p>In altre parole, abbiamo la seguente situazione con le versioni:<\/p>\n<p>PTPv1<br \/>\n(IEEE 1588-2002)<\/p>\n<p>PTPv2<br \/>\n(IEEE 1588-2008)<\/p>\n<p>PTPv2.1<br \/>\n(IEEE 1588-2019)<\/p>\n<p>PTPv1 (IEEE 1588-2002)<\/p>\n<p> \u2014<br \/>\nIncompatibili<\/p>\n<p>Incompatibili<\/p>\n<p>PTPv2 (IEEE 1588-2008)<\/p>\n<p>Incompatibili<\/p>\n<p> \u2014<br \/>\nCompatibili<\/p>\n<p>PTPv2.1 (IEEE 1588-2019)<\/p>\n<p>Incompatibili<\/p>\n<p>Compatibili<\/p>\n<p> \u2014 <\/p>\n<p>\nMa, come sempre, ci sono sfumature.<\/p>\n<p>L'incompatibilit\u00e0 tra PTPv1 e PTPv2 implica che un dispositivo che supporta PTPv1 non potr\u00e0 sincronizzarsi con orologi di alta precisione che funzionano su PTPv2. Per la sincronizzazione utilizzano diversi formati di messaggio.<\/p>\n<p>Tuttavia, \u00e8 comunque possibile combinare dispositivi con PTPv1 e dispositivi con PTPv2 nella stessa rete. A tal fine, alcuni produttori consentono di selezionare la versione del protocollo sulle porte degli orologi di frontiera. Ci\u00f2 significa che gli orologi di frontiera possono sincronizzarsi tramite PTPv2 e nel contempo sincronizzare altri orologi collegati a loro sia tramite PTPv1 che PTPv2.<\/p>\n<p><b>Dispositivi PTP. Quali sono e come si differenziano?<\/b><\/p>\n<p>Lo standard IEEE 1588v2 descrive diversi tipi di dispositivi. Tutti sono elencati nella tabella.<\/p>\n<p>I dispositivi interagiscono tra loro attraverso una rete locale, utilizzando PTP.<\/p>\n<p>I dispositivi PTP sono chiamati orologi. Tutti gli orologi prendono il tempo preciso da orologi grandmaster.<\/p>\n<p>Esistono 5 tipi di orologi:<\/p>\n<p>Grandmaster clock (Orologio Master)<\/p>\n<p>Fonte principale del tempo preciso. Spesso dotata di un'interfaccia per la connessione GPS.<\/p>\n<p>Ordinary Clock (Orologio Ordinario)<\/p>\n<p>Dispositivo con una porta che pu\u00f2 essere master (orologio principale) o slave (orologio secondario)<\/p>\n<p>Orologio principale (master)<\/p>\n<p>\u00c8 la fonte del tempo preciso, a cui si sincronizzano altri orologi<\/p>\n<p>Orologi secondari (slave)<\/p>\n<p>Dispositivo finale che si sincronizza con gli orologi principali<\/p>\n<p>Boundary Clock (Orologio di Frontiera)<\/p>\n<p>Dispositivo con pi\u00f9 porte, che pu\u00f2 essere master o slave.<\/p>\n<p>Quindi, questi orologi possono sincronizzarsi dagli orologi principali superiori e sincronizzare gli orologi secondari inferiori.<\/p>\n<p>Orologio Trasparente End-to-End<\/p>\n<p>Dispositivo con porte multiple che non \u00e8 n\u00e9 un orologio principale n\u00e9 un orologio secondario. Trasmette dati PTP tra due orologi. <\/p>\n<p>Durante la trasmissione dei dati, l'orologio trasparente corregge tutti i messaggi PTP. <\/p>\n<p>La correzione avviene aggiungendo un tempo di ritardo a questo dispositivo nel campo di correzione nell'intestazione del messaggio inviato.<\/p>\n<p>Orologio Trasparente Peer-to-Peer<\/p>\n<p>Dispositivo con porte multiple che non \u00e8 n\u00e9 un orologio principale n\u00e9 un orologio secondario. <br \/>\nTrasmette dati PTP tra due orologi. <\/p>\n<p>Durante la trasmissione dei dati, l'orologio trasparente corregge tutti i messaggi PTP Sync e Follow_Up (di cui si parler\u00e0 pi\u00f9 dettagliatamente di seguito).<\/p>\n<p>La correzione si ottiene aggiungendo al campo di correzione del pacchetto trasmesso il ritardo sul dispositivo di trasmissione e il ritardo sul canale di trasmissione dei dati.<\/p>\n<p>Nodo di Gestione<\/p>\n<p>Dispositivo che configura e diagnostica altri orologi<\/p>\n<p>Gli orologi principali e secondari si sincronizzano tramite timestamp nei messaggi PTP. Ci sono due tipi di messaggi nel protocollo PTP:<\/p>\n<ul>\n<li>Messaggi di Evento \u2013 sono messaggi sincronizzati che presuppongono la generazione di un timestamp nel momento dell'invio del messaggio e nel momento della sua ricezione.<\/li>\n<li>Messaggi Generali \u2013 questi messaggi non richiedono timestamp, ma possono contenere timestamp per messaggi correlati.<\/li>\n<\/ul>\n<p><\/p>\n<p>Messaggi di Evento<\/p>\n<p>Messaggi Generali<\/p>\n<p>Sync<br \/>\nDelay_Req<br \/>\nPdelay_Req<br \/>\nPdelay_Resp<\/p>\n<p>Annuncio<br \/>\nFollow_Up<br \/>\nDelay_Resp<br \/>\nPdelay_Resp_Follow_Up<br \/>\nGestione<br \/>\nSegnalazione<\/p>\n<p>Di seguito saranno esaminati tutti i tipi di messaggi pi\u00f9 in dettaglio.<\/p>\n<p><b>Problemi principali di sincronizzazione<\/b><\/p>\n<p>Durante la trasmissione del pacchetto di sincronizzazione attraverso una rete locale, esso viene ritardato dallo switch e dal canale di trasmissione dei dati. Qualsiasi switch dar\u00e0 un ritardo di circa 10 \u00b5s, che \u00e8 inaccettabile per PTPv2. Infatti, sul dispositivo finale abbiamo bisogno di una precisione di 1 \u00b5s. (Questo nel caso dell'energia. Altre applicazioni possono richiedere anche maggiore precisione.)<\/p>\n<p>Nell'IEEE 1588v2 sono descritti diversi algoritmi di funzionamento che permettono di registrare il tempo di ritardo e di correggerlo.<\/p>\n<p><b>Algoritmo di funzionamento<\/b><br \/>\nIn condizioni normali, il protocollo funziona in due fasi.<\/p>\n<ul>\n<li>Fase 1 \u2013 stabilimento della gerarchia \"Orologi Principali \u2013 Orologi Secondari\".<\/li>\n<li>Fase 2 \u2013 sincronizzazione degli orologi tramite il meccanismo End-to-End o Peer-to-Peer.<\/li>\n<\/ul>\n<p>\n<i>Fase 1 \u2014 Impostazione della gerarchia \u00abMaster-Slave\u00bb<\/i><\/p>\n<p>Ogni porta di orologi normali o di bordo ha un numero definito di stati (orologi slave ed orologi master). Lo standard descrive l'algoritmo di transizione tra questi stati. In programmazione, tale algoritmo \u00e8 chiamato automa a stati finiti o macchina a stati (ulteriori dettagli su Wiki).<\/p>\n<p>Questo automa a stati utilizza l'algoritmo Best Master Clock Algorithm (BMCA) per stabilire il master durante il collegamento di due orologi.<\/p>\n<p>Questo algoritmo consente agli orologi di assumere i doveri degli orologi master quando gli orologi master superiori perdono il segnale GPS, si scollegano dalla rete, ecc.<\/p>\n<p>Le transizioni tra stati secondo il BMCA sono brevemente rappresentate nello schema sottostante:<br \/>\n<img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/add811d60135de3be9c6865a5e4493c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe informazioni sugli orologi dall'altro lato del \u00abcavo\u00bb vengono inviate in un messaggio speciale (Announce message). Quando queste informazioni vengono ricevute, l'algoritmo della macchina a stati viene eseguito e viene effettuato un confronto per determinare quale orologio sia migliore. La porta sull'orologio migliore diventa l'orologio master.<\/p>\n<p>Una gerarchia semplice \u00e8 rappresentata nello schema sottostante. I percorsi 1, 2, 3, 4, 5 possono contenere orologi trasparenti (Transparent clock), ma non partecipano all'impostazione della gerarchia \u00abOrologi master \u2013 Orologi slave\u00bb.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/05831c032a2d4df286ef41c531c949a3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Fase 2 \u2014 Sincronizzazione degli orologi normali e di bordo<\/b><\/p>\n<p>Subito dopo l'impostazione della gerarchia \u00abOrologi master \u2013 Orologi slave\u00bb inizia la fase di sincronizzazione degli orologi normali e di bordo.<\/p>\n<p>Per la sincronizzazione, gli orologi master inviano agli orologi slave un messaggio contenente un timestamp.<\/p>\n<p>Gli orologi master possono essere:<\/p>\n<ul>\n<li>a una fase;<\/li>\n<li>a due fasi.<\/li>\n<\/ul>\n<p>\nGli orologi a una fase per la sincronizzazione inviano un singolo messaggio Sync.<\/p>\n<p>Gli orologi a due fasi per la sincronizzazione utilizzano due messaggi: Sync e Follow_Up.<\/p>\n<p>Per la fase di sincronizzazione possono essere utilizzati due meccanismi:<\/p>\n<ul>\n<li>Meccanismo di richiesta-risposta per il ritardo (Delay request-response mechanism).<\/li>\n<li>Meccanismo di misurazione del ritardo del nodo vicino (Peer delay measurement mechanism).<\/li>\n<\/ul>\n<p>\nIniziamo a considerare questi meccanismi nel caso pi\u00f9 semplice \u2014 quando non vengono utilizzati orologi trasparenti.<\/p>\n<p>Meccanismo di richiesta-risposta per il ritardo (Delay request-response mechanism)<\/p>\n<p>Il meccanismo prevede due passaggi:<\/p>\n<ol>\n<li>Misurazione del ritardo nella trasmissione del messaggio tra orologi master e slave. Viene effettuata tramite il meccanismo di richiesta-risposta per il ritardo.<\/li>\n<li>Viene eseguita la correzione dello spostamento del tempo esatto.<\/li>\n<\/ol>\n<p>\n<i>Misurazione del ritardo<\/i><br \/>\n<img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/3a0d534384329c6232259736995eb0bd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nt1 \u2013 Tempo di invio del messaggio Sync da parte degli orologi principali; t2 \u2013 Tempo di ricezione del messaggio Sync da parte degli orologi secondari; t3 \u2013 Tempo di invio della richiesta di ritardo (Delay_Req) da parte degli orologi secondari; t4 \u2013 Tempo di ricezione di Delay_Req da parte degli orologi principali.<\/p>\n<p>Quando gli orologi secondari conoscono i tempi t1, t2, t3 e t4, possono calcolare il ritardo medio nella trasmissione del messaggio di sincronizzazione (tmpd). Questo viene calcolato nel seguente modo:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/513eb7352a143073835fe36aedd9cb98.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDurante la trasmissione del messaggio Sync e Follow_Up si calcola il ritardo di tempo dal master allo slave \u2013 t-ms.<\/p>\n<p>Durante la trasmissione dei messaggi Delay_Req e Delay_Resp si calcola il ritardo di tempo dallo slave al master \u2013 t-sm.<\/p>\n<p>Se tra questi due valori c'\u00e8 qualche asimmetria, si genera un errore di correzione del tempo esatto. L'errore \u00e8 determinato dal fatto che il ritardo calcolato \u00e8 la media dei ritardi t-ms e t-sm. Se i ritardi non sono uguali tra loro, correggeremo il tempo in modo impreciso.<\/p>\n<p><i>Correzione dello sfasamento del tempo esatto<\/i><\/p>\n<p>Dopo che il ritardo tra orologi principali e secondari \u00e8 noto, gli orologi secondari eseguono la correzione del tempo.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/27f230252126a768273b40e8c8e7cc4e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli orologi secondari utilizzano il messaggio Sync e il messaggio opzionale Follow_Up per calcolare lo sfasamento del tempo esatto durante la trasmissione del pacchetto dagli orologi principali agli orologi secondari. Lo sfasamento viene calcolato secondo la seguente formula:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/190604a9287f285e191eb26381fca52c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Meccanismo di misurazione del ritardo del nodo vicino (Peer delay measurement mechanism)<\/b><\/p>\n<p>Questo meccanismo utilizza anch'esso due passaggi per la sincronizzazione:<\/p>\n<ol>\n<li>I dispositivi misurano il ritardo di tempo verso tutti i vicini attraverso tutte le porte. Per questo utilizzano il meccanismo di ritardo peer.<\/li>\n<li>Correzione dello sfasamento del tempo esatto.<\/li>\n<\/ol>\n<p>\n<i>Misurazione del ritardo tra dispositivi che supportano la modalit\u00e0 Peer-to-Peer<\/i><\/p>\n<p>Il ritardo tra le porte che supportano il meccanismo peer-to-peer \u00e8 misurato utilizzando i seguenti messaggi:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/897c9914110e9a56f98f4fa835f524cd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuando la porta 1 conosce i tempi t1, t2, t3 e t4, pu\u00f2 calcolare il ritardo medio (tmld). Questo viene calcolato secondo la seguente formula:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/17416bf3b60f86136002b27cf4987b27.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSuccessivamente, la porta utilizza questo valore nel calcolo del campo di correzione per ciascun messaggio Sync o messaggio opzionale Follow_Up che passa attraverso questo dispositivo. <\/p>\n<p>Il ritardo totale sar\u00e0 uguale alla somma del ritardo nella trasmissione attraverso questo dispositivo, del ritardo medio nella trasmissione attraverso il canale dati e del ritardo gi\u00e0 presente in questo messaggio, incluso in dispositivi superiori.<\/p>\n<p>I messaggi Pdelay_Req, Pdelay_Resp e l'opzionale Pdelay_Resp_Follow_Up consentono di ottenere il ritardo dal maestro allo slave e dallo slave al maestro (circolare).<\/p>\n<p>Qualsiasi asimmetria tra questi due valori introdurr\u00e0 un errore nella correzione del ritardo dell'orario preciso.<\/p>\n<p><i>Correzione del ritardo dell'orario preciso<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/c9cdedffd98db044718b8bc0eef156b9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli orologi slavi utilizzano il messaggio Sync e l'opzionale messaggio Follow_Up per calcolare il ritardo dell'orario preciso durante la trasmissione del pacchetto dagli orologi principali agli orologi slavi. Il ritardo viene calcolato secondo la seguente formula:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/dff497d0f5644c3591f05f99e4c8c23a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI vantaggi della correzione del meccanismo peer-to-peer \u2013 il ritardo di ciascun messaggio Sync o Follow_Up viene calcolato mentre viene trasmesso nella rete. Di conseguenza, anche il cambiamento del percorso di trasmissione non influir\u00e0 in alcun modo sulla precisione della correzione.<\/p>\n<p>Utilizzando questo meccanismo, la sincronizzazione dell'orario non richiede il calcolo del ritardo temporale sul percorso del pacchetto di sincronizzazione, come avviene nello scambio di base. Cio\u00e8, i messaggi Delay_Req e Delay_Resp non vengono inviati. In questo metodo, il ritardo tra gli orologi principali e slavi viene semplicemente sommato nel campo di correzione di ciascun messaggio Sync o Follow_Up.<\/p>\n<p>Un altro vantaggio \u00e8 che gli orologi principali sono alleggeriti dall'obbligo di elaborare i messaggi Delay_Req.<\/p>\n<p><b>Modalit\u00e0 di funzionamento degli orologi trasparenti<\/b><\/p>\n<p>Di conseguenza, sono stati analizzati semplici esempi. Ora supponiamo che si presentino switch lungo il percorso di sincronizzazione.<\/p>\n<p>Se si utilizzano switch senza supporto per PTPv2, il pacchetto di sincronizzazione subir\u00e0 un ritardo nello switch di circa 10 \u00b5s.<\/p>\n<p>Gli switch con supporto PTPv2 nella terminologia IEEE 1588v2 sono chiamati orologi trasparenti (Transparent clock). Gli orologi trasparenti non vengono sincronizzati dagli orologi principali e non partecipano all' gerarchia \"Orologi principali \u2013 Orologi slavi\", ma durante la trasmissione dei messaggi di sincronizzazione memorizzano quanto tempo messaggio \u00e8 stato ritardato su di essi. Ci\u00f2 consente di correggere il ritardo temporale.<\/p>\n<p>Gli orologi trasparenti possono operare in due modalit\u00e0:<\/p>\n<ul>\n<li>End-to-End.<\/li>\n<li>Peer-to-Peer.<\/li>\n<\/ul>\n<p>\n<b>End-to-End (E2E)<\/b><\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/94e5d2f343d1657f1458adcbb344d024.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli orologi trasparenti E2E trasmettono i messaggi Sync e i messaggi correlati Follow_Up a tutte le porte. Anche a quelle bloccate da alcuni protocolli (ad esempio, RSTP).<\/p>\n<p>Lo switch registra il timestamp in cui il pacchetto Sync (Follow_Up) \u00e8 stato ricevuto sulla porta e quando \u00e8 stato inviato dalla porta. Sulla base di questi due timestamp viene calcolato il tempo di elaborazione del messaggio da parte dello switch. In standard, questo tempo \u00e8 chiamato residence time.<\/p>\n<p>Il tempo di elaborazione viene aggiunto al campo correctionField del messaggio Sync (orologi a singolo stadio) o Follow_Up (orologi a doppio stadio).<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/b04cfa6cd1a93f25222079d5bb864a6d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli orologi trasparenti E2E misurano il tempo di elaborazione per i messaggi Sync e Delay_Req che passano attraverso lo switch. Ma \u00e8 importante capire che il ritardo di tempo tra gli orologi principali e secondari viene calcolato tramite il meccanismo di richiesta-risposta del ritardo. Se gli orologi principali cambiano o cambia il percorso dagli orologi principali a quelli secondari, il ritardo viene misurato nuovamente. Questo aumenta il tempo di transizione in caso di modifiche nella rete.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/5bcb72a639accf802ffba7a1fa9a4767.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGli orologi trasparenti P2P, oltre a misurare il tempo di elaborazione del messaggio da parte dello switch, misurano il ritardo sul canale di trasmissione dati fino al vicino pi\u00f9 vicino, utilizzando il meccanismo di misurazione del ritardo del nodo vicino.<\/p>\n<p>Il ritardo viene misurato su ciascun canale in entrambe le direzioni, compresi i canali bloccati da qualche protocollo (ad esempio, RSTP). Questo consente di calcolare immediatamente il nuovo ritardo sul percorso di sincronizzazione se gli orologi grandmaster o la topologia di rete cambiano.<\/p>\n<p>Il tempo di elaborazione dei messaggi da parte degli switch e il tempo di ritardo si accumulano durante la trasmissione dei messaggi Sync o Follow_Up.<\/p>\n<p><b>Tipi di supporto PTPv2 da parte degli switch<\/b><\/p>\n<p>Gli switch possono supportare PTPv2:<\/p>\n<ul>\n<li>in modo software;<\/li>\n<li>in modo hardware.<\/li>\n<\/ul>\n<p>\nCon l'implementazione software del protocollo PTPv2, lo switch richiede un timestamp dal firmware. Il problema \u00e8 che il firmware funziona ciclicamente e bisogna aspettare che completi il ciclo corrente, prenda in carico la richiesta e alla fine del ciclo successivo fornisca il timestamp. Questo richieder\u00e0 tempo, e quindi avremo un ritardo, sebbene non cos\u00ec sostanziale come senza supporto software per PTPv2.<\/p>\n<p>Per garantire la necessaria precisione \u00e8 possibile solo con il supporto hardware di PTPv2. In questo caso, la fornitura del timestamp viene eseguita da un ASIC speciale installato sulla porta.<\/p>\n<p><b>Formato del messaggio<\/b><\/p>\n<p>Tutti i messaggi PTP sono composti dai seguenti campi:<\/p>\n<ul>\n<li>Header \u2013 34 byte.<\/li>\n<li>Body \u2013 la dimensione dipende dal tipo di messaggio.<\/li>\n<li>Suffix \u2013 opzionale.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/99086e6601dcdf8f41c10f273c4ebfdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Header<\/b><\/p>\n<p>Il campo Header \u00e8 identico per tutti i messaggi PTP. La sua dimensione \u00e8 di 34 byte.<\/p>\n<p>Formato del campo Header:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/e4500d7e9026d9d059b1dcd668a44e5f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>messageType <\/b>\u2013 indica il tipo di messaggio trasmesso, ad esempio Sync, Delay_Req, PDelay_Req, e cos\u00ec via.<\/p>\n<p><b>messageLength<\/b> \u2013 contiene la dimensione totale del messaggio PTP, inclusi header, body e suffix (escludendo i byte di riempimento).<\/p>\n<p><b>domainNumber<\/b> \u2013 determina a quale <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/domain\/\"   title=\"dominio\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1225\">dominio<\/a> appartiene il messaggio PTP.<\/p>\n<p><b>Dominio<\/b> \u2013 \u00e8 composto da diversi orologi riuniti in un unico gruppo logico e sincronizzati da un orologio principale, ma non necessariamente sincronizzati con gli orologi appartenenti a un altro dominio.<\/p>\n<p><b>flags<\/b> \u2013 questo campo contiene vari flag per identificare lo stato del messaggio.<\/p>\n<p><b>correctionField<\/b> \u2013 contiene il tempo di ritardo in nanosecondi. Il tempo di ritardo include il ritardo di trasmissione attraverso orologi trasparenti, oltre al ritardo nella trasmissione attraverso il canale quando si utilizza la modalit\u00e0 Peer-to-Peer.<\/p>\n<p><b>sourcePortIdentity<\/b> \u2013 questo campo contiene informazioni su quale porta ha originariamente inviato il messaggio.<\/p>\n<p><b>sequenceID<\/b> \u2013 contiene un numero identificativo per i messaggi individuali.<\/p>\n<p><b>controlField<\/b> \u2013 campo artefatto =) \u00c8 rimasto dalla prima versione dello standard e contiene informazioni sul tipo di messaggio. In sostanza, \u00e8 la stessa cosa del messageType, ma con meno opzioni.<\/p>\n<p><b>logMessageInterval<\/b> \u2013 questo campo \u00e8 determinato dal tipo di messaggio.<\/p>\n<p><b>Body<\/b><\/p>\n<p>Come discusso sopra, esistono diversi tipi di messaggi. Questi tipi sono descritti di seguito:<\/p>\n<p><b>Messaggio Announce<\/b><br \/>\nIl messaggio Announce viene utilizzato per \"informare\" gli altri orologi all'interno di un dominio dei propri parametri. Questo messaggio consente di stabilire una gerarchia \"Orologi principali \u2013 Orologi subordinati\".<br \/>\n<img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/054b35f0c74757d531205fa352b90f4e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Sync<\/b><br \/>\nIl messaggio di sincronizzazione (Sync) viene inviato dagli orologi principali e contiene il tempo degli orologi principali al momento in cui il messaggio Sync \u00e8 stato creato. Se gli orologi principali sono a doppio passo, il timestamp nel messaggio Sync sar\u00e0 impostato a 0, mentre il timestamp attuale sar\u00e0 inviato nel messaggio associato Follow_Up. Il messaggio Sync viene utilizzato per entrambi i meccanismi di misurazione del ritardo.<\/p>\n<p>Il messaggio \u00e8 trasmesso tramite Multicast. In modo opzionale, \u00e8 possibile utilizzare Unicast.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/38268221aa5663ba021f225c9de01df9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Delay_Req<\/b><\/p>\n<p>Il formato del messaggio Delay_Req \u00e8 identico a quello del messaggio Sync. Gli orologi subordinati inviano Delay_Req. Contiene il tempo di invio del Delay_Req da parte degli orologi subordinati. Questo messaggio \u00e8 utilizzato solo per il meccanismo di richiesta-risposta del ritardo.<\/p>\n<p>Il messaggio \u00e8 trasmesso tramite Multicast. In modo opzionale, \u00e8 possibile utilizzare Unicast.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/1e64f3902ff3364b968581ff6b6a6573.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Follow_Up<\/b><\/p>\n<p>Il messaggio Follow_Up viene inviato facoltativamente dai cronometri principali e contiene l'orario di invio <b>messaggi Sync<\/b> dal maestro. Il messaggio Follow_Up \u00e8 inviato solo dai cronometri principali a due fasi.<\/p>\n<p>Il messaggio Follow_Up \u00e8 utilizzato per entrambi i meccanismi di misurazione del ritardo.<\/p>\n<p>Il messaggio \u00e8 trasmesso tramite Multicast. In modo opzionale, \u00e8 possibile utilizzare Unicast.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/00917743466b8a331922d18e0928d3db.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Delay_Resp<\/b><\/p>\n<p>Il messaggio Delay_Resp \u00e8 inviato dai cronometri principali. Contiene il tempo di ricezione di Delay_Req da parte dei cronometri principali. Questo messaggio \u00e8 utilizzato solo per il meccanismo di richiesta-risposta del ritardo.<\/p>\n<p>Il messaggio \u00e8 trasmesso tramite Multicast. In modo opzionale, \u00e8 possibile utilizzare Unicast.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/b9d0bc41f94ceee560c0c593dd9e4afd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Pdelay_Req<\/b><\/p>\n<p>Il messaggio Pdelay_Req \u00e8 inviato dall'apparato che richiede un ritardo. Contiene l'orario di invio del messaggio dalla porta di questo apparato. Pdelay_Req \u00e8 utilizzato solo per il meccanismo di misurazione del ritardo del nodo adiacente.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/7eef44a2655158758cdbcfbc25fc2e48.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Pdelay_Resp<\/b><\/p>\n<p>Il messaggio Pdelay_Resp \u00e8 inviato dall'apparato che ha ricevuto la richiesta di ritardo. Contiene il tempo di ricezione del messaggio Pdelay_Req da parte di questo apparato. I messaggi Pdelay_Resp sono utilizzati solo per il meccanismo di misurazione del ritardo del nodo adiacente.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/6a3bb44c70fc09db3025df93c4d58a3f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggio Pdelay_Resp_Follow_Up<\/b><\/p>\n<p>Il messaggio Pdelay_Resp_Follow_Up \u00e8 inviato facoltativamente dall'apparato che ha ricevuto la richiesta di ritardo. Contiene il tempo di ricezione del messaggio Pdelay_Req da parte di questo apparato. Il messaggio Pdelay_Resp_Follow_Up \u00e8 inviato solo dai cronometri principali a due fasi.<\/p>\n<p>Inoltre, questo messaggio pu\u00f2 essere utilizzato per il tempo di esecuzione invece del timestamp. Il tempo di esecuzione \u00e8 il tempo che intercorre dal momento di ricezione del Pdelay-Req fino all'invio del Pdelay_Resp.<\/p>\n<p>I Pdelay_Resp_Follow_Up sono utilizzati solo per il meccanismo di misurazione del ritardo del nodo adiacente.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/523043f7a880030474098fcdc1c5822d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Messaggi di gestione (Messaggio Management)<\/b><\/p>\n<p>I messaggi di gestione PTP sono necessari per la trasmissione delle informazioni tra uno o pi\u00f9 orologi e il nodo di gestione.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/4388d9f4b6b12f3a2cdc764c20597499.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Trasmissione in LV<\/b><\/p>\n<p>Il messaggio PTP pu\u00f2 essere trasmesso su due livelli:<\/p>\n<ul>\n<li>Livello di rete - come parte dei dati IP.<\/li>\n<li>Livello di collegamento - come parte del frame Ethernet.<\/li>\n<\/ul>\n<p>\nTrasmissione del messaggio PTP tramite UDP su IP via Ethernet<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/361e008fc48396915e5e9c23cc52bd63.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPTP tramite UDP su Ethernet<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/1862a5d27931a744e75e3c5bc63d7091.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Profili<\/b><\/p>\n<p>PTP ha molti parametri \"flessibili\" che devono essere configurati. Ad esempio:<\/p>\n<ul>\n<li>Opzioni BMCA.<\/li>\n<li>Meccanismo di misurazione del ritardo.<\/li>\n<li>Intervalli e valori iniziali di tutti i parametri configurabili, ecc.<\/li>\n<\/ul>\n<p>\nE nonostante abbiamo detto in precedenza che i dispositivi PTPv2 sono compatibili tra loro, in realt\u00e0 non \u00e8 cos\u00ec. I dispositivi devono avere impostazioni identiche per interagire.<\/p>\n<p>Esistono quindi i cosiddetti profili PTPv2. I profili sono gruppi di impostazioni configurate e di limitazioni specifiche del protocollo, in modo da poter realizzare la sincronizzazione temporale per un'applicazione specifica.<\/p>\n<p>Lo standard IEEE 1588v2 descrive solo un profilo: il \u201cDefault Profile\u201d. Tutti gli altri profili sono stati creati e descritti da varie organizzazioni e associazioni.<\/p>\n<p>Ad esempio, il profilo per il settore energetico o PTPv2 Power Profile \u00e8 stato creato dal comitato Power Systems Relaying Committee e dal comitato Substation Committee della IEEE Power and Energy Society. Questo profilo \u00e8 noto come IEEE C37.238- 2011.<\/p>\n<p>Il profilo descrive cosa pu\u00f2 essere trasmesso tramite PTP:<\/p>\n<ul>\n<li>Solo attraverso reti L2 (cio\u00e8 Ethernet, HSR, PRP, non IP).<\/li>\n<li>I messaggi sono trasmessi solo tramite multicast.<\/li>\n<li>Come meccanismo di misurazione del ritardo si utilizza il meccanismo di misurazione del ritardo dei peer.<\/li>\n<\/ul>\n<p>\nIl dominio predefinito \u00e8 0, il dominio raccomandato \u00e8 93.<\/p>\n<p>La filosofia alla base della creazione del C37.238- 2011 era quella di ridurre il numero di caratteristiche opzionali e mantenere solo le funzioni necessarie per una comunicazione affidabile tra i dispositivi e per aumentare la stabilit\u00e0 del sistema.<\/p>\n<p>Inoltre, \u00e8 stata definita la frequenza di trasmissione dei messaggi:<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/117c81192ff2eb160652738bb9ecbb1d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDi fatto, \u00e8 disponibile solo un parametro per la scelta: il tipo di orologio principale (monostadio o bistadio).<\/p>\n<p>La precisione non deve superare 1 microsecondo. In altre parole, in un percorso di sincronizzazione possono esserci al massimo 15 orologi trasparenti o tre orologi di confine.<\/p>\n<p><img decoding=\"async\" alt=\"Dettagli sull&#039;implementazione del protocollo di sincronizzazione del tempo PTPv2\" src=\"\/wp-content\/uploads\/2020\/04\/d3f1cb822d01b8733eadb6cd75805b20.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/phoenix_contact\/blog\/495920\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u044f \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u044f \u00ab\u0426\u0438\u0444\u0440\u043e\u0432\u043e\u0439 \u043f\u043e\u0434\u0441\u0442\u0430\u043d\u0446\u0438\u0438\u00bb \u0432 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u044d\u043d\u0435\u0440\u0433\u0435\u0442\u0438\u043a\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e 1 \u043c\u043a\u0441. \u0414\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0442\u0430\u043a\u0436\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c \u0432 \u043c\u043a\u0441. \u0412 \u044d\u0442\u0438\u0445 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u0438 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 NTP \u0443\u0436\u0435 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e. \u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 PTPv2, \u043e\u043f\u0438\u0441\u0430\u043d\u043d\u044b\u0439 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043e\u043c IEEE 1588v2, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0434\u043e\u0431\u0438\u0442\u044c\u0441\u044f \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u0438 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0432 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0434\u0435\u0441\u044f\u0442\u043a\u043e\u0432 \u043d\u0430\u043d\u043e\u0441\u0435\u043a\u0443\u043d\u0434. PTPv2 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0442\u044c \u043f\u0430\u043a\u0435\u0442\u044b \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0447\u0435\u0440\u0435\u0437 L2 \u0438 L3-\u0441\u0435\u0442\u0438. \u041e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77042,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77041","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u044f \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u044f \u00ab\u0426\u0438\u0444\u0440\u043e\u0432\u043e\u0439 \u043f\u043e\u0434\u0441\u0442\u0430\u043d\u0446\u0438\u0438\u00bb \u0432 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u044d\u043d\u0435\u0440\u0433\u0435\u0442\u0438\u043a\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e 1 \u043c\u043a\u0441. \u0414\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0442\u0430\u043a\u0436\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c \u0432 \u043c\u043a\u0441.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 PTPv2 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u044f \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u044f \u00ab\u0426\u0438\u0444\u0440\u043e\u0432\u043e\u0439 \u043f\u043e\u0434\u0441\u0442\u0430\u043d\u0446\u0438\u0438\u00bb \u0432 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u044d\u043d\u0435\u0440\u0433\u0435\u0442\u0438\u043a\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e 1 \u043c\u043a\u0441. \u0414\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0442\u0430\u043a\u0436\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c \u0432 \u043c\u043a\u0441.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-07T11:42:46+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-07T11:42:46+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Dettagli sull'implementazione del protocollo di sincronizzazione temporale PTPv2 | ProHoster","description":"Introduzione La concezione della \u00abSottostazione Digitale\u00bb nel settore energetico richiede sincronizzazione con una precisione di 1 microsecondo. Anche per le transazioni finanziarie \u00e8 necessaria una precisione in microsecondi.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 PTPv2 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u044f \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u044f \u00ab\u0426\u0438\u0444\u0440\u043e\u0432\u043e\u0439 \u043f\u043e\u0434\u0441\u0442\u0430\u043d\u0446\u0438\u0438\u00bb \u0432 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u044d\u043d\u0435\u0440\u0433\u0435\u0442\u0438\u043a\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e 1 \u043c\u043a\u0441. \u0414\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u044f \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0442\u0430\u043a\u0436\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c \u0432 \u043c\u043a\u0441.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podrobnosti-realizaczii-protokola-sinhronizaczii-vremeni-ptpv2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-07T11:42:46+00:00","article:modified_time":"2020-04-07T11:42:46+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"77041","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:25:29","updated":"2026-02-09 15:52:39","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77041","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=77041"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77041\/revisions"}],"predecessor-version":[{"id":158469,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77041\/revisions\/158469"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/77042"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=77041"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=77041"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=77041"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}