Come studiamo Windows

Nella sezione «Ricerche su Windows» verifichiamo specifiche affermazioni tecniche. In ogni articolo spieghiamo cosa abbiamo verificato, in quali condizioni e a quali sistemi si applica il risultato.

La presenza di un parametro, il suo impatto sul funzionamento del sistema e l’aumento di prestazioni richiedono prove separate.

Cosa si considera una prova

Utilizziamo diversi tipi indipendenti di evidenza:

1. Documentazione primaria. Documenti ufficiali Microsoft, specifiche e documentazione del produttore dell’hardware o dell’applicazione.
2. Osservazione statica. Indizi di implementazione in una specifica versione del componente. Tale osservazione è limitata alla build studiata e di per sé non dimostra l’esecuzione del percorso durante il funzionamento.
3. Osservazione dinamica. Eventi di sistema, stato dei componenti e tracce ottenute nello scenario descritto.
4. Misurazione controllata. Confronto di una metrica scelta in anticipo con una modifica nota e un ritorno allo stato verificato.
5. Riproduzione. Ripetizione del risultato in un’esecuzione indipendente, su un altro sistema o build.

I metodi interni di automazione della raccolta e dell’elaborazione non vengono pubblicati. Ciò non modifica l’obbligo di divulgare la domanda verificata, la configurazione, le metriche, il numero di esecuzioni e i limiti.

Stati dei materiali

Stato	Significato
Documentato	Il comportamento è descritto in una fonte pubblica primaria.
Osservato	L’evento o lo stato è stato rilevato nell’ambiente indicato.
Misurato	È stata ottenuta una differenza numerica secondo la metodologia descritta.
Riprodotto	Il risultato è stato ripetuto in modo indipendente.
Non riprodotto	L’effetto dichiarato non è stato rilevato nelle condizioni indicate.
Dati insufficienti	La metodologia o il campione non consentono di trarre una conclusione.

Lo stato si riferisce a una singola affermazione, non automaticamente all’intero articolo. Non utilizziamo una percentuale di fiducia arbitraria e non dichiariamo un risultato universalmente dimostrato senza verifica su altri sistemi.

Come si costruisce l’esperimento

Prima della misurazione si fissano:

• una domanda da verificare;
• la variabile indipendente;
• la metrica principale e la sua unità;
• Windows build, hardware rilevante, driver e versioni delle applicazioni;
• una soglia praticamente significativa;
• il metodo di ripristino dello stato iniziale.

Confrontiamo lo stato iniziale e quello modificato, poi verifichiamo il ripristino. Quando possibile alterniamo l’ordine delle esecuzioni appaiate. Controlliamo il riscaldamento, l’alimentazione, le temperature e il carico in background; se ciò non è possibile, indichiamo il limite.

Singoli intervalli di una stessa traccia mostrano cambiamenti nel tempo, ma non sono considerati ripetizioni indipendenti. Il risultato di una macchina virtuale non può essere trasferito automaticamente a un computer fisico. Per una conclusione su tutti i dispositivi di una classe non è sufficiente verificare un solo dispositivo.

Banco fisico click-to-photon

Per le ricerche sul gaming utilizziamo un banco hardware dedicato. Esso misura fisicamente la latenza completa dal segnale elettrico del pulsante del mouse al cambiamento della luminosità del pixel sullo schermo, senza una stima software di questo intervallo.

Il percorso principale è strutturato così:

1. Un filo è saldato alla linea del pulsante sinistro di un Logitech G PRO X SUPERLIGHT di prima generazione. Il fronte elettrico avvia il timer di un Arduino Uno.
2. Lo stesso clic passa attraverso il controller del mouse, USB, Windows, il gioco, la coda di rendering, GPU e monitor.
3. Un fotosensore fissato allo schermo ferma il timer quando la luminosità dell’area di test supera una soglia scelta in anticipo.
4. Un singolo risultato contiene l’intervallo click-to-photon completo in millisecondi.

Tale avvio include intenzionalmente l’elaborazione da parte del controller del mouse e il suo click debounce, ma non include la corsa meccanica del pulsante fino alla chiusura del contatto. Non sottraiamo la latenza del mouse dal valore finale. Nella metodologia attuale di misurazioni indipendenti RTINGS per il G PRO X SUPERLIGHT sono indicati 2.5 ms via cavo e 3.1 ms tramite receiver. La bassa click latency misurata rende questo mouse una parte stabile e adatta del banco, ma non trasforma il risultato nella pura latenza di Windows o del gioco.

Un microcontrollore HID separato in formato Arduino Nano può inviare clic a Windows automaticamente. Questo percorso viene utilizzato quando occorre eliminare le differenze della pressione manuale e ripetere il segnale di input a un ritmo controllato. Esso risponde a un’altra domanda e non viene mescolato con le serie che partono dalla linea fisica del pulsante del mouse.

In CS2 viene utilizzata la mappa workshop BXLAT, dove il clic provoca un cambiamento prevedibile dell’area di test. Uno scenario visivo analogo viene applicato in Valorant. La posizione del fotosensore, la risoluzione, la frequenza del monitor, il limite di FPS, la modalità display scaling, la presentation mode e la soglia di luce vengono fissati per tutta la serie confrontata.

Lo standard attuale richiede almeno 300 clic validi per stato. Nelle nuove serie conserviamo media, deviazione standard, minimo, massimo, percentili, incluso P90, e la distribuzione per costruire i grafici. Attivazioni errate, superamenti del tempo di attesa e valori al di fuori dell’intervallo stabilito in anticipo vengono contrassegnati e considerati nella verifica dell’idoneità della serie.

Le ricerche su questo banco vengono condotte da diversi anni e il formato di archiviazione nel tempo è cambiato. Nella tabella pubblica delle misurazioni storiche ci sono serie da 300 clic e serie più vecchie da 100. Per una parte dei vecchi test sono conservati solo AVG, STDDEV, MIN e MAX; i P90 o i grafici mancanti non vengono ricostruiti dagli aggregati e sono indicati esplicitamente come non disponibili. Le nuove serie saranno pubblicate con statistiche estese.

Cosa viene pubblicato nel risultato

L’articolo contiene:

• una risposta breve;
• l’affermazione verificata;
• l’ambito della ricerca;
• la metodologia e il numero di tracce indipendenti;
• i valori delle metriche e la dispersione;
• le conclusioni confermate e non confermate;
• le metriche escluse o contaminate;
• i limiti;
• una raccomandazione pratica senza garanzia di un risultato identico;
• la conferma del ripristino dello stato;
• le fonti pubbliche primarie e la data di verifica.

Se il risultato non ha confermato una raccomandazione popolare o una funzione di BoosterX, esso può comunque essere pubblicato. La presenza di una regolazione nel prodotto non è prova della sua efficacia.

Come verificare autonomamente

Una parte significativa delle osservazioni dinamiche delle nostre ricerche è riproducibile con strumenti pubblici: Sysinternals ProcMon per le tracce di sistema e WinDbg con i simboli pubblici Microsoft. Il percorso di verifica di base è il seguente.

1. Lettura del parametro — ProcMon. Aprite Options → Configure Symbols e indicate il server pubblico dei simboli Microsoft, affinché gli stack mostrino i nomi dei moduli e delle funzioni. Poi aggiungete un filtro Path contains — ad esempio SystemResponsiveness da HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. Dagli eventi di lettura si vede se il valore viene letto, quando e da quale processo.
2. Chi legge — lo stack di chiamata. Un doppio clic sull’evento apre le sue proprietà; nella scheda Stack è mostrata la catena dei moduli — è proprio il «lettore» del parametro. Ad esempio, una catena da user32.dll a win32kfull.sys significa che del valore è responsabile il sottosistema Win32k.
3. Comportamento a runtime — WinDbg. Con i simboli pubblici Microsoft si può impostare un punto di interruzione su una funzione dello stack e osservare come il valore letto viene applicato.
4. Test sintetici. Modificate il valore e misurate il comportamento osservato. Ad esempio, gli intervalli di input del mouse vengono misurati con tester pubblici della frequenza di polling.

Confine onesto. L’analisi statica dei binari e le tracce complete non vengono pubblicate negli articoli. Il percorso sopra ripete la parte dinamica delle nostre osservazioni, ma non sostituisce l’analisi statica — le sue conclusioni si riferiscono alla build studiata.

Limiti della misurazione della latenza

La latenza software, la profondità della coda, il periodo del motore audio, il tempo di pianificazione del thread e la latenza fisica completa descrivono grandezze diverse. Ad esempio, la coda XAudio2 non determina l’intero intervallo dall’azione dell’utente al suono dall’altoparlante. Per misurarlo serve un’attrezzatura esterna.

Analogamente, il tempo CPU di un singolo processo non è uguale all’influenza complessiva su FPS, frametime, consumo energetico o reattività del sistema. Tali conclusioni vengono verificate con metriche separate.

Protezione dei dati

Gli ETL, PML, i registri eventi, i dump di memoria e le esportazioni del registro di sistema originali non vengono pubblicati per impostazione predefinita. Le tracce di sistema possono contenere nomi utente, percorsi, righe di comando, indirizzi di rete e altri dati sensibili. Microsoft lo avverte separatamente nelle condizioni Sysinternals.

Sul sito vengono pubblicate solo tabelle selezionate manualmente e anonimizzate. Rimuoviamo identificatori univoci di dispositivi e installazioni, percorsi utente, dati degli account, identificatori di rete, dati di accesso e informazioni su processi non correlati alla ricerca.

Correzione delle conclusioni

Windows, i driver e le applicazioni cambiano. Ogni articolo riceve la data dell’ultima verifica e l’ambito di applicabilità. Se una nuova misurazione contraddice una vecchia conclusione, l’articolo viene aggiornato con la spiegazione del motivo. Il vecchio risultato non viene trasferito automaticamente a una nuova build.

Indipendenza e marchi

Le ricerche sono pubblicate dal team di BoosterX e possono riguardare funzioni del prodotto. Questo possibile conflitto di interessi viene considerato separando la metodologia, i valori misurati, i limiti e i risultati negativi dalla raccomandazione di prodotto.

BoosterX Wiki è una pubblicazione indipendente e non è associata, autorizzata, sponsorizzata o approvata da Microsoft Corporation. I nomi Microsoft e Windows sono utilizzati solo per descrivere con precisione l’oggetto della ricerca. Maggiori dettagli: Microsoft Trademark and Brand Guidelines.

Cronologia delle modifiche

• 2026-08-24: metodologia pubblicata.
• 2026-09-20: aggiunta la sezione «Come verificare autonomamente»; corretto il link alla fonte dei dati del mouse.

Ultima verifica della metodologia: 2026-09-20.