High DPC Latency Does Not Mean a Slow VPN Path

An audio glitch and a VPN pause land in the same ten seconds, and a utility reports a high figure labelled DPC latency. The temptation is to conclude that the driver is slowing the tunnel, or that the tunnel is stressing the driver. Neither conclusion follows from that number.

Three measurements are in play here, and they do not share a boundary.

Three Numbers, Three Boundaries

A deferred procedure call is work a driver postpones from its interrupt handler, and the time spent inside those routines is a processor-local measurement attributed to modules and functions. An echo round trip is a timing observation at the socket, produced by a network stack and a remote responder. A disconnect event is a state transition recorded by the client. Each answers a question the others cannot, and matching units do not make them interchangeable.

The useful discipline is to name the boundary before reading the value. Write the unit and the boundary next to each other. If a tool reports milliseconds, ask milliseconds of what: time inside a routine, time waiting to run, or time until a reply arrived.

A high number in one category is a lead, never a diagnosis.

Read the Definition Behind the Headline

Utilities differ in what they call latency. Some report the duration of driver routines, others report scheduling delay, and the two quantities can move in opposite directions on the same machine. A dashboard that labels one of them simply DPC latency has told you less than it appears to. Two dashboards can therefore disagree about a machine that has not changed at all.

The same caution applies inside a single analysis tool. Inclusive duration follows a routine from entry to exit, while exclusive duration totals only the fragments where that routine itself was executing. Choosing the wrong column turns a caller into a culprit.

Local driver work and network delay also interact without merging. Excessive interrupt-related activity can delay time-sensitive work on the machine, and a congested path can delay packets, and both can be true during one visible pause.

Put Every Observation in One Window

A trace is only useful if you read the interval that contains the symptom. Record the trace, the client's event and the application's failure with timestamps, then look at the same seconds in all three. A maximum from an hour-long trace and a disconnect later that afternoon are two unrelated facts.

wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt

Then open the trace in the analysis tool and sort by duration within that window, rather than by the whole capture. The CPU analysis guidance describes the DPC/ISR duration view that attributes time to modules and functions.

Confirm what actually happened to the tunnel while you are there. Losing application traffic briefly does not mean the client started a new negotiation, and a successful small probe does not prove that everything else kept working.

Change the Component the Evidence Names

A busy module is a place to investigate, not a verdict. It may be doing work caused by another component, or by the workload you generated. Keep the module name, the device, the driver version and the observed interval together, because that set is what a vendor can act on.

One change per experiment is the only way to learn from the result. A wired comparison narrows the scope, but it changes the radio path and the driver activity at the same time, so treat it as a clue rather than as proof.

Treat the trace as sensitive. It can contain process names and environment details, so it belongs in the supported capture channel rather than in a public attachment. Say which observation the trace was meant to answer.