Intervalli dei messaggi IEEE 1588, parametri del profilo SMPTE ST 2059-2 e Synchronization Metadata, conversione TAI/UTC e allineamento dei frame ST 2059-1. Tutto viene calcolato nel tuo browser.
Gli intervalli PTP si esprimono come logaritmo in base 2 dei secondi.
logSyncInterval = −3 significa 2−3 = 0,125 s, cioè 8 messaggi al secondo.
La banda è una stima per PTP su UDP/IPv4 in Ethernet: payload di 44 byte per Sync e Follow_Up, 64 byte per Announce, 44 byte per Delay_Req, 54 byte per Delay_Resp, ciascuno più 42 byte di header UDP/IP/Ethernet e 20 byte fra preambolo e inter-frame gap. Si assume il funzionamento two-step. Serve a dimensionare un collegamento, non a certificarlo.
Scegli un profilo per vedere i range ammessi e i valori di default, e per verificare i valori inseriti qui sopra.
Il PTP conta i secondi dall'epoca PTP, 1 gennaio 1970 00:00:00 TAI. Il TAI non ha secondi intercalari, quindi è avanti sull'UTC di un numero intero di secondi — oggi 37.
Il valore è 37 s dal 1° gennaio 2017. L'USNO ha annunciato che
a fine dicembre 2026 non sarà introdotto nessun secondo
intercalare, quindi 37 resta valido. Prendi sempre il valore vivo dal
campo currentUtcOffset del messaggio Announce, invece di scriverlo
fisso nella configurazione.
SMPTE ST 2059-1 allinea i confini dei frame video all'epoca PTP. Il frame 0 comincia sull'epoca, e ogni confine successivo è un multiplo esatto del periodo di frame. Qui sotto si usa aritmetica intera esatta, quindi non c'è nessuna deriva di arrotondamento.
Premi Adesso nella sezione 3 per riempire il campo dei secondi PTP con l'istante corrente, poi leggi dove cade il prossimo confine di frame.
I campi che un grandmaster ST 2059-2 mette nel messaggio Announce.
currentLocalOffset è quello sbagliato più spesso, perché si misura dal
tempo PTP (TAI), non dall'UTC.
Nomi e tipi dei campi seguono la Tabella 2 di SMPTE ST 2059-2:2021.
timeOfNextJump, timeOfNextJam e
timeOfPreviousJam sono secondi PTP unsigned a 48 bit.
currentLocalOffset, jumpSeconds e
previousJamLocalOffset sono signed a 32 bit.
Realizzato da Elettronica Mangione, Roma — sincronizzazione broadcast dal 1984. Valori verificati su SMPTE ST 2059-2:2021 e sui bollettini USNO dei secondi intercalari. Questo strumento calcola, non certifica: verifica sempre sulla norma pubblicata valida per il tuo impianto.
Il Precision Time Protocol (PTP, IEEE 1588) è il modo in cui gli apparati di una rete si mettono d'accordo su che ora è, con una precisione molto sotto il microsecondo. Un apparato — il grandmaster — tiene il riferimento, di solito preso dal GPS, e tutti gli altri misurano quanto ci mettono ad arrivare i suoi messaggi per correggere il ritardo. In un impianto broadcast è quello che tiene telecamere, audio, timecode e orologi di studio sullo stesso istante. Questa pagina fa i conti che servono per configurarlo.
Il PTP non è difficile da capire, ma è facile da configurare male, e gli errori sono silenziosi: la rete si aggancia, tutti gli apparati dichiarano un grandmaster, e il tempo è sbagliato lo stesso. Quattro cose spiegano quasi tutti i casi.
−3 significa 0,125 secondi, cioè otto messaggi al secondo.
Scrivere 3 dà un messaggio ogni otto secondi: la rete si aggancia
comunque, e al resto pensa l'holdover.Ogni intervallo PTP è scritto come logaritmo in base 2 di un numero di secondi. L'intervallo in secondi è 2 elevato a quel valore, e la frequenza dei messaggi è il suo reciproco:
0 → 1 s → 1 messaggio al secondo−1 → 0,5 s → 2 al secondo−3 → 0,125 s → 8 al secondo−4 → 0,0625 s → 16 al secondo−7 → 0,0078125 s → 128 al secondoPiù veloce non è automaticamente meglio. I messaggi Sync sono multicast e costano uguale a prescindere da quanti apparati ascoltano, ma il Delay_Req lo manda ogni slave e la Delay_Resp torna indietro individualmente. Duecento apparati a otto richieste al secondo fanno 3.200 coppie di messaggi al secondo in arrivo su un solo grandmaster. Il calcolatore qui sopra stima quel carico, così lo dimensioni prima di installarlo.
ST 2059-2 è il profilo broadcast di IEEE 1588. Restringe i range ammessi e aggiunge i metadati che servono al video. Dall'edizione 2021: dominio da 0 a 127 con default 127; logAnnounceInterval da −3 a +1 con default 0; logSyncInterval da −7 a −1 con default −3, cioè otto messaggi Sync al secondo; announceReceiptTimeout da 2 a 10 con default 3; priority1 e priority2 da 0 a 255, entrambi con default 128. Il logMinDelayReqInterval si inizializza al valore del logSyncInterval e può essere fino a cinque passi più lento.
Sul numero di dominio vale una nota. Il default 127 è voluto: tiene la rete media separata da un dominio PTP generico, che per convenzione usa lo 0. Se il tuo grandmaster è sul 127 e un apparato guarda lo 0, non si incontreranno mai, e l'apparato segnalerà nessun grandmaster invece di uno sbagliato.
Il PTP conta dall'epoca PTP — 1 gennaio 1970 00:00:00 TAI — e
il TAI non ha secondi intercalari. L'UTC sì, ed è per questo che i due si sono
allontanati di 37 secondi dall'ultimo secondo intercalare, a fine 2016. Il campo
currentUtcOffset del messaggio Announce porta quel numero, e un
ricevitore che lo ignora va avanti di 37 secondi.
Il valore da pubblicare in currentLocalOffset non è il tuo fuso
orario. È il fuso orario meno l'offset UTC: l'ora locale è uguale al tempo
PTP più currentLocalOffset. Per Roma d'estate fa 7200 − 37 = 7163 secondi.
Pubblicare 7200 lascia tutti gli orologi dell'edificio avanti di 37 secondi, ed è
esattamente il tipo di errore che sopravvive al collaudo perché tutto è
coerentemente sbagliato.
SMPTE ST 2059-1 definisce dove stanno i frame video nel tempo: il frame 0 comincia all'epoca PTP, e ogni confine successivo è un multiplo esatto del periodo di frame. Per i frame rate interi il pattern si ripete ogni secondo. Per 29,97 fps — cioè 30000/1001 — si ripete ogni 1001 secondi, ed è il motivo per cui due apparati possono essere d'accordo sull'ora e in disaccordo su quale frame sia, se uno dei due arrotonda.
Il calcolatore usa aritmetica intera esatta per questo, non virgola mobile, così l'indice di frame che ti dà è quello su cui il tuo hardware deve essere d'accordo.
ST 2059-2 aggancia al messaggio Announce un blocco di metadati con le cose che servono al video e che il PTP semplice non porta: il frame rate di sistema come numero razionale, lo stato di aggancio del grandmaster, l'offset dell'ora locale, il momento del prossimo cambio di ora legale o del prossimo secondo intercalare, e gli istanti del Daily Jam precedente e successivo. Il calcolatore produce tutti e undici i campi dai dati del tuo impianto, compresi i due su cui si sbaglia di più: currentLocalOffset e timeOfNextJam.
Un calcolatore ti dice quali dovrebbero essere i numeri. Qualcosa deve però produrli, tenerli quando l'antenna GNSS perde il cielo, e continuare a produrli alle tre di notte. Il nostro PTPMaster è un grandmaster PTP IEEE 1588 disciplinato da GNSS, con timestamping hardware, dashboard web integrata e supporto dei profili SMPTE ST 2059-2 e AES67 — costruito a Roma, dove facciamo apparecchiature di timing per il broadcast dal 1984.
Questi strumenti sono gratuiti perché costruiamo le apparecchiature che fanno lo stesso lavoro dentro una regia, ventiquattro ore su ventiquattro, senza bisogno di tenere aperta una scheda del browser.
Elettronica Mangione progetta sistemi di sincronizzazione broadcast a Roma dal 1984, con oltre 1.000 installazioni in 15 paesi. Parla con un tecnico.
Servono entrambi a tenere allineati gli orologi su una rete, ma sono pensati per lavori diversi. L'NTP marca temporalmente i pacchetti via software e regge Internet: per questo funziona ovunque e per questo, su una rete locale in ordine, si ferma di solito attorno al millisecondo. Il PTP marca via hardware, dentro la scheda di rete e dentro gli switch che lo capiscono, e toglie di mezzo il ritardo di accodamento che quegli switch introducono. È così che scende sotto il microsecondo, spesso a decine di nanosecondi.
La differenza pratica in un impianto broadcast: l'NTP basta per gli orologi a muro, i log e l'informatica generale. Il PTP è quello che pretendono il video SMPTE ST 2110 e l'audio AES67, perché l'essenza va allineata al campione e un millisecondo è enormemente troppo grossolano. Altre due differenze su cui si inciampa spesso: il PTP conta in TAI e l'NTP in UTC, quindi fra i due ci sono 37 secondi; e un grandmaster PTP col profilo SMPTE manda otto messaggi Sync al secondo, dove un client NTP può interrogare il server una volta al minuto.
Il valore è il logaritmo in base 2 dell'intervallo in secondi. 2−3 è 0,125 secondi, quindi il grandmaster manda otto messaggi Sync al secondo. È il default del profilo SMPTE ST 2059-2.
Il PTP conta in TAI, che non ha secondi intercalari. All'UTC ne sono stati aggiunti 37, l'ultimo a fine 2016. Il messaggio Announce porta la differenza corrente nel campo currentUtcOffset. Per fine 2026 non è previsto nessun secondo intercalare.
Il tuo offset UTC locale meno l'offset TAI−UTC, perché l'ora locale è uguale al tempo PTP più currentLocalOffset. A Roma d'estate fa 7200 − 37 = 7163 secondi. Metterci 7200 porta avanti tutti gli orologi di 37 secondi.
SMPTE ST 2059-2 ha come default il dominio 127, che tiene il traffico media separato dai domini PTP generici, che per convenzione usano lo 0. È ammesso qualsiasi valore da 0 a 127, ma tutti gli apparati devono usare lo stesso.
ST 2059-1 definisce come i segnali video e audio si allineano all'epoca PTP. ST 2059-2 definisce il profilo PTP vero e proprio: i range ammessi dei parametri e i Synchronization Metadata trasportati nel messaggio Announce.
Perché 29,97 fps è esattamente 30000/1001 fotogrammi al secondo. In 1001 secondi entrano esattamente 30.000 fotogrammi, quindi il rapporto fra confini di frame e confini di secondo torna al punto di partenza solo dopo 1001 secondi.
In pratica no. Il suo unico messaggio Sync al secondo è pensato per reti industriali. Il timing video ha bisogno degli otto al secondo del profilo SMPTE, e dei metadati che il profilo default non trasporta affatto.
Sì, senza registrazione. Tutto viene calcolato nel tuo browser e i dati che inserisci non vengono inviati da nessuna parte.