Misurare l’autonomia di un notebook con rigore richiede più di una prova veloce a luminosità media. Serve una procedura controllata replicabile e documentata, capace di distinguere tra dispersione statistica e differenze reali. Il vantaggio è duplice: comparabilità tra modelli e capacità di diagnosticare colli di bottiglia energetici.
Questa metodologia si concentra su quattro pilastri: profili energetici coerenti, scenari sintetici e real-world ben definiti, logging accurato e analisi della varianza. In aggiunta, affronta i fattori che più inquinano i test: calibrazione, battery wear impatto del display dei codec e dello stack di rete.
Preparazione: calibrazione e condizioni di test
Prima di tutto, eseguire una calibrazione di base: carica al 100%, riposo 10 minuti a cavo staccato per stabilizzare, quindi avvio del test. Verificare lo stato di salute della batteria (battery wear) con gli strumenti nativi del sistema o utility affidabili; documentare cicli capacità di progetto e capacità stimata. Se il wear supera il 10%, i risultati vanno etichettati come “degradati” o esclusi dai confronti diretti.
Stabilire l’ambiente: aggiornamenti disattivati, sincronizzazioni sospese, modalità aereo quando non si testa la rete, temperatura ambiente tra 20–24 °C. Impostare la luminosità a un valore misurabile (ad esempio 200 nit con colorimetro) o a una percentuale fissa, dichiarandola nel report. Disabilitare screen saver e sospensione automatica; mantenere costante la risoluzione del display e la frequenza di refresh.
Profili energetici controllati e ripetibili
Definire due profili cardine: Balanced per l’uso d’ufficio e Battery saver per la massima efficienza. In sistemi che lo permettono, impostare limiti di PL1/PL2 o equivalenti e bloccare la modalità GPU su integrata. Uniformare la politica di sospensione delle unità NVMe, la gestione del Wi-Fi (power save attivo/disattivo) e il comportamento delle porte USB. Salvare e riutilizzare questi profili, così da garantire ripetibilità tra sessioni e tra macchine.
Annotare ogni deroga: ventole in modalità silent o standard, app in background consentite, eventuale uso di HDR o di profili colore. Ogni scostamento ha impatto misurabile; la trasparenza qui evita falsi confronti e riduce la varianza non spiegata.
Scenari sintetici e real-world ben definiti
Gli scenari sintetici servono a isolare sottosistemi. Tre prove utili: 1) Idling da tavolo, con Wi-Fi spento, schermo a 200 nit, solo un documento aperto; 2) Web loop script che carica ciclicamente pagine statiche e dinamiche, con scorrimento a intervalli regolari; 3) Video playback locale con file H.264, H.265 e AV1, per misurare l’efficienza dei codec e del decoding hardware rispetto al software.
Le prove real-world misurano il lavoro quotidiano: un blocco office (editing di testi e fogli, PDF con annotazioni), un blocco collaboration (videochiamata 1080p, 30 minuti, Wi-Fi attivo), e un blocco developer/creativo leggero (build o esportazione foto con accelerazione GPU disattivata o dichiarata). Ogni blocco dura 30–60 minuti e si ripete fino allo shutdown o al 5% di batteria residua, registrando il tempo totale.
Logging rigoroso e analisi della varianza
Senza logging il test vale poco. Registrare a intervalli di 30–60 secondi: percentuale batteria, energia stimata in Wh, potenza istantanea (W), temperatura, frequenze CPU/GPU, stato Wi-Fi, luminosità. Su sistemi che lo supportano, acquisire anche C-states e P-states per capire la qualità dell’inattività. Salvare i log in CSV con timestamp e fuso orario, così da confrontare run diversi.
Eseguire almeno tre run per scenario e calcolare mediadeviazione standard e coefficiente di variazione. Se il CV supera il 5–7% in scenari stabili (idling, playback), indagare processi anomali o interferenze di rete. L’analisi degli outlier tramite grafici potenza-nel-tempo mostra drift termici, boost prolungati o task in background che falsano i risultati.
Display, codec e stack di rete: gli effetti nascosti
Il display è spesso il primo responsabile dei consumi. OLED e LCD ad alta frequenza hanno profili diversi: testare a 60 Hz e indicare se è attivo VRR. Su OLED, i contenuti scuri riducono la potenza; usare pattern misti per evitare bias. La gestione automatica della luminosità (ABL, auto-brightness) va disattivata o quantomeno dichiarata, perché introduce oscillazioni difficili da mediare.
Sui codec il decoding hardware di H.265/HEVC e AV1 può dimezzare la potenza rispetto al software. Verificare con tool di sistema quale pipeline è in uso e bloccarla per l’intera run. Per lo stack di rete separare i test: Wi-Fi 6/6E con segnale forte e rete locale minimale per il web loop; poi scenario di videocall con bitrate costante, disattivando upload di backup e sync. Jitter e ritrasmissioni gonfiano i watt: meglio una rete dedicata o orari a bassa congestione.
Battery wear, report e criteri di confronto
Il battery wear riduce l’energia utile e altera la stima software. Registrare la capacità in Wh riportata dal sistema prima e dopo i test; se la stima varia molto, preferire il tempo-a-carico costante ricavato dalla potenza media. Un esempio: se il playback AV1 consuma 6,5 W medi su una batteria da 55 Wh effettivi, l’autonomia attesa è circa 8h 27m; dichiararla insieme a intervallo di confidenza basato sulla varianza dei run.
Il report finale include: versione OS, driver grafici, profilo energetico, luminosità, codec, rete, temperatura ambiente, log allegati e metrica di dispersione. I confronti tra notebook vanno fatti a parità di profilo e scenario; per scenari diversi, indicare il consumo medio in W oltre alle ore, così da rendere confrontabili batterie di taglio differente.
