Misurare il tempo con AI e browser: l’Attimo Massimamente Preciso
Misurare il tempo con AI e browser: l’Attimo Massimamente Preciso
Di Salvatore Martino
Misurare il tempo sembra un problema semplice: basta leggere un orologio.
Quando però l’obiettivo diventa misurare un intervallo temporale nel modo più accurato realisticamente possibile, il problema cambia completamente. Entrano in gioco il clock del dispositivo, il browser, la rete, la latenza, la stabilità del sistema, la sorgente UTC, il jitter, la deriva e, soprattutto, l’incertezza della misura.
È da questa prospettiva che nasce ATTIMO ENGINE, un esperimento sviluppato partendo anche dalla mia precedente esperienza di cronometrista della FICr: non un tentativo di costruire un “orologio atomico nel browser”, ma un sistema che cerchi di determinare quanto possiamo realmente sapere sull’istante presente, dichiarando contemporaneamente ciò che non possiamo sapere.
Artefatto Attimo engine
Artefatto – Pensai Speed Test
Dal cronometro alla misura del tempo
L’idea iniziale era realizzare un semplice orologio standalone HTML.
Durante il lavoro, tuttavia, è emerso un problema più interessante: un numero come
12:34:56.123456789
non significa necessariamente che l’istante sia conosciuto con accuratezza di un nanosecondo.
La quantità di cifre visualizzate e la qualità della misura sono due cose differenti.
Per questo il progetto è stato progressivamente trasformato in un sistema di analisi temporale, nel quale vengono distinti:
- risoluzione;
- precisione;
- accuratezza;
- stabilità;
- jitter;
- deriva;
- latenza;
- incertezza;
- riferimento temporale.
Questa distinzione è fondamentale anche sul Web. La Web Performance API mette a disposizione performance.now(), un clock monotono destinato alle misure di intervalli e non soggetto alle normali correzioni del clock civile. La sua risoluzione effettiva, però, può essere ridotta dal browser per ragioni di sicurezza e privacy. (MDN Web Docs)
performance.now() non è un orologio UTC
Una delle decisioni progettuali fondamentali è stata separare due funzioni.
performance.now() viene utilizzato per misurare intervalli temporali.
Date.now() e i riferimenti esterni vengono utilizzati per collegare la misura all’epoca UTC.
La differenza è sostanziale.
performance.now() utilizza un riferimento monotono: per la stessa origine temporale, i valori non devono diminuire e non sono direttamente modificati dalle regolazioni dell’orologio di sistema. (MDN Web Docs)
Questo lo rende adatto alla domanda: Quanto tempo è trascorso tra A e B?
Ma non risponde da solo alla domanda:
Qual è l’istante UTC corrispondente adesso?
Per questa seconda domanda occorre un riferimento esterno.
Il problema del riferimento UTC
UTC non è semplicemente “l’ora di Internet”. Il BIPM è responsabile della realizzazione e disseminazione della scala internazionale UTC. Le realizzazioni fisiche di UTC, denominate UTC(k), sono mantenute da istituti metrologici nazionali e osservatori che contribuiscono alla costruzione della scala internazionale. (BIPM)
Questo introduce una distinzione essenziale per ATTIMO ENGINE:
un server web che restituisce l’ora non equivale automaticamente a un riferimento metrologico UTC.
Il NIST, per esempio, offre un servizio Internet il cui tempo è direttamente riconducibile a UTC(NIST), ma sottolinea anche che l’accuratezza osservata dall’utente dipende in larga misura dalla stabilità e dalla reciprocità della connessione di rete. (NIST)
Pertanto il nostro sistema non deve limitarsi a chiedere:
“Che ora mi restituisce il server?”
Deve chiedersi:
“Con quale incertezza posso trasferire quel riferimento temporale fino al mio browser?”
La rete diventa parte dell’esperimento
Per ogni richiesta temporale il sistema registra il comportamento della comunicazione.
In forma semplificata:
T0 browser → server rete T1 server riceve T2 server risponde rete T3 browser riceveDa questi dati possiamo ottenere almeno il Round Trip Time (RTT).
Il modello più semplice assume che il ritardo di andata e quello di ritorno siano simmetrici:
ritardo ≈ RTT / 2
Ma questa è un’ipotesi, non una legge fisica della rete.
Il rapporto tecnico prodotto durante la sessione identifica proprio questa assunzione come una delle principali fonti di incertezza del sistema.
Di conseguenza ATTIMO ENGINE deve dichiarare l’ipotesi, non nasconderla.
Misurare invece di inventare
Uno dei passaggi più importanti dello sviluppo è stato eliminare le simulazioni.
Il sistema finale deve distinguere rigorosamente:
MISURATO
da
STIMATO
e da
NON DETERMINABILE.
Il rapporto di realizzazione documenta l’eliminazione di Math.random() e il passaggio a interrogazioni reali tramite HTTPS/CORS.
Questo principio sembra banale, ma è probabilmente il punto più importante dell’intero progetto.
Se una sorgente temporale non risponde, non si deve inventare un valore.
Se la rete è instabile, non si deve nascondere il problema.
Se l’incertezza non può essere calcolata, non si deve produrre una falsa precisione.
Il risultato corretto può essere:
NON DETERMINABILE
L’“Attimo Massimamente Preciso”
Da questa impostazione nasce il concetto centrale del progetto.
Non cerchiamo il timestamp con il maggior numero di decimali.
Cerchiamo la migliore stima dell’istante associata alla minima incertezza dimostrabile.
In forma concettuale:
[
T^*=\arg\min_T U(T)
]
dove:
- (T^*) è l’istante stimato migliore;
- (U(T)) è l’incertezza associata alla stima.
Questo è l’Attimo Massimamente Preciso.
Il rapporto della sessione documenta proprio la scelta del campione con la minore incertezza, invece di selezionarlo sulla base del maggior numero di cifre visualizzate.
L’intelligenza artificiale non deve misurare il tempo
Un’altra evoluzione interessante è stata l’introduzione del concetto di sistema agentico.
L’AI non dovrebbe sostituire il motore di misura.
Il principio è:
SENSORE / CLOCK
↓
MISURA
↓
DATI GREZZI
↓
ANALISI
↓
INCERTEZZA
↓
VERIFICA
↓
DECISIONEL’AI può analizzare i dati, confrontare le fonti, individuare anomalie e proporre quale campione sia migliore.
Non deve però modificare arbitrariamente i dati grezzi né trasformare un’incertezza sconosciuta in una precisione apparente.
Questa separazione rende il sistema più facilmente verificabile.
Anche il computer diventa una variabile
Durante lo sviluppo sono stati introdotti controlli per individuare condizioni che possono compromettere la misura.
Tra queste:
- throttling del browser;
- sospensione del sistema;
- risveglio;
- variazioni del clock;
- instabilità della rete;
- campioni anomali.
Il rapporto documenta anche l’introduzione del controllo per rilevare la divergenza del clock locale durante sleep/throttling.
La documentazione W3C conferma che i browser possono limitare o sospendere timer e callback in determinate condizioni, e che le caratteristiche del clock monotono devono quindi essere considerate nel contesto reale di esecuzione. (W3C)
Geografia: un parametro, non una correzione magica
Nel progetto è stata introdotta anche la posizione geografica.
L’idea è semplice: conoscere la posizione dell’utente può permettere di stimare la distanza geografica da un riferimento remoto.
Ma la distanza geografica non è il percorso effettivo dei pacchetti Internet.
Perciò la geolocalizzazione può diventare un parametro diagnostico, ma non deve essere trasformata automaticamente in una correzione temporale.
Anche qui il principio è:
modello dichiarato, non falsa certezza.
Il passo successivo: HTML + PHP
L’esperimento ha portato infine a una possibile architettura ibrida.
Il browser continua a fornire il motore locale ad alta risoluzione:
HTML / JavaScript
│
performance.now()
│
▼
ATTIMO ENGINEmentre un server PHP può fornire un ulteriore riferimento remoto:
Browser
│
HTTPS
▼
PHP server
│
timestamp
▼
BrowserDisponendo di due infrastrutture, come Hostinger e Aruba, diventa inoltre possibile confrontare due nodi remoti.
Non per assumere che uno dei due sia “la verità”, ma per osservare:
- concordanza;
- offset;
- RTT;
- jitter;
- stabilità;
- disponibilità.
Se i due riferimenti divergono, il sistema deve aumentare l’incertezza o fermarsi.
Il risultato non è un orologio atomico
Questo limite deve rimanere esplicito.
Un browser non può trasformarsi in un laboratorio di metrologia temporale semplicemente aggiungendo decimali.
Anche un riferimento Internet di alta qualità deve attraversare una rete la cui latenza e asimmetria influenzano la misura. Il NIST osserva esplicitamente che la qualità del tempo percepito dal client è fortemente condizionata dalla rete. (NIST)
Per questo ATTIMO ENGINE non dovrebbe mai affermare:
“Accuratezza: 1 nanosecondo”
solo perché sullo schermo compare:
12:34:56.123456789
La formulazione corretta è:
Risoluzione visualizzata: 1 ns
Incertezza stimata: ±X ms
Sono due informazioni completamente diverse.
Da cronometrista a progettista di un sistema di misura
L’aspetto forse più interessante di questa esperienza è che il progetto è partito da un’esigenza apparentemente semplice — costruire un orologio — ed è arrivato a una domanda molto più generale:
Qual è il massimo livello di conoscenza temporale che possiamo ottenere con una determinata tecnologia, in determinate condizioni, e come possiamo dimostrarlo?
È una domanda che appartiene più alla misura che alla semplice visualizzazione dell’ora.
La risposta di ATTIMO ENGINE non pretende di essere assoluta.
È invece una risposta sperimentale:
misurare → confrontare → stimare → quantificare l’incertezza → verificare → dichiarare il limite.
E quando i dati non sono sufficienti:
STOP — NON DETERMINABILE.
È probabilmente questa, più ancora della quantità di decimali visualizzati, la caratteristica più importante del progetto.
Bibliografia e riferimenti
- BIPM — Time Metrology, riferimento istituzionale per UTC, UTC(k) e metrologia del tempo. (BIPM)
BIPM — Time Metrology - NIST — Internet Time Service (ITS), informazioni sulla distribuzione di UTC(NIST), NTP e dipendenza dalle condizioni della rete. (NIST)
NIST — Internet Time Service - W3C — High Resolution Time, specifiche relative a clock monotoni e
performance.now(). (W3C)
W3C — High Resolution Time - MDN — High precision timing, confronto tra
performance.now()eDate.now(), riduzione della precisione e isolamento cross-origin. (MDN Web Docs)
MDN — High precision timing
Report di realizzazione ATTIMO ENGINE, documentazione della sessione sperimentale e dei limiti metodologici.
Disclaimer AI: questo articolo è stato realizzato con il supporto di strumenti di intelligenza artificiale. L’AI è stata utilizzata come strumento di elaborazione, sviluppo e supporto al ragionamento, ma non costituisce una fonte autonoma di verità né sostituisce la verifica umana. Le informazioni, i risultati sperimentali e le valutazioni riportate devono essere interpretati considerando le condizioni tecniche, le fonti utilizzate e i limiti dichiarati nel progetto. La responsabilità finale dei contenuti e delle decisioni derivanti dal loro utilizzo rimane dell’autore.
