Latenza DPC: quando è un driver a fare scatti

Hai passato in rassegna tutta la lista. Non c'è niente in esecuzione, le temperature sono a posto, il disco è veloce, il gioco sta su un SSD, e la macchina continua a dare scossoni. Gestione attività mostra un sistema fermo. Il grafico dei frame time mostra il frame in ritardo ma non dice niente sul perché fosse in ritardo.

C'è una causa che spiega esattamente questa forma, ed è invisibile in tutti gli strumenti a cui la maggior parte delle persone ricorre, perché avviene sotto di loro.

Prima di tutto, la frase onesta. La soluzione per un driver che tiene occupato un core è quel driver, dal suo produttore. La parte di w0a è la misura, il nome del file e la riparazione dei valori lasciati indietro da strumenti più vecchi. L'unico interruttore che offriva in questa zona, instradare gli interrupt di un dispositivo verso core scelti, è in sola lettura dall'8 ottobre 2026, perché nessun test A/B in un gioco ha mai mostrato un frame guadagnato grazie a lui.

Che cosa sta succedendo davvero

Un dispositivo — una scheda di rete, un controller del disco, un chip audio, un controller USB — ha bisogno dell'attenzione del processore. Solleva un interrupt, e Windows esegue subito la routine di servizio dell'interrupt del driver. Quella routine gira sopra ogni priorità di thread che esista: non «priorità alta», ma proprio fuori dallo scheduler dei thread. Su quel core non si può mettere in esecuzione nient'altro finché non ritorna.

Siccome è un posto costoso in cui stare, i driver dovrebbero farci il minimo indispensabile e rimandare il resto a una chiamata differita — un DPC — che gira un istante dopo, sempre davanti a ogni thread di quel core.

Mentre una delle due è in esecuzione, quel core non disegna niente e non legge input. Se il tuo thread di rendering era lì sopra, il tuo frame è in ritardo. Se il report del tuo mouse era in coda dietro di essa, il tuo input è in ritardo. E nessuno dei due eventi compare in un task manager, perché non c'è nessun processo a cui attribuirlo.

Perché qui un millisecondo è tanto

È l'aritmetica a rendere la cosa degna di essere inseguita:

• Con polling a 1000 Hz arriva un report ogni millisecondo. Un'occupazione di 1 ms costa un report.
• A 240 Hz un frame dura 4.2 ms. Un'occupazione di 1 ms è circa un quarto del budget di un frame, speso per niente.
• Da 4 ms in su, la macchina non riesce a tenere un frame time stabile qualunque altra cosa tu cambi — ed è per questo che questa voce va prima di ogni altra della tua lista, non dopo.

Misurarla, e i due modi in cui la misura fallisce

Il Test di latenza di w0a apre una sessione di tracciamento del kernel e registra, per dodici secondi di movimento reale del mouse, per quanto tempo ogni driver ha tenuto occupato un core. Servono i diritti di amministratore. Perché il test chiede 12 secondi parla della durata; leggere il test di latenza parla dei colori.

Due risultati non sono risposte, ed entrambi vengono riportati come tali invece di essere arrotondati a «pulito»:

• La sessione non si è potuta aprire. Può darsi che un driver anti-cheat si sia preso il tracciamento del kernel per sé. Chiudi il gioco e misura di nuovo.
• La sessione si è aperta e non ha consegnato niente. Nessun Windows in funzione ha zero esecuzioni di driver in dodici secondi, quindi questa è una misura che non è avvenuta. Rifalla.

Ce n'è un terzo, più sottile: una sessione che ha perso degli eventi può essersi lasciata sfuggire del tutto l'esecuzione peggiore, perciò la pagina dice che quel numero potrebbe non essere il vero peggiore. È lo stesso principio che la scansione degli scatti applica ovunque — una regola che non è potuta girare viene contata come non controllata, mai come pulita.

I numeri, esattamente

Leggere l'elenco

Ogni driver compare con il nome del suo file, la sua occupazione singola più lunga, la sua quota del tempo misurato e quante volte è stato eseguito. Ordina per occupazione più lunga; è quello il numero che ti costa un frame.

Due letture che la gente sbaglia:

• Una riga gialla non è un problema che devi per forza risolvere. È una candidata. Senza un sintomo non spiega niente, e parecchie macchine sane ne hanno una.
• Un gestore di interrupt lungo è peggio di una chiamata differita lunga della stessa durata. Durante una chiamata differita gli altri interrupt possono comunque essere serviti; durante un gestore di interrupt su quel core non entra proprio niente. La pagina lo segnala quando il caso peggiore di un driver è stato un interrupt.

Quale file è quale, e che cosa fare per ciascuno

Il nome del file è tutto l'indizio, e la famiglia a cui appartiene decide la soluzione:

Un driver di filtro merita una riga a sé. Gli strumenti che modellano il traffico e instradano le connessioni fanno passare ogni pacchetto attraverso un driver loro, e gli intoppi di rete da più secondi sono il loro effetto collaterale più noto; la scansione degli scatti li nomina quando li trova. Lo stesso vale per le suite di macro e per i programmi di illuminazione che installano un filtro sul percorso di mouse e tastiera.

La soluzione, e le non-soluzioni

La soluzione è aggiornare quel singolo driver, dal produttore dell'hardware. Non tutto il sistema, non attraverso uno strumento che aggiorna driver, e non reinstallando Windows. La pagina nomina il file con precisione, così puoi cercare a quale dispositivo appartiene.

Quello che non risolve il problema, e che proprio per questo qui viene rifiutato: le forzature della risoluzione del timer, i valori di gestione della memoria del kernel (DisablePagingExecutive, LargeSystemCache) e le liste di chiavi di registro che circolano sotto la parola «latenza». Nessuna di queste cose cambia per quanto tempo un driver tiene occupato un core, perché a tenerlo occupato è il codice del driver. Nemmeno disattivare dispositivi a caso è una diagnosi — anche se disattivare un dispositivo come prova, con una misura prima e una dopo, è un esperimento perfettamente valido. Lo stesso vale per i valori a livello di dispositivo che circolano insieme a queste liste: MSISupported cambia la modalità di interrupt di un dispositivo e, impostato male, il risultato può essere uno schermo nero, quindi w0a non lo scrive mai, e la scheda di riparazione dell'instradamento degli interrupt qui sotto lo lascia stare.

Le due impostazioni vicine che w0a tocca

Criterio degli interrupt del dispositivo: sola lettura, con una scheda di riparazione

Dove lo tiene Windows: per dispositivo, sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\<device>\<instance>\Device Parameters\Interrupt Management\Affinity Policy. DevicePolicy (DWORD) sceglie come vengono collocati gli interrupt del dispositivo; quando vale 4, «processori specificati», AssignmentSetOverride è la maschera dei processori che possono usare.

Valore predefinito di Windows: nessuno dei due valori esiste. Windows calcola allora da sé la collocazione, e Microsoft raccomanda il criterio predefinito ovunque sia applicabile.

Che cosa fa w0a: legge questi valori e non li scrive. Dall'8 ottobre 2026 l'instradamento che offriva dalla pagina Test di latenza non c'è più, per tre motivi: nessun test A/B in un gioco ha mostrato un frame guadagnato grazie a lui, Microsoft raccomanda la collocazione che calcola Windows, e una maschera sbagliata è un dispositivo che non si avvia.

Come tornare indietro: se uno strumento ha fissato gli interrupt di un dispositivo e qualcosa si è rotto — un mouse che si disconnette, un «Codice 10» in Gestione dispositivi —, la scheda Instradamento degli interrupt del dispositivo cancella i due valori da tutti i dispositivi PCI, compreso l'instradamento lasciato dalle versioni più vecchie di w0a. Chiede un riavvio solo quando ha davvero tolto qualcosa, e lascia stare MSISupported.

«Sotto carico: controllo di flusso, moderazione degli interrupt e coalescenza dei segmenti spenti» (pagina Connessione)

Che cosa scrive: 0 nella parola chiave *FlowControl dell'adattatore di rete, su ogni adattatore che la dichiara. *InterruptModeration, *RscIPv4 e *RscIPv6 vengono scritte solo sulle macchine con almeno sei core fisici, e solo sugli adattatori che si sa che funzionano sotto i 2,5 Gbit/s; su quelle macchine la casella spegne anche la coalescenza dei segmenti a livello dello stack di rete, a meno che non sia già spenta.

Perché la moderazione resta attiva sulle macchine più piccole: con moderazione e coalescenza entrambe spente, ogni pacchetto ricevuto diventa un interrupt a sé invece di uno per intervallo di moderazione, e il carico di chiamate differite finisce sul core che riceve. Spegnere la moderazione non è quindi un modo per accorciare la riga del driver di rete nel Test di latenza: secondo la descrizione di w0a stessa, quello che toglie è l'attesa di decine o centinaia di microsecondi che un pacchetto passa nell'adattatore finché non scade il timer del lotto, e quello che aggiunge è un interrupt per pacchetto. Il suo effetto sull'elenco dei driver non è stato misurato. Se la tua riga è il driver di rete, esegui il test con la casella applicata e senza.

Che cosa promette la casella stessa: microsecondi, sul ping sotto carico. Il suo messaggio dice che il ping medio non cambia.

Quando ha effetto: quando l'adattatore si riavvia; w0a chiede un riavvio ogni volta che ha scritto qualcosa.

Come tornare indietro: la scheda Offload della scheda di rete rimette gli offload hardware, la moderazione degli interrupt, Energy Efficient Ethernet, la sospensione selettiva e i buffer di ricezione ai valori predefiniti del driver stesso, come li dichiara il driver.

Controlla da te

Questi comandi si limitano a leggere. Nel prompt dei comandi o in PowerShell:

reg query "HKLM\SYSTEM\CurrentControlSet\Enum\PCI" /s /v DevicePolicy
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\PCI" /s /v AssignmentSetOverride

Una risposta che dice che la ricerca è finita senza nessuna corrispondenza (in un Windows in inglese, End of search: 0 match(es) found.) vuol dire che nessun dispositivo ha una forzatura: il valore predefinito di Windows. Una corrispondenza viene elencata sotto la chiave in cui è stata trovata, e la parte PCI di quel percorso identifica il dispositivo.

In PowerShell, per l'adattatore di rete:

Get-NetAdapterAdvancedProperty -Name "*" -RegistryKeyword "*FlowControl","*InterruptModeration","*RscIPv4","*RscIPv6" -AllProperties

Questo elenca, per ogni adattatore, l'impostazione attuale delle quattro parole chiave che la casella della pagina Connessione può scrivere. Un adattatore che non compare per una parola chiave non la dichiara, e lì la casella non scrive niente.

Poi misura di nuovo

Stesso metodo, stessi dodici secondi, stessa macchina. La pagina confronta con la tua esecuzione precedente e riporta un cambiamento sotto il 5% come nessun cambiamento invece che come un miglioramento, perché due esecuzioni su una macchina non toccata differiscono comunque di qualche punto percentuale — una mano si muove ogni volta in modo diverso.

Se la riga del driver è scesa e gli scatti no, hai imparato qualcosa di vero: la tua causa non era questa, e perché i giochi scattano su Windows 11 ha il resto della lista. Se quello che hai è un frame rate che cala e resta giù invece di uno scossone, non è mai stato questo — la lista giusta è cali di FPS improvvisi nei giochi.

Correlati

• Leggere il test di latenza
• Perché i giochi scattano su Windows 11
• Come ridurre l'input lag: cosa può accorciare un software e cosa no
• Cosa cerca la scansione degli scatti
• Perché il test chiede 12 secondi di movimento del mouse
• Tweak di rete