Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

DPC latency checker says

A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. ... There is one DPC queue per CPU available in the system. ... If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. ... Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.

Stack Overflow answer says:

A DPC is queued into the global DPC queue, and can be run on any processor. So if you really have a long (-running) DPC on one core, the other core is free to process another. So any timing information is really dependent on the count of processors you have and how many things get currently executed concurrently. So on multicore processors these numbers might vary widely.

Generally what I've read is that a fast dual core is better than a slower quad core for audio, since most audio apps aren't optimized to use more than one core.

But in modern computers it sounds like DPC issues are bottleneck for audio production. Does this mean a quad core processor would be better than a dual core? Other free cores could theoretically handle the audio DPCs while one is locked up by a rude Wi-Fi DPC routine. Is the queue shared between cores, and DPCs can be shuffled around to whichever one is free? Or is there one queue per core, allowing for a core to be hijacked? What about virtual cores?

share|improve this question
    
If you had both systems you could use this tool to compare and get real world data...thesycon.de/eng/latency_check.shtml –  Moab Sep 18 '10 at 22:36
add comment

1 Answer

Latency in a Deferred Procedure Call (DPC) is caused by a driver taking a long time to do its thing.

Adding more CPUs will not improve the time a poorly written driver takes to do its processing.

share|improve this answer
    
Can you back up your opinion with facts? There's a separate DPC queue for each CPU. –  endolith May 6 '11 at 4:41
    
i cannot. Kernel mode code cannot be multi-threaded. And the only time there's an issue with DPC latency is when a poorly written driver is behaving poorly. Throwing more cores at it won't make it run gooder. –  Ian Boyd Jun 15 '11 at 2:15
    
The question asked was not "will more CPUs make a bad DPC run faster?" The question is "will more CPUs let my audio driver run when a badly behaved driver is also installed in the system?" –  Colin Jensen Aug 27 '13 at 22:46
    
Then his only option is to buy the faster machine and observe for himself that things are not any better –  Ian Boyd Aug 28 '13 at 1:17
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.