Yes, there is. But it's rather complicated. The tool to use is XPERF, which is separate install file (MSI) that's part of the Windows Performance Analysis toolkit: http://msdn.microsoft.com/en-us/performance/cc825801.aspx
What makes it so complicated is that the documentation on this tool is so poorly written. You CAN figure it out, however. There's an article pending (to be published online on my company's technical portal in the next week or so) that explains a but a bit how to use XPERF. I plan to edit this for the general audience and put it on my web site for folks to read. Unfortunately, that'll take a couple of weeks. Peter K1PGV From: Joe Camilli [mailto:joen7...@gmail.com] Sent: Friday, April 16, 2010 12:44 PM To: Peter G. Viscarola Cc: Tim Ellison; Mark Ericksen; Flexradio Subject: Re: [Flexradio] Updated - My 64 Bit Windows 7 Adventure (DPCs explained... again) it there a method to track the down the offending driver or log the time each driver is taking? On Fri, Apr 16, 2010 at 10:19 AM, Peter G. Viscarola <pete...@osr.com<mailto:pete...@osr.com>> wrote: The amount of DPC activity generated by any user-mode program is directly proportional to the amount of device I/O it generates. Network access, disk access, video access. If it's not causing device I/O, an application cannot be generating or affecting DPCs in the system. <QUOTE> I do not think you fully understand what a DPC actually is because a co-processor board would not solve the DPC problem... As an example, an application requests data from a hardware device like a network card or disk drive or sends data to a hardware device, like a video card. While that hardware device is fulfilling the request, the operating system waits momentarily for the hardware to complete it's task. A poorly written hardware driver will keep the operating system in this "wait state" for a long time until the task is completed and that is the reason for long duration DPCs. </QUOTE> Your description is not correct. Not at all. People are already confused enough without having incorrect information. To correct your simplified example: As an example, an application requests data from a hardware device like a network card or disk drive or sends data to a hardware device, like a video card. While that request is in progress the only thing that waits is the user application that requested the operation (and, even at that, the wait is optional). The operating system and the driver definitely DO NOT wait. When the request is completed on the hardware, the hardware device generates an interrupt to indicate that something about its state has changed. Windows services this interrupt at VERY HIGH priority, temporarily interrupting almost anything else happening on the system at the time, and calls the Interrupt Service Routine of the driver responsible for the device. In its Interrupt Service Routine, the driver examines the hardware, determines the reason that the device interrupted, and -- if there is more work to do -- tells the operating system to call him (the driver) back at a LOWER priority level so he can finish attending to the device's needs without blocking everything else on the system. This call back is a Deferred Procedure Call (DPC). All requests for DPC callbacks are placed on a queue. Before returning to execute user applications the OS will remove one DPC request at a time and call the requesting back so the driver can complete the servicing of its hardware device. Within its DPC, the driver for the hardware device does whatever is necessary to service its device. This might mean moving data from a disk controller or a network card to a user data buffer and completing a request. But, it COULD (and most of the time WILL) mean completing SEVERAL such requests. The problem occurs when there are multiple devices, each with multiple requests, that generate interrupts within a short period of time. The DPC queue can grow long... and the amount of time that a given driver has to wait, from the time he requests his DPC callback from his ISR to when his DPC callback is actually run, depends on (a) the number of DPCs in the queue ahead of him, and (b) how much time each of those drivers spends in their DPC callbacks. A poorly written driver will spend an unacceptably long amount of time in its DPC, thus causing devices with DPC requests behind his in the queue to wait an unusually long time... thus causing "excessive DPC latency" for that waiting driver. To give you an idea of the timeframes we're talking about: The (currently) suggested maximum amount of time any driver should spend in either its ISR or DPC is 10us. In my experience, this is wishful thinking by Microsoft... there are LOTS of drivers that spend far more than 10us in their DPC callback routines -- There are Microsoft drivers that exceed this guideline and I know that I've written several drivers that routinely violate it as well. But, a well-written driver servicing a nicely designed piece of modern hardware should be able to get close to this guideline in most circumstances. Peter K1PGV _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz<mailto:FlexRadio@flex-radio.biz> http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/ _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kc.flex-radio.com/ Homepage: http://www.flex-radio.com/
