Lo stesso evento può ricevere due ore diverse
Un sistema embedded associa vibrazioni e temperatura prima di inviarle a un modello AI. I due sensori osservano lo stesso processo, ma i dati arrivano con timestamp diversi e una correzione iniziale sembra perdere efficacia dopo un’ora. Il problema può precedere il modello: gli orologi non soltanto partono da valori diversi, possono anche avanzare a velocità leggermente differenti. Studieremo che cosa possiamo correggere da coppie di riferimenti temporali e che cosa rimane ambiguo quando confondiamo l’istante della misura con quello di ricezione del pacchetto.
Abstract. Costruiamo un orologio affine C(t)=(1+40 × 10⁻⁶)t+0,012 s. Dopo 3600 s il suo timestamp supera il riferimento di 156 ms; sottrarre soltanto l’offset iniziale lascia 144 ms. Due ancore temporali vere ricostruiscono esattamente il modello sintetico, mentre due ancore basate sulla ricezione, con ritardi 4 e 20 ms, lasciano 100 ms di errore dopo un’ora. Un secondo calcolo, separato e a frequenze uguali, mostra che quattro timestamp con ritardi di andata 2 ms e ritorno 18 ms stimano un offset 4 ms quando quello vero è 12 ms. Sono equazioni e simulazioni, non misure su microcontrollori né un’implementazione NTP.
Tre concetti che non vanno scambiati
Il timestamp è un numero prodotto da un orologio, non il tempo fisico in sé. Chiamiamo t il riferimento ideale in secondi e C(t) il valore locale, già convertito nella stessa unità. L’offset è la differenza fra i due a un istante; la deriva di frequenza descrive quanto la velocità dell’orologio differisca dal riferimento. Il ritardo di trasporto è invece il tempo fra l’evento e la ricezione dell’informazione. Un pacchetto può arrivare tardi pur contenendo un timestamp corretto, oppure arrivare presto con una misura datata da un orologio non sincronizzato.
Il modello affine assume che il rapporto fra le velocità resti costante nell’intervallo. Scriviamo C(t)=at+b: a è adimensionale e b ha unità di secondi. a=1 significa stessa frequenza, non necessariamente stessa ora; b=0 significa stesso valore all’origine, non necessariamente stessa frequenza. Quaranta parti per milione, abbreviate ppm, corrispondono a 40 microsecondi guadagnati ogni secondo nel nostro caso. Sono parametri scelti per il calcolo, non una specifica attribuita a un quarzo o a una scheda.
La formula risponde alla domanda su quanto diverga l’ora dopo un’attesa. Il termine b è fisso, mentre(a−1)t cresce con il tempo:40 × 10⁻⁶× 3600 s=0,144 s. Aggiungendo 12 ms otteniamo 156 ms. La derivazione spiega perché sottrarre il valore iniziale 12 ms non risolva il problema: elimina l’intercetta, non la pendenza. Se i dati sono campionati idealmente ogni 10 ms,144 ms equivalgono a 14,4 periodi di campionamento. È un confronto di scale, non la misura di quattordici campioni persi o una frequenza realmente verificata su un dispositivo.
Due ancore identificano pendenza e origine
Supponiamo di conoscere due istanti veri t₀, t₁ e le letture locali corrispondenti c₀, c₁, acquisite agli stessi eventi. La differenza fra le letture elimina b; dividendola per la differenza dei riferimenti ricaviamo a. Poi una coppia basta a recuperare b. Per riportare una lettura locale al riferimento invertiamo la relazione affine. Non stiamo impostando fisicamente il contatore del dispositivo: possiamo anche lasciare intatti i timestamp originali e applicare una conversione documentata a valle.
Con t₀=0 s e t₁=600 s, il modello dà c₀=0,012 s e c₁=600,036 s. La pendenza ricavata è 600,024/600=1,00004 e l’intercetta 0,012 s. A 3600 s la lettura locale è 3600,156 s: invertendo otteniamo 3600 s, entro la tolleranza floating point del programma. Il successo è previsto dalla costruzione: un modello affine esatto con due ancore esatte determina due parametri. Non dimostra che due messaggi arbitrari identifichino la frequenza reale di una scheda, né che temperatura e alimentazione lascino costante la pendenza.
Ricevere non significa osservare l’istante di misura
Ora usiamo gli stessi timestamp del dispositivo, ma al gateway annotiamo gli istanti di ricezione r₀=0,004 s e r₁=600,020 s. I ritardi sono 4 e 20 ms, scelti esplicitamente. Se trattiamo r come se fosse t, il fit restituisce a_hat=600,024/600,016≈1,000013333 e b_hat≈0,007999947 s. Le due ancore sono adattate perfettamente in termini di ricezione; la trasformazione non ricostruisce però il riferimento fisico dell’evento. Il parametro apparente di frequenza contiene anche la variazione del ritardo fra i due pacchetti.
Applicando quella conversione alla lettura dell’evento t=3600 s otteniamo 3600,1 s, quindi 100 ms di errore. Non è il ritardo che abbiamo assegnato a un ipotetico pacchetto futuro: è l’errore della mappa temporale stimata dalle due ancore precedenti. Il modello vero continua ad avere 40 ppm costanti. L’esempio mostra un’identificabilità pratica: senza conoscere o limitare i ritardi, una differenza di tempo può essere attribuita alla frequenza oppure al trasporto. Aumentare il numero di decimali nel timestamp non aggiunge l’informazione mancante.
Nella tabella 1 indica il timestamp grezzo,2 la sola sottrazione dell’offset,3 le ancore vere e 4 le ancore di ricezione. Lo zero è una proprietà del modello esatto, non una precisione dichiarata per un dispositivo.
| Metodo a3600 s | Errore(ms) |
|---|---|
| 1 | 156 |
| 2 | 144 |
| 3 | 0 |
| 4 | 100 |
Quattro timestamp: che cosa cancella il viaggio di ritorno
La specifica NTPv 4 RFC 5905 del giugno 2010 usa quattro timestamp per stimare offset e ritardo di andata e ritorno; abbiamo letto le definizioni e la sezione 8. Non implementiamo il protocollo, i suoi filtri o la sua disciplina di clock. Isoliamo invece l’equazione per capire un limite. In questo secondo calcolo assumiamo frequenze uguali durante lo scambio: non riutilizziamo il parametro 40 ppm del precedente esperimento. Il riferimento A invia aT₁, B riceve aT₂, B risponde aT₃ e A riceve aT₄; T₂ e T₃ sono letti sull’orologio B.
L’ultima riga deriva sostituendo tempi ideali e ritardi: il tempo che B trascorre a elaborare la risposta si cancella, ma l’asimmetria di trasporto no. Se andata e ritorno hanno la stessa durata, l’offset stimato coincide con b nel modello. Se il viaggio di ritorno è più lungo, la stima si sposta verso valori minori. Il ritardo complessivo permette di conoscere la somma dei due viaggi, non di separarli univocamente. Una misura del tempo totale di rete non dimostra che metà di quel tempo appartenga a ciascuna direzione.
Scegliamo b=12 ms, andata 2 ms, elaborazione 1 ms, ritorno 18 ms. Le quattro letture sonoT₁=0, T₂=14 ms, T₃=15 ms, T₄=21 ms. La formula dà[(14−0)+(15−21)]/2=4 ms, mentre il ritardo di rete stimato è(21−0)−(15−14)=20 ms. L’errore nell’offset è−8 ms, metà della differenza fra i due ritardi con il suo segno. Il programma esegue questo conto e lo verifica con asserzioni. Non è una misura delle prestazioni di NTP in generale: il protocollo completo affronta molti altri problemi che questo scambio isolato non rappresenta.
Che cosa significa per l’AI sul dispositivo
Un modello che combina due finestre temporali può ricevere segnali relativi a istanti diversi anche quando i timestamp numerici sembrano allineati. Se la conversione temporale è calibrata sull’arrivo dei pacchetti, variazioni nella coda di trasmissione possono diventare un’apparente variazione del processo osservato. Non abbiamo misurato quanto peggiori l’accuratezza di un classificatore: non c’è un modello addestrato nell’esperimento. Il risultato è più circoscritto e verificabile: una parte della discordanza fra sensori può essere creata dalla catena temporale prima dell’inferenza.
Per passare al microcontrollore occorrerebbe specificare quale contatore produce il timestamp, dove viene acquisito rispetto all’evento, come si trattano overflow e riavvii, quale riferimento comune è disponibile e quali ritardi si possono limitare o misurare. Un’interruzione elaborata tardi non deve essere confusa con una misura acquisita tardi se l’hardware aveva già registrato l’evento; al contrario una lettura software eseguita dopo l’interruzione può includere latenza. Sono distinzioni di progetto da verificare sulla piattaforma: qui non affermiamo risoluzione, jitter o prestazioni di una scheda specifica.
Il codice allegato usa Python 3.14.0, senza casualità, e salva una griglia di 61 istanti da 0 a 3600 s. Il fit a due punti ha costo costante; applicare la conversione a N timestamp richiede O(N) operazioni. La griglia serve per visualizzare errori delle equazioni, non equivale a 61 acquisizioni hardware. Il frammento mostrato ricalcola il fit esatto e converte la lettura dopo un’ora. Figure, risultati e istruzioni permettono di riprodurre il ragionamento; nessuna installazione embedded EL-AI viene dedotta da questo materiale didattico.
I timestamp non concordano perché gli orologi e il trasporto introducono effetti diversi. Un solo offset non corregge una frequenza sbagliata; due ancore aiutano soltanto se sappiamo che cosa rappresentano; quattro timestamp non eliminano automaticamente l’asimmetria di rete. Il percorso scientifico porta quindi a una conclusione pratica: prima di attribuire al modello AI un disaccordo fra segnali, dobbiamo poter spiegare come ciascuna lettura locale è stata collegata all’istante fisico dell’evento, e con quali limiti.
from experiment import device,fit
a,b=fit([0.,600.],[device(0),device(600)])
print(device(3600)-3600,(device(3600)-b)/a)Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 17 ottobre 2026.