Nanosecondi, microsecondi e millisecondi spiegati — con esempi reali

La maggior parte delle persone ha un’idea intuitiva di secondi, minuti e ore. Ma le unità sotto il secondo — millisecondi, microsecondi e nanosecondi — sono il terreno su cui vivono informatica, reti e misurazioni di precisione. Non sono solo “secondi più piccoli”: ogni unità rappresenta una scala di attività completamente diversa, e confonderle nel contesto sbagliato può fare la differenza tra un sistema veloce e uno che non funziona.

Il Convertitore di tempo gestisce le conversioni tra tutte le unità di tempo, inclusi millisecondi e secondi. Questo articolo entra nel dettaglio sulle unità sotto il secondo: cosa misurano, come si relazionano e dove compaiono davvero.

Le unità e le loro relazioni

Partendo da un secondo e scendendo:

Ogni passo è esattamente 1.000× più piccolo. 1 millisecondo = 1.000 microsecondi. 1 microsecondo = 1.000 nanosecondi. Quindi 1 millisecondo = 1.000.000 nanosecondi.

Per dare un’idea di cosa sia 1 nanosecondo: la luce percorre circa 30 centimetri (circa 1 piede) in 1 nanosecondo. Nel tempo che impiega la luce ad attraversare una stanza (circa 10 nanosecondi), una CPU moderna può eseguire 10–30 istruzioni.

Millisecondi (ms): informatica a scala “umana”

Un millisecondo è 1/1.000 di secondo. È l’unità in cui la percezione umana inizia a contare nella tecnologia.

Tempo di reazione umano: in media 150–250 ms a uno stimolo visivo. Questo stabilisce la soglia di ciò che “sembra istantaneo” nel design delle interfacce: sotto i 100 ms appare immediato, tra 100–300 ms è percepibile ma accettabile, oltre 300 ms gli utenti avvertono un ritardo.

Tempi di caricamento delle pagine web: si misurano in millisecondi. Una pagina che carica in 500 ms sembra veloce; 2.000 ms (2 secondi) inizia a sembrare lenta. I Core Web Vitals di Google puntano a un Largest Contentful Paint sotto i 2.500 ms.

Latenza di rete: all’interno di un data center è tipicamente 1–5 ms. Tra continenti (New York–Londra) di solito 70–90 ms. New York–Tokyo è intorno a 150–170 ms. Questi numeri fissano il limite minimo di velocità per qualsiasi operazione di rete, a prescindere da quanto rapidamente il server elabori la richiesta.

Query di database: in un sistema ben ottimizzato si concludono in 1–50 ms. Una query da 500 ms è lenta; oltre 1.000 ms (1 secondo) di solito è un problema.

Buffer audio: nei software di produzione musicale si impostano in millisecondi. Un buffer di 10 ms dà 10 ms di latenza tra suonare una nota e sentirla — impercettibile. Un buffer di 50 ms si nota quando si suona una tastiera dal vivo. Molti setup di registrazione puntano a 5–20 ms.

Frame time nei giochi: è il numero di millisecondi per frame. Un gioco a 60 fps renderizza un frame ogni 16,67 ms. A 120 fps, ogni 8,33 ms. È su questa metrica che gli sviluppatori misurano le prestazioni.

Microsecondi (µs): tempi di rete e del kernel

Un microsecondo è 1/1.000.000 di secondo — 1.000 volte più piccolo di un millisecondo. È la scala in cui operano il calcolo ad alte prestazioni, il networking a bassa latenza e gli interni dei sistemi operativi.

High-frequency trading (HFT): lavora a latenze di microsecondi. Sistemi di trading co‑locati presso le principali borse ottengono tipicamente latenze round‑trip di 1–10 µs. Un vantaggio di 100 µs può tradursi in milioni di profitto nei mercati veloci.

Tempo di accesso SSD (solid-state drive): per letture casuali è tipicamente 50–150 µs. In confronto, gli HDD stanno sui 5–10 ms — quindi gli SSD sono 50–100× più veloci su questa misura. Gli SSD NVMe sono ancora più rapidi, con tempi di accesso di 20–50 µs.

Context switch della CPU: il passaggio del sistema operativo tra processi richiede 1–10 µs. Questo overhead è uno dei motivi per cui i sistemi ad alte prestazioni riducono i context switch tramite architetture event‑driven o core dedicati.

Accesso alla memoria (RAM): richiede circa 50–100 ns (nanosecondi), ma i cache miss che obbligano ad andare in RAM vengono spesso citati nell’intervallo 50–100 µs se si considera l’overhead di risoluzione dei miss nei programmi reali.

Trasmissione di frame Ethernet: a 10 Gbps richiede circa 1 µs per un frame da 1.500 byte. Il ritardo di propagazione (tempo di viaggio del segnale) tra due dispositivi nello stesso rack di un data center può essere 100–500 ns.

Nanosecondi (ns): timing a livello hardware

Un nanosecondo è 1/1.000.000.000 di secondo — 1.000 volte più piccolo di un microsecondo. A questa scala, la velocità della luce diventa un vincolo concreto.

Cicli di clock della CPU: si misurano in nanosecondi. Un processore a 3 GHz completa un ciclo ogni 0,33 ns. Una singola istruzione richiede tipicamente 1–4 cicli (0,33–1,3 ns) in una CPU moderna con pipeline.

Tempi di accesso alle cache della CPU:

• Cache L1: ~1 ns (2–4 cicli)
• Cache L2: ~4 ns (10–15 cicli)
• Cache L3: ~10–40 ns (30–100 cicli)
• RAM: ~50–100 ns (150–300 cicli)

Ecco perché la progettazione delle cache è critica: un programma che “entra” in L1 gira molto più velocemente di uno che va spesso in miss fino alla RAM.

Velocità del bus di memoria: si valuta in nanosecondi. La memoria DDR5 ha un tempo di ciclo di circa 0,625 ns (che corrisponde a una velocità effettiva di 6.400 MT/s). I timing indicati come “CL16” significano che la latenza CAS (column access strobe) è di 16 cicli di clock.

Ritardi su cavi di rete e PCIe: sono nell’ordine dei nanosecondi. Il segnale viaggia in un cavo di rame a circa 2/3 della velocità della luce — approssimativamente 20 cm/ns. Un cavo da 1 metro introduce circa 5 ns di ritardo di propagazione.

Timing GPS: richiede precisione nell’ordine dei nanosecondi. I satelliti GPS devono sincronizzare gli orologi entro 20–30 ns per ottenere accuratezza al metro. Un errore di soli 10 ns si traduce in circa 3 metri di errore di posizione.

Conversioni tra unità sotto il secondo

Le conversioni seguono lo schema 1.000×:

Conversioni comuni:

• 1 secondo = 1.000 ms = 1.000.000 µs = 1.000.000.000 ns
• 100 ms = 100.000 µs = 100.000.000 ns
• 50 µs = 0,05 ms = 50.000 ns
• 500 ns = 0,5 µs = 0,0005 ms

Per convertire da queste unità piccole fino a minuti, ore e giorni, il Convertitore di tempo gestisce automaticamente l’intera catena.

Perché la precisione conta nel codice

Quando lavori con timestamp e misurazioni del tempo in programmazione, confondere le unità è una fonte frequente di bug. I più comuni:

Secondi vs millisecondi nelle API. I timestamp Unix sono in secondi; Date.now() in JavaScript restituisce millisecondi. Passare millisecondi dove ci si aspetta secondi crea date nel 2527; passare secondi dove ci si aspetta millisecondi crea date nel gennaio 1970.

Dormire per la durata sbagliata. time.sleep(1) in Python sospende per 1 secondo. In alcuni framework, la chiamata equivalente accetta millisecondi o microsecondi. Controlla sempre la documentazione per capire l’unità attesa.

Deriva nelle misurazioni delle prestazioni. Se fai benchmarking con un timer a risoluzione in millisecondi ma le operazioni durano 10–50 µs, le misure non significano nulla — serve un clock a risoluzione più alta. time.perf_counter() in Python e performance.now() in JavaScript offrono risoluzione sotto il millisecondo.

Timeout di rete configurati male. Un timeout impostato a 100 può significare 100 millisecondi o 100 secondi a seconda della libreria. 100 secondi è lunghissimo per una richiesta web; 100 millisecondi può essere troppo poco per una query di database sotto carico.

Azzeccare l’unità non è pignoleria: è la differenza tra un sistema che si comporta correttamente e uno che fallisce in modo sottile e difficile da diagnosticare.