<QUOTE>
In addition to hardware device drivers, applications too can generate
long DPCs. MS Outlook and
Media Player are VERY BAD about doing this adding sometimes up to 300 ms
(1/3 of a second) of latency, which, for an almost real-time application
such as PowerSDR, is an eternity.
</QUOTE>
With all due respect: Applications can not generate DPCs.
DPCs (Deferred Procedure Calls) are a Windows kernel construct. There
is no way for a non-kernel entity, such as an application program, to
build a DPC object or cause a DPC object to be inserted into a given
processor's DPC list.
DPC latency is only influenced by the time the operating system spends
at IRQLs ("Interrupt Request Levels") >= IRQL DISPATCH_LEVEL. There are
relatively few things that actually execute in Windows at these elevated
IRQLs. Device interrupt service routines and DpcForIsr's are two.
Other DPCs (such as kernel timer callbacks) are another. The time a
kernel-mode module spends holding a spin lock is yet one more. None of
these things can happen in user-mode.
Now, it is true that applications can engage in certain behaviors (like
very frequent system calls, or increasing the timer frequency) that can
result in some kernel-mode entity (like the OS itself or a driver)
spending more time at elevated IRQL, and therefore increase ISR to DPC
latency.
I'll be happy to discuss this issue further with you (or anyone else)
off-list if you like. No sense cluttering up the list with arcana of
Windows internals.
de Peter K1PGV
>-----Original Message-----
>From: Tim Ellison [mailto:[EMAIL PROTECTED]
>Sent: Monday, August 06, 2007 3:51 PM
>To: Peter G. Viscarola; FlexRadio@flex-radio.biz
>Subject: RE: [Flexradio] Fw: Helpful software
>
>As FLEX-5000 beta testers, we used this tool to identify potential
>problems with the Firewire device driver and in the process got to
>understand how DPC latencies adversely effected performance.
>
>In addition to hardware device drivers, applications too can generate
>long DPCs. MS Outlook and Media Player are VERY BAD about doing this
>adding sometimes up to 300 ms (1/3 of a second) of latency, which, for
>an almost real-time application such as PowerSDR, is an eternity.
>
>If you have DPC latencies in the 250 to 300 ms range when not running
>PowerSDR, you will need to try to find the culprit, if there is one to
>be identified. Sometimes it can be solved easily by upgrading a
>hardware driver. Other time it takes actually upgrading the hardware
>(video cards, for one).
>
>I have a fairly fast laptop, but the average DPC latency is 260 ms with
>spikes up to 350 ms and it is essentially useless for running PowerSDR
>above a 48K sampling rate. I have updated all of the drivers and tried
>to find a "silver bullet" application or service that is running that
>causes the long DPC latencies, but I can not find it. Conversely, my
>Core2 Duo has an average DPC latency of 35 uS (microseconds) and it is
a
>screamer running PowerSDR...as long as I do not run Outlook and/or
Media
>Player, which when very small buffers are used running at a 192 KHz
>sampling rate, will result in audio drop outs
>
>This is just one tool that will give you some insight into how well you
>system is performing or is prepared to perform.
>
>
>-Tim
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Peter G.
>Viscarola
>Sent: Monday, August 06, 2007 3:21 PM
>To: FlexRadio@flex-radio.biz
>Subject: Re: [Flexradio] Fw: Helpful software
>
>>
>>Flexers might find the DPC Latency checker of use. You can download it
>>free at the Thesycon site under "Free Utilities"
>>
>
>EXCELLENT suggestion, Mike, thanks!
>
>I know Udo Eberhardt (who runs the company that wrote this tool), and I
>wasn't even aware of this utility. So, thanks very much!
>
>Interpreting the results can be tricky, even if you're a Windows driver
>developer. Keep in mind the tool reports ISR to DPC latency... not
>device interrupt request to ISR latency. ISR to DPC latency is best
>thought of as the time it takes from a device's interrupt being
serviced
>to when that device is able to start returning data to an application.
>This is typically the type of latency that really matters to device in
a
>Windows system.
>
>Note that the AVERAGE ISR to DPC latency is almost never a problem.
>Rather, what you're looking for is the repeated occurrence of
>"outliers"... worst-case ISR to DPC latency.
>
>The bad part of all this is if you experience packet loss as a result
of
>excessive worst-case (or even average) ISR to DPC latency, there's
often
>little you can do about it. You're mostly restricted to changing the
>devices involved... and it's rarely the device you're concerned about
>that's the problem. I knew of an infamous network card that created
>well over 1ms of ISR to DPC latency (for other drivers in the system)
>each time it periodically checked the speed of the network to which it
>was connected. Devices that were "backed up" behind this NIC often
>suffered from overruns and dropped data. Swap the NIC, and problems
>with those other devices disappeared.
>
>The worst offenders, in terms of causing excessive ISR to DPC latency
>for other system devices, are typically video and network cards.
>
>Thanks again, Mike, for making us all aware of this tool,
>
>de Peter K1PGV
>
>
>_______________________________________________
>FlexRadio mailing list
>FlexRadio@flex-radio.biz
>http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
>Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
>FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage:
>http://www.flex-radio.com/
_______________________________________________
FlexRadio mailing list
FlexRadio@flex-radio.biz
http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/
FlexRadio Knowledge Base: http://kb.flex-radio.com/
FlexRadio Homepage: http://www.flex-radio.com/
