Thursday, March 04, 2010

Dell posts NV beta driver to resolve DPC audio interrupt

Today Dell posted the 196.86 NV Beta driver. This driver implements the change which ManuelG of NVIDIA Forums spoke of here:
The fix does not disable Powermizer. The driver was in a DPC state for too long and this was corrected. It should not have an adverse affect on performance. Tomorrow (Tuesday) we will be releasing a new driver which unfortunately does not include this fix as it did not make it in time (the fix was added shortly after this driver was built). The fix will be in drivers following this. Once I get the exact driver versions, I will update this thread. Quote Source

Given this information posted by ManuelG, we now know this was an NVIDIA issue which touched many systems and manufacturers. I for one, am glad Dell took the lead on this and cranked out this beta driver so quickly.  Makes you wonder why NV did not catch this during their driver QA process.

While John-B has not yet updated his blog post to include the driver release, I'm sure the update will follow shortly.

I want to share the following with you as there appears to be a bit of coufusion on what DPC is,

DPC (deferred procedure call) is defined by Microsoft as:
A queued call to a kernel-mode function that will usually be executed at a later time. DPCs are used by drivers to schedule I/O operations that do not have to take place in an ISR at a high IRQL, and can instead be safely postponed until the processor IRQL has been lowered.

NBR Member Stamatisx said it best when talking about DPC Latency:
Something else I wanted to mention is that you will never find a computer that is 100% free of kernel conflicts under all kind of circumstances. It is against the nature of programming. The only perfect code is the non existing code.
The only computer I found that has not kernel conflicts and latency is my pocket calculator and that's because it has no kernel or drivers.

We are the ones who define what we consider as a problem.
Microsoft set the threshold at 100μs for the kernel to resolve a conflict.
Others could set it even lower.
For me and the tasks I have to perform on this machine, latency as it is right now is not a problem since it does not affect my work any more. - Quote Source

That being said, there will always be some driver or OS component coded badly which throws a spike. Not everything plays nice with the OS, including some components of the OS. The important thing to remember... Does it impact audio or performance? If not, enjoy and who cares if it shows up as a 8k or 6k spike? I certainly do not but you can decide for yourselves.

Without further delay, you can grab the driver and view all the info HERE. Please be sure to review the IMPORTANT NOTES section of the download page for Known Issues.



Senan said...

You tried it on win7 yet man?

M said...

Yes, of course - Win7 and Vista. The beta driver released by Dell resolves the 65k+ spike observed at each level of GPU downclock. This 65k+ spike was responsible for the audio interrupt.


Senan said...

Excellent, look forward to trying it over the weekend, i see on the additional information section that it doesnt support 60hz though, isnt that the default refresh rate for the M17x's native res? =[

hazardic said...

good - will you post this on nbr? just curious about proper downclocking, idle temps and other typical problems..

M said...

Its already being discussed in the DPC Latency thread.

There is also a thread on game performance with this beta driver.


hazardic said...

oh thanks i missed it=)

Kade said...

I forgot to post here earlier, but I have to comment.

While this driver is buggy, and does inheret some of the flaws from Nvidia's newer 190 drivers, I will say that this driver does carry with it some good implications and marks a step in the right direction for Dell.

Here's to a proper WHQL release with an even better performance index.

Post a Comment