DPC latency, explained in 3 minutes
What Deferred Procedure Calls are, why they can cause audio crackle and input hitches, and what a DPC number does, and does not, tell you.
The 3-minute version
When a device needs the CPU’s attention, it raises an interrupt. The driver’s interrupt service
routine (ISR) runs first, at the device’s interrupt level, and is expected to do only the
minimum. The rest of the work is queued as a DPC (Deferred Procedure Call) and runs shortly
afterwards at DISPATCH_LEVEL.
DISPATCH_LEVEL sits above normal thread scheduling: while a DPC runs on a core, no ordinary
thread can run on that core, whatever its priority. Microsoft’s driver guidelines therefore say a
typical DPC routine should run for no more than 100 microseconds each time it is called.
If a driver’s DPCs (or ISRs) run too long or too often, time-sensitive threads wait: audio buffers, input processing, frame submission. That is why the symptoms of bad DPC behaviour are audio crackle, mouse hitches and short stutters that an average-FPS figure does not show.
What the numbers mean
DPC/ISR measurements report how long these routines occupy a core, and which driver they belong to:
- A healthy system has short routines, with occasional longer ones that are too rare to disturb real-time work.
- A problem usually looks like one specific driver (often network, storage, audio or GPU) repeatedly holding a core long enough to starve time-sensitive work.
Two things a DPC number is not:
- Not an FPS predictor. A system can show clean DPC behaviour and still be GPU-bound at 45 fps, or show DPC spikes and still benchmark well on averages.
- Not a score to minimise for its own sake. Chasing the lowest possible reading has no audible or visible effect by itself. What matters is whether long routines happen often enough, and at the wrong moments, to disrupt real-time workloads.
How it is treated in the Alchemy protocol
The responsiveness measurement in the benchmark suite is an advisory metric: useful context and a pointer for diagnosis, but it never drives a verdict on its own. When DPC/ISR behaviour is the suspected cause, it is examined with an ETW trace (Windows Performance Recorder / Windows Performance Analyzer), which attributes the time to a specific driver instead of a single number.
When to suspect DPC problems
- Audio crackle or dropouts that coincide with network or disk activity
- Input that feels momentarily “stuck” while the system is otherwise idle
- Stutter that persists across GPU driver reinstalls and in-game settings changes
If that sounds familiar, a System Check is the diagnosis-first way in: the system is measured, a likely offending driver is identified if there is one, and the Baseline Report tells you what is going on before anything is changed.
References
- Microsoft Learn: Introduction to DPC objects
- Microsoft Learn: Guidelines for writing DPC routines
- Microsoft Learn: Managing hardware priorities (IRQL)
- Microsoft Learn: Windows Performance Toolkit (WPR / WPA)